В середине 80-х, профессор Дональд Норман, «гуру» в области проектирования пользовательского интерфейса, проводил семинар в исследовательском центре XEROX PARC в Пало-Альто, Калифорния. Он начал с, казалось бы, постороннего вопроса: «Кто ездит на машине с ручной коробкой передач?». В то время «коробка-автомат» еще только завоевывала американский авторынок, поэтому руки подняли большинство присутствующих. Норман оглядел лес рук и изрек: «Никто из вас не должен заниматься проектированием пользовательского интерфейса!».
Разница между ручной и автоматической коробкой передач, действительно, хорошо иллюстрирует различия между архитектурой обычной сети и сети SDN. Простота ручной коробки заставляет водителя совершать больше движений при езде и контролировать больше параметров: обороты, скорость, включенная передача. Автоматическая коробка, при своей бóльшей технической сложности, значительно упрощает управление автомобилем. Хотя и усложняет его внутреннее устройство. Точно так же, основное предназначение программно конфигурируемых сетей SDN (Software Defined Networks), или в русском переводе – ПКС, упростить управление и администрирование сети передачи данных за счет декомпозиции плоскости управления, хотя и путем внесения усложнений в архитектуру сети.
Как говорит один из создателей архитектуры SDN, профессор университета Беркли в Калифорнии Скотт Шенкер: «Способность справляться со сложностью технической системы – не то же самое, что делать ее простой в обращении». При начальной реализации технической системы обращают внимание, в основном, на первое. При ее развитии и совершенствовании – на второе. Именно с этой целью были созданы стартер, стеклоочиститель, парктроник и «коробка-автомат».
Однако, как указывает Скотт Шенкер, архитектура сетей до сих пор не сделала перехода от сложности реализации к простоте обращения. До сих пор компьютерные сети сложны в управлении и администрировании. Исследование Yankee Group показывает, что 62% времени простоя сетей предприятий случается из за «человеческого фактора», а 80% ИТ-бюджета предприятий тратится на обслуживание сети.

Суть SDN — логическая абстракция уровней управления сетью, с целью упрощения технической эксплуатации сети, точно так же как «коробка-автомат» скрывает (абстрагирует) техническую сложность управления автомобилем.

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

Почему SDN?
Почему логическая (программная) структура Интернет была столь успешной? Потому, что она очень хорошо структурирована и абстрагирована: приложения (www, email, видео и голос) работают поверх транспортного уровня (TCP, UDP и RTCP), который, в свою очередь, основан на уровне сети глобальной передачи пакетов (IP), лежащем на уровне канальной передачи (Ethernet), поверх физической инфраструктуры (медная пара, оптоволокно, радиодоступ…). Все это хорошо взаимодействует при помощи стандартных интерфейсов.
Польза такой уровневой структуры сети – в декомпозиции процесса доставки пакетов, когда не нужно думать о передаче каждого бита информации. Инновации на каждом уровне можно проводить независимо, не затрагивая соседние уровни. Именно поэтому Интернет так быстро и успешно развивается.
Однако, в построении сетей (networking) такой подход почему-то не прижился. Научные принципы построения сетей практически отсутствуют. Преподавание в университетах других «компьютерных» дисциплин (операционные системы, программирование, базы данных и пр.) ведется на основе базовых принципов, как академическая наука. Построение сетей преподается как «нагромождение протоколов». Почему так происходит? Сети остаются довольно простыми по структуре. Например, принципы сети Ethernet очень просты. Это, видимо, рудимент ARPAnet, сети военного назначения, прообраза Интернет. ARPAnet должна была работать даже в случае, если любая, сколь угодно большая, часть ее будет уничтожена в ходе боевых действий. Такую сеть нельзя было делать архитектурно сложной. Именно поэтому до сих пор корпоративные сети проектируются, строятся и обслуживаются в «ручном режиме». Однако, несмотря на довольно простые приемы построения сетей, их топологическая структура все больше усложняется. Администрировать такие сети становится все сложнее. Получается замкнутый круг.
В программировании, напротив, переход от управления сложной системой к декомпозиции и упрощению этого управления был сделан давно. Сначала были т.н. «машинные языки», которые не обладали никаким абстрагированием, где требовалось определять точный адрес хранения каждого бита в памяти. Затем появились операционные системы, скрывающие от программиста особенности реализации «железа», и т.н. «языки высокого уровня» (абстрагирования), файловые системы, виртуальная память, абстрактные типы данных. Это позволяло хорошо структурировать процесс разработки программ, давая возможность программистам не вникать в особенности технической реализации каждого компьютера. Современные языки обеспечивают еще более высокий уровень абстрагирования: объектно-ориентированное программирование и пр.
Абстрагирование – не что иное, как декомпозиция проблемы на отдельные уровни, которая ведет к созданию стандартных интерфейсов между модулями (уровнями) системы, что значительно упрощает как работу с ней, так и ее модернизацию.
Любая сеть имеет две плоскости – плоскость передачи данных (data plane) и плоскость управления сетью (control plane). Data plane производит обработку поступающих пакетов по принципу: политика передачи пакета + заголовок пакета = решение о передаче пакета. При этом обеспечивается абстрагирование услуг (механизм best effort в IP, надежность байтовой передачи в TCP и пр.). Сontrol plane, которая определяет политику передачи на каждом сетевом узле (forwarding policy), напротив, не обеспечивает уровня абстракции для управления. На этой плоскости реализуется множество различных механизмов: распределение алгоритмов маршрутизации, изоляция пользователей и узлов (ACL, VLAN, межсетевые экраны…), инжиниринг трафика (MPLS, алгоритмы взвешивания, OSPF, BGP, IS-IS и пр).
Для обеспечения абстрагирования плоскости управления (control plane) и была создана концепция SDN. В целом, она основана на трех основных абстракциях: абстракции распределения политик узлов (distribution), абстракции механизма продвижения пакетов (forwarding) и абстракции конфигурирования сетевых узлов (configuration).

Эволюция SDN
Механизм управления сетью до SDN можно упрощенно представить так:

Сетевые узлы обмениваются между собой данными по конфигурации и топологии сети при помощи протоколов распределения (distribution). Эти алгоритмы достаточно сложны и зависят от назначения сети.
В SDN вводится понятие сетевой операционной системы NOS (рис.2), которая работает на отдельных серверах в сети (дублированных для надежности). Сервер NOS «общается» с каждым сетевым узлом и таким образом получает глобальную топологию сети (Global Network View) и представляет его для управляющей платформы сети в виде сетевого графа. Кроме того, NOS отвечает за централизованное конфигурирование сетевых узлов. Управляющая платформа формирует параметры, которые применяются к конкретной сети через ее граф, извлеченный NOS.
Таким образом, конфигурация сетевых узлов является, по сути, функцией сетевого графа. Механизм управления теперь сводится к определению политик работы сетевых узлов (изоляция пользователей, контроль доступа, QoS…). Однако, за реализацию этих политик на конкретной физической инфраструктуре сети управляющая программа не отвечает, это задача NOS.
Можно сказать, что NOS выполняет ту же функцию, что и компилятор в программировании, преобразующий выражения языка высокого уровня в блоки машинных команд, которые понимает конкретное «железо» того или иного компьютера. Как сам компилятор не может создать программу, так же и NOS не формирует политики.

Архитектура SDN версии 1 (SDN v.1)

Поясним на примере. Предположим, что требуется обеспечить логическую изоляцию пользователя А на сети (например, клиента, подключившегося через гостевой доступ корпоративной сети WLAN в холле предприятия) от сервера базы данных B, где хранится конфиденциальная информация.
В отсутствие SDN, сетевой администратор должен проанализировать реальную схему сети и сконфигурировать узлы 1 и 2 таким образом, чтобы, при появлении на них пакетов с IP-адресом источника А и IP-адресом назначения В, такие пакеты отбрасывались. Однако, с ростом предприятия сеть будет развиваться, в ней могут появиться новые узлы и маршруты, и может появиться возможность проникновения пакетов от А к В. Сетевой администратор должен быть начеку и вовремя произвести необходимые действия по дополнительной конфигурации узлов.
В случае абстрактного представления топологии сети в SDN, администратору следует лишь прописать правило «маршрут от A к В = сброс пакета» в управляющей программной платформе и оно будет действовать всегда, а изменения топологии сети будет автоматически отслеживаться в NOS.

Пример абстракции SDN.

Виртуализация сетевых функций (NFV)
NOS облегчает реализацию, выполнение функциональности сети в целом. Но она никак не определяет эту функциональность. Однако, в архитектуре SDN глобальную топологию сети тоже можно вывести на уровень абстракции, как на верхней части рис. 3, чтобы обеспечить некие правила относительно того, кто с кем может связываться в сети, какой функционал доступен тому или иному пользователю и пр. Для этого в архитектуру плоскости управления SDN вводится еще один уровень – виртуализации сетевых функций NFV (Network Functions Virtualization). NFV реализует через сетевой граф такой функционал, как трансляция сетевых адресов (NAT), параметры межсетевых экранов (firewall), распознавание вторжений, службу доменных имен (DNS), кэширование и пр., забирая эти функции у «железа» сетевых узлов, тем самым, нивелируя особенности реализации на оборудовании различных производителей. Теперь эти функции можно реализовывать и конфигурировать программно, отсюда и название «программно-конфигурируемые сети».

Архитектура SDN версии 2 (SDN v.2) с NFV

Инфраструктура сети теперь состоит из хорошо определяемых и отслеживаемых модулей (уровней абстракции) – сетевая виртуализация NFV, сетевая операционная система NOS и интерфейс для описания передачи пакетов (например, OpenFlow). NFV и NOS тем не менее, представляют собой достаточно сложный программный код, но все проблемы теперь можно легко отслеживать, локализовывать и решать на соответствующем уровне. Теперь нужно заботиться лишь о том, ЧТО должно происходить в сети, а не о том, КАК сделать так, чтобы это происходило.

OpenFlow
Часто говорят, что «SDN – сеть, работающая на базе протокола OpenFlow». Какую же роль протокол OpenFlow играет на самом деле? При помощи этого протокола NOS переносит конфигурацию глобальной топологии сети (network view) на реальные физические устройства сети (маршрутизаторы, коммутаторы, межсетевые экраны, пограничные контроллеры, контроллеры сети беспроводного доступа и пр.), а также получает информацию о глобальной топологии сети. Важен ли этот протокол в структуре SDN? Несомненно, да. Хорошее ли это решение? На данный момент – тоже да. Единственно ли возможное это решение? Определенно, нет. Возможно, в будущем будет создано что-то другое, благо, что иерархичность и модульность control plane теперь легко позволяет вводить такие усовершенствования. Именно по этой причине на рис. 2 написано «управление через интерфейсы [передачи пакетов]», а не OpenFlow.

В чем практическая польза SDN?
В середине 1990-х, на пике развития Интернет, самой большой проблемой была скорость передачи данных по сети. Важнее всего было то, насколько быстро можно было передать, например, большую базу данных или скачать файл видеофильма с сервера. В середине 2000-х, с появлением приложений, работающих в реальном времени (IP-телефония, видеоуслуги), на повестку дня вышел параметр «качества услуг» QoS (Quality of Service). Однако, услуга услуге – рознь, «что для голоса хорошо, то для видео – смерть». Например, для голоса большое значение имеет задержка передачи пакетов (при задержке более 50 мс разговор становится некомфортным). Однако, процент потери пакетов для голоса не столь важен, например, речь вполне различима даже при 5% потерянных в сети пакетов. Однако для видеоуслуг все наоборот – 5% потерянных пакетов существенно ухудшит качество видео, а задержка пакетов для видеовещания не столь важна и иногда даже используется для повышения качества.
Поэтому, приходится вводить технологии «инжиниринга трафика» ТЕ (Traffic Engineering), для того, чтобы, например, обеспечить приоритет передачи пактов по протоколу SIP (голос) перед пакетами по протоколу FTP (передача файлов). Сейчас, на повестке дня остро стоит задача динамического управления сетью. До «эпохи SDN» формировать сетевой трафик динамически, «в реальном времени» было практически невозможно. SDN позволяет формировать состав трафика (traffic shaping) также «в реальном времени». Например, в SDN можно в течение рабочего дня для VoIP можно выделить 70% полосы пропускания сети, а для видеонаблюдения – 10%. Ночью можно для голоса оставить 3%, а для видео – 70% и при этом повысить его качество, т.к. ночная съемка требует более высокого разрешения. Причем, сделать это в несколько кликов мышкой.
Или, например, можно представить такую экстренную ситуацию. В здание бизнес-центра ворвалась группа террористов. Можно включить сирену, но никто не будет знать, где находятся террористы, куда бежать? SDN позволяет практически мгновенно включить трансляцию видеонаблюдения в высоком разрешении на все рабочие станции сотрудников, выделив для этого все 10 Гигабит корпоративной сети, чтобы все сотрудники сразу увидели, куда именно бежать не надо, чтобы не попасть в заложники. А после того, как опасность минует, быстро переключить приоритет сети на трафик VoIP, чтобы сотрудники могли позвонить домой и сообщить, что с ними все в порядке.
SDN уже имеет применение на практике. Например, в центре ядерных исследований CERN в Швейцарии SDN используется для масштабирования услуг центров обработки данных (ЦОД), балансировки нагрузки на серверы ЦОД, обеспечения мобильности виртуальных машин, оперативной связи ЦОД между собой. При исследованиях элементарных частиц в «адронном коллайдере» ежесекундно генерируются огромные массивы данных (порядка экзабайт), которые нужно быстро отправить в системы хранения для последующей обработки, причем с резервированием, чтобы не потерялся ни один бит. Для этого нужно оперативно настроить передачу трафика в сети ЦОД под такую задачу. Когда экспериментальная часть закончена, наступает черед научной обработки данных. Для этого нужно быстро перенастроить сеть под другую задачу, с тем, чтобы эта обработка была произведена как можно быстрее, и здесь незаменимым помощником также выступает технология SDN.

(Опубликовано в журнале Коннект №4 2014 г.)