Первые пару десятилетий своей истории интернет был набором серверов, характеристики которых определяли возможности сервисов. Грубо говоря, если у сайта резко посещаемость, нужно было покупать новый сервер. Растущие потребности поставили разработчиков перед выбором: либо создавать множество «железок», либо найти способ повысить гибкость существующих серверов. Так концепция сети (SDN), которая предлагает гибкий набор программных настроек, а возможности сервисов больше не ограничены «железом».
Лучше понять суть сетей позволяет аналогия с мобильными телефонами. У старых моделей телефонов функциональность была заложена в — изменить ее простому человеку было нельзя. То есть если производитель не в телефон микросхему определителя номера, пользователь уже не мог выяснить, кто звонил. Функциональность современных мобильных телефонов реализуется программным способом: устанавливая разные приложения, пользователь получает доступ к новым и ресурсам. SDN превращает серверы в подобие смартфонов, позволяя нужную систему из виртуальных «кубиков», которые нужны в каждый конкретный для решения определенной задачи. В результате повышается продуктивность, а могут быстрее реагировать на конкурентные вызовы.
Как SDN влияет на жизнь и бизнес
Большинство современных технологий и сервисов, от Facebook и Amazon до продуктов Google и Microsoft, работают благодаря сетям. К примеру, платформы распределяют нагрузку, не нарушая работы сервисов, — именно SDN делает это возможным.
Часто люди пользуются преимуществами SDN, даже не осознавая этого. Сервис Skype for Business совершил переворот в корпоративных коммуникациях, позволив забыть о номерах. Именно возможности SDN позволили сотрудникам тысяч компаний с помощью чатов, видеозвонков и обмена файлами через одно приложение. SDN нечувствительно для пользователей распределяет трафик в сети таким образом, что всё работает стабильно. С повсеместным внедрением технологий SDN таких примеров станет больше: «умные» сети будут незаметно влиять на жизнь миллиардов людей.
SDR/SDN — как новая архитектура реализуется в реальной сотовой сети
Сеть Сотовой Связи – структура весьма консервативная в силу своей огромной стоимости и больших сроков строительства. Изменения в стандартах связи происходят регулярно, но переход к новому стандарту (к примеру — 3G после 2G) требует новых вложений и замены оборудования, которое часто еще не выработало свой ресурс. Сейчас для запуска сети нового поколения всё становится проще благодаря подходам SDR и SDN.
Упрощая, это чем-то похоже на виртуализацию железа: изменение функционала происходит не заменой материальной части, а изменением его программной части. Если вы читали Лема, то грубая аналогия – перестроение его умных структур, где одинаковые элементы составляли сложную схему. Роль каждого элемента определялась не конструкцией, а положением в структуре и данными от других элементов. Только в нашем случае в роли составных частей выступают программные блоки, а не элементарные механизмы.
Я расскажу, как эти подходы находят применение в реальной сети.
Про оба подхода уже не раз писали на Хабре. Я расскажу, какие особенности накладывает на реализацию SDR и SDN сеть крупного оператора, где требуется сохранить весь функционал, наследуемый из уже работающих мобильных сетей.
Предыстория
Для начала немного истории. Первоначально (как это часто бывает) концепция SDR родилась в недрах военных ведомств и предназначалась для быстрой замены устаревающих протоколов радиосвязи. Поддерживаемые протоколы и диапазоны были реализованы на аналоговом оборудовании, и любое изменение требовало полной физической замены всего комплекса. Переход к цифро-аналоговому преобразованию радиосигнала открыл возможность перехода на новые протоколы и стандарты простой сменой программного обеспечения в цифровом блоке.
Долгие годы этот подход был труднореализуем в мобильных сетях операторов, поскольку предъявлял очень высокие требования к производительности цифрового блока, отвечающего за преобразование. Но закон Мура доказал свою справедливость, и мощность вычислительных систем достигла значений, достаточных для обработки алгоритмов, заложенных в мобильные сети стандартов GSM/UMTS/LTE. Это, кажется, позволяет нам перейти к чистым SDR системам и получить компактные и производительные базовые станции. Однако здесь возникла вторая проблема, связанная с используемым спектром и требуемой выходной мощностью для мобильных сетей разных стандартов.
К примеру, сейчас в России у каждого оператора большой тройки работают мобильные сети в следующих диапазонах:
3GPP Band
Стандарт связи
ДиапазонUL, MHz
ДиапазонDL, MHz
Band 20
LTE 800
Закрыть весь этот частотный спектр одним передатчиком – задача с технической точки зрения решаемая, но при этом оборудование будет совершенно не пригодно по массово-габаритным характеристикам для использования в существующей сети. С учетом этого ограничения стандартное решение при переходе на архитектуру SDR выглядит так: к общему процессорному блоку подключается несколько радиомодулей, каждый из которых обеспечивает создание ЭМ излучения в определенном частотном диапазоне.
Эволюция от выделенных процессорных блоков под каждый стандарт, к виртуализации всех стандартов в одном процессорном блоке
Какой стандарт связи будет при этом создаваться, определяется процессорным блоком и стратегией оператора по рефармингу одних стандартов в другие. Интерфейс от процессорного блока до радиопередатчика также стандартизован, и все производители предлагают свои варианты реализации протокола CPRI — Common Public Radio Interface. Последние реализации протокола CPRI поддерживаются также и производителями оборудования транспортной сети, например, радиорелейных линий, что позволяет подключать радиопередатчики на значительных расстояниях от процессорного блока.
Такой вариант реализации SDR-концепции существенно снижает количество требуемых процессорных блоков и одновременно обеспечивает агрегацию трафика от всех стандартов мобильных сетей в одну транспортную сеть.
Сегодня
Пример реализации концепции SDR на оборудовании базовых станций мобильной сети:
Было: 3 базовые станции для трёхстандартной сети (GSM/UMTS/LTE)
Стало: разделение стандартов только на уровне передатчиков и антенн с общим процессорным блоком
Теперь попытаемся представить самую упрощенную архитектуру сети оператора для приема трафика от мультистандартной радиосети GSM/UMTS/LTE. Согласно рекомендациям 3GPP и, соответственно, предложениям от ведущих производителей оборудования, максимально упрощенная архитектура сети релиза R8 выглядит следующим образом:
При этом каждый узел в квадрате «Стандартное оборудование мобильной сети на стороне оператора» представляет собой целую стойку оборудования (а часто и не одну) со специфичными интерфейсами, платами, оригинальными сабрэками и т.д. Поставщиками разных узлов оказываются разные производители, оборудование принадлежит к разным поколениям или даже эпохам развития сети. Эксплуатация такого «зоопарка» – занятие сложное, требующее квалифицированных инженеров, причем, имеющих опыт эксплуатации различного оборудования, различных производителей. Здесь самое время вспомнить про концепцию SDN, которая будто специально создана для оптимизации такой архитектуры.
Сейчас под аббревиатурой SDN понимают программно-конфигурируемые транспортные сети. Однако в мобильных сетях это понятие объединяется с алгоритмами «виртуализации» – Mobile Virtualization – и из них рождается новая архитектура строительства мобильных сетей – Mobile SDN. Базовые подходы, применяемые при проектировании mobile SDN сетей, те же, что и для транспортных сетей:
Новая архитектура фактически означает замену всех типов разнообразного оборудования мобильных сетей (BSC/RNC/MSC/MSS/SGSN/GGSN/MME и т.д.) общей HW платформой, на которой виртуализированы все их функции. Если построить сеть с использованием подходов SDR и SDN, можно получить следующую картину с точки зрения операторского оборудования:
Мобильная сеть, построенная по принципам Mobile SDN, дополненная радиосетью, построенной по принципам SDR, позволяет создавать современные мобильные сети, на которых легко можно переходить от стандарта к стандарту (GSM-UMTS-LTE-LTE Adv-….), предоставляя новейшие услуги в самые короткие сроки.
Это значит, что скоро нам не придется для реализации нового функционала, вводимого в новом стандарте, монтировать новую стойку оборудования и ломать голову над её интеграцией с живой сетью. Достаточно будет провести обновление программного обеспечения на нашей платформе с виртуальными машинами, и новый функционал открыт для использования.
Описанные в статье концепции сейчас находятся на разных стадиях промышленной реализации. SDR можно назвать фактически свершившимся фактом: все последние модели базовых станций ведущих производителей выполняются по данной схеме, позволяя использовать общий процессорный блок и обеспечивать работу радиопередатчиков заданного диапазона одновременно в нескольких стандартах. Все мобильные сети Билайн, строящиеся последние годы, используют данный подход в части оборудования радидоступа.
Концепция же SDN в мобильных сетях (как, впрочем, и в транспортных) только набирает обороты. Ведущие производители оборудования начинают эксперименты с виртуализацией различных функций на базе производительных серверов от третьих компаний либо с использованием собственных разработок.
Например, упоминаемый нами в недавнем обзоре Тестовой Зоны, новый тип контроллера от компании NSN – в чистом виде SDN платформа. Правда, пока она предназначена для виртуализации только сетевых элементов, к которым подключаются базовые станции – BSC/TRC/RNC, и не может выполнять все функции одновременно (для каждой логической функции требуется выделенный HW модуль), но единая аппаратная платформа – уже значительный шаг в сторону оптимизации сети оператора.
Было – стандартная платформа RNC (отдельная стойка):
Стало – SDN платформа RNC (8 Rack Unit):
В качестве второго примера приведу недавно протестированное в Тестовой Зоне решение от Cisco – универсальная серверная платформа Cisco UCS – Unified Computing System. Фактически она представляет из себя Blade Server, на котором с использованием виртуальных машин можно запустить любое приложение для любой операционной системы, в частности, любое приложение, используемое на оборудовании Cisco (Cisco IOS, StarOS и др.). В нашей лаборатории мы тестировали сетевые решения: «Cisco HomeNodeB Gateway», «Cisco Wi-Fi Access Gateway» с одновременной эмуляцией на том же сервере большого количества необходимых сетевых элементов – SecGW, DHCP Server, AAA, SGSN, PCEF и др.
В лабораторных условиях уже подтверждены функциональность и жизнеспособность концепции SDN, сейчас производители работают над обеспечением требуемого уровня производительности для обработки огромных объемов трафика, генерируемых в современных мобильных сетях.
Сетевые технологии SDN – Software Defined Networking
В современном мире, бизнес в сфере информационных технологий предъявляет все большие требования к гибкости и масштабируемости компьютерных сетей. Так, старожилу IT рынка компании AOL для привлечения одного миллиона клиентов понадобилось 9 лет, Facebook понадобилось 9 месяцев, а онлайн сервису DrawSomething понадобилось всего 9 дней.
При всем этом, можно наблюдать, что основными трендами развития корпоративных сетей и сетей центров обработки данных являются: • стремительный рост объемов трафика и изменение его структуры в сторону передачи видео и унифицированных коммуникаций (UC-C); • необходимость поддержки мобильных пользователей (BYOD) и социальных сетей; • высокопроизводительные кластеры для обработки Больших Данных (BIG DATA); • виртуализация для предоставления облачных сервисов (Cloud Bursting).
При этом сеть в классическом ее виде (управление через командную строку и конфигурационные файлы) становиться ограничивающим фактором развития вычислительной инфраструктуры. Классические подходы к решению проблем, к примеру, на основе виртуализации сетей (VLAN, VRF), не соответствует уровню развития виртуализации серверов и систем хранения данных. Традиционные сети прежде всего статичны и не соответствуют быстрой динамике развития современного IT бизнеса. Возможности масштабирования традиционных сетей не соответствуют требованиям крупного бизнеса и сервис провайдеров (Deutsche Telekom, Facebook, Google, Microsoft, Verizon и Yahoo), а распределенное управление устройствами традиционных сетей слишком сложное и не эффективное. Привязка же к выбранному сетевому производителю не гарантирует поддержку будущих приложений и сервисов, так, по слухам, очередной апгрейд сетевого оборудования компании Amazon имел ценник с девятью нулями. Как результат наблюдается картина, что традиционные архитектуры/дизайны сетей становятся неэффективны в динамических средах.
Необходима новая технология или подход к построению информационных сетей позволяющая решить перечисленные выше проблемы. Такая технология есть и носит название — Software Defined Networking или сокращенно SDN.
Что такое SDN?
По определению от Wikipedia: Программно-конфигурируемая сеть (SDN от англ. Software-defined Networking, также программно-определяемая сеть) — сеть передачи данных, в которой уровень управления сетью отделён от устройств передачи данных и реализуется программно, одна из форм виртуализации вычислительных ресурсов.
Давайте расшифруем это определение. Если рассмотреть современное сетевое устройство (роутер или коммутатор, не принципиально), то оно, как пирог, логически состоит из трех компонентов. 1. Уровень управления – это CLI, встроенный веб-сервер или API и протоколы управления. Задача этого уровня обеспечить управляемость устройством. 2. Уровень управления трафиком – это различные алгоритмы и функционал задачей которого является автоматическая реакция на изменения трафика т. е. интеллект устройства. 3. Передача трафика – функционал обеспечивающий физическую передачу данных, уровень микросхем и сетевых пакетов.
Рисунок 1 Типичное сетевое устройство
Что если: • централизовать управление трафиком, отделив управление от устройств? • централизовать управление устройствами?
В результате «новый» роутер или коммутатор обслуживает только поток данных (уровень передачи трафика DATAPLANE), становиться более простым соответственно более дешевым. Конечно же лишить полностью интеллекта сетевое устройство не получиться, но его достаточно заменить простой таблицей переадресации (forwarding table).
Весь интеллект (MANAGEMENT PLANE и CONTROL PLANE) переносится в отдельное центральное устройство называемое контроллером SDN.
Рисунок 2 Логическая модель сетевых устройств SDN
Итак, мы получаем: • Разделение функций передачи трафика от функций управления (включая контроль как самого трафика, так и осуществляющих его передачу устройств) • Единый, стандартный, открытый интерфейс между устройствами управления и передачи (получивший название OpenFlow) • Централизованное управление сетью (Контроллер SDN) • Виртуализация физических ресурсов сети • Возможности программирования как оборудования (OpenFlow), так и приложений (API — Контроллер SDN) • Быстрее реагировать на изменения в сети • Оптимизировать передачу трафика (L2/3) через большее количество резервных путей • Легче и быстрее настраивать сети • Существенно сократить время развертывания приложений • Упростить управление сетевыми устройствами • Сократить затраты на управление сетями • Централизованное применение политик, увеличение производительности, уменьшение задержек приводит к более эффективному взаимодействию пользователей и приложений как в корпоративных сетях, так и в сетях датацентров • Простота управления. Управление целыми сетями, а не сетевыми устройствами • Открытые, основанные на стандартах протоколы позволят взаимодействовать различным производителям сетевого оборудования между собой, одновременно увеличивая выбор заказчику и конкуренцию между вендорами при снижении затрат, ускоряя инновации как в области программного обеспечения, так и аппаратных средств. • Контроллер SDN поддерживает открытый интерфейс программирования (API), который позволяет программировать его извне, создавая среду для автоматизации и контроля, а также масштабировать функционал для будущих приложений. • Приложение может запрашивать напрямую определенные требования к сети • Видимость всего трафика сети контроллером
Рисунок 3 Общая архитектура SDN
Как видно из архитектуры, кроме классического управления сетью прямыми командами системного администратора к контроллеру, SDN контроллер поддерживает запуск на себе приложений управления сетью. Что из себя представляют эти приложения?
Каждое SDN приложение, по сути, являет собой интерфейс оптимизации сети под конкретное бизнес приложение (к примеру Microsoft Lynk) и его основная роль — изменение сети в реальном времени под текщие нужды обслуживаемой программы. В случае Microsoft Lynk это может быть, к примеру, изменение QoS сети между двумя телефонными абонентами для предачи HD видеозвонка в реальном времени без задержек или создание VPN тоннеля между двумя абонентами.
Рисунок 4 SDN приложение для MS Lynk
Если рассмотреть более подробно информационные потоки в архитектуре SDN, можно заметить два основных направления обмена информацией: первый – между SDN приложениями и второй для управления физическими сетевыми устройствами.
Рисунок 5 Структура и компоненты SDN
Первый поток получил название «северный мост», а второй «южный мост». В качестве «северного моста» выступает протокол на основе RESТ API, а в качестве «южного моста» прижился протокол OpenFlow.
Рисунок 6 Управляющие информационные потоки контроллера SDN
Что же такое OpenFlow?
Openflow — стандартный протокол, является основным элементом концепции SDN который обеспечивает взаимодействие контроллера с сетевыми устройствами. Контроллер используется для управления таблицами потоков коммутаторов, на основании которых принимается решение о передаче принятого пакета на конкретный порт коммутатора. Таким образом, в сети формируются прямые сетевые соединения с минимальными задержками передачи данных и необходимыми параметрами.
Соответственно коммутатор OpenFlow состоит, как минимум, из двух компонент: • таблицы потоков (flow table); • безопасного канала (secure channel)
Рисунок 7 Пример таблицы потоков OpenFlow
Коммутаторы с поддержкой OpenFlow уже доступны на рынке, так в портфолио лидера в разработки концепции SDN – компании Hewlett-Packard, уже более 40 моделей коммутаторов поддерживают OpenFlow версии 1.3, соответственно готовы выступать «кирпичиками» построения реальной сети SDN.
Кроме коммутаторов Hewlett-Packard предлагает несколько моделей готовых контроллеров SDN и бесплатно предоставляет несколько готовых приложений SDN для конкретных бизнес программ, к примеру, Microsoft Lync. Компания HP также поддерживает активное сообщество разработчиков SDN (sdndevcenter.hp.com), где пользователи могут делиться своими идеями, а также онлайн-магазин приложений SDN App Store, откуда пользователи могут скачивать различные приложения на контроллер HP VAN SDN всего в несколько кликов.
Такой интерес Hewlett-Packard к технологии SDN не случаен. Считается, что SDN изменит сети так же, как это сделала в свое время виртуализация на рынке корпоративных серверных систем. Соответственно SDN для компании Hewlett-Packard это стратегическое направление, ведь успех в этом направлении может предоставить лидерство на рынке, пример тому, успех таких крупных игроков на рынке сетевых сервисов как Amazon и Google активно использующих SDN в своей работе.
Hewlett-Packard также считает, что SDN должна строиться на базе открытых стандартах, чтобы каждый желающий мог в этом поучаствовать. Такая открытая экосистема возобновит процесс внедрения инноваций в области сетевых технологий, который приостановился за последние два десятилетия.
SDN: альтернатива или дополнение к традиционным сетям?
Современные информационные технологии предъявляют все большие требования к гибкости и масштабируемости компьютерных сетей. Как ожидается, программно-конфигурируемые сети помогут решить целый ряд имеющихся проблем, будут способствовать созданию автоматизированных, программируемых, гибких и экономичных сетевых инфраструктур, однако стратегии SDN у ведущих вендоров заметно различается. Наглядный пример – подходы Cisco и HP.
По оценкам Gartner, на сетевую инфраструктуру приходится примерно 17% ИТ-бюджета. При этом она далеко не всегда может адаптироваться к меняющимся потребностям бизнеса. Новые тенденции – виртуализация, облачные вычисления, мобильность пользователей, рост объемов трафика – меняют требования к сетевым инфраструктурам. Смогут ли устанавливаемые сегодня сетевые продукты обеспечить поддержку будущих приложений и сервисов? В какой мере развитие сети будет привязано к продуктам выбранного производителя коммутаторов?
Проприетарность решений, архитектура традиционного сетевого оборудования делает эту привязку очень прочной. Некоторые даже характеризуют текущую ситуацию в сетевой отрасли как революционную. Ряд экспертов в качестве рецепта устранения вскрывшихся в сетях проблем называют переход к архитектуре программно-конфигурируемых (программно-управляемых) сетей (Software-Defined Networking, SDN). SDN обещает существенно ослабить зависимость заказчиков от технологий конкретного вендора.
В SDN вся логика управления сетевыми устройствами выносится в так называемую «плоскость управления», которая реализуется программным образом. Конструктивно контроллеры могут строиться либо на базе физических, либо виртуальных хостов. Управление сетевыми устройствами, как правило, осуществляется по протоколу OpenFlow.
Главная идея SDN – отделение функций передачи трафика от функций управления. В традиционных коммутаторах и маршрутизаторах эти процессы неотделимы друг от друга. В SDN сеть, состоящая из множества устройств разных производителей, предстает для приложения как один логический коммутатор. SDN позволяет администраторам программировать сеть как единое целое, а не заниматься отдельными коммутаторами, которые могут просто выполнять инструкции контроллера.
Реализация такой концепции значительно упрощает эксплуатацию сети, ее конфигурирование. Коммутаторы могут быть простыми и дешевыми. Характеристики сети можно оперативно изменять в режиме реального времени, сокращаются сроки внедрения новых приложений и сервисов. Программные интерфейсы (API) контроллера позволяют разработчикам создавать приложения для управления сетью. Такие приложения могут выполнять самые разные функции, причем для этого не требуется знать особенности работы конкретных сетевых устройств.
Казалось бы, такой подход не должен вызывать энтузиазма у производителей сетевого оборудования, многие годы совершенствовавших уникальные функции своих коммутаторов и маршрутизаторов, ведь возможность использования простых и дешевых коммутаторов, создания приложений сторонними разработчиками за счет открытых API подрывает бизнес этих компаний, лишает их источника добавленной стоимости. Однако крупные заказчики, включая ведущих операторов связи и провайдеров, уже прониклись идеями SDN, а производители микросхем для коммутаторов объявили о поддержке OpenFlow, поэтому вендоры не могут оставаться в стороне.
Теперь создать собственный коммутатор, работающий по протоколу OpenFlow, в состоянии даже компания, не имеющая многолетнего опыта в использовании сетевых технологий. Организация Open Network Foundation (ONF), объединившая сторонников «открытых сетей» на базе протокола OpenFlow, включает в себя все большее число игроков сетевого рынка. Бизнес Cisco и других традиционных производителей коммутаторов может оказаться под угрозой. По оценкам экспертов, повсеместное принятие SDN способно более чем вдвое сократить оборот сетевого гиганта.
По данным опроса Infonetics Research (июль, 2014 года), 87% средних и крупных предприятий планируют к 2016 году запустить SDN в своих ЦОД в эксплуатацию.
В любом случае SDN существенно перекроит сетевой рынок, кардинально изменит подход к проектированию, развертыванию и управлению сетями, к доставке приложений и сервисов. Традиционные сетевые вендоры по-разному относятся к SDN. Однако такие крупные игроки сетевого рынка как Cisco и HP сформировали основные элементы своей стратегии в области программно-конфигурируемых еще несколько лет назад.
В 2012 году появилась информация о том, что Cisco Systems может выпустить проприетарные сетевые продукты, реализующие концепцию SDN, но не обязательно использующие OpenFlow. В то же время HP объявила о поддержке стандартного протокола OpenFlow во многих своих продуктах. В отрасли заговорили о том, что в SDN эти компании пошли принципиально разными путями, одна – проприетарным, другая – основанным на открытых стандартах. Руководители HP не преминули отметить, что открытые стандарты и совместимость с оборудованием других вендоров остаются основой подхода компании, и проприетарный путь – не в интересах заказчиков.
SDN от HP
На самом деле коммутатор с поддержкой OpenFlow компания HP продемонстрировала на конференции ACM SIGCOMM еще в 2008 году. В 2012 году сетевое подразделение HP Networking представило девять новых моделей коммутаторов линейки HP 3800, реализующих протокол OpenFlow. Позднее вышел полный комплект ПО с собственным контроллером SDN от HP и интерфейсы программирования (API), позволяющие разработчикам создавать приложения для SDN.
В настоящее время практически вся линейка коммутаторов и маршрутизаторов HP поддерживает протокол OpenFlow и может работать как в традиционных сетях, когда управление сетевым трафиком реализуется на каждом устройстве, так и в программно-конфигурируемых сетях под управлением контроллера HP.
HP Virtual Application Networks SDN Controller
HP Virtual Application Networks SDN Controller был представлен в 2013 году как ПО и как готовое решение на базе сервера HP ProLiant. Контроллер можно установить на обычном (или виртуальном) сервере, либо на кластере серверов для более производительного и отказоустойчивого решения. Он реализует стандартную функциональность динамического конфигурирования сетевых устройств на основе заданных правил, взаимодействуя с компонентами инфраструктуры SDN по протоколу OpenFlow.
Контроллер поддерживает ряд встроенных функций, включая возможности сетевой виртуализации, обеспечения безопасности, управления трафиком, а также механизмы авторизации и аутентификации для контроля доступа интегрированных в контроллер средств и внешних приложений SDN. Для взаимодействия с последними предлагается интерфейс RESTful, который могут использовать различные системы оркестрации и управления, а также бизнес-приложения.
В HP протокол OpenFlow считают одним из важных, но не единственных компонентов для построения полнофункциональной инфраструктуры SDN. Кроме этого, компонентами SDN также считают и другие механизмы для динамического конфигурирования устройств, например, NETCONF, OVSDB. Наряду со стандартизацией взаимодействия уровня управления с сетевой инфраструктурой (т.н. «южный мост»), существует необходимость стандартизации его взаимодействия с приложениями (т.н. «северный мост»). Это реализуется на основе технологии REpresentational State Transfer (REST). Кроме этого, немаловажным остается вопрос взаимодействия контроллеров SDN разных производителей. Пока лишь небольшое число независимых вендоров предпринимают шаги по обеспечению взаимодействия своих решений. Один из примеров – интеграция SDN-контроллера HP и VMware NSX.
Приложения SDN
На платформе SDN-контроллера компании НР уже создан ряд приложений. Часть из них разработана НР, например, Net Optimizer, Net Protector. Другие создаются компаниями-партнёрами НР и открытым сообществом. Такие приложения позволяют создавать комплексную среду SDN, включающую приложения, адаптированные для взаимодействия с сетевой средой посредством контроллера SDN, собственно контроллер SDN и сетевую инфраструктуру с поддержкой протокола OpenFlow. Это создаёт основу для автоматизации процессов динамического управления сетями по запросам приложений «на лету», что повышает эффективность и гибкость использования ресурсов инфраструктуры, а также сокращает совокупную стоимость владения.
Стратегия SDN
В HP подчеркивают приверженность компании к разработке открытых сетевых решений, которые помогают полнее раскрыть возможности бизнес-приложений и уже сейчас подготовить инфраструктуру к полномасштабному использованию SDN-технологий с минимальными затратами. Главной задачей стратегии SDN в компании считают комплексную (end-to-end) автоматизацию сетей – от ЦОД до кампусов и филиалов компаний. Поэтому решение HP SDN не ограничивается сетями ЦОД – оно также охватывает филиальные и глобальные сети, где также приходится решать непростые задачи гибкого управления ресурсами.
Выпущенные в середине 2014 года коммутаторы серии HP 5400R zl2 – новое поколение оборудования, призванного помочь клиентам увеличить производительность сетевой инфраструктуры и перейти на технологии гибких сетей SDN.
НР рекомендует заказчикам уже сейчас готовиться к внедрению SDN и приобретать сетевое оборудование с поддержкой технологий SDN, создавать тестовые зоны для проверки совместимости инфраструктуры с приложениями. Апробированные решения можно постепенно развертывать в сети предприятия. Если предприятие приступит к внедрению технологий программно-конфигурируемых сетей сейчас, то через пару лет оно сможет развернуть полноценную инфраструктуру SDN со всеми ее преимуществами с точки зрения гибкости и повышения эффективности бизнеса. В конечном счете, увеличение числа доступных приложений приведет к масштабному развертыванию SDN в сети предприятий. По прогнозу IDC, рынок сетевых приложений SDN к 2017 году достигнет 1,1 млрд долларов.
SDN App Store
В прошлом году был запущен проект электронной площадки НР SDN AppStore для корпоративного сегмента. В его ассортименте – различные приложения, решающие большой спектр задач от обеспечения безопасности до поддержки облачных вычислений и мобильности, а также доступ к средствам их разработки. Перечень приложений постоянно расширяется за счёт активной работы компаний-партнеров и интернет-сообщества. Наиболее популярными стали контроллеры виртуальных сетей, приложения для оптимизации трафика при работе унифицированных коммуникаций на базе Microsoft Lync, а также пакеты SDN SDK. Кроме этого, НР предлагает различные формы обучения разработчиков приложений.
В конце прошлого года HP открыла онлайн-супермаркет приложений SDN. Разработчики могут представить там свои SDN-решения, а заказчики — подобрать для себя наиболее выгодное и удобное сетевое приложение.
Cisco ACI
В ноябре 2013 года руководители Cisco Systems продемонстрировали разработанную приобретенной Cisco компанией Insieme концепцию программного управления сложной сетевой инфраструктурой, ориентированную на оптимизацию работы приложений и имеющую приблизительно те же цели, что и SDN. Она получила название Application Centric Infrastructure (ACI). В состав ACI вошли контроллер APIC (Application Policy Infrastructure Controller), коммутаторы серии Nexus 9000 и расширенная версия операционной системы NX-OS. Для работы Nexus 9000 в режиме ACI применяются микросхемы ASIC разработки Cisco.
ACI часто рассматривают как вариант SDN с проприетарными компонентами, такими как коммутаторы Nexus 9000. Создание ACI демонстрирует желание Cisco использовать ведущие позиции в сетевой отрасли, чтобы противопоставить собственные разработки распространению стандартных технологий SDN. Однако полностью игнорировать эти технологии сегодня не может ни один вендор. Поэтому не удивительно, что в так называемом автономном режиме эти коммутаторы поддерживают функциональность SDN и протокол OpenFlow.
В чем же отличие подхода Cisco? Подобно SDN, ACI предусматривает программное управление, но в роли управляемых элементов выступают не простые коммутаторы, а по-прежнему сложные и многофункциональные сетевые устройства. Главная идея ACI – дать приложениям возможность программировать сеть «под себя». Для этого создается профиль Application Network Profile (ANP), где указываются параметры качества обслуживания (QoS), безопасности, балансировки нагрузки и пр. Эти профили загружаются в контроллер APIC, а тот – программирует коммутаторы Cisco. Профили служат для конфигурирования сети и применения политик управления. Контроллер APIC – важнейший компонент ACI, управляющий физическими и виртуальными сетевыми устройствами, используя ANP. По замыслу разработчиков, ACI должна помочь заказчикам полностью раскрыть потенциал приложений и увеличить гибкость бизнеса.
ACI очень похожа на SDN, но в Cisco подчеркивают, что APIC не является контроллером SDN. Он работает независимо от коммутационного уровня данных и уровня управления, не разделяя соответствующие процессы. Его важнейшие функции – управление инфраструктурой и информирование систем вышестоящего уровня о ее состоянии (мониторинг).
Возможности интеграции и партнерская экосистема
В настоящее время Cisco Systems продолжает продвигать ACI в качестве альтернативы SDN. Год назад компания представила «основанный на стандартах» протокол OpFlex, который должен играть такую же роль, что и OpenFlow. Корпорация даже рассчитывает с помощью IETF сделать данный протокол отраслевым стандартом. Пока же для развертывания ACI требуются новые коммутаторы (линейки Nexus 9000) и новое ПО (Application Policy Infrastructure Controller, APIC), хотя есть возможность интеграции с различными средствами оркестрации и автоматизации.
Для взаимодействия ACI с платформами управления и оркестрации, такими как OpenStack, Puppet, CFEngine и др., используются API-интерфейсы XML, JSON и RESTful. Они должны также обеспечить интеграцию ACI с открытой платформой SDN OpenDaylight, виртуальными коммутаторами Open Source и технологией VXLAN. Для поддержки и развития новой инфраструктуры Cisco формирует экосистему партнеров. Инициативу Cisco ACI поддерживают BMC, Computer Associates, Citrix, EMC, Emulex, F5, IBM, Microsoft, NetApp, VMware и ряд других компаний.
Тем не менее, ACI – проприетарное альтернативное решение, ограничивающее клиентов закрытой экосистемой поставщика. Для некоторых компаний это может быть приемлемым вариантом, но идет вразрез с общими тенденциями рынка.
Между тем Cisco старается сохранить рыночные позиции своего оборудования, предлагая для них некую дополнительную оболочку, и называя это SDN. В частности, поддержка SDN, добавленная в 2013 году в Cisco Open Network Environment (ONE) и в Cisco OnePK (Platform Kit), позволяет рассматривать их как инструменты, призванные помочь компании защитить свои позиции на ключевом рынке. Это изначально обеспечивает лучшие результаты при работе с устройствами Cisco, то есть ориентировано на ее собственные продукты, и не дает той открытости, которая требуется SDN.
Дорога к SDN
В конечном счете, более перспективным, по мнению аналитиков, считается открытое SDN-решение. На данный момент SDN уже предоставляет компаниям множество вариантов для выбора: коммутаторы с поддержкой OpenFlow, NETCONF, OVSDB и расширяющаяся библиотека API, а также корпоративное программное обеспечение, которое пользуется преимуществами этих протоколов. Как и любая другая, инфраструктура SDN должна строиться на базе открытых стандартов. Такая открытая экосистема ускорит процесс внедрения инноваций в области сетевых технологий.
Хотя из-за инерции мышления и негативного влияния кризисных явлений пока доминирует традиционный подход к построению сетевой инфраструктуры, SDN уже сейчас позволяет эффективно решать задачи на стыке виртуальных и физических сред. Опыт крупных интернет-компаний продемонстрировал возможности адаптации масштабной сетевой инфраструктуры к постоянно меняющимся требованиям. Но большинство компаний не спешат с реализацией стратегии SDN, полагая, что им придется полностью менять свое сетевое оборудование.
Часть этих опасений происходит от общего заблуждения в том, что SDN является продуктом. На самом деле это скорее подход к проектированию сетей, а также новая парадигма их администрирования, мониторинга и, в конечном счёте, адаптации под бизнес-задачи, реализуемые приложениями. Переход к SDN – поэтапный процесс, учитывающий бизнес-сценарии использования сети. Хотя существуют определенные продукты, например, коммутаторы SDN с поддержкой OpenFlow, в полной замене сетевой инфраструктуры нет никакой необходимости.
По прогнозам, в Европе и США массовое внедрение SDN начнется в 2016 году. К этому времени объем мирового рынка SDN может превысить, по прогнозам IDC, 3,7 млрд. долларов. Около 670 млн. долларов поступит от приложений SDN. По мере роста темпов внедрения также будут развиваться инструменты и возможности. SDN как технология достигла критической массы, и для тех компаний, которые предпочтут ею воспользоваться, сейчас есть много различных вариантов.
В России активный интерес к программно-конфигурируемым сетям начнётся несколько позже, но уже сегодня ряд российских заказчиков обсуждают пилотные проекты с SDN, ведутся исследования, создан первый российский SDN-контроллер. Как ожидается, основанные на открытых стандартах программно-конфигурируемые сети, позволят привести сетевую инфраструктуру в соответствие с потребностями бизнеса и бюджетом. Кроме того, клиент не будет привязан к какому-то конкретному вендору, поэтому сможет внедрять технологии разных производителей.
Наши предыдущие публикации:
Спасибо за внимание, готовы ответить на ваши вопросы в комментариях.
