SDN: как работают программно-определяемые сети

Программно-определяемые сети, или SDN, меняют сам принцип управления сетевой инфраструктурой. Вместо настройки каждого коммутатора и маршрутизатора по отдельности администратор может задавать правила централизованно — через программный контроллер, API и средства автоматизации. При этом физические устройства продолжают передавать трафик, но логика принятия решений переносится на отдельный уровень.

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

Содержание:

• Что такое SDN и чем программно-определяемая сеть отличается от классической
• Архитектура SDN и принцип работы
  • Прикладной уровень
  • Уровень управления
  • Инфраструктурный уровень
  • Как проходит пакет в SDN
  • Модели SDN
• SDN-контроллеры
• Преимущества и недостатки SDN
• Где применяется SDN и что такое SD-WAN
  • Дата-центры
  • Микросегментация
  • Облачные платформы
  • Операторские сети
  • Корпоративные сети
  • SD-WAN
• Что такое NFV и как оно связано с SDN
• Как внедрить SDN
• Перспективы SDN
• Частые вопросы

Что такое SDN и чем программно-определяемая сеть отличается от классической

SDN, или Software-Defined Networking, — подход к построению сети, при котором функции управления логически отделяются от непосредственной передачи пользовательского трафика. В русскоязычных источниках встречаются два перевода: программно-определяемые и программно-конфигурируемые сети. В 2013 году для них ввели аббревиатуру ПКС, но на практике чаще используют английское SDN.

В спецификациях уровень передачи называют forwarding plane или data plane — это синонимы. 

Чтобы понять разницу, рассмотрим обычный маршрутизатор. В традиционной сети одно и то же устройство одновременно выполняет несколько задач:

• принимает информацию о состоянии сети;
• строит таблицу маршрутизации;
• решает, по какому пути отправлять пакеты;
• непосредственно передает их через интерфейсы;
• применяет локальные политики и списки доступа.

То есть внутри устройства находятся и control plane — плоскость управления, и data plane — плоскость передачи данных.

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

В результате вместо набора автономно настроенных узлов появляется программно управляемая инфраструктура с общей логикой.

Контроллер централизован логически: физически это может быть кластер из нескольких узлов.

Главная особенность SDN — программное управление сетевым поведением через централизованный уровень. Конкретный протокол и модель коммутатора при этом вторичны.

Параметр	Классическая сеть	SDN
Где находится control plane	Внутри каждого устройства	На отдельном уровне управления
Как вносятся изменения	Вручную через CLI на каждом устройстве	Централизованно через контроллер и API
Изменение политики на 50 устройствах	50 операций	Одна операция
Представление о сети	У каждого устройства своё	Общее у контроллера
Единая точка отказа	Нет	Контроллер, если не зарезервирован
Требования к инженеру	CLI, сетевые протоколы	CLI, протоколы, API, Linux, автоматизация
Цена ошибки	Ограничена одним устройством	Распространяется на все устройства сразу

Архитектура SDN и принцип работы

Классическую SDN-архитектуру удобно представить в виде трех уровней:

1. прикладного;
2. уровня управления;
3. инфраструктурного.

В спецификациях SDN эти части также описываются как Application Plane, Controller Plane и Data Plane.

Прикладной уровень

Правила для сети задают приложения: 

• политик безопасности и сегментации;
• балансировки нагрузки;
• контроля качества обслуживания (QoS);
• построения и пересчета маршрутов;
• управления виртуальными сетями.

Отдельно стоят смежные системы: мониторинг поставляет им данные о состоянии сети, а оркестратор дата-центра вызывает их при развертывании сервисов. 

Например, приложение может сформулировать правило: трафик голосовой связи необходимо направлять по каналу с минимальной задержкой, а резервное копирование — по менее дорогому каналу.

Самому приложению необязательно знать команды конкретных моделей маршрутизаторов. Оно передает свое требование контроллеру через программный интерфейс.

Интерфейсы между приложениями и контроллером традиционно называют northbound API, или северными интерфейсами.

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

Уровень управления

В центре архитектуры находится SDN-контроллер.

Он получает информацию о сетевой инфраструктуре и формирует абстрактное представление о ней: какие устройства существуют, как они соединены, какие пути доступны и какие политики должны применяться.

Контроллер:

• собирает данные о топологии;
• отслеживает состояние узлов;
• рассчитывает маршруты;
• создает правила передачи трафика;
• применяет политики безопасности;
• управляет виртуальными сетями;
• предоставляет API внешним приложениям.

Поэтому контроллер часто называют «мозгом» программно-определяемой сети.

Предположим, между двумя дата-центрами существует три пути. Один канал перегружен, второй работает нормально, а третий предназначен для резервирования. Система мониторинга передает сведения контроллеру, а тот может изменить политику и направить часть потоков по другому маршруту.

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

Инфраструктурный уровень

Нижний уровень состоит из физических и виртуальных сетевых устройств:

• аппаратные коммутаторы и маршрутизаторы;
• их программные аналоги: виртуальные коммутаторы в гипервизорах, маршрутизаторы на серверах общего назначения;
• шлюзы на границе сегментов.

Все эти устройства образуют data plane. 

В виртуализованной инфраструктуре нижний уровень начинается внутри гипервизора: виртуальный коммутатор на узле обрабатывает трафик между виртуальными машинами и физической сетью и получает правила от контроллера так же, как аппаратный коммутатор. 

В платформах виртуализации нижний уровень строится на Open vSwitch — программном коммутаторе, который работает на каждом узле кластера. Поверх него работает контроллер: он хранит описание логической топологии — какие сети, подсети и маршрутизаторы существуют и как они связаны — и транслирует ее в правила OpenFlow для коммутаторов на всех узлах. Администратор работает с логическими объектами в интерфейсе, настройки каждого узла платформа формирует сама. 

Контроллер передает устройствам необходимые инструкции через так называемые southbound interfaces — южные интерфейсы.

Одним из наиболее известных протоколов этого уровня стал OpenFlow. Он задает формат обмена между контроллером и коммутатором: контроллер записывает в таблицу потоков коммутатора записи вида «признаки пакета — действие», а коммутатор сообщает о пакетах, для которых записи нет. 

Спецификация OpenFlow остановилась на версии 1.5.1, и производители все чаще реализуют вместо нее P4Runtime, gNMI и собственные API. OpenFlow сегодня важен как исторический стандарт и как интерфейс части установленного оборудования, а не как обязательный элемент SDN. 

Кроме OpenFlow, контроллеры используют NETCONF, gRPC и вендорские API — OpenDaylight, например, работает сразу с несколькими southbound-механизмами.

Как проходит пакет в SDN

Рассмотрим упрощенный пример.

Пользователь отправляет данные серверу.

1. Пакет приходит на коммутатор.
2. Коммутатор сравнивает поля заголовка пакета — MAC- и IP-адреса, порты, метки VLAN — с записями своей таблицы потоков. 
3. При совпадении коммутатор выполняет действие из записи: отправить в порт, изменить заголовок, отбросить.
4. Если совпадения нет, коммутатор передает пакет или его заголовок контроллеру. 
5. Контроллер выбирает действие с учетом топологии и политик и записывает в таблицу коммутатора новую запись с таймаутом жизни. 
6. Остальные пакеты того же потока коммутатор обрабатывает сам, без обращения к контроллеру. 

Поэтому утверждение, что каждый пакет в SDN обязательно проходит через центральный контроллер, неверно. Контроллер управляет правилами и состоянием сети, а фактическая передача трафика выполняется специализированным оборудованием.

Когда правила попадают в таблицу

Описанный выше порядок называют реактивным: записи появляются по мере того, как приходят новые потоки. Первый пакет потока ждет решения контроллера, остальные идут по готовому правилу.

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

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

Именно это разделение позволяет одновременно сохранить высокую скорость forwarding и получить программируемое управление.

Модели SDN

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

Открытая модель. Контроллер управляет коммутаторами по открытому протоколу — чаще всего OpenFlow. Оборудование разных производителей работает под одним контроллером, если поддерживает протокол. Это исходный вариант концепции SDN, и требования к оборудованию у него самые жесткие.

Управление через API. Вместо открытого протокола контроллер обращается к программным интерфейсам конкретных устройств: REST API производителя, NETCONF, gNMI. Модель работает с оборудованием, которое не поддерживает OpenFlow, но привязывает автоматизацию к интерфейсам каждого вендора.

Overlay-модель. Виртуальная сеть строится поверх существующей физической инкапсуляцией трафика в туннели. Физическая сеть передает эти туннели и остается без изменений — настройки коммутаторов трогать не нужно. По этой модели работают платформы виртуализации и облачные инфраструктуры: логическую топологию перестраивают программно, аппаратная часть об этом не знает.

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

Выбор модели определяет масштаб проекта. Открытая модель требует совместимого оборудования и часто его замены. Overlay и гибридная работают поверх того, что уже есть, — поэтому их чаще и выбирают при переходе.

SDN-контроллеры

Контроллер объединяет данные об инфраструктуре и предоставляет программный слой для управления сетью. Контроллеры различаются по назначению: одни ориентированы на дата-центры, другие на операторские IP/MPLS-сети, третьи поставляются только в составе решения одного производителя.

Открытые SDN-платформы: OpenDaylight и ONOS. OpenDaylight позиционируется как open source-платформа для централизованного программного контроля и мониторинга устройств с использованием открытых протоколов.

Например, SDN-контроллер анализирует топологию IP/MPLS и рассчитывает туннели с учетом заданных ограничений по задержке, полосе и запрещенным участкам сети.

В производственной инфраструктуре особое внимание уделяется отказоустойчивости контроллера. Если управление критично для всей сети, его сервисы нельзя оставлять на одном сервере без резервирования.

Узлы кластера синхронизируют общее представление о сети между собой — этот обмен называют east-west-интерфейсом. Коммутатор при этом держит соединения с несколькими узлами сразу: если ведущий узел отказал, роль принимает следующий, и правила в таблицах остаются на месте.

Преимущества и недостатки SDN

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

Преимущества:

1. Централизованное управление. Администратор получает общее представление об инфраструктуре и может задавать политики сразу для большого числа устройств.
2. Автоматизация. Изменения можно выполнять программно через API. Например, при запуске нового приложения автоматически создать необходимый сегмент сети и применить правила доступа.
3. Быстрое масштабирование. Добавление десятков узлов не требует вручную повторять одинаковую конфигурацию на каждом из них.
4. Единообразие настроек. Централизованные политики уменьшают риск ситуации, когда два похожих коммутатора настроены по-разному из-за человеческой ошибки.
5. Программируемость. Сеть становится частью общей ИТ-автоматизации. Ее можно связывать с облачной платформой, оркестратором, системой мониторинга или Infrastructure as Code.
6. Управление трафиком по общей топологии. Контроллер способен учитывать общую топологию и применять централизованные политики маршрутизации.

Недостатки:

1. Сложность внедрения. Для сети из нескольких десятков устройств с редкими изменениями переход к SDN обойдется дороже, чем может сэкономить.
2. Новые требования к компетенциям. Одного CLI маршрутизатора инженеру больше не хватает. Нужны API, Linux, модели данных YANG и инструменты автоматизации. 
3. Зависимость от контроллера. Логически централизованный control plane превращается в критический компонент, поэтому его резервируют и защищают в первую очередь.
4. Совместимость. Не все существующие устройства поддерживают одинаковые интерфейсы программного управления. В гетерогенной инфраструктуре возможности автоматизации могут различаться.
5. Цена ошибки. Некорректная централизованная политика способна одновременно повлиять на большое количество устройств. Поэтому особенно важны тестирование, контроль изменений и возможность быстрого отката.

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

Где применяется SDN и что такое SD-WAN

SDN особенно полезен там, где инфраструктура часто меняется или имеет большой масштаб.

Дата-центры

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

SDN позволяет связать создание вычислительных ресурсов с настройкой сетевой части.

Например:

1. оркестратор запускает новую группу виртуальных машин;
2. автоматически создается виртуальная сеть;
3. к ней применяются политики безопасности;
4. на нужных узлах появляется необходимая конфигурация;
5. после удаления сервиса временные ресурсы сети также удаляются.

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

Микросегментация 

В классической схеме сеть делят на сегменты по VLAN, и внутри сегмента виртуальные машины видят друг друга без ограничений. Если злоумышленник получил контроль над одной машиной, он доходит до остальных машин сегмента без препятствий.

Микросегментация переносит фильтрацию на уровень отдельной виртуальной машины и ее сетевого интерфейса. Администратор задает политику фильтрации и описывает в ней правила: какой трафик разрешен, какой блокируется. Политика применяется к виртуальной сети или к конкретной машине, а контроллер транслирует правила в инструкции OpenFlow для виртуальных коммутаторов на узлах.

Изоляция работает и внутри одного физического сервера: трафик между двумя машинами на одном узле проходит через виртуальный коммутатор и попадает под те же правила.

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

Облачные платформы

В публичном или частном облаке множество клиентов используют одну физическую инфраструктуру, но должны иметь логически изолированные сети.

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

Операторские сети

Операторы используют идеи SDN для автоматизации транспортных сетей, управления трафиком, расчета маршрутов и предоставления услуг.

Централизованный контроллер видит загрузку всех каналов сразу и выбирает путь по загрузке и требованиям конкретного сервиса. Обычная таблица маршрутизации такие данные не учитывает.

Корпоративные сети

В крупных компаниях SDN помогает унифицировать политики между кампусами, филиалами, ЦОД и облачной инфраструктурой.

Особенно заметно программно-определяемый подход проявляется в SD-WAN.

SD-WAN

SD-WAN — применение принципов программно-определяемого управления к распределенным WAN-сетям.

Компания может использовать сразу несколько каналов:

• каналы MPLS от оператора;
• широкополосный интернет;
• мобильный доступ LTE/5G.

Поверх этих каналов SD-WAN строит overlay — шифрованные туннели между площадками. Физические каналы становятся underlay: они переносят туннели, но не знают о политиках, по которым распределяется трафик.

MEF описывает SD-WAN как ориентированный на приложения и управляемый политиками программно-определяемый overlay, работающий поверх различных транспортных соединений.

Например, видеоконференцию можно направлять по пути с минимальной задержкой, критичный корпоративный трафик — по наиболее стабильному каналу, а фоновое резервное копирование — по более дешевому интернет-соединению.

Централизованная политика при этом распространяется сразу на множество филиалов. В современных SD-WAN-архитектурах контроллеры могут централизованно управлять control plane, маршрутизацией и политиками overlay-сети.

Что такое NFV и как оно связано с SDN

NFV, или Network Functions Virtualisation, — виртуализация сетевых функций.

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

В программном виде могут работать:

• маршрутизаторы;
• межсетевые экраны;
• балансировщики;
• VPN-шлюзы;
• другие сетевые сервисы.

ETSI развивает архитектуру NFV как отдельное направление виртуализации сетевых функций и управления ими.

SDN и NFV могут использоваться вместе. Например, виртуальный firewall создается как программный сетевой сервис, а SDN-контроллер направляет через него необходимые потоки.

При этом понятия не являются синонимами: SDN работает без NFV, а виртуализированная сетевая функция без классической SDN-архитектуры.

Как внедрить SDN

Переход к программно-определяемой инфраструктуре начинают с конкретной задачи. Выбор контроллера идет следом.

Для российских компаний к техническим критериям добавляется регуляторный. Решения VMware, Cisco и других западных вендоров после ухода с рынка в 2022 году не поставляются и не поддерживаются официально, а для объектов КИИ и систем, обрабатывающих персональные данные по 152-ФЗ, требуется ПО из реестра Минцифры и сертификация ФСТЭК. Поэтому аудит инфраструктуры начинают с вопроса, какие компоненты придется заменить по регуляторным причинам, даже если технически они работоспособны.

Основные этапы выглядят так:

1. Определить проблему. Например, слишком долго создаются сетевые сегменты или трудно поддерживать единые политики между филиалами.
2. Провести аудит инфраструктуры. Для каждой модели оборудования необходимо выяснить три вещи: поддерживает ли она программный интерфейс управления (OpenFlow, NETCONF, gNMI, вендорский REST), до какой версии ПО ее можно обновить и остается ли она на поддержке. Оборудование, не проходящее по всем трем пунктам, попадает в список на замену — это основная статья бюджета проекта. 
3. Выбрать архитектуру. Решить, какие функции переходят под централизованное управление и какие остаются традиционными. На практике это выбор между overlay-моделью поверх существующей сети и переходом по сегментам в гибридной схеме.
4. Определить контроллер и интерфейсы. Важно проверить поддержку существующего оборудования и нужных систем автоматизации.
5. Создать тестовый контур. Минимум один сегмент из 5–10 устройств, где живет непроизводственный трафик, и полная копия конфигурации контроллера. Контур должен пережить сценарий «контроллер недоступен 30 минут»: проверяют, продолжает ли сегмент передавать трафик по установленным правилам. 
6. Настроить отказоустойчивость. Контроллеры, базы состояния и управляющие каналы должны иметь необходимое резервирование.
7. Продумать безопасность. Нужно защищать API, учетные записи, сертификаты и доступ к control plane.
8. Автоматизировать постепенно. Сначала разумно перенести повторяющиеся операции, а затем более критичные политики.
   

Особенно важно предусмотреть откат. Если централизованная конфигурация оказалась ошибочной, команда должна иметь понятный способ вернуть сеть в рабочее состояние.

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

Перспективы SDN

Развитие SDN постепенно выходит за рамки первоначальной модели, ассоциировавшейся прежде всего с OpenFlow. Современные платформы используют программируемые data plane, модели данных, телеметрию, P4Runtime, gNMI и другие механизмы. Например, архитектура µONOS уже ориентируется на P4Runtime и gNMI как на ключевые абстракции управления.

Другой важный вектор — intent-based networking (сеть на основе намерений). Администратор описывает желаемый результат: например, какие сервисы должны иметь доступ друг к другу и какие требования предъявляются к соединению. Система управления преобразует это намерение в конкретную конфигурацию.

Развивается и потоковая телеметрия: коммутаторы передают счетчики и состояние интерфейсов контроллеру не по запросу раз в минуту, а непрерывным потоком. Это дает системе управления данные, по которым она замечает деградацию канала и меняет маршрут до того, как о проблеме сообщит пользователь.

SDN описывает переход от ручной настройки узлов к программируемой инфраструктуре. Отдельной технологией или одним протоколом он не ограничивается.

Частые вопросы

SDN — это программа или сеть?

SDN — архитектурный подход к организации сети. Он включает физические или виртуальные сетевые устройства, контроллеры, программные интерфейсы и приложения управления. Поэтому считать SDN одной программой неправильно.

Нужен ли для SDN OpenFlow?

Нет. OpenFlow сыграл важную роль в развитии классической концепции SDN и стандартизировал интерфейс между control plane и forwarding plane. Однако современные решения используют и другие протоколы, API и модели управления.

SDN-контроллер — это единая точка отказа?

Не обязательно. Контроллер логически централизован, однако физически его можно построить как отказоустойчивый кластер из нескольких узлов. Такая архитектура позволяет сохранять единое представление о сети без зависимости от одного сервера.

Чем SDN отличается от SD-WAN?

SDN — широкая концепция программно-определяемого управления сетями. SD-WAN применяет схожие принципы к распределенной WAN-инфраструктуре и позволяет централизованно управлять overlay-сетью между филиалами, ЦОД и другими площадками поверх различных каналов связи.

Чем SDN отличается от NFV?

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