sdn контакты что это

Сеть как смартфон: как SDN изменит интернет

Что такое SDN

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

Лучше понять суть сетей позволяет аналогия с мобильными телефонами. У старых моделей телефонов функциональность была заложена в — изменить ее простому человеку было нельзя. То есть если производитель не в телефон микросхему определителя номера, пользователь уже не мог выяснить, кто звонил. Функциональность современных мобильных телефонов реализуется программным способом: устанавливая разные приложения, пользователь получает доступ к новым и ресурсам. SDN превращает серверы в подобие смартфонов, позволяя нужную систему из виртуальных «кубиков», которые нужны в каждый конкретный для решения определенной задачи. В результате повышается продуктивность, а могут быстрее реагировать на конкурентные вызовы.

Как SDN влияет на жизнь и бизнес

Большинство современных технологий и сервисов, от Facebook и Amazon до продуктов Google и Microsoft, работают благодаря сетям. К примеру, платформы распределяют нагрузку, не нарушая работы сервисов, — именно SDN делает это возможным.

Часто люди пользуются преимуществами SDN, даже не осознавая этого. Сервис Skype for Business совершил переворот в корпоративных коммуникациях, позволив забыть о номерах. Именно возможности SDN позволили сотрудникам тысяч компаний с помощью чатов, видеозвонков и обмена файлами через одно приложение. SDN нечувствительно для пользователей распределяет трафик в сети таким образом, что всё работает стабильно. С повсеместным внедрением технологий 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 стремительно ворвалась в мир сетевых технологий, став хедлайнером многих конференций и форумов. И хотя на слух многие еще путают ее с ISDN, это только повышает градус интереса. Так что такое SDN? Гениальная идея университетских исследователей? Или «второй Ethernet»?

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.

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

Источник