SDN: кому и зачем это надо?

SDN стремительно ворвалась в мир сетевых технологий, став хедлайнером многих конференций и форумов, включая Ethernet-форум, проведенный в октябре «Журналом сетевых решений/LAN». И хотя на слух многие еще путают ее с ISDN, это только повышает градус интереса. Так что такое SDN? Гениальная идея университетских исследователей, которую по силам реализовать только таким гигантам, как Google, Facebook или Yahoo? Или «второй Ethernet», который вскоре станет основой сетей разного масштаба и назначения?

Используемые в русскоязычной литературе переводы термина Software-Defined Networking, такие как «программно определяемые» или «программно конфигурируемые» сети, не отражают основную идею данной концепции. Согласитесь, конфигурирование сетей уже давно осуществляется посредством программного обеспечения, поэтому что же здесь нового и тем более революционного?! Потому за отсутствием адекватного русскоязычного термина будем использовать английскую аббревиатуру.

В ОЖИДАНИИ ПЕРЕМЕН

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

Главная проблема: традиционные сети слишком статичны и потому не соответствуют динамике, свойственной современному бизнесу, в отличие от серверов — чем последние обязаны технологиям виртуализации. Сегодня приложения распределены между множеством виртуальных машин, которые интенсивно обмениваются данными (что ведет к росту трафика запад — восток, который начинает доминировать над традиционным для архитектур клиент-сервер трафиком север — юг). Для оптимизации загрузки серверов виртуальные машины часто мигрируют, что меняет точки «привязки» трафика. Традиционные схемы адресации, логического деления сетей и способы назначения правил обработки трафика в таких динамичных средах становятся неэффективны.

Например, при запуске новой виртуальной машины, реконфигурирование списков контроля доступа (ACL) на всех сетевых устройствах в крупной сети может занять несколько дней. Причина — ориентация имеющихся инструментов управления на работу с отдельными устройствами: в лучшем случае автоматизация назначения параметров распространяется на группу устройств, в которую входят представители одного модельного ряда конкретного производителя. В результате администраторам приходится тратить массу времени на то, чтобы вручную перенастроить правила обработки трафика на каждом отдельном устройстве. Такие же проблемы возникают с переконфигурацией механизмов QoS при добавлении в мультисервисную сеть нового приложения, например видеосвязи. Недопустимо много времени в больших сетях занимают процедуры по изменению параметров защиты, что не позволяет оперативно реагировать на возникающие угрозы.

«Лоскутная» природа имеющихся средств управления значительно усложняет масштабирование современных сетей. Дополнительные сложности в части масштабирования создают и ограничения по числу логических групп. Например, как известно, стандартная технология VLAN обеспечивает поддержку только 4096 виртуальных локальных сетей, а при развертывании облачных сервисов IaaS коммерческим ЦОД уже сегодня требуется гораздо большее число виртуальных сетей. Представьте, что услуги IaaS предоставляются сотне предприятий, у каждого из которых по сотне VLAN, — уже в этом случае число логических сетей составляет 10 тыс.

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

РАЗДЕЛЯЙ И УПРАВЛЯЙ

Рисунок 1. Архитектура типичного коммутатора или маршрутизатора.

Главная идея SDN заключается в отделении функций передачи трафика от функций управления (включая контроль как самого трафика, так и осуществляющих его передачу устройств). В традиционных коммутаторах и маршрутизаторах эти процессы неотделимы друг от друга и реализованы в одной «коробке»: специальные микросхемы обеспечивают пересылку пакетов с одного порта на другой, а вышележащее ПО определяет правила такой пересылки, выполняет необходимый анализ пакетов, производит изменение содержащейся в них служебной информации и т. д. (см. Рисунок 1). Для определения маршрута передачи или недопущения зацикливания трафика устройства, конечно, «общаются между собой», для чего разработано множество протоколов, таких как OSPF, BGP и Spanning Tree, но при этом каждое функционирует достаточно автономно.

Согласно концепции SDN, вся логика управления выносится в так называемые контроллеры, которые способны отслеживать работу всей сети (см. Рисунок 2). Нельзя сказать, что это революционно новая идея: связисты помнят, что подобную логику в свое время предполагалось реализовать при модернизации телефонных сетей, результатом чего стало появление «интеллектуальных сетей», а затем и коммутаторов класса Softswitch.

Рисунок 2. Архитектура SDN.

Согласно замыслу разработчиков, SDN позволит программировать сеть как единое целое, а администраторам не придется заниматься отдельными устройствами. Главным становится контроллер: он все видит, все знает и раздает сетевым устройствам инструкции по обработке трафика. Самим устройствам больше не надо разбираться в сотнях замысловатых протоколов — достаточно следовать инструкциям контроллера, а значит, они могут быть простыми и дешевыми.

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

Основным элементом концепции SDN является протокол OpenFlow, который обеспечивает взаимодействие контроллера с сетевыми устройствами (см. Рисунок 2). На «северной» стороне контроллер предоставляет программные интерфейсы (API), наличие которых позволяет владельцу сети или сторонним разработчикам создавать приложения для управления сетью. Такие приложения могут выполнять самые разные функции в интересах бизнес-задач (например, контролировать доступ, управлять пропускной способностью и т. п.), причем их разработчикам не надо знать детали функционирования конкретных сетевых устройств. Благодаря контроллеру, вся сеть, состоящая из множества разнотипных устройств разных производителей, предстает для приложения как один логический коммутатор.

НЕМНОГО ИСТОРИИ

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

Интерес к SDN со стороны неуниверситетских кругов первыми проявили крупные поставщики интернетсервисов, которым требовались высокопроизводительные инфраструктуры для организации взаимодействия между десятками и даже сотнями серверов в гигантских ЦОД. Традиционная трехуровневая архитектура (доступ — агрегация — ядро) и необходимость производить множество действий при обработке трафика в каждом узле представлялись для них избыточными и чрезмерными. Именно шесть крупных поставщиков услуг — компании Deutsche Telekom, Facebook, Google, Microsoft,Verizon и Yahoo — весной 2011 года сформировали организацию Open Networking Foundation (ONF) с целью развития технологий SDN в целом и протокола OpenFlow в частности. Сегодня членами ONF являются практически все основные поставщики сетевого оборудования, включая Alcatel-Lucent, Brocade, Ciena, Cisco, Dell, Ericsson, Extreme Networks, HP, Huawei, IBM, Infinera, Intel, Juniper Networks, Mellanox, Netgear, Nokia Siemens Networks, ZTE, а также лидеры рынка систем виртуализации VMware и Citrix.

КАК РАБОТАЕТ SDN

Как и следует из названия, протокол OpenFlow при идентификации трафика оперирует понятием «потока». Ключевым элементом коммутатора, поддерживающего этот протокол, является таблица потоков (Flow Table). Группа столбцов в левой части таблицы формирует поля соответствия, где указаны характеристики потоков: это могут быть различные параметры, включая МАС- и IP-адреса отправителя и получателя, идентификатор VLAN, номера протокольных портов TCP и UDP, а также другая информация (см. Рисунок 3). Эти данные с помощью протокола OpenFlow записывает в таблицу коммутатора контроллер, он же определяет приоритет разных потоков: чем выше приоритет, тем выше соответствующая запись в таблице потоков.

Рисунок 3. Типичная таблица потоков в сетевом устройстве, поддерживающем OpenFlow.

Входящие пакеты проверяются на соответствие указанным в таблице параметрам. Если соответствие выявлено, к пакетам применяется действие, которое указано в следующем столбце таблицы. Типичным действием является пересылка пакета на один или несколько выходных портов. Кроме того, коммутатор может изменить содержимое служебных полей пакета, сбросить его, направить для анализа контроллеру и т. д. В случае если совпадение не найдено, пакет сбрасывается или направляется контроллеру, который определит, как следует обрабатывать данный поток, и добавит соответствующую запись в таблицу. Статистика по проходящему трафику — число пакетов, байтов и пр. — помещается в соответствующие поля (на Рисунке 3 они обозначены как Count).

Используя протокол OpenFlow, контроллер добавляет, модифицирует и удаляет записи в таблице потоков. Кроме того, он может запрашивать у коммутатора его характеристики и собранную статистику, конфигурировать коммутатор и его отдельные порты.

Хотя в названиях организации ONF и ее основного протокола присутствует слово «открытый», как вы понимаете, это совсем не синоним слову «бесплатный». Члены ONF могут использовать протокол OpenFlow в своих продуктах, но за само членство взимается ежегодная плата в 30 тыс. долларов.

ТЕКУЩАЯ СИТУАЦИЯ НА РЫНКЕ

Интерес к SDN со стороны крупных поставщиков интернет-сервисов, облачных услуг и владельцев мегаЦОД понятен: новые технологии позволят им решать свои задачи более эффективно и, главное, за меньшие деньги. А что же производители сетевого оборудования?

Наиболее рьяно за осваивание нового «поля» взялись стартапы. Один из пионеров в области SDN компания Nicira разработала контроллер и платформу виртуализации сетей (Network Virtualization Platform, NPV), а летом 2012 года она была куплена Vmware. По-видимому, следующий претендент на поглощение кем-нибудь из крупных игроков — компания Big Switch Networks, выпустившая контроллер Floodlight и средство тестирования OFTest. Упомянем еще один стартап — компанию Pica8, которая предлагает серию недорогих OpenFlowсовместимых коммутаторов.

Известные компании тоже не остаются в стороне. Так, например, NEC разработала контроллер и коммутаторы с поддержкой OpenFlow. IBM выпустила линию OpenFlow-совместимых коммутаторов, а также сотрудничает с NEC с целью обеспечения их совместимости с ее контроллером. НР добавила поддержку OpenFlow в большое число моделей коммутаторов и разрабатывает контроллер SDN. Многие ведущие производители коммутаторов и маршрутизаторов, включая Brocade, Cisco, Extreme Networks и Juniper Networks, либо уже объявили о выпуске OpenFlow-совместимых коммутаторов/маршрутизаторов, либо планируют сделать это в ближайшее время.

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

Интересно, зачем вообще эти компании ввязались в историю с SDN? Думаю, одна из причин заключается в том, что производители не хотят терять крупных заказчиков, которые «прониклись» идеями SDN. Еще раз взгляните на список основателей ONF, добавьте к ним других операторов связи и ЦОД, которые уже присоединились к этой организации (Colt, Deutsche Telekom, France Telecom Orange, Goldman Sachs, KDDI, Korea Telecom, Level 3 Communications, NTT Communications, SK Telecom, Swisscom, Telecom Italia), учтите заинтересованность, высказанную множеством других игроков, например «Ростелекомом», — и станет понятно, что вендорам просто нельзя дистанцироваться от столь представительной компании.

Другая, возможно, гораздо более важная причина — у сетевых вендоров просто нет альтернативы. Компании Broadcom и Marvell, ведущие производители микросхем для коммутаторов, — тоже члены ONF — уже объявили о поддержке OpenFlow. А собрать простенький коммутатор, работающий по протоколу OpenFlow, из имеющихся наборов микросхем может даже не слишком искушенная в вопросах сетевых технологий компания. Что, собственно, и продемонстрировала Google: сеть, связывающая ее центры обработки данных, построена на базе коммутаторов SDN собственной разработки. Если по этому пути пойдут и другие крупные игроки, бизнес Cisco и других традиционных производителей коммутаторов может оказаться под угрозой.

ВИРТУАЛЬНЫЙ SDN

Разделение «плоскостей» передачи и управления можно реализовать вообще не затрагивая имеющуюся физическую сеть — задействуя виртуальные коммутаторы наподобие Cisco Nexus 1000v, VMware DVS, IBM 5000v или даже Open vSwitch с открытым исходным кодом (см. Рисунок 4). Программирование таких коммутаторов с помощью контроллера позволяет создать виртуальную сеть SDN поверх имеющейся физической инфраструктуры. Некоторые эксперты рассматривают этот подход как альтернативу развиваемому ONF, но на самом деле, поскольку описываемая схема не исключает возможности использования стандартного протокола OpenFlow, противопоставлять ее решениям ONF не стоит.

Рисунок 4. Реализация принципов SDN с использованием виртуальных коммутаторов vSwitch.

Это далеко не умозрительная конструкция: подобное решение развернула компания «Крок» в своем ЦОД, где для предоставления облачных сервисов используются программные коммутаторы Open vSwitch, контроллеры компании Nicira и протокол OpenFlow. Все это функционирует поверх высокопроизводительной физической сети, построенной на базе оборудования Extreme Networks. Главная задача, которую успешно решила «Крок», — формирование более 1 млн изолированных сетей на втором уровне (L2). С помощью обычных VLAN такая задача не решается в принципе.

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

ДРУГОЙ ПОДХОД

В рамках своей стратегии SDN ряд производителей заявили об открытии функционала операционных систем своих устройств через API. До сих пор настройка сетевых устройств производилась преимущественно через командную строку или Webинтерфейс. Но эти инструменты ограничены той оболочкой программирования, которую предлагает производитель. При наличии API можно использовать более широкий набор инструментов программирования и создавать приложения не только для настройки сетевого устройства, но и для программирования сетевой среды в целом. По сути, этот подход является альтернативой SDN, при этом он обеспечивает доступ к более широкому набору функций сетевых устройств, что потенциально позволяет реализовать больше возможностей, чем заполнение таблицы потоков.

В частности, наличие доступа через API непосредственно к функционалу сетевых устройств позволяет системам типа VMware vCenter программировать сеть — например, задавать настройки VLAN в рамках общих задач по развертыванию и обслуживанию виртуальных машин. Для многих производителей коммутаторов интеграция с системой vCenter чрезвычайно важна, поскольку она упрощает и автоматизирует процедуры конфигурирования сетей для сред виртуализации VMware.

Одним из примеров описываемого подхода служит анонсированная летом 2012 года компанией Cisco инициатива Open Network Environment (ONE), в рамках которой она представила несколько библиотек API для своих основных операционных систем: IOS, IOS XR и NX-OS. Используя эти API, заказчики могут разрабатывать свои собственные приложения, которые устанавливаются непосредственно на устройствах или запускаются удаленно (более подробно о стратегии Cisco применительно к SDN см. интервью с Полом Пересом, вице-президентом Cisco и главным директором по технологиям подразделения по разработке решений для ЦОД). Подобные возможности предлагают и другие производители, скажем Juniper (интерфейс XML API) или F5 Networks (API-интерфейс iControl).

Предоставление производителями подобных API означает, что для реализации централизованного программирования и управления совсем необязательно использовать протокол OpenFlow. Кроме того, такие инициативы снимают с повестки дня тезис о том, что коммутаторы могут быть очень простыми и дешевыми.

ТРУДНОСТИ ПЕРЕВОДА

Преимущества, которые дает SDN, очевидны, причем не только для сетей в центрах обработки данных, но и для других типов сетевых инфраструктур. Централизованное управление мультивендорной средой, значительное упрощение обслуживания и модернизации, сокращение времени на обновление программных кодов коммутаторов/ маршрутизаторов и внедрение новых сервисов — все перечисленное важно как для корпоративных сетей, так и для инфраструктур операторов связи. Однако это не повод разом отказываться от преимуществ развиваемого десятилетиями традиционного подхода, когда каждое сетевое устройство наделяется «интеллектом», достаточным для автономного функционирования.

Полагаю, элементы SDN будут внедряться постепенно, при этом только компании уровня Google смогут позволить себе перейти на коммутаторы, полностью управляемые из центрального контроллера. Скорее всего, часть функционала, например по конфигурированию и заданию политики безопасности, будут выносить в контроллеры, при этом сами коммутаторы останутся достаточно «разумными», по крайней мере для того чтобы участвовать в работе протоколов определения маршрутов или балансировки трафика.

Что же касается русскоязычного термина, то SDN — это, скорее, «централизованно программируемая сеть». И надо поскорее прийти к консенсусу относительно такого термина. Напомню, что ISDN неформально расшифровывался как «I Still Don’t Need it», то есть «мне этого пока не нужно», причем именно такое отношение и предопределило судьбу этой технологии в России. Надеюсь, очень разумные идеи SDN ждет лучшая доля.

Александр Барсков — ведущий редактор «Журнала сетевых решений/LAN». С ним можно связаться по адресу: ab@lanmag.ru.