В конце марта 2011 года компании Deutsche Telecom, Facebook, Google, Microsoft, Verizon и Yahoo, операторы и владельцы ряда крупнейших мировых сетей и центров обработки данных, объявили о создании Open Networking Foundation, некоммерческой организации, целями которой являются продвижение и стандартизация принципиально нового подхода к передаче данных — программируемой сетевой инфраструктуры, или Software Defined Networking. Спустя три месяца организация объединяла уже 42 участника, а программно определяемые сети и протокол OpenFlow стали постоянной темой новостей и блогов разработчиков и производителей сетевого оборудования.

 

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

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

ВРЕМЯ ПЕРЕМЕН?

Ключевые сетевые протоколы были разработаны на заре Интернета и Ethernet, когда невозможно было даже представить современные скорости и объемы передаваемых данных. Если бы сегодня существовала возможность разработать их с чистого листа и с учетом всего накопленного опыта, скорее всего, они оказались бы абсолютно иными.

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

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

ВЫНОС ИНТЕЛЛЕКТА

При продвижении кадров данных коммутатор Ethernet подает запрос к таблице коммутации. Затем на основании полученной информации, в том числе адреса порта получателя, параметров качества обслуживания и т. д., коммутационная матрица осуществляет дальнейшую обработку и передачу данных на целевой выходной порт (см. Рисунок 1).

Рисунок 1. Обработка и продвижение данных в коммутаторе.

 

В обычном коммутаторе Ethernet одновременно реализуются и уровень управления, и уровень передачи данных. Уровень управления представлен встроенным микроконтроллером, уровень передачи данных — таблицей коммутации и коммутационной матрицей (см. Рисунок 2). Обладая некоторыми интеллектуальными функциями, микроконтроллер сам принимает решения о продвижении кадров на основе собранной им информации о структуре сети, которая зачастую имеет лишь отдаленное отношение к подлинной топологии сети (карта не является территорией). Непосредственно управлять принятием решений нельзя — можно лишь конфигурировать микроконтроллер, задавая определенные наборы правил и приоритетов. Это накладывает заметные ограничения на функциональность коммутатора и всей сети. В частности, для организации связей «каждый с каждым» в такой сети не обойтись без коммутаторов третьего уровня — маршрутизаторов (см. Рисунок 2).

Рисунок 2. Функциональная схема традиционного коммутатора Ethernet и сети «каждый с каждым»: без маршрутизаторов не обойтись.

 

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

Центральный контроллер имеет точную информацию о структуре и топологии сети. Это позволяет оптимизировать продвижение кадров и, в частности, прокладывать связи «каждый с каждым» на уровне L2, не прибегая к IP-маршрутизации (см. Рисунок 3), и, кроме того, предварительно «коммутировать» каналы передачи данных на всем пути от источника до пункта назначения. В результате по сети передаются уже не отдельные кадры, а потоки данных.

Рисунок 3. Коммутатор OpenFlow использует для заполнения таблиц потоков центральный контроллер сети. Знание топологии позволяет строить сети «каждый с каждым» на уровне L2.

 

Как следствие, в терминологии OpenFlow таблица коммутации получает иное название, более точно отражающее суть происходящих процессов, — таблица потоков. У каждого коммутатора своя, уникальная таблица потоков. Эту таблицу он заполняет только на основании информации, полученной от центрального контроллера. Центральный контроллер, в свою очередь, строит таблицы потоков, взаимодействуя с ПО более высокого уровня — платформами виртуализации центров обработки данных и др.

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

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

СТАНДАРТЫ

Протокол OpenFlow 1.0, принятый в конце 2009 года, специфицировал идентификаторы потоков и моделей коммутаторов, статистику по портам, квантование исходящих портов на потоки с гарантированной пропускной способностью (Slicing), обработку полей ToS/DSCP и запросов ARP. Это позволяет использовать его в кампусных сетях и проектах по виртуализации сетей центров обработки данных.

Работа над протоколом была продолжена, и в марте 2011 года свет увидела спецификация OpenFlow 1.1, в которую была добавлена функциональность, необходимая для операторских сетей: множественные таблицы потоков, маршрутизация по множественным равнозначным каналам (Equal Cost Multi-Path, ECMP), многопротокольная коммутация на основе меток (Multiprotocol Label Switching, MPLS).

Таблицы потоков, объединенные в древовидные структуры, позволяют более эффективно использовать ассоциативную память TCAM и реализовать практически любые сценарии обработки и продвижения данных. Поддержка ECMP помогает средствами OpenFlow, на втором уровне модели OSI, решить задачи, за которые традиционно отвечают коммутаторы третьего уровня. Поддержка меток MPLS — эмулировать обработку протоколов MPLS на действующем (и относительно недорогом) оборудовании программными средствами.

ПРИМЕНЕНИЕ В ЦОД…

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

Сети IP могут быть любого размера, но накладывают определенные ограничения на перемещение виртуальных и реальных машин между подсетями IP. Пропускная способность сетей Ethernet в традиционной архитектуре доступ/агрегация/ядро тоже далека от максимально реализуемых значений и требований решаемых задач. Как результат, все большую популярность приобретают распределенные коммутационные матрицы (Fabric), уменьшение числа уровней агрегации трафика и ячеистые сетевые структуры (Mesh). Редкий производитель сетевого оборудования для центров обработки данных не предлагает сегодня соответствующих решений. Увы, как правило, они не совместимы друг с другом и ограничивают для оператора ЦОД выбор поставщиков сетевого оборудования. Масштабы современных центров обработки данных еще больше затрудняют такой выбор.

OpenFlow обещает решить многие из существующих проблем благодаря использованию стандартных строительных блоков — коммутаторов потоков с единым интерфейсом управления/программирования, отсутствию практических ограничений на размеры сегментов второго уровня, возможности организации детерминированных скоростных каналов (потоков) «каждый с каждым», виртуализации сети центра обработки данных и абстрагированию от ее реальной физической структуры.

Потенциальные преимущества OpenFlow и программируемой сетевой инфраструктуры для сетей ЦОД:

  • создание программируемой распределенной среды передачи данных с минимальными задержками и высокой пропускной способностью;
  • неблокируемая передача данных на уровне L2 со скоростью поступления пакетов;
  • множественные параллельные пути передачи данных с быстрым восстановлением после ошибок;
  • замена остовного дерева, формируемого протоколами xSTP, на ячеистые структуры, обеспечивающие кратчайшие соединения «каждый с каждым»;
  • простое конфигурирование, настройка и предоставление услуг программными средствами вместо конфигурирования отдельных коммутаторов;
  • бесшовная интеграция с программными платформами виртуализации сетей центров обработки данных и предоставления услуг.

… И ОПЕРАТОРСКИХ СЕТЯХ

Сетевая нейтральность. Коллективное использование несколькими операторами общей сетевой инфраструктуры становится распространенной практикой — одним из недавних и характерных примеров является создание в России консорциума «Союз LTE», в рамках которого планируется создание единой сети LTE Advanced. Услуги на базе этой сети будут предоставлять четыре компании — МТС, «Вымпелком», «Мегафон», «Ростелеком», а может статься, и пятая — Yota, как создатель сетевой инфраструктуры. Сетью планируется охватить все населенные пункты России с населением более 1000 жителей, причем каждый оператор должен установить по 29 тыс. базовых станций. Согласно предварительным оценкам, затраты на создание национальной сети превысят 340 млрд рублей и окупятся не ранее чем через семь-восемь лет. В случае строительства независимых сетей, по разным оценкам, потребовалось бы значительно большее время — до 10–16 лет. В рамках проекта Nando ученые испанского Университета страны Басков доказали, что с помощью OpenFlow и префиксов Ethernet PF можно не только строить мультиоператорские сети Ethernet второго уровня, но и значительно снизить затраты на создание сети, надежно разделить трафик разных абонентов и операторов и предотвратить неавторизованный доступ.

Многопротокольная маршрутизация. Еще один проект, SPARC, нацелен на разработку и тестирование сетей доступа MPLS, в которых протокол OpenFlow призван обеспечить разделение уровней управления и продвижения данных и взаимодействие с опорными сетями IP/MPLS. В реализации поддержки MPLS активно участвовала и компания Ericsson.

Голосовая и видеосвязь. Согласно прогнозам Cisco, через пару-тройку лет 90% сетевого трафика будет занято видео. Часть этого объема придется на видеосеансы и видеоконференции, часть — на видеотрансляции. Видеотелефония потребует передачи больших потоков данных с жесткими требованиями к значениям задержек и их вариациям. Используя связку протоколов SIP/OpenFlow можно будет не только устанавливать IP-адреса отправителя и получателя, но и программным способом коммутировать необходимые потоки и каналы данных в операторских сетях — не исключено, еще до начала передачи данных.

Беспроводной роуминг. В рамках проекта OpenRoads разработчики Стэнфордского университета, используя эшелонированные сети OpenFlow из коммутаторов, точек доступа WiFi и базовых станций WiMAX, на практике продемонстрировали бесшовный, без разрыва соединения, роуминг между беспроводными сетями передачи данных разных стандартов.

Список можно продолжить…

В ЖЕЛЕЗЕ И ПЕСКЕ

В настоящее время поддержка протокола OpenFlow 1.0 реализована в коммутаторах множества производителей — Extreme Networks, Cisco, Juniper, IBM, HP, NEC, Huawei и некоторых других. Как правило, поддержка реализуется программно, заменой прошивки коммутатора. Так, по заявлениям разработчиков HP Labs, коммутаторы серий HP E3500, E5400 zl и E6600 с поддержкой OpenFlow используются в проектах более 30 организаций по всему миру, представители компании Extreme Networks сообщают об успешном тестировании коммутаторов Extreme Networks Summit X460 и X480 в связке с контроллерами Стэнфордского университета и коммерческим контроллером BigSwitch.

Изменения, внесенные в спецификацию OpenFlow 1.1, оказались настолько существенными, что некоторые аналитики поспешили выступить с заявлениями о годах, которые потребуются на реализацию новшеств в микропрограммах сетевых процессоров и коммутаторов. Однако уже через три месяца, в июле 2011-го, компания EZChip Semiconductor опубликовала пресс-релиз, в котором сообщила о реализации OpenFlow 1.1 в микропрограммах для сетевого процессора NP-4 сразу несколькими независимыми группами разработчиков, в том числе исследователями Монреальского университета. О масштабе потенциально решаемых задач можно судить по возможностям NP-4: EZChip предлагает использовать этот процессор с пропускной способностью 100 Гбит/с в линейных картах, коммутаторах, маршрутизаторах и устройствах глубокой инспекции трафика операторских сетей и сообщает о поддержке синхронного Ethernet, расширенных возможностях управления трафиком видео и приложений. Как ожидается, к поставкам первых устройств с NP-4 на борту до конца года приступят компании Ericsson, Huawei и ZTE, а в I квартале 2012-го появятся модули для коммутаторов Cisco Catalyst-6500/7600.

Как уже отмечалось, коммутаторы OpenFlow 1.0, включая коммерческие, с технической поддержкой, доступны уже сейчас, в том числе для сетей 40G Ethernet. Использование системы на кристалле Broadcom Trident BCM56840 и собственной программной архитектуры открытого коммутатора (Open Switch Software Architecture, OSSA) позволило компании Pronto вывести на рынок две модели устройств OpenFlow для центров обработки данных: Pronto 3980 с 16 портами 40 Гбит/с и Pronto 3920 с 48 портами 10 Гбит/с и четырьмя 40 Гбит/с. Оба коммутатора имеют пропускную способность 1,28 Тбит/с при цене немногим выше 10 тыс. долларов. Поддержка OpenFlow доступна и для сетевых процессоров Quanta LB4G, Broadcom 56634, Broadcom 56820 и т. д.

Еще одна модель коммутатора OpenFlow, на этот раз виртуального, вошла в состав платформ виртуализации XenServer 5.6 Feature Pack 1 и последующих версий. По заявлениям компании Citrix, использование OpenFlow, наряду с другими новшествами, реализованными в виртуальных коммутаторах Open vSwitch, обеспечивает прирост производительности до 70%. Более того, как заявляется, Open vSwitch может управлять и аппаратными коммутаторами Ethernet с поддержкой OpenFlow.

В общем и целом сегодня битва за OpenFlow происходит в секторе наукоемких коммутаторов для критических приложений: именно там имеется платежеспособный спрос, и именно оттуда — если, конечно, будут востребованы — технологии SDN и OpenFlow пойдут в наступление на другие секторы рынка.

OPENFLOW В РОССИИ И В МИРЕ

История OpenFlow, вне всякого сомнения, только начинается. Будучи протоколом нижнего уровня, он нуждается в обширной программной надстройке, созданием которой занимаются более 70 компаний и университетов всего мира. На карте проектов отмечены США, Европа, Бразилия, Индия, Китай, Япония. Есть даже Африка…

Нет лишь России — на схемах здесь, по крайней мере пока, девственно чистая территория. Пытаясь найти хоть какие-то следы OpenFlow, я буквально прошерстил российский Интернет, обзвонил нескольких своих знакомых, в том числе профессионально занимающихся разработкой российских суперкомпьютеров и эксплуатацией коммерческих ЦОД. Казалось бы, преимущества OpenFlow в гибкой организации детерминированных скоростных каналов и построении масштабных матричных структур со связями «каждый с каждым» могли бы быть востребованы при объединении системных блоков — составных элементов суперкомпьютеров. Как выяснилось, для текущих задач вполне хватает возможностей, уже реализуемых коммутаторами Ethernet и Infiniband. Операторы ссылались на небольшой размер центров обработки данных: масштабные облачные проекты — впереди, а пока потребности заказчиков можно удовлетворить с помощью имеющихся технологий и ресурсов.

 

Extreemальный OpenFlow

Механизмы и идеи, заложенные в технологию OpenFlow, очень перспективны и обязательно будут востребованы рынком. Стимулом для спроса станут прежде всего экономические факторы: унифицированные коммутаторы, работающие с внешними управляющими контроллерами (без собственной Control Plane), будут стоить существенно меньше, чем полнофункциональные устройства.

Extreme Networks постоянно взаимодействует с университетами и участвует в их разработках и исследованиях. По направлению OpenFlow компания тесно сотрудничает не только со Стэнфордским университетом, ставшим родоначальником этой технологии, но и еще с тремя — с Массачусетским, Эссекским и Вашингтонским. Интерес к OpenFlow наблюдается и со стороны коммерческих заказчиков.

Технология OpenFlow может быть реализована в двух типах коммутаторов:

  • OpenFlow-only switch реализует только основные клиентские функции протокола OpenFlow;
  • OpenFlow-capable switch поддерживает основные клиентские функции протокола OpenFlow, а также стандартные функции коммутаторов (STP, LAG и т. д.).

Коммутаторы Extreme Networks относятся ко второй разновидности. Это позволяет, с одной стороны, уменьшить их стоимость, а с другой — очень гибко использовать в уже существующих инфраструктурах ЦОД и существенно упростить процесс перехода на OpenFlow.

Первой компанией, решившейся на тестирование и внедрение технологии OpenFlow в России, стала «Крок», которая уже сейчас внедряет технологию OpenFlow в облачной сети, построенной на основе сетевого оборудования Extreme Networks.

В данный момент проводится тестирование модуля OpenFlow для ExtremeXOS на коммутаторах Extreme Networks Summit X460 и X650. Тестирование проходит успешно и показывает хорошие результаты. К началу следующего года мы планируем выпустить промышленный релиз ExtremeXOS с поддержкой OpenFlow. — Сергей Гусаков, технический директор Extreme Networks Россия и СНГ.

 

Тем не менее некоторые производители уже сегодня предпринимают определенные действия по продвижению программных сетей и открытых стандартов программно-сетевого взаимодействия. В частности, рассказу о возможностях Open Fabric — новой сетевой платформы Extreme Networks для центров обработки данных, во многом основанной на OpenFlow, — посвятил свой доклад на конференции «Мир ЦОД 2011» Борис Гермашев, региональный директор Extreme Networks в России и СНГ(см. врезку «Extreemальный OpenFlow»). Находит свое применение OpenFlow и в центрах обработки данных «Крок» (см. врезку «OpenFlow в облаке ‘‘Крок’’»).

 

OpenFlow в облаке «Крок»

В облаке «Крок» OpenFlow применяется для виртуализации сетевой инфраструктуры: эта услуга доступна заказчикам в рамках предложения IaaS — виртуального центра обработки данных. Благодаря OpenFlow они могут развертывать и настраивать виртуальные сети в режиме самообслуживания, причем речь идет о виртуальных сетях Ethernet на втором сетевом уровне — не об IP-виртуализации. Вследствие этого в нашу инфраструктуру можно перенести, в том числе, экзотические и устаревшие приложения, где используются, скажем, протоколы IPX.

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

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

Основное преимущество OpenFlow — снятие вышеперечисленных ограничений традиционных технологий. Полностью оно проявляется только при использовании средств автоматизации управления, без которых самообслуживание невозможно. Но это уже наш секрет. — Руслан Заединов, руководитель направления центров обработки данных «Крок».

 

А ведь Россия, с ее традиционно сильными программистами и тем более опытом разработки суперкомпьютеров, могла бы практически на равных участвовать в создании как нового направления, так и нового поколения сетей. Ждем-с?

Георгий Башилов — научный редактор «Журнала сетевых решений/LAN».

Поделитесь материалом с коллегами и друзьями

Купить номер с этой статьей в PDF