Развитие и внедрение SDN
Идет уже восьмой год с момента появления, пожалуй, одной из самых революционных концепций в сетевых технологиях за последнюю пару десятилетий. В сейчас уже далеком 2006 году, в стенах Стенфордского университета несколько единомышленников, сами того не подозревая, перевернули мир. По крайней мере, мир компьютерных сетей точно.
Несмотря на столь почтенный по меркам высоких технологий возраст самой идеи Software Defined Networking (SDN), о которой мы сегодня и поговорим, или, как называют ее специалисты в России — идеи программно-конфигурируемых сетей (ПКС), активные обсуждения и первые пробы коммерческого применения стали актуальны только в последние два года.
Причин достаточно долгой адаптации SDN даже хотя бы к тому состоянию, когда технология может заинтересовать бизнес в качестве «лабораторной», то есть такой, на которую, по крайней мере, стоит обратить внимание и, может быть, потратить небольшой бюджет на ее исследование, несколько.
История компьютерных сетей насчитывает несколько десятков лет. За такой, достаточно долгий, период рождалось множество технологий, обещавших переворот во всем, что касалось строительства и развития сетей. Но так же стремительно многие из них и умирали. Вспомним, например, тот же ATM, Frame Relay или ISDN, по своему революционные и многообещающие для своего времени. Развивались и преображались стандарты, появлялись и умирали производители сетевого оборудования, обещавшие, что их технологии изменят мир.
Как и для всего нового, пожалуй, основным препятствием на пути повсеместного внедрения ПКС является сама революционность идеи, которая на самом деле проста, как все гениальное. Жесткое разграничение уровня принятия решений по коммутации трафика в сети и уровня непосредственной реализации этого решения не является чем-то новым. Разделение сетевых устройств на логические уровни Control-Plane, где принимаются решения, и Data-Plane, на котором осуществляется непосредственная отправка трафика, существует давно. Однако концепция SDN предлагает вывести такое разграничение на совершенно иной уровень. Если все устройства в сети вынуждены принимать одни и те же решения, все устройства так или иначе реализуют тот самый уровень Control-Plane, который выполняет одни и те же функции, независимо от места устройства в сети. Эти решения едины, по сути, для всей сети в целом, почему бы не реализовать этот уровень один раз и всего на одном устройстве? Такое устройство впоследствии, в терминологии ПКС станет называться контроллером.
Что все это означает на практике? Да то что общепринятые технологические стандарты работы сетей, направленные в первую очередь на принятие таких решений, например, такие, казалось бы, основополагающие и неприкосновенные вещи, как протоколы динамической маршрутизации (RIP, OSPF, IS-IS, BGP), становятся не нужны. Парадигма ПКС предлагает отказаться от всего привычного и подойти к сетям с совершенно другой стороны. И здесь находится не так уж много организаций, готовых взять и в один момент полностью изменить свои взгляды на сетевую инфраструктуру и построить ее по новым принципам, не имея ни своего опыта, ни примеров реализации у других.
Традиционно лоббистами нового в мире сетевых технологий являются сами производители сетевого оборудования. Именно они, как никто другой, заинтересованы в продвижении инновационных решений. Именно они должны быть генераторами идей и опыта, а также основными консультантами для организаций, внедряющих новые технологии. Но SDN появился на свет вне стен исследовательских центров какого-то конкретного вендора. Концепция родилась без участия консультантов и средств игроков рынка сетевых решений. И в этом состоит второе большое препятствие на пути повсеместного внедрения ПКС.
Для производителей сетевых решений SDN представляет вполне определенную угрозу. На фоне общей консьюмеризации сетевого оборудования и, как следствие, его удешевления, SDN еще больше нивелирует различия между решениями различных сетевых вендоров. Контроллер сети ПКС, в котором сосредоточен весь интеллект для управления сетью, является продуктом программным. А какие конкретно устройства будут выполнять функции по непосредственной отправке трафика в нужный порт, в общем-то неважно, главное, чтобы хватало производительности под все имеющиеся задачи. Ярким примером может служить перевод сети компании Google, объединяющей ЦОДы по всему миру, на технологию SDN. Для ввода этой сети в эксплуатацию Google не потребовались услуги ни одного из производителей сетевых решений. Они создали и использовали свой собственный коммутатор для работы под управлением контроллера ПКС. Напомню, что до этого компания Google не имела абсолютно никакого опыта разработки сетевых устройств.
Необходимость контролировать развитие столь опасного направления, каким для вендоров является концепция ПКС, привела к появлению нескольких технологических альянсов, таких как, например, Open Networking Foundation. На практике подобные альянсы, скорее, тормозили развитие SDN, чем помогали ему, тем самым давая вендорам, состоящим в этих организациях, время на передышку и разработку собственной тактики обуздания и использования ПКС.
Если посмотреть на сетевых производителей сегодня, то практически все заявляют о наличии решений SDN в своем портфеле продуктов. Однако если присмотреться к этим решениям повнимательнее, выяснится, что они не вполне соответствуют всей красоте изначальной задумки ученых из Стенфорда. Последние основное внимание уделяли аспекту открытости всех протоколов работающих в ПКС. И первым результатом работы ученых стало появление на свет открытого протокола OpenFlow, описывающего правила взаимодействия между «мозгом» сети — контроллером, и коммутаторами, выполняющими его волю. Однако общие открытые стандарты также подразумевались и на уровне выше — на уровне взаимодействия приложений с контроллером, а значит, и со всей сетью.
Производители сетевых решений сегодня предлагают своим клиентам гибридный подход. Он заключается в том, что оборудование остается прежним, Control-Plane с него полностью не исчезает. На некоторые линейки устройств добавляется поддержка протокола OpenFlow, для того чтобы можно было заявлять о совместимости с «классическим» SDN. Cама реализация концепции ПКС, как правило, заключается в наличии собственного «закрытого» контроллера и собственных API для взаимодействия сторонних программ с сетью конкретного производителя. Интерфейс, описанный для этих программ, будет работать, соответственно, только с оборудованием этого производителя. Удобно, не правда ли? С одной стороны полная поддержка и реализация идеи Software-Defined Networking, с другой — полная гарантия того, что клиенты будут использовать только определенное оборудование и будут сильно ограничены закрытыми технологиями.
Закрытость и, как следствие, разнородность доступных организациям платформ SDN от сетевых производителей, естественно, не способствует свободной разработке в условиях здоровой конкуренции непосредственно сервисов и приложений, которые могли бы быть интересны бизнесу и которые могли бы стать тем самым поводом пересмотреть подход к организации сетей в пользу концепции ПКС. Отсутствие большого числа приложений, имеющих коммерческую ценность для организаций, задумывающихся об использовании ПКС, является еще одним, третьим препятствием для тотального принятия новой концепции.
Однако есть и альтернативный путь, который может выбрать для себя производитель сетевых решений. Заключается он в использовании открытых стандартов на всех уровнях реализации концепции программно-конфигурируемых сетей, как на уровне контроллер-коммутатор, так и на уровне интерфейса приложение-контроллер, или, что более точно, интерфейса приложение-сеть. Для стремительного развития рынка приложений ПКС важно позволить разработчикам программных средств беспрепятственно использовать интерфейс приложение-сеть, основанный на открытых стандартах, ни чем не привязанный к конкретной реализации конкретного производителя.
Одним из самых быстро развивающихся проектов, целью которых является разработка контроллера сети ПКС с открытым исходным кодом и свободным доступом к API является Open Day Light.
Только открытые стандарты могут помочь нарастить пул приложений, привлечь инвестиции в создание новых стартапов и генерацию новых идей, обеспечить цепную реакцию выхода востребованных приложений для сетей SDN и повышения интереса к самой платформе. Примером того, что это действительно работает, может послужить история операционной системы Android, API к которой находится в открытом доступе и полностью абстрагирован от конкретной аппаратной реализации устройства, работающего под управлением этой ОС.
Сетевые производители, использующие открытые платформы там, где требуется привлечение инвестиций со стороны разработчиков программных средств, остаются в выигрыше. Использование открытой платформы ничуть не мешает также предлагать добавленную ценность за счет собственных разработок. С точки зрения заказчика это можно рассматривать как бонус: собственные надстройки и технологии, полностью интегрированные с открытыми технологиями.
Еще один важный аспект — возможность использования преимуществ SDN без замены сетевого оборудования. И здесь выигрывают те сетевые производители, которые предлагают поддержку стандарта OpenFlow н максимальном количестве продуктов в портфеле производителя.
Только открытые технологии и мягкая миграция, не требующая полной замены всего сетевого оборудования, которое закупалось на протяжении последних нескольких лет, и сможет дать толчок повсеместному использованию столь революционной, но в то же время столь многообещающей технологии как Software-Defined Networking. Которая однажды обязательно изменит наш мир. К лучшему.
