В последнее время в области телекоммуникаций все больше внимания привлекают к себе технологии Software Defined Networks (SDN) и Network Function Virtualization (NFV). В предлагаемом материале рассматриваются ключевые аспекты применения решений, основанных на OpenFlow[1], который сегодня является стандартом де-факто для SDN-решений, использующих открытые технологии.
Развитие технологий SDN и NFV связано с появлением облачного подхода к организации приложений и виртуализацией при эксплуатации инфраструктуры. Такие свойства облаков, как эластичность подсистем, линейное масштабирование мощности и географическая распределенность как способ резервирования и обеспечения отказоустойчивости, привлекают владельцев не только массовых веб-сервисов, но и других приложений.
Использование виртуализации дает возможность отделить функциональное приложение от аппаратной части и инфраструктуры, что обеспечивает серьезные экономические преимущества. Это позволяет унифицировать аппаратную часть и организовать циклы технического перевооружения независимо от самих приложений, которые могут существовать в отдельном ритме, и использовать разнообразные ценовые модели, такие как подписка, оплата по мере использования и др.
Кроме того, облачный подход предусматривает максимальную автоматизацию управления инфраструктурой и приложениями, что, в свою очередь, обусловливает использование сети как инфраструктурной услуги. Это уже приводит к повышению спроса на технологии SDN, которые становятся востребованными и понятными в таком окружении.
Однако то, что развитие решений идет от обеспечения работы ЦОД, зачастую становится причиной неочевидных, но серьезных недостатков, связанных с обеспечением надежности работы сети и сетевых сервисов. В частности, распространенные SDN-решения, ориентированные на организацию сетевых сервисов в ЦОД, рассчитаны на организацию избыточной Clos-топологии, обеспечивающей отказоустойчивость и резерв полосы на случай отказов отдельных элементов сети на разных уровнях коммутации, что в целом является распространенной практикой для ЦОД. Такой подход крайне избыточен и достаточно сложен для реализации в сетях операторов связи, когда сеть объединяет множество узлов, находящихся на большом расстоянии друг от друга. В этом случае организация множества избыточных линков – довольно дорогостоящий вариант.
Отказоустойчивость, защита, QoS и контроль
Еще один аспект, связанный с расстоянием, необходимо учитывать при организации централизованного управления. При использовании OpenFlow-коммутаторов подход, при котором используются коммутаторы с малыми Flow-таблицами и, как следствие, постоянными запросами на контроллер за инструкциями по обработке пакетов, практически невозможно реализовать. Таким образом, решение SDN для операторов связи требует подхода, способного обеспечить следующие характеристики:
- отказоустойчивость контроллера при централизованном управлении;
- защита пути, линка и узлов для обеспечения быстрого восстановления услуги при отказах;
- наличие в коммутаторах физических механизмов обеспечения QoS, таких как планировщик очередей и многоуровневые ограничители трафика;
- контроль состояния коммутаторов и параметров обработки трафика.
Для обеспечения отказоустойчивости в стандарте OpenFlow предусмотрена поддержка нескольких контроллеров, с которыми может работать коммутатор. На данный момент предусмотрены разнообразные схемы, позволяющие использовать одновременно несколько контроллеров для обеспечения отказоустойчивости и распределения нагрузки. Однако для эффективной работы требуется реализация режима кластера со стороны контроллера в целях сохранения консистентности состояния сети.
Защита сервиса – еще один аспект, который не столько решается на уровне стандарта OpenFlow, сколько обеспечивается самим приложением. К наиболее доступным вариантам реализации этой функциональности относятся программирование резервных путей работы сетевых сервисов и применение групп портов для переключения на альтернативные пути отправки трафика. Но такие механизмы требуют поддержки расширенной функциональности в коммутаторах, не относящейся к стандарту OpenFlow (в частности, механизмы обнаружения отказов линков и соседних узлов, например BFD). Кроме того, программирование альтернативных путей повышает требования к размерам Flow-таблиц при равных масштабах сети и сервисов.
Для реализации QoS в самом стандарте OpenFlow заложены необходимые механизмы, такие как:
- поддержка очередей – протокол позволяет получать список очередей на каждом интерфейсе, информацию о распределении полосы между очередями и направлять трафик в конкретную очередь;
- ограничители трафика (meters) – дают возможность регулировать полосу, занимаемую каждым потоком, реализуя как ограничения, так и перемаркировку DSCP.
Таким образом, стандарт OpenFlow обеспечивает механизмы, достаточные для реализации DiffServ в SDN-сети. Однако механизмы, заложенные в стандарт OpenFlow, должны быть установлены в коммутаторе, причем на уровне не только агента OpenFlow, но и аппаратного обеспечения, что встречается далеко не в каждой модели. Это необходимо учитывать при планировании SDN-сети, в которой требуется широкомасштабная поддержка QoS.
С точки зрения мониторинга и получения информации о состоянии коммутатора стандарт OpenFlow предоставляет широкие возможности. Поддерживаются статистика по эффективности использования каждого правила, таблиц, статистика текущей загруженности портов и очередей, статистика по использованию ограничителей. Следовательно, обеспечиваются механизмы контроля трафика в SDN-сети и качества услуг, однако вопрос конкретной реализации в значительной мере зависит от выбранного решения – как с точки зрения ПО управления сетью и сервисами, так и с точки зрения коммутаторов.
Помимо чисто технических характеристик, позволяющих контролировать и обеспечивать качество сервиса в SDN-сетях, есть и архитектурные аспекты, повышающие эффективность управления сетью. За счет централизованного мониторинга и управления SDN-сеть обеспечивает управление, основанное на глобальной видимости состояния сети и трафика и интегрируемости с данными сопряженных систем.
Традиционная сеть состоит из совокупности автономных элементов, обменивающихся информацией друг с другом через наборы протоколов. Для того чтобы использовать возможности согласованного управления трафиком, необходимо применять все более сложные и комплексные протоколы и повышать требования к вычислительным способностям контрольного уровня устройств.
SDN-подход предлагает централизованное управление сервисами в рамках всей сети. Это позволяет избавиться от сложных протоколов обмена состояниями благодаря построению централизованной модели и транслированию ее в инструкции конкретному сетевому устройству. За счет этого можно оптимальным образом распределять трафик по сети, сбалансированно использовать канальную емкость и повышать общее качество сервисов. В качестве критериев для выбора пути следования можно также использовать параметры за пределами сетевых метрик, такие как стоимость каналов/трафика, временные параметры и др.
Экономические преимущества SDN-подхода
Жизненный цикл устройств – от разработки до смены поколений – занимает значительный отрезок времени. Это требует либо перезакладывания характеристик, что приводит к увеличению себестоимости и, как следствие, TCO, либо к более частым циклам перевооружения, что снижает экономическую эффективность устройств.
При улучшении экономической модели за счет снижения требований к аппаратному обеспечению SDN-подход позволяет добиться повышения гибкости построения сервисов и скорости внедрения новых услуг. Благодаря автоматизации управления он способствует сокращению издержек на управление, снижению количества ошибок, связанных с ручным управлением сетью, и уменьшению задержек между обнаружением аварий и корректирующими действиями.
Внедрение проектов на базе технологий SDN – перспектива ближайшего будущего. Уже 2016 г. наверняка ознаменуется массой пилотных проектов, особенно для географически распределенных корпоративных сетей. Скорее всего, эти пилоты перейдут в коммерческую эксплуатацию – слишком уж велики преимущества решений на базе SDN. И следующий логический шаг – использование технологий виртуализации сетевых сервисов (NFV).
[1] Упомянутые в статье возможности стандарта OpenFlow относятся к спецификации OpenFlow 1.3.4.
