Уже никого не удивишь стартапами и разработками в области software-defined networks (SDN) – тема широко исследуется как крупными мировыми корпорациями, так и open source сообществами.
Однако до недавнего времени практически все разработки были направлены на управление инфраструктурой дата-центров, и еще немногим более года назад мало кто верил, что концепция SDN сможет быть применена в транспортных сетях (transport networks).
В октябре 2015 года контроллер T-SDN (transport software-defined networks) компании NetCracker был развернут на сети одного из европейских операторов. Контроллер автоматизировал значительную часть сетевых операций и, как следствие, позволил оператору значительно экономить время – сотни часов, которые инженеры тратили на настройку сети и выделение сервиса.
Структура сети
Сетевые элементы внутри доменов включали платы ROADM/WSS, которые фактически являются перенастраиваемыми оптическими мультиплексорами ввода-вывода и позволяют изменять пути сигнала между сетевыми элементами. Междоменные соединения поднимались между клиентскими портами, эти порты находятся на платах, называемых транспондерами (оптический транспондер – устройство, обеспечивающее интерфейс между оборудованием оконечного доступа и линией WDM). В нашем случае использовались транспондеры с десятью 10Гбит/с (IEEE 802.3ae) клиентскими интерфейсами и агрегирующим ODU4. ODU – это контейнер с данными, обеспечивающий контроль этих данных на всем пути следования и являющийся частью технологии OTN (optical transport network). Тестовая оптическая сеть могла передавать до 80 таких контейнеров в одном физическом волокне, скорость каждого была равна 100Гбит/с.
Контроллер позволил поддержать в сети следующие функции:
- автоматическая прокладка сервиса в сети по запросу клиента;
- автоматическое переключение на защитный маршрут в случае выхода из строя порта устройства, либо пересчет пути, если устройство не поддерживает защитные маршруты;
- мониторинг ошибок и уведомлений.
T-SDN
Попробуем детальнее разобраться в том, что же вкладывают в понятие T-SDN его архитекторы и идейные вдохновители.
Основной идеей T-SDN, так же как и в SDN для дата-центров, является разделение плоскости передачи данных (data plane) и контрольной плоскости (control plane), которое реализуется через создание единого управляющего контроллера, взаимодействующего с сетевыми устройствами некоторого домена транспортной сети. Над контроллером находится уровень приложений (SDN application layer), общающийся с контроллером по определенному интерфейсу. Благодаря тому, что контроллер знает все о структуре своего домена, появляются дополнительные возможности для улучшения работы сети. Для некоторых из них уже существуют решения в различных протоколах, но T-SDN может значительно улучшить уже существующие подходы.
Итак, что же предлагает T-SDN:
- Упрощение операций по работе с транспортной сетью.
Предполагается, что запросить сервис у провайдера будет так же просто, как сделать заказ в интернет-магазине. Как только заказ сделан, контроллер автоматически переконфигурирует все устройства и выделит необходимые ресурсы. Таким образом, клиент получит необходимый сервис за считанные минуты.
- Оптимальное использование пропускной способности.
Оптимизация использования пропускной способности канала (или, как еще говорят, оптимальная утилизация канала) – задача далеко не новая. Однако полноценного решения для динамического распределения клиентских каналов в транспортной сети до сих пор не существует, и предполагается, что в будущем решение этой задачи возьмет на себя транспортный контроллер.
В качестве примера рассмотрим такой случай. Клиентский траффик проходит между оптическими устройствами A и B двумя путями. Голубой пунктир – оптическое волокно, черные линии – клиентский канал. Графики показывают, какая часть канала занята, а какая свободна – красный и зеленый цвета соответственно.
Теперь представим, что нужно разместить новый клиентский канал – больший по емкости, занимающий 50% пропускной способности соединения. Для этого можно, например, провести один из каналов идущих сверху по нижнему пути, и таким образом освободить 50% соединения.
Эту операцию нужно провести так, чтобы существующий клиент не заметил, что его траффик теперь идет другим путем – даже кратковременный отказ в обслуживании или ухудшение качества услуг (QoS) неприемлемы. Такое перераспределение каналов возможно, но на данный момент оно выполняется инженерами в ручном режиме, занимает немало времени и подвержено ошибкам. Контроллер же потенциально может автоматизировать этот процесс. Нужно отметить, что использование пропускной способности на 100% в реальности невозможно, цифры приведены лишь для иллюстрации проблемы. В действительности показатель утилизации обычно составляет порядка 80-90%.
- Пропускная способность по запросу (bandwidth on demand) – автоматическое увеличение пропускной способности клиентского сервиса, в случае если объем траффика превышает емкость купленного им канала. Такое поведение позволит передавать данные с большей скоростью в течение небольшого промежутка времени, а также предотвратит сброс пакетов в случае пиковых нагрузок. Пропускная способность по запросу не потребует от клиента больших финансовых вложений – оплатить нужно будет только тот промежуток времени, в течение которого пропускная способность была увеличена.
- Построение оптимальных маршрутов в транспортных сетях.
Централизованное управление сетью дает возможность оптимально подбирать маршрут для прокладки сервиса с учетом разнообразных метрик и требований.
- Высокий уровень надежности и доступности сервиса (high availability).
Автоматическое управление позволяет быстро реагировать на сбои в сети. Контроллер поддерживает любые способы защитного резервирования маршрута для быстрого восстановления сервиса при сбоях.
- Безопасное конфигурирование сети через высокоуровневые приложения.
При изменении конфигурации устройства сетевым администратором возможны ошибки, которые могут привести к серьезным последствиям, в том числе долгосрочным отказам в обслуживании. Известно немало случаев значительных сбоев в глобальной сети из-за ошибок инженеров – чего стоит только утечка маршрутов (route leak) 12 июня 2015 года, затронувшая значительную часть Интернета. Использование высокоуровневых визуальных приложений позволяет сильно снизить вероятность неправильной конфигурации – большая часть скрупулезной работы выполняется автоматически.
- Возможность легко масштабировать систему (scalability).
Увеличения числа устройств и управляющих приложений выполняется без дополнительных настроек контроллера.
Эти и другие заявленные возможности T-SDN сейчас вызывают самую разную реакцию, в том числе жесткую критику и недоверие, но реальное понимание ситуации могут дать только полноценные исследования, прототипирование и пилотные запуски программно-конфигурируемых транспортных сетей.
Сотрудники компании NetCracker в Москве, Санкт-Петербурге и Нижнем Новгороде при поддержке инженеров из компании NEC в настоящий момент ведут активную работу по исследованию T-SDN и развитию функциональности контроллера T-SDN.
Контроллер T-SDN компании NetCracker
При разработке контроллера мы ориентируемся на поддержку следующих требований:
- полное управление сильно распределенной транспортной сетью крупного провайдера;
- прокладывание маршрута по всей сети провайдера;
- оптимизация маршрута с учетом требований и различных метрик;
- поддержка мультивендорной сети (сети, построенной на устройствах различных производителей);
- пропускная способность по запросу;
- высокий уровень надежности и доступности сервиса;
- возможность легко масштабировать систему;
- оптимальное использование пропускной способности.
В компании NetCracker ведется разработка контроллера, который мог бы в одиночку контролировать сеть провайдера любого уровня. Требования к производительности для управления такой сетью очень высоки, поэтому контроллер имеет иерархическую структуру, состоящую из контроллеров двух типов – доменный контроллер T-SDN (контроллер нижнего уровня) и собственно контроллер T-SDN (контроллер верхнего уровня). Доменный контроллер управляет только частью сети, то есть некоторым доменом, и берет на себя функции управления непосредственно транспортными сетевыми устройствами. Контроллер верхнего уровня управляет не сетевыми устройствами, а доменными контроллерами, таким образом абстрагируясь от общения с сетевой инфраструктурой, что позволяет повысить производительность системы. Задачи по управлению сетью декомпозируются и делегируются котроллерам нижнего уровня. Контроллер верхнего уровня принимает данные о работе домена, обрабатывает их и предпринимает дальнейшие действия.
На схеме ниже показаны сети, управляемые доменным контроллером T-SDN (управление одним доменом) и контроллером T-SDN верхнего уровня (управление всеми доменами).
Проще говоря, контроллер верхнего уровня «видит» целую группу устройств как одно устройство. Такая концепция, с одной стороны, позволяет избежать значительных накладных расходов и улучшить производительность, с другой – дает возможность просматривать сеть целиком, вместе с кросс-доменными соединениями, которые не могут быть проконтролированы на доменном уровне, так как не находятся в зоне видимости доменного контроллера T-SDN. Такой подход позволяет прокладывать клиентский сервис по всей сети: от точки входа в сеть провайдера, до точки выхода из нее, и, как следствие, эффективно управлять утилизацией, оптимизацией прокладки пути, надежностью и доступностью сервиса.
Архитектура контроллера T-SDN компании NetCracker
Компанией NetCracker совместно с NEC разработана архитектура контроллера T-SDN. Архитектура представляет собой иерархическую структуру. На нижнем уровне находится сетевая инфраструктура, устройства которой по некоторому API связываются с доменными, в том числе проприетарными контроллерами SDN. Далее идет уровень доменных контроллеров, который, в свою очередь, подключен к единому контроллеру T-SDN верхнего уровня. На самом верхнем уровне находятся приложения, предоставляющие функции мониторинга и конфигурирования.
Архитектура контроллера, разработанного компанией NetCracker, целиком вписывается в эталонную архитектуру контроллера SDN, предложенную организацией Open Networking Foundation в 2014 году (ONF Архитектура). Это подтверждает полное соответствие нашего контроллера T-SDN мировым стандартам. Жизнеспособность такой архитектуры уже неоднократно проверена в сетевой лаборатории компании NetCracker на оборудовании различных производителей.
Контроллер имеет следующие основные модули:
прокладка маршрутов (path provisioning) включает в себя операции построения маршрутов на логическом уровне, а также непосредственно взаимодействует с Медиатором (Mediation), от которого получает обработанную информацию с подключенных доменных контроллеров;
вычисление пути (path computation) отвечает за определение маршрута на сетевом графе с учетом различных критериев;
управление утилизацией (utilization management) отвечает за оптимизацию использования пропускной способности каналов;
сервисная топология (service topology) осуществляет хранение актуальных и запланированных сервисов и их параметров;
медиатор (mediation) отвечает за работу с API нижележащих устройств и осуществляет поддержку достаточно богатого набора протоколов сетевого управления, таких как RESTCONF, NETCONF, SNMP, SSH, OpenFlow а также HTTP/HTTPS;
управление контроллером (controller management) соответствует модели FCAPS стандарта ISO и включает в себя управление конфигурацией, отказами и производительностью контроллера.
Модуль вычисления пути
Одним из интереснейших и сложнейших модулей контроллера является модуль вычисления пути (PCE) – модуль, отвечающий за расчет конкретного пути для запрошенного клиентом сервиса. Реализация такого модуля является непростой задачей с точки зрения математического алгоритма. Знатоки протоколов маршрутизации по состоянию канала OSPF и IS-IS или протокола маршрутизации канального уровня HWMP стандарта 802.11s, возможно, скажут, что задача уже давно решена, реализована и проверена временем – достаточно использовать стандартные подходы для поиска пути на графе, например, алгоритм Дейкстры и его модификации. Однако специфика, накладываемая оборудованием различных вендоров, а также требования, представленные системе, делают задачу поиска пути принципиально новой, требующей детального анализа и небанальных подходов.
Основные требования, предъявляемые к PCE:
- нахождение пути при условии его существования;
- гибкая поддержка метрик;
- учет желательных или нежелательных для посещения узлов;
- учет обязательных для посещения узлов;
- учет запрещенных для посещения узлов;
- независимость от производителя оборудования.
Особую сложность представляют пункты 4 и 6.
Поиск оптимального пути на графе с обязательным посещением заданных вершин является NP-полной задачей, однако расчет пути отдельно для каждого домена хорошо оптимизирует временные затраты. Для решения задачи используется эвристический алгоритм в комбинации с алгоритмом поиска пути Дейкстры.
Независимость от производителя требует, чтобы правильный путь был найден вне зависимости от того, какова реализация внутренней структуры устройства конкретного производителя и того, какие ограничения эта структура накладывает. Для решения этой проблемы разрабатывается полнофункциональный алгоритм поиска пути на многоуровневом графе, включающем физический, физико-логический и абстрактный уровни.
Дальнейшее развитие
Успешный запуск пилотной версии даёт возможность разработчикам контроллера T-SDN вносить свой вклад в развитие Open Source проектов, таких как ONOS и ODENOS, участвовать в стандартизации новой технологии SDN в Open Networking Foundation и в других организациях.
Развитие проекта ведется в тесном сотрудничестве с компанией NEC – производителем современного сетевого оборудования. Таким образом, функционал контроллера тестируется в сетевой лаборатории NetCracker на новейших устройствах от NEC, а отделы разработки компаний NetCracker и NEC имеют возможность тесно сотрудничать и напрямую обсуждать технические вопросы. Такое взаимодействие позволяет лучше понимать возможности вендоров и эффективнее работать с сетевыми устройствами.
Функциональные потребности крупных провайдеров постоянно растут – компании, заинтересованные в контроллере T-SDN неустанно снабжают разработчиков компании NetCracker всё новыми, более сложными и интересными задачами. Значительное развитие получат (и уже получают) абсолютно все составляющие – от низкоуровневых сетевых интерфейсов Медиатора (Mediation) до визуализирующих и управляющих приложений. Команда контроллера T-SDN компании NetCracker, имеющая за плечами многолетний опыт работы с ведущими провайдерами в рамках OSS- и BSS-решений, уверено положила начало развитию этой непростой, но чрезвычайно интересной области.
Автор: NetСracker
