Структурный разбор данных SDN: Все дело в аналитике

Важность аналитики SDN

Ченгиз Алаєтиноглу

Поставщики услуг вынуждены управлять все более сложными сетями для поддержки сразу нескольких сервисов с различными и часто взаимоисключающими потребностями. Также им приходится обрабатывать все большее количество все более частых запросов к ресурсам сети, предоставляя нужные ресурсы за считанные секунды. Эксплуатировать сети такого размера и сложности, как сейчас, силами одних только инженеров невозможно. Технологии виртуализации сети и SDN позволяют строить динамические, гибкие сети IP/MPLS, которые можно быстро переконфигурировать для адаптации к новым бизнес-требованиям. Однако для того, чтобы сделать автономные сети реальностью, им не хватает управленческого интеллекта.

Программно-определяемые сети (Software-defned networking, SDN) революционизируют сети дата-центров, разделяя уровни управления и уровни данных, а также позволяя приложениям программировать уровень управления. Сейчас мы наблюдаем высочайший уровень инноваций в сетевых приложениях для дата-центров: от оверлеев виртуальных сетей до систем безопасности. Программно-определяемые WAN (SD-WAN) используют этот подход на границе сети, реализуя интеллектуальный метод перенаправления критически важного трафика WAN по дорогостоящим контурам MPLS, а некритичного трафика – по менее дорогим интернет-каналам.
Следующим этапом эволюции SDN станет применение этой архитектуры к WAN (Wide Area Network, территориально-распределенная сеть) и решение проблем с управлением, стоящих перед операторами. В отличие от SDWAN, WAN-SDN (также называемые Carrier SDN) распространяют принцип программно-определяемой сети и на базовую сеть. Для поставщиков услуг это магистральная сеть или городская сеть. Для крупных предприятий, не отдающих свою сеть IP/MPLS на аутсорсинг, это WAN. В этой статье мы будем рассматривать WAN-сети IP/MPLS поставщиков услуг.
Многие из поставщиков услуг делают ставку на технологии SDN, чтобы создавать динамичные, гибкие сети, которые можно быстро перенастраивать для реализации новых бизнес-требований. Автоматизация обеспечения связности и активации услуг дает убедительные преимущества, включая возможность предлагать больше услуг и получать большую отдачу от капиталовложений, сокращение срока окупаемости и повышение эффективности операций.

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

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

Проблемы мультисервисных сетей

Сети современных поставщиков услуг очень сложны, так как должны поддерживать множество приложений и сервисов сразу – доступ в Интернет, потоковое видео, VoIP, VPN уровней 2 и 3, мобильные транспортные сети связи 3GPP и базовые транспортные магистрали, облачные сервисы и многое другое. А ведь в прошлом, как правило, для разных приложений выделялись разные сети. Например, у провайдера могла быть сеть Frame Relay для корпоративных клиентов, городская сеть на основе кольца SONET для мобильной транспортной сети связи, сеть с негарантированной доставкой для доступа в Интернет и так далее.
Очевидно, что эксплуатация нескольких сетей требовала больших капитальных и операционных издержек, чем содержание одной многосервисной сети. Кроме того, многие традиционные сети использовали технологии коммутации каналов и трудно и дорого масштабировались, поскольку выделенная, но неиспользуемая мощность пропадала зря. Теперь многие приложения работают в виде сервисов поверх конвергентных сетей IP/MPLS с коммутацией пакетов, которые гораздо более эффективны, масштабируемы и терпимы к сбоям. Однако их быстродействие менее предсказуемо и требует внимательного мониторинга сервисных маршрутов.

Поддержка уникальных требований сервисов

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

В то же время у сервисов потокового видео сверхвысокого качества для домашних пользователей (таких, как Netﬂix и YouTube) высокие требования к качеству, и их невыполнение приведет к пикселизации, задержкам воспроизведения и в итоге к уходу клиентов. Поэтому для такого трафика лучше всего маршруты с низкой вариацией задержки. Потоковое видео адаптируется к доступной полосе пропускания в известных пределах, поэтому оператор может при нормальных условиях предоставлять оптимальное качество видео, но разрешить его снижение до приемлемого уровня во время пиковой нагрузки или при сбое.
Кроме поддержки нескольких сервисов, перед поставщиками услуг встает еще одна проблема – увеличение частоты запросов на активацию/деактивацию сервисов вместе с сокращением приемлемого времени провизионирования : от недель до часов и даже секунд. Например, многие провайдеры предлагают клиентам порталы самообслуживания, где они могут запросить дополнительную пропускную способность.

Необходимость автоматизации

Оптимизация сети для любого сервиса сложна и требует значительных затрат труда высокооплачиваемых инженеров. Такой подход не масштабируется. Например, рассмотрим время на оптимизацию трафика того или иного приложения. Как правило, создается матрица спроса на трафик, где сопоставляется объем входящего трафика на каждом входном маршрутизаторе и на каждом выходном маршрутизаторе, через который трафик покидает сеть. Потом на основе этой матрицы и топологии сети применяется алгоритм оптимизации, выдающий рекомендуемые маршруты для каждой пары «вход-выход» в матрице трафика, чтобы свести к минимуму максимальную нагрузку на каналы в сети. После вычисления маршрутов они провизионируются в сетевых устройствах.
Теперь, со смещением фокуса в сторону сетей IP/MPLS, работать вручную стало невозможно. Раньше IP/MPLS использовался на магистральных линиях сети и число маршрутизаторов не превышало, скажем, 500. С ростом трафика, в частности, трафика мобильных пользователей, поставщики услуг были вынуждены распространить IP/MPLS на сети доступа и агрегирования.
В результате количество маршрутизаторов, которыми поставщик услуг должен управлять, возросло в разы, иногда достигая 20 тысяч. Эксплуатация сети IP/MPLS такого размера – сложнейшая задача. Например, у провайдера среднего размера единовременно могут «лежать» 5% туннелей, используемых для инжиниринга трафика. Но это больше 1000 туннелей! Если инженеры будут вручную определять причины простоя туннелей, об оперативности не может быть и речи – процесс займет несколько часов или даже дней. Хуже того, к тому времени, когда анализ закончится, данные устареют, потому что сеть уже изменится.
Поэтому оптимизация мультисервисной сети вряд ли возможна без автоматизации. SDN поможет решить эти проблемы и упросить провизионирование сетей. На рис. 1 показана простая двухуровневая архитектура, где приложения SDN контролируют поведение сети. Сетевые устройства (физические и виртуальные) не конфигурируются. Вместо этого они программируются с помощью нисходящих программных интерфейсов (API) одним или несколькими контроллерами SDN или оркестраторами сервисов, выполняющими высокоуровневые функции планирования между доменами, а иногда и между IP/MPLS и оптикой. Контроллеры предоставляют доступ к приложениям посредством восходящих API, позволяя приложениям модифицировать поведение сети под собственные нужды.

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

Телеметрия и аналитика

Многие в индустрии говорят о телеметрии, которая совершенно необходима, но все же отличается от аналитики. Управление SDN требует множества данных о том, что происходит в сети, в частности, о топологии IGP, маршрутах BGP, правилах брандмауэров, требованиях трафика, задержках и их вариации, быстродействии, загрузки интерфейсов и т.д. Эти данные необходимы, но их недостаточно. Телеметрия – всего лишь сбор этих данных, то есть лишь начало эффективного управления SDN.
Аналитика – получение из этих данных выводов, на основе которых можно действовать. Аналитика, в частности, позволяет определить, что именно не в порядке с сетью, и предложить варианты исправления ситуации. Многие проекты больших данных просто топят инженера в них, не говоря, что с ними делать дальше.

Функции аналитики SDN

Аналитика SDN несет две важных функции. Первая из них – поддерживать прозрачность управления сетью, даже если изменения в ней делаются программно. В отсутствие традиционного процесса постановки задач операторы могут просто не знать об изменениях. До тех пор, пока программные изменения работают и дают желаемые результаты, такая непрозрачность может быть приемлемой. Но когда изменение становится проблематичным, как оператор может диагностировать проблему или найти «ответственное» за нее приложение, забагованный контроллер или неисправное сетевое устройство?
Аналитика SDN должна обеспечивать прозрачность сети – устройств и контроллеров, – регистрируя данные телеметрии в реальном времени, поступающие с уровней управления и данных в сети, в том числе топологию маршрутов, метрики быстродействия и данные потоков трафика. Зарегистрированные данные могут быть очень полезны при разборах инцидентов постфактум для определения основополагающих причин.
Вторая, еще более важная функция аналитики SDN, – это интеллектуальное управление. Аналитика SDN жизненно важна для таких задач, как:

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

Например, традиционно, когда оператору требуется внести существенные изменения в сеть, создается группа планирования, оценивающая готовность сети к таким изменениям. Когда поставщик услуг получает нового корпоративного клиента, либо когда предприятие развертывает новый сервис, группа планирования должна определить, достаточно ли у сети для этого мощностей. Если ответ отрицательный, группа планирования пытается найти в сети маршруты, которые могут удовлетворить новые потребности.
Для того, чтобы программируемое планирование SDN было жизнеспособно, ноу-хау планирования, применяемые в практике такой работы, должны быть воспроизведены в аналитическом ПО. Как только программа выдает решение, контроллер или оркестратор SDN может провизионировать его в сети. Такая аналитика делает возможным управлять значительно более крупными сетями за счет автоматизации. Разумеется, аналитическое ПО не может принимать правильные решения без данных телеметрии о каждом аспекте сети.

Место для аналитики

Чтобы аналитика была жизнеспособной, необходимо подобрать ей правильное место в архитектуре SDN. Это место – не в устройствах. Четыре-пять лет назад индустрия полагала, что аналитику стоит размещать в контроллере. Этого не случилось.
Во-первых, контроллеры подешевели и в чем-то упростились. Изготовители отвели аналитике место дополнительной платной функции и стали реализовывать ее лишь в наиболее продвинутых продуктах своих линеек.
Во-вторых, контроллер – это устройство уровня управления. Поставщикам услуг нежелательно осуществлять работу с большими данными в контроллерах. Аналитику можно размещать в приложениях (например, для инжиниринга трафика), но здесь возникает та проблема, что не у всех приложений есть доступ к одной и той же телеметрии. Одно приложение не знает, что происходит в другом, другое – в третьем, и так далее.
Следовательно, аналитику следует размещать на отдельном уровне над уровнем управления. Поэтому в архитектуру SDN добавлен новый уровень: аналитики и автоматизации. Так что, с учетом важности аналитики SDN, двухуровневую архитектуру SDN с рисунка 1 необходимо расширить, включив в нее основанный на аналитике уровень планирования, как показано на рисунке 2. Этот новый уровень реализует как прозрачность управления, так и интеллект для приложений SDN.

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

Применение аналитики SDN

Поставщики услуг все время находят новые возможности применения SDN. Приведем несколько примеров использования SDN и продемонстрируем на них всю важность аналитики.
Быстрое провизионирование: радикальная оптимизация рабочего процесса. Одна из основных целей поставщиков услуг – сократить время создания и активации услуг с нескольких недель до нескольких минут. Организации могут достичь этой цели, устранив трудоемкое ручное планирование для таких задач, как инжиниринг трафика, и автоматически генерируя рекомендации по оптимальной конфигурации сети.
Увеличение КПД сетей: традиционно, сети поставщиков услуг работают при нагрузке на каналы примерно 45%. Это дает достаточный запас прочности на случай аварии. Но это же означает многомиллионный мертвый капитал. Один из методов снижения затрат, что является приоритетной целью для многих поставщиков услуг, – это повышение нагрузки на каналы, что позволит получить большую отдачу от уже сделанных капиталовложений в инфраструктуру сети и даст экономию на дополнительных капитальных издержках.
Для многих поставщиков услуг конечной целью является доведение нагрузки на каналы до 70%. SDN может сделать эту цель реальной благодаря самооптимизируемым, самовосстанавливаемым сетям. Однако высокая нагрузка достижима только при наличии аналитики, как в реальном времени, так и прогностической, которая управляла бы сетевой конфигурацией, успевая за изменяющимися потребностями. Например, поведение сети в условиях аварии можно предсказать на основе исторических данных о состоянии сети и моделирования. Развернув контроллеры SDN, управляемые таким интеллектом, поставщики услуг могут быть уверены, что никакие автоматические изменения не сорвут работу приложений и сервисов, даже в аварийных условиях.
Многоуровневая оптимизация: поставщики услуг желают использовать технологию SDN для того, чтобы объединить управление и планирование уровней IP/MPLS и оптического транспортного уровня. Это позволит операторам оптимизировать инжиниринг трафика, учтя показатели быстродействия, защиты и стоимости для каждого уровня. Операторы получат гибкий пул ресурсов, которые смогут автоматически и интеллектуально реагировать на изменение состояния сети и бизнес-требований.
Восстановление после аварий: при возникновении аварии с точки зрения SDN поставщик услуг должен быстро восстановить их предоставление и обеспечить соблюдение SLA. Для этого требуется понимание характера трафика – как в реальном времени, так и в прошлом – и того, как следует перенаправлять трафик в различных аварийных сценариях. У контроллеров SDN должен иметься источник интеллекта, который давал бы им инструкции по оптимальному перенаправлению трафика в таких ситуациях, с тем чтобы альтернативные маршруты не перегружали другие приложения и сервисы.
Инжиниринг трафика: поставщики услуг желают автоматизировать сложную и трудоемкую задачу балансировки сетевой нагрузки IP/MPLS, чтобы свести к минимуму нагрузку на слабейшее звено, ликвидировать перегрузки сети и перенаправлять трафик в обход перегруженных каналов. Этого можно добиться посредством SDN, создавая туннели RSVP-TE (Resource Reservation Protocol) или SR-TE (Segment Routing) для перенаправления трафика с сильно перегруженных линий на слабозагруженные. В результате сетевые ресурсы в целом используются лучше, а сервисы предоставляются более надежно.
Для этого требуется такая аналитика, как матрицы трафика для различных сегментов сети, периодов времени и условий; моделирование маршрутов в реальном времени для прогнозирования эффекта изменений; алгоритмы оптимизации – все под управлением политик, определяемых пользователем.

Сервисы в разное время суток: Поставщики услуг предоставляют несколько сервисов, перепровизионируя сети в расчете на пиковый трафик. Вместо этого можно, используя прогностическую аналитику на основе исторических моделей, оптимизировать сети в расчете на несколько пиков в день или неделю и минимизировать дополнительные капитальные издержки. Например, сеть можно оптимизировать для корпоративной сети в рабочее время и для потокового видео в нерабочее.
Гибридные облака: для эффективного использования ресурсов WAN и поддержки новых сервисов, таких как облачное резервное копирование или аварийное восстановление центров данных, требуется предоставление полосы пропускания по запросу и календарное планирование. Для этого необходимо регистрировать данные маршрутизации, трафика и быстродействия сети и создавать их базовые модели, чтобы подавать их на вход алгоритмов машинного обучения, рассчитывающих оптимальные сетевые конфигурации.
Суверенитет данных: многие организации в мире требуют, чтобы их данные не пересекали государственных границ. Это делается либо для выполнения законодательных требований, либо для соблюдения строгих внутренних политик безопасности, либо для того и другого сразу. Поставщикам услуг требуется создавать политики, явно определяющие устройства и каналы, по которым может проходить трафик, как на уровне оптики, так и на уровне IP-адресов. Необходимо знать, какие маршруты можно использовать, и иметь возможности для восстановления. Обычно это очень трудоемкий процесс. SDN делает возможными услуги защиты суверенитета данных, если у поставщика услуг есть интеллект, необходимый для автоматического обеспечения маршрутов.
Провизионирование VPN: VPN-сервисы являются важным источником дохода для многих операторов, и автоматизация провизионирования VPN, позволяющая ускорить их развертывание, является очень привлекательным направлением применения WANSDN. Однако не все VPN созданы равными: их требования к качеству обслуживания сильно различаются в зависимости от цели применения. Например, для репликации БД требуются маршруты с низкой задержкой; для гигантских потоков данных нужна большая полоса пропускания, где лучше всего подходит оптический уровень; для видео требуются маршруты с максимально стабильным пингом. Поэтому аналитика должна вычислить лучшие маршруты для каждого из этих сценариев, а также рассчитать воздействие новой VPN на другие услуги до автоматизации провизионирования.

Отвечать сложностью на сложность

В силу сложности и важности сетей поставщиков услуг, где по всему стеку используется сразу несколько технологий, ни один вендор не может предложить полное решение. В самом деле, ранние архитектуры WAN-SDN, разрабатываемые и развертываемые поставщиками услуг, весьма сложны. Как правило, это многоуровневые, многодоменные экосистемы со множеством контроллеров и оборудованием от множества вендоров. Упрощенное представление такой архитектуры приведено на рисунке 3.

Тем выше потребность в открытых API для интеграции разнородных компонентов и в тесном сотрудничестве вендоров, ориентированном на удовлетворение потребностей заказчика. Например, в сценарии многоуровневой оптимизации возможность централизованного планирования сервисов, которое перенаправляло бы трафик на уровнях IP/MPLS и оптического транспорта, выполняя требования к стоимости и качеству обслуживания, становится реальностью благодаря сотрудничеству
поставщиков электрического и оптического оборудования.

Итоги

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

Об авторе:

Ченгиз Алаэттиноглу (Cengiz Alaettinoglu) – один из основателей научно-исследовательского подразделения компании Packet Design. Он отвечает за техническую стратегию разработки портфеля ее продуктов. Его ранние экспериментальные работы, посвященные анализу сходимости маршрутов и свойств масштабируемости, а также корреляции между быстродействием сети и инцидентами в работе протоколов маршрутизации, легли в основу технологии анализа маршрутов и портфеля продуктов Packet Design в целом. В настоящее время Ченгиз работает над созданием приложений для аналитики и планирования SDN в реальном времени с элементами искусственного интеллекта, которые смогут удовлетворять потребности в маршрутах и пропускной способности, не оказывая негативного влияния на другие сервисы. До прихода в Packet Design Ченгиз работал в Институте информационных наук Университета Южной Калифорнии, разрабатывая проект Routing Arbiter. Также он был сопредседателем рабочей группы IETF Routing Policy System, имеет большое количество публикаций и часто выступает на отраслевых мероприятиях по всему миру. Получил степень бакалавра (BS) по компьютерному инжинирингу в Ближневосточном техническом университете (Анкара), магистерскую и докторскую степени (MS и PhD) по компьютерным наукам в Университете штата Мэриленд.