SDN и другие

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

«Программно определяемые» (или «программно конфигурируемые») сети (Software-Defined Networking, SDN) и виртуализация сетевых функций (Network Function Virtualization, NFV) становятся фокусными темами крупнейших отраслевых форумов. И это не случайно, ведь благодаря их использованию значительно меняются традиционные методы проектирования и управления корпоративными сетями, сетевой инфраструктурой телекоммуникационных компаний и ЦОД.

По прогнозу аналитиков, к 2018 году объем мирового рынка SDN вырастет до 35 млрд долларов (см. Рисунок 1). А 40% всех расходов на сети передачи данных будут так или иначе связаны с SDN. В первую очередь SDN будут востребованы сервис-провайдерами, облачными коммерческими центрами обработки данных, крупными корпоративными ЦОД. Между тем 67% российских специалистов по сетям (из числа опрошенных «Журналом сетевых решений/LAN») отметили, что их интерес к SDN носит пока лишь «чисто теоретический» характер, а 30% и вовсе не знают, что это такое.

Рисунок 1. Рост затрат на SDN в мире.

Пролить свет на эти современные сетевые технологии, непосредственно связанные с виртуализацией, помогают такие мероприятия, как диспут-клуб «Сеть для облака: SDN и NFV», проведенный «Журналом сетевых решений/LAN» в рамках Международной выставки «Связь-Экспокомм 2014». В числе основных вопросов, обсуждавшихся в ходе дискуссии, — виртуализация сети и сетевых функций (NFV), SDN как философия и технология, сеть для приложений. В качестве экспертов на диспут-клубе, который вел ведущий редактор журнала Александр Барсков, выступили: Алексей Стребулаев, ведущий системный инженер компании NEC; Виталий Томилко, старший менеджер по сетевым решениям Huawei Enterprise Business Group; Виктор Пустошилов, системный инженер Cisco Systems; Руслан Смелянский, член-корреспондент РАН, профессор МГУ им. Ломоносова, директор по науке и образованию Центра прикладных исследований компьютерных сетей (ЦПИКС); Игорь Бакланов, генеральный директор PR Group; Алексей Семеняка, независимый эксперт с опытом создания сетевой инфраструктуры в компаниях «Мегафон» и «Яндекс».

SDN И NFV

«Мы живем в эпоху кардинальной перестройки сетевых инфраструктур, осуществляемой под флагом SDN и NFV, — отметил Александр Барсков, открывая дискуссию. — Ее необходимость вызывается многими факторами, в первую очередь быстрым ростом числа подключенных к Интернету устройств и объемов сетевого трафика, причем если в традиционных сетях он передается в основном между клиентом и сервером (север — юг), то в виртуализированных и облачных средах доминирующим становится трафик между серверами и виртуальными машинами (запад — восток). В результате конфигурирование крупномасштабных сетей превращается в очень сложную задачу. Серьезные изменения в подходах к построению, эксплуатации сетей и управлению ими требуются также в связи с распространением мобильных технологий, концепции BYOD, Больших Данных и другими тенденциями».

Технология SDN и протокол OpenFlow были разработаны в Стэнфордском университете в ответ на потребность выделения сетевых ресурсов для тестирования новых сервисов. Идею быстро подхватили крупные интернет-провайдеры, и вскоре появилась организация Open Networking Forum. Одним из ее начинаний стала стандартизация протокола OpenFlow для взаимодействия контроллера с коммутаторами в инфраструктуре SDN. Как ожидается, SDN позволит использовать недорогие коммутаторы и управляемые контроллеры.

Идея NFV, изначально продвигавшаяся крупными европейскими операторами, предполагала перенос сетевых сервисов со специализированных устройств на стандартные компьютерные платформы в виртуализированные среды. Работа по стандартизации NFV ведется европейским институтом ETSI. SDN и NFV — разные, хотя и частично пересекающиеся технологии.

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

Рисунок 2. Передача пакетов в традиционной сети и в сети SDN.

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

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

Основные типы сетей, где может быть востребована (и уже задействуется) технология SDN — это кампусные сети, сети ЦОД, облачные платформы, а области применения — сети для облаков, оркестрация и автоматизация. В настоящее время основными объектами внедрения SDN являются крупные облачные сети и платформы. Пока лишь немногие заказчики решаются построить ЦОД на базе SDN, хотя такие примеры есть. Технология NFV используется в маршрутизаторах, межсетевых экранах и шлюзах, устройствах CDN, акселераторах WAN, контроллерах доставки приложений (ADC) в сетях операторов и сервис-провайдеров. SDN и NFV не связаны между собой, но хорошо дополняют друг друга, заключают эксперты.

ФЕДЕРАЦИЯ ОБЛАКОВ И ОРКЕСТРАЦИЯ

Понятие «сеть для облака» в значительной степени зависит от того, какой смысл вкладывать в термины «облако» и «сеть», подчеркивает Руслан Смелянский. Нередко облако рассматривают как некую инфраструктуру с эффективным масштабированием сервисов и ограничиваются контекстом ЦОД, однако более правильным следует считать расширенный подход и ориентироваться на такие масштабные реализации, как Amazon или Azure. В настоящее время для подобных облаков не предусматривается единое планирование ресурсов (вычислительных, сетевых и хранилищ данных), а также отсутствуют специальные встроенные средства повышенной отказоустойчивости и инструменты, позволяющие управлять топологией виртуальной сети. И вообще из-за особенностей своей структуры они не предназначены для использования NFV.

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

При помощи современных методов можно более чем на порядок ускорить данный тракт. Они работают в обход стека протоколов ОС и используют виртуальные коммутаторы. ЦПИКС реализовал такой подход для целого ряда сетевых сервисов, и теперь — благодаря NFV — у операторов появился шанс снизить себестоимость услуг за счет сокращения капитальных и эксплуатационных затрат.

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

Для стыковки NFV с SDN может потребоваться дополнительный сервисный оркестратор, который в общем случае усложняет сеть, увеличивает ее стоимость и снижает надежность. Такой внешний оркестратор может сообщать контроллеру о доступной пропускной способности: контроллеры SDN должны располагать информацией о канале и предоставлять приложениям сведения о трафике и свободных ресурсах.

Вместо специализированного сетевого оборудования NFV предполагает использование стандартных серверов с гипервизором виртуализации и перевод всех сетевых компонентов на уровень ВМ. Как следствие, важной задачей становится создание гипервизора виртуализации операторского класса, позволяющего преодолеть проблемы производительности сетевого стека и обеспечить мониторинг ВМ с контролем производительности и функциональности, подчеркивает Алексей Стребулаев. Учитывая ограниченную производительность ВМ, нужен максимально эффективный механизм балансировки нагрузки, и таковым является сеть SDN на базе OpenFlow, позволяющая использовать физические порты, а не прослойку в виде Open vSwitch, производительность которой ограничена сетевым стеком.

Компания NEC, например, разработала гипервизор операторского класса на базе KVM (Carrier Grade HyperVisor, CGHV), поддерживающий компоненты NFV. Реализованные программно на базе гипервизора сетевые компоненты (VNF) c использованием стандартного аппаратного обеспечения позволяют снизить капитальные и эксплуатационные затраты. Разработчикам NEC удалось минимизировать задержки в сети и обеспечить высокую доступность. Виртуальной машине, работающей под управлением этого гипервизора, на сервере x86 может быть предоставлен полнодуплексный канал 10GbE. Специальные механизмы протоколируют исполняемые ВМ инструкции и контролируют активность запущенных процессов и ее производительность. При сбое в работе ВМ оркестратор запускает ее копию, создавая новую виртуальную машину.

Автоматическое устранение неисправностей и восстановление системы позволяют гарантировать высокий уровень доступности (по данным NEC — «пять девяток»), сократить среднее времени восстановления (MTTR) по сравнению с традиционными сетями и снизить операционные затраты за счет автоматизации.

Оркестратору уделяется особое внимание, но, чтобы реализовывать функции эффективно и дешево, работа гипервизора, сети и оркестратора должна быть согласована, поясняет Алексей Стребулаев. Учитывая идеологию открытых сетей, лежащую в основе SDN, сделать это непросто, что подчеркивает важность оркестратора. В настоящее время группа NFV, действующая в рамках организации ETSI, занимается стандартизацией интерфейсов оркестратора с компонентами NFV и SDN, а также вопросами интеграции с системами управления OSS/BSS.

Чтобы гарантировать исполнение требований SLA, оркестрация должна осуществляться как на уровне каждой площадки, за управление которой отвечает отдельный контроллер, так и на уровне федерации облаков. Последняя представляет собой распределенную сеть площадок, каждая из которых имеет пул ресурсов для федеративного использования (см. Рисунок 3). Для работы с этими ресурсами необходимо новое решение — «метаоркестратор». Контроллер SDN определяет набор правил для обработки пакетов и загружает их в коммутаторы. Сами же контроллеры взаимодействуют по протоколу BGP (как это реализовано, например, в проекте OpеnDaylight и в протоколе BGP-LS с поддержкой OpenFlow). Одна из нерешенных проблем SDN связана с тем, что несколько контроллеров SDN могут загружать в коммутаторы логически противоречивые конфигурации и правила. Такие конфликты крайне сложно разрешать в реальном времени (чтобы избежать задержек).

Рисунок 3. Федерация распределенных облаков с пулом совместно используемых ресурсов (по данным ЦПИКС).

SDN В РАЗВИТИИ

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

В соответствии со своей концепцией SDN (см. статью Александра Барскова «Всеобъемлющий Интернет: без ‘‘тумана’’ не обойтись» в февральском номере «Журнала сетевых решений/LAN») Cisco разработала API для взаимодействия с сетевыми устройствами (виртуальными или физическими), контроллеры и агенты для коммуникаций с управляемыми элементами сети, рассказывает Виктор Пустошилов (см. Рисунок 4). Для программирования различных сетевых устройств можно использовать единые интерфейсы Cisco API OnePK.

Рисунок 4. Платформа Cisco Open Network Environment реализована в виде набора API-интерфейсов для различных платформ, агентов и контроллеров, а также дополнительных сетевых технологий.

Через API с сетевым устройством взаимодействует приложение. Оно может находиться внутри контейнера виртуализации ОС самого сетевого оборудования или быть внешним. Такие приложения уже предлагаются заказчикам. Одно из них — агент OpenFlow для коммутаторов, поддерживающих контейнерную виртуализацию, например коммутаторов уровня ЦОД Cisco Nexus. Внутреннее взаимодействие агента с коммутатором происходит через API, а внешнее (с контроллером) — по стандартному протоколу OpenFlow. В результате коммутаторы Nexus могут «общаться» с контроллером SDN — Cisco XNC. Контроллер XNC на базе проекта OpenDaylight с поддержкой OpenFlow и открытым SDK для создания приложений — собственная разработка Cisco, предлагаемая в качестве коммерческого продукта.

С помощью SDK заказчики могут создавать собственные уникальные решения, и подобные примеры уже есть. Поскольку контроллер XNC снабжен и встроенными приложениями от Cisco, заказчики могут применять их для управления трафиком и конфигурациями, а также мониторинга состояния. Например, одна из компаний создала специализированную сеть для сбора, мониторинга и анализа трафика: функциями передачи данных для последующего анализа были оснащены обычные коммутаторы Cisco, что обошлось дешевле применения специального оборудования.

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

Рисунок 5. Агенты Chef и Puppet размещаются на коммутаторе Cisco Nexus и сетевых устройствах. Они могут изменять конфигурацию устройств через onePK API.

Ряд заказчиков используют для управления конфигурацией приложений в крупных сетях (десятки тысяч коммутаторов уровня доступа) «открытые» агенты Chef и Puppet. Эти механизмы применяются для отслеживания конфигурации ПО на серверах и служат для управления ею. Однако их удалось расширить для конфигурирования сетевых устройств, и в результате получилось хорошо масштабируемое решение (см. Рисунок 5).

Huawei, работающая над собственной концепцией SDN и NFV с централизованным управлением и разделением уровней управления и передачи данных, в этом году планирует анонсировать новые технологии и продукты. Ее решение SDN предполагает использование стандартизированных «северных» (приложения) и «южных» (оборудование) интерфейсов. Интерфейсы API должны обеспечить интеграцию нового оборудования в существующую сеть и облегчить процесс миграции.

Недавно Huawei выпустила программируемый «сетевой процессор» (Ethernet Network Processor, ENP), на основе которого уже созданы и будут строиться ее решения SDN, в частности новая линейка продуктов Agile Evolution. ENP — альтернатива ASIC — упрощает реализацию различных схем обработки трафика, безопасности и качества обслуживания. Программируемость данных продуктов позволяет оперативно анализировать и изменять форматы кадров и применять к любому трафику правила переадресации.

В отличие от протокола OpenFlow, рассчитанного на IP, поддержка Protocol Oblivious Forwarding (POF) дает возможность работать с любыми протоколами и нестандартными пакетами. В то же время POF совместим c OpenFlow для обеспечения взаимодействия с решениями других производителей. Таким образом, POF в сочетании с ENP гарантирует независимость от применяемого протокола. Процессоры ENP позволяют внедрять новые протоколы программным путем. Сторонние разработчики могут задействовать открытый исходный код POF в своих проектах.

По словам Виталия Томилко, Huawei будет предлагать три вида контроллеров SDN: для операторских и кампусных сетей, а также облачных ЦОД (см. Рисунок 6). Например, в кампусных сетях SDN помогает осуществлять управление пользовательским доступом, а в облачных ЦОД — снижать расходы на внедрение новых сервисов. Предусматривается наличие платформы оркестрации Network Orchestration Platform с унифицированным управлением проводными и беспроводными сетями.

Рисунок 6. Линейка продуктов Huawei Agile Network.

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

Компания NEC, разрабатывая решения SDN для операторов, фокусируется на четырех направлениях: оркестрации (система NetCracker уже имеется в портфеле решений NEC) и поддержке операций, решениях SDN для ЦОД и продуктах SDN для транспортных сетей. Последние позволят виртуализировать транспортные сети и управлять их конфигурированием и выделением ресурсов клиентам с помощью контроллера SDN.

Одно из самых масштабных внедрений NEC SDN — проект, реализованный NT&T и охватывающий около десятка ЦОД этого оператора. В виде коммерческих продуктов уже доступны виртуальный шлюз для операторов сотовой связи и решение для виртуализации абонентских устройств (CPE), позволяющее, подобно VDI, перенести функции из такого устройства CPE в ЦОД и тем самым удешевить и упростить внедрение новых сервисов.

ЧТО ДАЛЬШЕ?

«С точки зрения философии и технологии в SDN ничего нового нет — это проявление того же принципа декомпозиции, который использовался при разработке ОКС-7 и интеллектуальных сетей, — считает Игорь Бакланов. — Разделение управления и коммутации — известная идея. Но будет ли она удачной в случае SDN? Однозначного ответа нет. Пока имеет место противостояние крупных компаний, и у каждой из них есть стремление как к закрытости (своя SDN и проприетарный контроллер), так и к открытому подходу. Успех SDN зависит от того, будет ли достигнут баланс». Возможны несколько сценариев дальнейшего развития SDN, например: отраслевое сотрудничество в выборе лучших решений или разработка интерфейсов для взаимодействия систем разных вендоров.

Между тем технология SDN уже готова к внедрению. Ее используют NT&T, Deutsche Telecom, Telecom Italia и другие крупные операторы. Серьезные надежды возлагают на SDN и производители коммутаторов, ведь внедрение любого нового протокола третьего сетевого уровня предполагает огромный объем работ по программированию — созданию систем оркестрации и управления ИТ- и сетевой инфраструктурой. Ведущие вендоры открывают «центры решений» SDN, предоставляют разработчикам API и SDK.

Отечественные же специалисты ищут возможности использования технологии SDN для создания собственных решений в области коммутации, позволяющих преодолеть зависимость от зарубежных поставщиков. SDN — хороший вариант для реализации в России собственных разработок и решений. Этот подход предоставляет огромные возможности для российских разработчиков и компаний-стартапов. SDN приведет к появлению нового емкого сегмента рынка ПО — программного обеспечения для сетевых приложений. И у нашей страны есть хорошая возможность проявить себя в этой перспективной области.

Уже создан консорциум 10 российских университетов, работающих над тематикой SDN, и Министерство образования и науки объявило о начале финансирования соответствующих проектов. Налаживается международное сотрудничество России в области SDN. В конце октября при содействии Министерства образования и науки в России планируется провести международную конференцию по SDN/NFV с участием 15 ведущих мировых экпертов. А среди полутора десятков перспективных направлений, выделенных Правительством РФ, присутствует одно из области ИКТ — SDN/NFV.

По словам Руслана Смелянского, в ЦПИКС, занимающемся проблематикой SDN уже три года, создан самый быстрый в мире контроллер SDN и проведен целый ряд исследований, включая реализацию NFV и возможности использования платформы OpenStack. Эти разработки используются компанией Intel и применяются в «Ростелекоме». Успех SDN в России зависит от заинтересованности госструктур и от уровня поддержки национальных проектов.

Примером федерации облаков могла бы стать сеть научных организаций. Она позволила бы определять требования по предоставляемым ресурсам (топология, скорости обработки и передачи данных, маршрутизация) при проведении соответствующих экспериментов, прежде всего в области Больших Данных.

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

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

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

Преимущества SDN заключаются в стандартных открытых API для сетевых приложений и возможности создания операторами собственного ПО для управления сетью (см. Рисунок 7). Очень важна экосистема приложений, формируемых вокруг той или иной платформы. Конкуренция платформ SDN — это конкуренция экосистем приложений. Именно экосистему будет оценивать заказчик при выборе платформы SDN. Такие экосистемы сейчас только формируются.

Рисунок 7. Концепция SDN в представлении разработчиков NEC.

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