Український телекомунікаційний портал

Программно-конфигурируемые сети (ПКС/SDN) — самый шумный тренд последних лет в телекоммуникационной отрасли. Все хотят понять, что это. Вендоры, разумеется, тянут одеяло на себя, телекомы — недоумевают, а стартапы вокруг SDN плодятся, как грибы-опята на трухлявом пне. В этой статье я попытаюсь в очередной раз описать применимость концепции, причем, на собственной практике.

Для начала, давайте напомню несколько статей, с которых началось исследование проблемы:

• Самое первое описание ПКС в форме описательного опуса так и называлось «Управляется программно». Статья носила «гуманитарно-ознакомительный характер», что, с одной стороны, не очень корректно, но с другой — нужно же с чего-то начинать знакомство с темой.
• Потом была попытка описать что-то конкретно-практическое в парадигме SDN. Например, сервис мониторинга Sinefa. Попытка вызвала нешуточный холивор на десяти страницах форума, самым ценным из которого было вот такое видео:

(мне лично больше всего по нраву пришелся эпизод про Market adoption of SDN в самом конце).

• Потом последовала статья про то, как в теме SDN работает Facebook. Спора в той статье не получилось, потому что по большому счету, тема была не про ПКС, а про самый большой по количеству пользователей коммуникационный сервис в мире. И почему Open Source в проектах Hardware может вполне себе существовать.

Кстати, буквально несколько часов назад Google объявил о своем присоединении к проекту Open Computer Project. Теперь, получается, что два самых крупных потребителя-держателя дата-центров в Мире будут работать совместно над стандартами и решениями. При этом результаты публикуются и их могут использовать и производители оборудования, и эксплуатанты решений. Есть основания полагать, что теперь OCP будет развиваться куда быстрее.

• Еще одна статья с гораздо большим пониманием происходящих в отрасли перемен была посвящена SDN и Applicatoin  Programming Interface — API. Здесь уже понимания (лично у автора, конечно) гораздо больше. Но у читателей, как кажется, все равно конкретики понимания не случилось.

Не удивительно. Ибо понимания нет до сих пор даже у разработчиков и евангелистов (включая автора). Процесс ощупывания слона в темноте продолжается — пришлось даже  перерисовать картинку со слоном:

Давайте очень быстро-коротко пробежимся еще раз по концепции SDN, и оценим степень непонимания, по которой и возникают холивары:

• «SDN —  маркетинговый bullshit, он никому не нужен, это вендоры хотят продать больше оборудования» — разумеется, это так. С оговоркой, что крупнейшие вендоры, как обычно, проспали с трендом и занялись скупать технологические стартапы в этой области за безумные миллиарды. Думаю, достаточно упомянуть:
  • покупку Cisco компании Meraki за 1,2 миллиарда долларов в 2012 году;
  • конкурирующую с Meraki Aruba в 2015 году купил Hewlett Packard за 3 миллиарда долларов;
  • Dell скупил с рынка достаточно много компаний, которые работали с SDN — Cumulus, SonicWALL, StatSoft и, как вишенка на торте — EMC за космические 67 миллиардов долларов. EMC, в свою очередь скупила VMWare и еще массу компаний, связанных с виртуализацией, в том числе, сетевого функционала.

Так что, да — это bullshit, на который вендоры пока тратят свои миллиарды, хотя каких-то продаж особых не обнаружено.

• «SDN — заменяет «железные решения» на программные» — вообще нет. Совсем нет. Оборудование остается оборудованием, на котором и «крутится» софт. Никуда железки не денутся. Просто идеология их применения может чуточку измениться.
• «SDN это OpenFlow» — не совсем. OpenFlow — это протокол управления процессом обработки данных, передающихся по сети передачи данных маршрутизаторами и коммутаторами, реализующий концепцию ПКС. То есть, это «всего лишь» компонент SDN, который реализует одну из задач — более гибкое управление «потоками данных». По сути, OpenFlow это протокол управления многими маршрутизаторами-коммутаторами из единого центрального «оркестратора». Вещь очень полезная и нужная. Возможно, OpenFlow когда-то станет базовым в построении сетей — просто потому, что концепция «управления потоками» делает передачу данных более управляемой и понятной, а разделение функций управления сетью от функций управления устройствами позволяет разобраться во все усложняющейся схеме сети со многими устройствами и протоколами. OpenFlow банально упрощает понимание функционирования Сети, чем экономит время на… дальнейшее усложнение сети.
• «SDN — это для ЦОДов» — очевидно, да. Технологии, упрощающие сложности (см. предыдущий пункт),  внедряются там, где сложность достигла предела понимания. В ЦОДах, тем более, крупных, сложность связей уже столь высока, что внедрение потоков OpenFlow — насущная необходимость. И, что интересно, не только Google с Facebook это поняли, но и, например, Microsoft работает над этим. Причем, настолько, что опубликовали исходные коды собственной ОС для коммутатора  (каково, а! Майкрософт публикует исходный код Open Network OS для коммутатора на базе Linux!). Если конкретному читателю пока непонятно, зачем ему SDN, то это просто пока читателю не нужно. Но это совершенно не означает, что концепт плохой и негодный.
• … тут можно продолжить в камментах, что еще непонятно.

Причина непонимания заключается в так называемой «пропасти технологической адаптации». Это нормально, когда что-то новое, в корне переписывающее реальность, вызывает отторжение и недоверие. Technology Adoption Chasm иллюстрируется вот такой картинкой, где теория «дрейфа инноваций» очень хорошо накладывается на Hype Cycle от Gartner:

Все очень просто: разработчики и изобретатели — изобретают. Сразу за ними «визионеры» начинают рассказывать о технологии ширнармассам — возникает «HYPE» (рекламный шум). Но до непосредственной применимости, необходимо чтобы технологию вообще приняли и начали использовать. И существует неслабая вероятность, что ширнармассы не примут. Причины могут быть разные — или «визионеры» плохо объяснили, или, что чаще — сама технология не очень-то и нужна.

Вот, например, Hype Cycle для телекома, который был опубликован летом 2015-го:

Стрелочками отмечены технологии, речь о которых рассмотрим чуть подробнее.

1. Managed WLAN

Управляемые беспроводные сети. На самом деле, с концепцией SDN и ее практическим применением автор столкнулся, изучая именно данную технологию: о проектах по монетизации публичного Wi-Fi я уже писал много раз, и читал доклады на КРОСе и на НАГ-Академиях.

По сути, управление хотспотами — это предтеча SDN. Поскольку решается именно задача программного управления сетью, хотя и в довольно прикладном значении:

• Нужно как-то управлять отдельными устройствами, иногда в достаточно большом объеме. Конфигурации отдельных маршрутизаторов и их совокупности — это задача NETCONF.
• Поскольку сети Wi-Fi могут быть географически удаленными друг от друга, то локальный контроллер не годится  — нужен облачный контроллер, а это «облака». Или NVF
• Для отдельных типов пользователей, или их групп, требуются специальные политики пропуска трафика. Вполне возможно, что еще и по наложенным сетям. Почему бы и не использовать OpenFlow?
• Политики отдельных пользователей лучше применять по правилам и задачам в каком-нибудь каталоге учета. Как минимум из  LDAP или AD. Вот вам задачка для NorthBridge.

То есть, Managed WLAN — это предтеча SDN, так?

Совет директоров Cisco, поглощая Meraki, именно так и думал, как мне кажется. Вот скриншот системы управления Meraki:

Обратим внимание, что Gartner оценивает управляемые беспроводные сети, как очень близкие к преодолению «технопропасти адаптации» — выход на продуктивность в течение пары лет.

2. WhiteBox Switching

Отдельная тема для разбора для очередной статьи. Очевидно, что потребители в лице телекомов хотели бы иметь приборы с весьма небольшой стоимостью, но возможностями и гибкостью «виртуальных портов». Взять вот хотя бы пользовательские домашние Wi-Fi-мыльницы. Например, выпускать под своим брендом и конфигурировать под свои сети — двухдиапазонная мечта, воплощенная в пластике:

Но как управлять десятками и сотнями тысяч таких устройств? К каждому подключаться CLI, чтоб взять однажды, и перевести сеть на IPv6?

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

… даже, если это «пятый диапазон», и оборудование Cisco (на скриншоте — семь SSID, которые расположены в одном диапазоне. Два раза.)?

Тут опять сгодится подход ПКС, когда собственно устройство «в поле» довольно простое и, главное, дешевое, с открытой архитектурой и сетевой операционной системой класса OpenWRT (да хоть Contiki — неважно).

Под сетевую ОС «накатывается» специальная прошивка, которая может содержать решения OpenFlow (например, уже в довольно законченном видеPantou) и NetConf (чего только не найдешь на GitHub!).

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

3. SDN Applications

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

Впрочем, иные задумки могут принести много радости и эксплуатантам-операторам. Взять вот хотя бы систему «Ревизор». Да-да. Тот самый «Аппаратный модуль «Агент Ревизор» имени Минкомсвязи (по ссылке есть «инструкция по монтажу», которая многое объясняет), который «пришел на помощь» операторам в нелегком деле цензуры соблюдения законов о блокировках. Это история про аппликации SDN, как бы дико это не звучало.

Вообще-то, очень похожую штуку описывал в статье про Sinefa, правда, в использовании в мирных целях мониторинга сетей. «Агент Ревизор» будет чуть проще, но смысл тот же —  WhiteLabel-коробочка (пусть бы и самый дешевый TP-Link с перманентно отваливающимся портом питания по microUSB), которая умеет «стучать» по заранее настроенным url в специальную облачную машинку (собственно — «виртуализация сетевых функций»), о том, доступен ли линк по списку, или не доступен. Не думаю, что там внутри виртуального сервачка неонка какая-то очень сложная BI-система, но часть слона SDN точно используется — как минимум, управление конфигурациями, NVF и буквально «белая коробочка». На выходе — нужное и полезное отдельным товарищамсетевое приложение.

Но для SDN App’сов можно найти и более прикладные задачи. В предыдущем кейсе описывались.

Например, оптимизация Wi-Fi-диапазона. В плотно застроенных городах это конкретная проблема для операторов техподдержки, на которых валится водопад звонков недовольных клиентов: «нам обещали скорость 100 мегабит, а у нас только два!!».

Некоторые точки доступа имеют так называемую «оптимизацию диапазонов частот», класса CleanAir. Но есть две проблемы:

1. Эта функция требует довольно сильных алгоритмов, которые влекут наличие вычислительных мощностей устройства. Все это довольно печально отражается на конечной стоимости прибора.
2. Локальный алгоритм оптимизации не оптимален, по причине одинаковых алгоритмов на соседних точках.

Поясню: предположим,  в одной локации у нас находится несколько АП одного вендора, с одним алгоритмом оптимизации. Что происходит? Правильно: точки доступа одинаково отрабатывают «свободный диапазон» и пузырьком бегают от первого канала к двенадцатому, и обратно.

Но если мы централизованно управляем всем десятком точек, то можем директивно приказать АП оптимально распределить каналы, причем, не просто в плоской шкале «от 1 до 12», но некоторые точки «пригасить по мощности». Всем становится хорошо — байтики бегают по воздуху, не мешая друг другу. Вот вам практическое применение NetConf.

Второй кейс очень хорошо отрабатывает Facebook в Open Source проекте NetNORAD. Эта история о проактивном мониторинге вообще сети. Особенно, когда сеть достаточно сложно заточена, как в ЦОДе, особенно таком большом, как ЦОДы Facebook. Но схема вполне применима и для сетей доступа оператора средней руки с парой-тройкой сотен коммутаторов доступа. Особенно, если коммутаторы неуправляемые.

Суть простая: на CPE пользователей накатывается упомянутый уже программный агент, который просто шлет ping на определенный хост. Хост записывает результаты  пингов в табличку, которая уже является объектом статистического анализа. Визуализация и искусственный интеллект — все дела.

В случае если статистически пинги (а лучше интегральные показатели типа NQS) начинают отличаться от заданных параметров — выставляется алерт.

Как-то так:

Далее, зная топологию сети, становится проще находить неполадки и проблемы. То есть, узнать, что вот-вот произойдет авария ДО того, как она произойдет и рассерженный клиент позвонит в ТП. И это знание возникает только на основании банальных регулярных пингов. А есть еще и специальныйfbtracert, на основании которого можно и автоматом строить логическую структуру сети…

Разумеется, этот сервис только в разработке и полное понимание того, как и что имеется пока что  у NetworkLab Фейсбука. Но довольно скоро, полагаю, появятся и вендоры за несколько миллионов вовсе не рублей. Или OpenSource тоже возможно.

4. Software Defined Network

Вернемся к «циклам шума» Гартнера и обратим внимание на положение точки SDN на кривой. Точка находится в почти самом низу кривой, в зоне «избавления от иллюзий».  Сообщество начинает подозревать, что большой и толстый слон  SDN — это вовсе не то, что предполагалось в далеком 2011 году, когда создавался Open Network Foundation. Слон оказался слишком велик, чтоб целиком использовать все технологические наработки сразу и везде. Гораздо проще и правильнее кушать его частями, применяя полезное и необходимое по месту и экономической целесообразности. Цвет точки, надо отметить — темно синий, что по легенде означает выход на «плато продуктивности» через 5-10 лет, что несколько позже, чем отдельные составляющие типа NVF или того же WhiteBox Switching. Но парадигма схожая — использование универсальных программных решений (да еще и Open Source!), а не создание очередного вертикально-ориентированного монстра, несовместимого даже в пределах линейки одного вендора. Даже главный копираст Планеты это начинает понимать — напомню про Microsoft Linux Router, что само по себе уже очень смешно показательно.

И о погоде…

Эволюция понимания идеи «монетизация публичного Wi-Fi» развивалась по спирали — от простой медийной рекламы на сплеш-пейдже, до развитого маркетинг-тулза с помощью которого прибыль извлекает владелец хот-спота и так называемого «триггерного маркетинга», когда контакт Гостя (человека подключившегося к публичной сети) обрабатывается по событиям и куче условий.

Но однозначно было одно: сетью Wi-Fi-маршрутизаторов нужно как-то управлять. Причем, параметров управления не так уж и мало: нужно понимать коннективити каждого устройства, знать радиообстановку вокруг, получать алярмы при отказе и еще с десяток технических параметров. Но самое главное — нужно уметь гибко изменять параметры входа каждого гостя, предлагая ту, или иную схему входа в Сеть в зависимости от входящих условий (собственно, триггеров) — место, время события, сколько раз Гость появлялся в конкретной локации и вообще в сети. Разумеется, обработка демпрофиля и подключение по социальных сетей — много всего.

Понимание того, что система должна быть разделена на OSS и BSS тоже пришло не сразу. Но очевидно, что контроль сетевых и бизнес-функций должен быть где-то в облаке интернета, поскольку услуга оказывается исключительно Over-The-Top и поверх базовых сетей операторов, название которых в бизнес-логике сервиса никому не интересна.

И вот, после многочисленных проверок гипотез и кучи потраченного времени, выходим на продакшн-релиз и система теперь выглядит так:

Сайт проекта доступен, можно даже заказывать устройства. Нарисованы красивые брошюрки — можно продавать.

Но тут появляется очередной государственный законотворческий приступ (если не помните, то летом прошлого года Минкомсвязи объявило, что хотят штрафовать заведения с публичным вайфаем, если нет идентификации от оператора связи), и кроме обязательной идентификации получается, что необходимо еще и быть оператором, а, следовательно — иметь СОРМ и куратора. Закон, кстати, так и не приняли. Но уверенности в том, что публичный Wi-Fi рано или поздно на территории России не будет запрещен, нет.

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

Но причем тут SDN?

Все очень просто.  Freee WiFi оказался только частью всего айсберга раскопа. По сути, монетизация публичных Wi-Fi-сетей, это SDN App, который в большей части про BSS, бизнес-процессы и юридические взаимоотношения.

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

Железка интересна, например, тем, что она модульная, и ее можно «заточить» под задачу. Например, установить модуль 3G (дешевле) или LTE (дороже) и использовать как точку доступа без наземного WAN:

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

Приборы пока достаточно дорогие — нужен тираж. Но нет основания сомневаться, что в очень скором времени они появятся в продаже на Shop.Nag.ru. Coming Soon…

Парни из Dueton очень хорошо знают тему  Embedded Operating System и могут «заточить» софт под любые задачи, иногда даже странные, типа ДВА LTE-модема на борту, так, чтоб прозрачно переключались резервные каналы. Или поднять хот-спот. Или накатить Programm Agent с вышеописанными темами.

Или сделать из простого понятного Wi-Fi-маршрутизатора Border-Router для грядущего «Интернета вещей». Да, в этом направлении делается рисерч.

Но по сути, это экспериментальный конструктор для WhiteBox, потому что в будущем, мы видим, это будет очень популярная тема, для которой нужно создавать «виртуальные сетевые функции» и «бизнес-приложения». Например, мониторинг, оптимизация частот, и приложения «интернета вещей».

Взято с nag.ru