"Дай под зад диплому" #3: Виртуализация услуг и сетевых функций, SDN и NFV (SDN vs NFV)

Камера, калькулятор, mp3-плеер, радио, телевизор, часы, телефон — отдельные устройства, выполняющие конкретно свои функции. Аппаратно реализованы под свои задачи, и не могут делать что-либо ещё. А если я хочу два телевизора? Купи второй. Хочу вместо чёрно-белого телевизора цветной! Хорошо, купи цветной телевизор. Нельзя из одного телека сделать другой, ведь он работает на основе аппаратной начинки. И в новом устройстве будет другая начинка.

Что покупателю, что производителю подобное неудобно. А что, если можно аппаратные функции воссоздать в компьютерном пространстве в виде программы? Вычисления бывают разные, но если найти наименьший знаменатель в вычислительных платах, который относительно несложно произвести, и который позволяет на программном уровне выполнять функции аппаратных аналогов — это ж вообще сказка! Как удобно то, когда все устройства в виде отдельных приложений в одном компьютере. Ещё круче, когда этот компьютер размером с телефон и лежит у тебя в кармане.

Вот только разве можно звонить программно без устройств передачи / приёмника и модуляции сигнала? Без АЦП и ЦАП (анаго-цифровое преобразование и цифро-аналоговое преобразование)? Такое только физике подвластно. Хорошо, так и быть, пусть это будет в телефоне, а остальное будет программным! А как же камера? Она не может работать без линз, матрицы. Хорошо, давайте дадим минимум по получению картинки, а большую часть работы отдадим на алгоритмы по апскейлу. Обычный процессор с этим не справляется? Ладно, пусть будет отдельный, отвечающий за работу с растровой графикой.

К чему эти примеры организации смартфона? И покупателям, и производителям выгодно использовать использовать программные, а не аппаратные решения, так как их легче создавать, обновлять, менять, чинить, выпускать, доставлять, устанавливать и тд. Но не все функции можно выполнить аппаратно, где-то вычислительная техника упирается в физику, по типу АЦП, антенн для получения и отправки сигнала, устройства ПАВ (поверхностно акустические волны). Поэтому мы идём на компромисс — функции, которые лучше выполняются аппаратно, оставляем аппаратной части, а где можно сэкономить и преуспеть программно — отдаём программам.

Со связью картина примерно та же. Как правило, не бывает сетей с одинаковым оборудованием: оно от разных вендоров, у которых свои методы выполнять задачи или свои критерии качества. В связи огромное количество специфичной техники, которая не имеет аналога в других областях, так что довольно тяжко для подобного выполнить перевод в программный вид. Так мало того, речь о разных устройствах от разных производителей, и это всё должно с друг другом работать. Там аппаратно то не все смогут объяснить взаимосвязь и работу многих элементов, а уж программно то это симулировать каким образом?

Например функция пересылки пакетов (forwarding/routing/switching) — по сути копирование пакета с одного порта, его редактура и копирование на другой порт. Вот только объёмы данных громадны, задержка должна быть минимальной, а программно вы как минимум пускаете пакет между ядром и драйвером, причём в обоих направлениях, и это не считая редактирования. В оборудовании, которое заточено под пересылку, свои собственные ASIC (специализированные интегральные схемы), работающие на троичной памяти TCAM. Они и быстрее, и меньше энергии жрут, и примитивны в своём устройстве, компактны и дёшевы. Вот только вы знаете об использовании чего-то подобного в бытовых компьютерах? Нет. Так как воссоздать подобный процесс программно.

Это была наглядная демонстрация, что не все процессы можно перенести в программную среду, некоторые вещи лучше работают аппаратно. Но не все. Пользовательский шлюз содержит в себе огромное количество функций: от простого роутинга до поддержки специальных методов маршрутизации PBR/ABF, от примитивных ACL до сложного Zone-Based фаерволлинга, такие роутеры подерживают различные стандарты энкапсуляции и туннелирования (GRE/IPIP/MPLS/OTV), трансляцию сетевых адресов (NAT,PAT), сложные QoS-политики (policing, shaping, marking, scheduling). Функционал Control Plane тоже очень широк — от примитивных ARP/ND до сложнейших фич типа MPLS Traffic Engineering. В основном это функции управления, а трафик не слишком большой. В полне себе можно функции управления вынести на ЦОД, и разместить там с десяток таких branch-маршрутизаторов.

Не будем разбирать все механизмы, но уже можно заметить, что роль играет объём передачи данных (низкоуровневая работа) и объём управления (высокоуровневая работа). Ломать — не строить, управлять — не мешки ворочать, можно это так запомнить. Управления зачастую проще реализовать программно, так как программа — это алгоритм действий, что и подразумевает управление. (Но не всегда это верно. Например, NAT лучше работает аппаратно, но это также связано с объёмом данных.) По большей, если мы поделим на уровни data plane (пересылка пакетов) и control plane (функционал управления), то верхний уровень может поддаться программным методам и облегчить нам огромное количество задач.

Прямым продолжением мысли разделения этих уровней является SDN — Software Defined Network, — метод администрирования компьютерных сетей, позволяющий управлять услугами сети, когда control plane отделен (абстрагирован) от нижележащего data plane. Планирование сети и управление трафиком в при этом происходит программным путем. Для приложений верхнего уровня предоставляются интерфейсы прикладного программирования API. Таким образом, ввод новых услуг на сети ускоряется и облегчается.

"Это и есть аналог тому примеру в самом начале стать, и часами и телевизором?" Нет. Это лишь архитектура управления над аппаратными устройствами. Мы лишь руководим программно, но не исполняем. Возвращаясь к аналогу выше, SDN — это возможность подключиться по Bluetooth к вашим колонкам и запустить музыку сразу на всех в один момент времени. В старом варианте вам бы пришлось подходить к каждой колонке отдельно с флешкой и пытаться запустить трек одновременно.

Уже лучше, но всё ещё не то. Мы хотим не просто управлять, мы хотим разворачивать функции на виртуальной среде, а не возить всевозможные коробки с оборудованием и придумывать, где их поставить. Нам один сервер заменит это всё, развернул на нём программную среду — и пошло поехало. Вот это уже NFV — Network Functions Virtualization, — технология виртуализации физических сетевых элементов телекоммуникационной сети, когда сетевые функции исполняются программными модулями, работающие на стандартных серверах (чаще всего х86) и виртуальных машинах (VM) в них. Эти программные модули могут взаимодействовать между собой для предоставления услуг связи, что ранее занимались аппаратные платформы.

Это не значит, что SDN и NFV, разные подходы или замена одного другим. Они сосуществуют вместе. И одна из главных прелестей для оператора связи — обе этих архитектуры упрощают и удешевляют масштабирование сети. Первый не требует изменения сети для своей установки, второй заменяет аппаратное многообразие одной серверной стойкой.

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

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