На данный момент, мы всё еще находимся на ранней стадии развития архитектуры Software Defined Networking (SDN). Вендоры и открытые сообщества сражаются за доминирующие позиции на развивающемся рынке. Следствием этого стало появление огромного количества SDN-контроллеров. Начинающий изучение SDN легко запутается в таком многообразии. SDNBLOG пытается помочь новичкам и рассказать о двух наиболее перспективных open source проектах.

Решения SDN можно разбить на три основные категории:

  • Академические проекты;
  • Решения с открытым исходным кодом в рамках сообществ;
  • Коммерческие продукты.

Однако, при ближнем рассмотрении становится очевидным следующий факт: несмотря на то, что на рынке присутствует множество SDN-контроллеров, медленно, но верно формируются две лидирующие платформы, обе из мира open source ­– проекты OpenDaylight (ODL) и Open Network Operating System (ONOS). Оба проекта входят в сообщество Linux Foundation.

Этот факт очень важен для развития SDN по следующим причинам:

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

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

Коммерческие продукты нацелены на поддержку своей собственной экосистемы и не более того. На данный момент – это наиболее готовые для использования решения, но не стоит забывать о возможных проблемах с совместимостью и потенциальной привязанности к конкретному производителю… Что бы эти производители не говорили о своей «открытости».

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

Давайте остановимся более подробно на проектах ODL и ONOS.

OpenDaylight (ODL)

Проект OpenDaylight – консорциум крупных производителей, основанный в 2013 году, с целью создания модульного SDN-контроллера. Но, фактически, ODL вырос в огромную платформу, где контроллер – всего лишь её часть.

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

Open Daylight Beryllium
Open Daylight Beryllium. Источник: сайт opendaylight.org

Из схемы выше видно, что ODL за два года достиг серьезного успеха. Масса реализованных модулей, широкий набор Southbound и Northbound интерфейсов. Об этом мы поговорим в других статьях.

Список участников Open Daylight постоянно пополняется. Недавно проект отпраздновал вторую годовщину своего существования, отметив за это время нескольких ключевых достижений:

  • 20 групп проекта включают более 1000 человек;
  • Запуск в эксплуатацию в нескольких организациях, включая операторов связи, гос. учреждения и институты.
  • Серьезный вклад в развитие и стандартизацию YANG-модели – подхода к описанию состояния и конфигурации сетевых устройств;
  • Развитие концепции “Intent Model”, сутью которой является «трансляция бизнес-требований (или, дословно, «намерений») в конфигурации сетевых устройств».

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

Как абстрагировать эту модель от сетевых элементов? Должны ли конфигурационные шаги для конкретной политики быть четко описаны «сверху» или подразумевается, что сетевое устройство само определит необходимые конфигурации для удовлетворения требования?

Это достаточно комплексная и, в то же время, важная задача для реализации концепции «программно-управляемой сети». ODL же является одним из основных проектов в индустрии, где подобные дискуссии хотя бы происходят.

В сообществе Open Networking Foundation и проекте OpenStack Congress также активно обсуждается концепция Intent Model (или Intent Based Networking)

Многие критикуют ODL за то, что в проекте «слишком много вендоров, и недостаточно конечных пользователей» – сервис-провайдеров, корпоративных клиентов и др. Для восполнения пробела была создана ODL Advisory Group – группа, состоящая из ТОП инженеров и архитекторов ведущих корпораций, телекоммуникационных компаний и сервис-провайдеров. Группа корректирует Roadmap, отвечает за проработку use-кейсов и расстановку приоритетов по разработке функционала.

Проект имеет сильную поддержку со стороны вендоров, постоянно выходят обновления платформы, но основных релизов вышло всего три – Hydrogen в феврале 2014 года, Helium в сентябре того же года и Lithium в декабре 2015. Наиболее актуальная версия на момент написания статьи – Lithium-SR3.

Upd. 24.02.16: Появилась новая версия – Open Daylight Beryllium

Наиболее интересный факт касательно ODL – многие вендоры используют код OpenDaylight в качестве «базы» для собственного коммерческого продукта. Вот неполный список SDN-контроллеров:

  • Brocade Vyatta Controller;
  • Extreme Networks OneController;
  • Ciena Multilayer WAN Controller;
  • ConteXtream ContexNet;
  • Cisco Open SDN Controller.

Cisco и Brocade являются одними из основных контрибуторов кода в ODL и платиновыми партнерами проекта, наряду с Citrix, Dell, Ericsson, HP, Intel и RedHat.

Open Network Operating System (ONOS)

OpenDaylight – не единственный SDN контроллер с открытым кодом, получивший широкую поддержку. За последние несколько месяцев серьезно развился проект ONOS от ON.Lab и сейчас находится в зоне пристального внимания многих сервис-провайдеров. Одной из главнейших задач, решаемых ONOS, является масштабируемость. В то время как возможность наращивания мощности SDN-контроллера важна для любой сети, особенно это применимо к операторам связи и сервис-провайдерам.

Почему масштабируемость SDN-контроллера имеет значение? Приложение, работающее на одном x86 сервере ограничено возможностями CPU, памяти, пропускной способностью шины, I/O дисковой подсистемы и другими характеристиками. Производительность ПО будет ограничиваться «узким местом» в системе, будь то память, процессор или дисковая подсистема. Для масштабирования системы, предназначенной для работы в рамках одного сервера, необходимо увеличить мощности этого сервера. Инженеры знакомы с тем, насколько затруднительным может быть процесс апгрейда. Перенос приложения на более мощный сервер – непростая задача, даже в случае виртуальной инфраструктуры.

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

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

Распределенная архитектура ONOS
Источник: Сайт ONOS Project

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

В свою очередь, ONOS – централизованный SDN контроллер, распределенный по нескольким узлам. Разница может быть не так заметна, но очень важна: в ONOS единый распределенный «экземпляр» ПО отвечает за предоставление унифицированного глобального вида сетевой топологии и состояния сети.

ONOS позиционируется как «SDN-платформа для сервис-провайдеров», дифференцируя себя от ODL. Однако, также не исключена возможность использования платформы в распределенных корпоративных сетях. ONOS делает упор и на то, что проект с самого начала включает как вендоров, так и конечных пользователей, «кидая камень в огород» ODL, чьи основатели, в основном, производители.

Хотя корпоративные клиенты вряд ли смогут адаптировать ONOS для применения в своей сети (по крайне мере в том виде, в котором он существует сейчас), архитектура распределенных вычислений может быть для них интересна. Компании, чувствующие, что OpenDaylight имеет узкое место в плане масштабируемости, могут протестировать ONOS у себя в лаборатории, чтобы проверить соответствие архитектуры их требованиям.

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

ONOS выпускает новые релизы ежеквартально. Актуальная версия на момент написания статьи – ONOS Emu, выпущенная в конце 2015 года. ONOS намерен выпускать новые релизы с более высокой частотой чем ODL, хотя они могут включать в себя не так много нововведений, по сравнению с основными версиями ODL.

Ключевые организации, входящие в проект – AT&T, NTT, SK Telecom, Ciena, Cisco, Ericsson, Fujitsu, Huawei, Intel, NEC, Open Networking Foundation и Infoblox.

Аналогично Open Daylight, производители также начинают использовать ONOS в качестве основы для коммерческого продукта. Пока что этим путем пошла только Ciena, которая объявила о выпуске первой коммерческой версии SDN-контроллера ONOS, но в скором времени список вендоров может пополниться.

Еще одним интересным фактом является взаимодействие ONOS и проекта OPNFV, который создает NFV-платформу с открытым кодом для сервис-провайдеров. Предполагается, что ONOS может стать SDN-контроллером в рамках OPNFV, и операторы смогут рассматривать оба проекта в качестве комплексного open source решения.

Выводы

Для рынка SDN, лидирующие позиции вышеописанных проектов предоставляют как минимум два преимущества.

Во-первых, разработчики SDN приложений могут с уверенностью в завтрашнем дне разрабатывать и продавать ПО для ONOS и ODL. Например, приложения, которые могут работать на «открытой» версии ODL, с большой вероятностью будут работать и на коммерческих версиях контроллера. Конечно, это не означает, что у разработчиков приложений для проприетарных платформ (например, Cisco APIC или HP VAN) нет будущего. Однако, подобные усилия сложно капитализировать.

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

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

 

SDNBLOGGER
SDNBLOGGER - команда SDNBLOG, которая занимается поиском наиболее интересных новостей из мира SDN и NFV, а также публикует статьи по тематике. В команду входят ведущие российские специалисты в области технологий SDN и NFV.

НЕТ КОММЕНТАРИЕВ

ОСТАВЬТЕ КОММЕНТАРИЙ