Революционные технологии всегда являются загадкой: взлетит — не взлетит, перейдут — не перейдут, будет у всех или забудут через полгода… Одни и те же вопросы мы повторяем себе каждый раз при встрече с чем-то действительно новым, но одно дело, если мы говорим о очередной соцсети или тренде на вид интерфейса и совсем другое, если дело касается промышленного стандарта.
OpenFlow, как составляющая часть концепции SDN в виде протокола управления между соответствующими контроллерами и коммутаторами, появился по мерками компьютерной индустрии уже сравнительно давно — 31 декабря первая версия стандарта отметит свое пятилетие. Что же в итоге мы получили? Давайте смотреть и разбираться, тем более, что история весьма интересная.
Сперва давайте вспомним, что подразумевает концепция Программно Конфигурируемых Сетей (Software Defined Networks, SDN), в рамках которой подразумевается использование OpenFlow.
Архитектура
Если не углубляться в дебри теории, то концепция предполагает для сетевой инфраструктуры отделить уровень передачи данных от уровня управления. В итоге на уровне данных сравнительно простые коммутаторы оперируют потоками данных сообразно заложенным в таблицы правилам. Правила же задаются централизованными контроллерами сети, в задачу которых входит анализ новых потоков (пакеты которых им пересылают коммутаторы) и выработка для них правил маршрутизации на основе заложенных в контроллер алгоритмов.
В целом, алгоритм действий, вызываемых приходом пакета на порт коммутатора, радикальных изменений не претерпел, поменялись лишь функциональные модули алгоритма: контроллер стал дальше и централизованным, а локальные таблицы — более сложными.
Возможные действия
Вся сетевая инфраструктура получила высокую степень виртуализации — виртуальные порты и коммутаторы управляются точно также, как и физические.
Страницы истории
Положив руку на сердце скажем честно: та самая вышедшая аккуратно под новый год первая версия стандарта OpenFlow 1.0, ответственного за связь коммутаторов и контроллеров и, по большому счету, вообще за маршрутизацию данных в сети, была скорее ознакомительной, чем реально рабочей. Да, она описывала базовое функционирование в рамках нового протокола, но в ней не было поддержки настолько большого количества необходимых функций, что говорить о реальном применении не приходилось. Поэтому последующие 2,5 года шло допиливание стандарта: добавляли множественные таблицы обработки, поддержку меток, поддержку IPv6, гибридный режим работы коммутаторов, контроль скорости потоков, резервные каналы связи коммутаторов и контроллеров, — уже по одному этому списку можно понять, насколько неполным был исходный стандарт. Поэтому лишь после 25 июня 2012 года с появлением версии 1.3.0 можно говорить о готовности стандарта к использованию. Дальнейшее развитие до текущей версии 1.4 можно охарактеризовать уже как незначительные изменения с ликвидацией ошибок.
Ну хорошо, вот уже два года как у нас есть полноценный стандарт, про который нам рассказывали, что это новая парадигма построения сетей, все будет стильно-модно-молодежно, OPEX и CAPEX упадут ниже плинтуса и прочие полагающиеся в таких случаях вещи. Так почему же до сих пор не видно повсеместного энтузиазма в вопросах внедрения новинки? Тому есть несколько причин из категории «гладко было на бумаге, да забыли про овраги».
Проблемы
1. Контроллеры
Несложно догадаться, что при такой концепции всей системы особенно важным становится выбор контроллера OpenFlow. Именно его быстродействие станет решающим фактором при возникновении любых экстренных ситуаций, именно его алгоритмы будут определять эффективность работы всей сети, именно его сбой с большой степенью вероятности «положит» всю сеть. На первый взгляд выбор контроллеров более чем велик: Open DayLight, NOX, POX, Beacon, Floodlight, Maestro, SNAC, Trema, Ryu, FlowER, Mul… есть даже RUN OS, разработанный в России ребятами из ЦПИКС. И это все не считая контроллеров от грандов, таких как Cisco, HP, IBM.
Проблема в том, что если мы берем контроллер с открытой архитектурой, то получаем, по большому счету, не готовое решение, а заготовку, в которую надо вложить изрядное количество сил, приводя ее возможности к необходимым в рамках вашей задачи. Для компаний уровня Google или Microsoft это, очевидно, не является проблемой. Для всех остальных, рангом пониже, это приводит к необходимости в собственном штате программистов, великолепно разбирающихся в сетевых технологиях. Ну и, естественно, требует существенного времени на подготовку проекта к запуску, а также создает изрядные риски, связанные с уникальностью и невозможностью широкомасштабного длительного тестирования.
Альтернативным вариантом является приобретение готовых коммерческих контроллеров. Но здесь мы получаем то, от чего все стремятся уйти, выбирая варианты, начинающиеся со слова «Open» — закрытые архитектуры с их неизвестной логикой работы, полная зависимость от поставщика при любых проблемах, вопросы совместимости, проприетарный дополнительный функционал, привязывающий, опять же, к конкретному производителю.
2. Вопросы архитектуры
Вынос плоскости управления из коммутаторов в отдельное устройство и централизация управления создает, пожалуй, столько же архитектурных вопросов, сколько и решает, поскольку возвращает нас к старому диспуту о эффективности и проблемах централизованного управления при сравнении с распределенным.
- Что происходит в случае выхода контроллера из строя?
- В случае резервирования контроллеров как осуществляется их связь и принятие решения о главенстве/передачи функций?
- По каким каналам связи осуществляется взаимодействие контроллера/ов и коммутаторов, по основной структуре передачи данных или параллельной? Что происходит при проблемах на линии связи?
И решение этих вопросов без права на ошибку должно происходить на этапе планирования сети.
3. Совместимость
Казалось бы, раз уж речь идет об открытом стандарте, то достаточно себя огородить от неминуемо появляющихся проприетарных решений, как в рамках одной версии стандарта все станет прекрасно. Но не тут то было. Из-за несовершенства железа в разных режимах функционирования изрядное количество проверок полей и даже экшенов может просто не поддерживаться на уровне коммутационной матрицы. А самое печальное, что узнать информацию такого уровня крайне сложно, поскольку производители крайне неохотно выкладывают ее в открытый доступ. И тут мы плавно переходим к следующему пункту…
4. Готовность коммутаторов
Если мы выносим план управления из коммутаторов — они должны стать проще. Так, да не совсем: новый протокол, а точнее огромное количество учитываемых по умолчанию полей в таблицах маршрутизации выдвигает повышенные требования к объемам памяти на коммутаторах.
Знаменитые 12 tuples базового стандарта
Они же, расширенные метками
Тут необходимо вспомнить, что в современных высокоскоростных коммутаторах для хранения таблиц используется TCAM (Ternary Content Addressable Memory) — это единственный адекватный по скорости поиска информации способ хранения данных, от которого невозможно никуда деться, если мы хотим заниматься коммутацией и маршрутизацией на скоростях интерфейса. И стоит TCAM достаточно дорого. Поэтому даже коммутаторы на мощных относительно современных ASIC'ах порой могут поддерживать OpenFlow исключительно формально, обеспечивая менее тысячи OF-записей в TCAM. В принципе, можно было бы организовать многоуровневое хранение записей, сделав в TCAM буфер для самых актуальных записей и сложив в оперативную память все остальное, но для этого необходимо весьма ощутимо модифицировать платформу коммутаторов, большинство существующих моделей на такое просто не способно.
И это не говоря о том, что многие ASIC в принципе не способны поддерживать часть заявленных в OpenFlow функций, поскольку попросту не имеют их поддержки «в кремнии».
Пример реально поддерживаемых полей и экшенов
Конечно, этот недостаток легко купируется добавлением к ASIC сетевых процессоров (NPU) с высокой степенью программируемости, но это сразу влечет ощутимый рост как энергопотребления, так и стоимости. А это уже, в свою очередь, вызывает вопрос о целесообразности всей затеи, поскольку вместо упрощения и удешевления конечных устройств мы получим строго обратное.
Все плохо?
Так что же, все плохо и у нового стандарта нет шансов?
Вовсе нет, если не верить всем обещаниям восторженных апологетов новых технологий и здраво оценивать возможности нового стандарта, то его уже сейчас вполне можно использовать себе на благо.
Большую часть вопросов озвученных выше вопросов можно успешно решить на стадии проектирования сети, тщательно подойдя к выбору оборудования. Хорошо выбранный контроллер (коммерческий или открытый, но дописанный «под себя»), продуманная архитектура, подобранные коммутаторы (например, такие как Eos420 на матрице Broadcom Trident 2 или Eos 410i, построенный на матрице Intel FM6764 с одной из самых больших в классе таблиц TCAM), и работоспособная сеть на OpenFlow 1.3 становится реальностью.
Не верите, что это доступно кому-либо, не являющемуся огромной Корпорацией Добра? Спросите компанию Перформикс, вот уже год имеющую стабильную сеть на OpenFlow в продакшн.
В общем, не так уж и страшен зверь, под названием OpenFlow, хотя, конечно, до повсеместного внедрения ему еще далеко. Но строить небольшие высокопроизводительные узкоспециализированные сетевые структуры на OpenFlow уже можно без вовлечения существенных усилий разработчиков. Более того, это может стать уникальным сочетанием производительности, удобства и управляемости при невысокой стоимости.
Светлое будущее?
Матрица Intel FM6764 уже обещает программируемость (для хардкорных любителей регистров), текущие продукты остальных разработчиков менее открыты.
Недостаток аппаратных возможностей остальных современных ASIC обещают решить в следующих поколениях, которые выйдут на рынок в 2015 году. Такие продукты показал Broadcom — его матрица Tomahawk может настраиваться для поддержки разных forwarding/match/action.
В свою очередь, Cavium обещает полностью программируемую матрицу XPliant, в которой будет возможно добавлять новые протоколы по мере их появления с сохранением line-rate скорости обработки.
Структура XPliant
Да и спрос на OpenFlow решения со стороны традиционных операторов связи подстегнет прогресс.
P.S. При подготовке этой статьи мы не поленились и перечитали статьи на хабре по тегам SDN и OpenFlow — довольно любопытно посмотреть как на оптимистов, так и на пессимистов с позиции прошедших 2-3 лет. Не будем ехидствовать, заметим лишь, что делать прогнозы на будущее — дело неблагодарное.
P.P.S. интересующимся темой SDN рекомендуем статью на «профильном» сетевом ресурсе NAG:
nag.ru/articles/reviews/26333/neodnoznachnost-sdn.html
интересны как сама статья, так и комментарии к ней.
Автор: ETegro_Technologies
