Поиск по сайту:

Программно определяемые сети (SDN) — архитектура и роль OpenFlow

В нашей предыдущей статье у нас был хороший обзор SDN как технологии, зачем она нужна и как ее внедряют в ИТ-отрасли. Теперь давайте углубимся в уровень и поймем архитектуру SDN и роль протокола Openflow в реализации технологии.

SDN в целом состоит из трех уровней:

  1. Прикладной уровень
  2. Слой управления
  3. Уровень инфраструктуры

Давайте попробуем понять эти слои в восходящем подходе.

Уровень инфраструктуры состоит из различного сетевого оборудования, которое образует базовую сеть для пересылки сетевого трафика. Это может быть набор сетевых коммутаторов и маршрутизаторов в центре обработки данных. Этот уровень будет физическим, на котором виртуализация сети будет осуществляться через уровень управления (где будут находиться контроллеры SDN и управлять базовой физической сетью).

Уровень управления – это уровень управления, в котором интеллектуальная логика контроллеров SDN будет находиться для управления сетевой инфраструктурой. Это та область, в которой каждый сетевой поставщик работает над созданием собственных продуктов для контроллера и инфраструктуры SDN. Здесь, на этом уровне, в контроллере записывается много бизнес-логики для получения и поддержки различных типов сетевой информации, сведений о состоянии, сведений о топологии, сведений о статистике и многого другого.

Поскольку контроллер SDN предназначен для управления сетями, он должен иметь логику управления для реальных сценариев использования сети, таких как коммутация, маршрутизация, L2 VPN, L3 VPN, правила безопасности брандмауэра, DNS, DHCP и кластеризация. Несколько поставщиков сетевых услуг и даже сообщества с открытым исходным кодом работают над реализацией этих вариантов использования в своих контроллерах SDN. После внедрения эти сервисы предоставляют свои API-интерфейсы (обычно основанные на REST) верхнему уровню (уровню приложений), что упрощает жизнь сетевым администраторам, которые затем используют приложения поверх контроллеров SDN для настройки, управления и мониторинга базовой сети. Уровень управления находится посередине и предоставляет два типа интерфейсов — северный и южный.

  • Северный интерфейс: предназначен для связи с верхним прикладным уровнем и обычно реализуется через REST API контроллеров SDN. Sисходящий интерфейс: предназначен для связи с нижними, инфраструктурными уровнями сетевых элементов и обычно реализуется через южные протоколы – Openflow, Netconf, Ovsdb и т. д.

Прикладной уровень  — это открытая область для разработки как можно большего количества инновационных приложений с использованием всей сетевой информации о топологии сети, состоянии сети, статистике сети и т. д. Может быть несколько типов приложений, которые можно разрабатывать, например те, которые связаны с сетевой автоматизацией, сетевой настройкой и управлением, сетевым мониторингом, устранением неполадок в сети, сетевыми политиками и безопасностью. Такие приложения SDN могут предоставлять различные комплексные решения для реальных корпоративных сетей и сетей центров обработки данных. Сетевые поставщики предлагают свой набор приложений SDN. Например, в Brocade есть следующие очень полезные приложения:

  • Оптимизатор потока Brocade

  • Виртуальный маршрутизатор Brocade

  • Консультант по сети Brocade

HPE также является одним из поставщиков, у которого есть магазин приложений SDN, в котором также есть множество приложений SDN от разных компаний. Например:

  • Оптимизатор сети HPE

  • Защита сети HPE

  • Визуализатор сети HPE

  • NEC UNC для контроллера HP SDN VAN

  • Балансировщик нагрузки Aricent SDN

  • Умное управление потоком TechM

  • Балансировщик нагрузки сервера TechM

Поскольку мы кратко коснулись Openflow в предыдущей статье, теперь мы рассмотрим детали южного взаимодействия от уровня управления к уровню инфраструктуры (сетевые коммутаторы) через протокол Openflow.

Openflow сыграл важную роль в революции SDN в том смысле, что он стал ключом к демонстрации разделения плоскости управления и плоскости данных. Openflow – это стандартная спецификация, предоставляемая Open Networking Foundation (ONF), которая со временем развивается, поддерживая различные требования современных мировых сетей. Текущая версия протокола Openflow – 1.5.1.

Openflow — это протокол, который дает стандартную спецификацию для связи между контроллером SDN и сетевым оборудованием (обычно коммутаторами). Это позволяет контроллерам SDN принимать решения о маршрутизации и разрешать правила переадресации и правила безопасности, передаваемые на коммутаторы в базовой сети.

Контроллер SDN и коммутаторы должны реализовать спецификации Openflow, чтобы они могли понимать общий язык сообщений Openflow. Чтобы управлять сетевыми коммутаторами, контроллер SDN передает правила в коммутаторы, чтобы они могли принимать решения, когда на них попадает сетевой трафик. Коммутаторы должны поддерживать такие правила в таблице Openflow. Согласно Openflow, такие правила называются «потоками» и хранятся в «таблицах потоков».

В широком смысле потоки несут три типа информации:

  1. Поля сопоставления: они будут определять критерии для сопоставления пакетов на основе полей их заголовков — L2 (адреса исходного и конечного Ethernet, идентификатор VLAN, приоритет VLAN и т. д.), L3 (IPv4/IPv6 источник адрес, тип протокола, DSCP и т. д.), поля L4 (порт назначения TCP/UDP/SCTP), поля ARP, поля ICMP, поля MPLS и т. д.
  2. Действия: определяют, что делать с пакетом, если он соответствует критериям. Действия могут быть такими, как удаление, пересылка на какой-либо порт коммутатора, изменение пакета (отправка/извлечение идентификатора VLAN, отправка/извлечение метки MPLS, увеличение/уменьшение IP TTL), пересылка в определенную очередь порта и т. д.
  3. Счетчики: для отслеживания количества пакетов, соответствующих потоку.

Чтобы быть точным, потоки содержат дополнительную информацию, которую можно проверить далее в спецификациях Openflow.

Канал или соединение Openflow — это настройка между коммутатором и контроллером, чтобы контроллер мог взаимодействовать с коммутатором для его настройки, управления и мониторинга. Согласно спецификации Openflow, Openflow работает на TCP- или TLS-подключении, а контроллер прослушивает подключение через порт 6653. Ожидается, что коммутатор инициирует подключение и должен отправить запрос на подключение на контроллер.

При желании соединение также может быть инициировано со стороны контроллера, и в этом случае коммутатор будет находиться в пассивном режиме для ожидания соединения. Будь то с любой стороны, это будет обычная настройка соединения TCP или TLS, после того как оно установлено, сообщения Openflow обмениваются через соединение TCP или TLS. Например, ниже приведена команда виртуального коммутатора Openflow с открытым исходным кодом (OpenVswitch) для инициирования TCP-соединения с контроллером:

ovs-vsctl set-controller <sampleBridgeName> tcp:192.168.56.101:6653

Здесь 192.168.56.101 — это IP-адрес контроллера, а 6653 — это порт контроллера, на котором он будет ожидать подключения.

Openflow определяет различные сообщения для обеспечения связи между коммутатором и контроллером, включая сообщения о настройке соединения, сообщения о конфигурации, сообщения о получении статистики коммутатора, сообщения проверки активности, сообщения об асинхронных событиях, сообщения об ошибках, сообщения экспериментатора и многое другое.

Давайте кратко разберемся с сообщениями Openflow:

  • После установления TCP-подключения оба объекта обмениваются сообщением Openflow HELLO для согласования версии Openflow, в которой будет осуществляться дальнейшая связь. Это необходимо, поскольку возможно, что коммутатор и контроллер работают на разных версиях Openflow. Оба согласятся на максимальную поддерживаемую версию.
  • После согласования версии контроллер сначала отправляет сообщение с запросом функции Openflow, чтобы в основном получить идентификатор пути данных переключателя в ответном сообщении и определить, какие функции поддерживает коммутатор.
  • Чтобы настроить коммутатор для обработки сетевого трафика, с контроллера можно отправлять сообщения Openflow, например записи потока. Они поддерживаются в таблицах потоков внутри коммутаторов.
  • Чтобы сгруппировать записи потока, группы могут быть настроены контроллером с помощью групповых сообщений, которые могут храниться в групповых таблицах внутри коммутаторов.
  • Чтобы получить подробную статистику от коммутатора, с контроллера можно отправлять сообщения Openflow, такие как статистика потока, статистика порта, статистика очереди, статистика группы, статистика таблицы и т. д.
  • Чтобы проверить работоспособность соединения, эхо-запрос и ответные сообщения Openflow могут быть отправлены либо с контроллера, либо с коммутатора.
  • Асинхронные сообщения Openflow, такие как удаление правила потока с коммутатора, ошибка применения конфигурации с коммутатора, статус включения/выключения порта с коммутатора и т. д., могут отправляться с коммутатора на контроллер обновления.

До сих пор мы рассмотрели архитектуру SDN, ее уровни и роль Openflow, чтобы реализовать основной принцип SDN, чтобы отделить плоскость управления от плоскости данных. Теперь нам нужно посмотреть, как контроллер сможет использовать Openflow для настройки и управления базовой сетью.

По сути, контроллеру необходимо реализовать некоторый код плагина Openflow, с помощью которого он может отправлять, получать и понимать сообщения Openflow на коммутаторы Openflow и обратно в базовой сети.

Чтобы настроить коммутаторы Openflow, контроллеру необходимо передать правила потока в таблицы коммутаторов Openflow, на основе которых последние могут обрабатывать поступающий на них сетевой трафик. Сообщение Openflow для записей потока имеет большой набор полей кортежа для соответствия критериям (поля L2, L3, L4 и т. д.) пакетов, поступающих из сети, что в целом может помочь в настройке правил ACL, правил политики безопасности, правил ограничения пропускной способности скорости QoS, правила маршрутизации, правила зеркального отображения портов и правила модификации пакетов.

Для мониторинга коммутаторов Openflow Openflow предоставляет различные сообщения запросов и ответов для получения информации о коммутаторе и сетевой статистике, а также сообщения о событиях для обновления контроллера о ручных изменениях или сбоях, произошедших на стороне коммутатора, включая событие удаления потока, изменения статуса порта UP/DOWN и многое другое.

Для выполнения некоторых конкретных задач поставщика на коммутаторах Openflow Openflow предоставляет экспериментальные сообщения, в которых поставщики могут свободно определять тело сообщения и обмениваться пользовательской информацией между контроллером и коммутаторами. Вот как Openflow используется многими приложениями SDN для предоставления решений для простого контроля и управления сетью.

This article is co-authored by Tarun Thakur.

Использованная литература:

  • https://www.sdxcentral.com/sdn/definitions/inside-sdn-architecture/
  • https://www.opennetworking.org/images/stories/downloads/sdn-resources/technical-reports/TR_SDN_ARCH_1.0_06062014.pdf
  • http://noviflow.com/the-basics-of-sdn-and-the-openflow-network-architecture/