Для любой технологии, а тем более в сфере IT, 10 лет – это достаточно заметный срок, чтобы можно было, с одной стороны, оценить проникновение и влияние на инфраструктуру, с другой – оценить и спрогнозировать дальнейшие перспективы. Итак, SDN – Software Defined Network – программно-определяемая сеть, стало ли это некой панацеей, «единорогом» или мыльным пузырём в структуре телекоммуникаций?
Впервые эта концепция прозвучала на 15-м симпозиуме по Usenix Security в Ванкувере в августе 2006 года в рамках доклада SANE: A Protection Architecture for Enterprise Networks, и, как ни странно, этот доклад был ориентирован на безопасность этого сетевого решения, так как в рамках SANE применялся «очень консервативный метод обеспечения безопасности – все права и доступы в сети определял только единственный центральный контроллер домена». Этот доклад объединял три университетские школы – Стэнфорд, Беркли и Карнеги Меллон, правда, в состав компании Nicira, которая стала первой реализовывать проекты на базе SDN, вошли представители только Стенфорда и Беркли, где в 2008 в кампусах была развёрнута первая сеть на основе SDN.
Чем же отличается эта концепция сети от привычных нам IDN – Infrastructure Defined Networks?
SDN имеет три уровня
- инфраструктурный уровень, предоставляющий набор сетевых устройств (коммутаторов и каналов передачи данных);
- уровень управления, включающий в себя сетевую операционную систему, которая обеспечивает приложениям сетевые сервисы и программный интерфейс для управления сетевыми устройствами и сетью;
- уровень сетевых приложений для гибкого и эффективного управления сетью.
Именно разделение на эти три очевидных уровня и создание стандартов управления и передачи данных фактически и есть SDN. Произошла небольшая революция, и от мира, где правили производители железа со своими ОС на уровне маршрутизаторов, появился новый мир, где им предлагали новые правила ведения дел, новые стандарты.
На данный момент основным активно развивающимся и поддерживаемым организацией Open Networks Foundation, стандартом для SDN является OpenFlow — открытый стандарт, в котором описываются требования, предъявляемые к коммутатору, поддерживающему протокол OpenFlow для удаленного управления.
С помощью существующих маршрутизаторов обычно решаются две основные задачи: передача данных (forwarding) — продвижение пакета от входного порта на определенный выходной порт, и управление данными — обработка пакета и принятие решения о том, куда его передавать дальше, на основе текущего состояния маршрутизатора.
Развитие маршрутизаторов до сих пор шло по пути сближения этих уровней, однако с уклоном на передачу (аппаратное ускорение, совершенствование ПО и внедрение новых функциональных возможностей для увеличения скорости принятия решения по маршрутизации каждого пакета), тогда как уровень управления оставался достаточно примитивным и опирался на сложные распределенные алгоритмы маршрутизации и замысловатые инструкции по конфигурированию и настройке сети. Разумеется, ПО маршрутизаторов, реализующее уровень управления, было проприетарным и закрытым. Что приводило к нашим любимым техническим сертификациям и корочкам от вендоров по заоблачных ценам.
В стандарте OpenFlow взаимодействие контроллера с коммутатором осуществляется посредством протокола OpenFlow — каждый коммутатор должен содержать одну или более таблиц потоков (flow tables), групповую таблицу (group table) и поддерживать канал (OpenFlow channel) для связи с удаленным контроллером — сервером. Спецификация не регламентирует архитектуру контроллера и API для его приложений.
Таким образом озвученная идея SDN о создании унифицированного, независимого от производителя сетевого оборудования, программно-управляемого интерфейса между контроллером и транспортной средой сети нашла отражение в протоколе OpenFlow, позволяющем пользователям самим определять и контролировать, кто с кем, при каких условиях и с каким качеством может взаимодействовать в Сети.
Как и в докладе 2006 года, ключевым элементом является контроллер – правда, если ранее он «занимался» вопросами безопасности, то теперь его функции стали шире – это отдельный физический сервер, который может управлять как одним, так и несколькими OpenFlow-коммутаторами и содержит сетевую операционную систему, предоставляющую сетевые сервисы по низкоуровневому управлению сетью, сегментами сети и состоянием сетевых элементов, а также приложения, осуществляющие высокоуровневое управление сетью и потоками данных.
В каждом контроллере имеется хотя бы одно приложение, которое управляет коммутаторами, соединенными с этим контроллером, и формирует представление о топологии физической сети, находящейся под управлением контроллера, тем самым централизуя управление.
Это всё скучное и умное описание, которое приводит в итоге к тому, что из-за централизации, возможной виртуализации сетей и управления нагрузкой практические результаты измеряются в уменьшении эксплуатационных расходов за счёт более полного использования уже имеющихся ресурсов. Причём внедрение и добавление функциональности в ЦОД не ведёт за собой изменения архитектуры, следовательно упрощает и последующую поддержку. Де-факто SDN позволяет строить масштабируемые облака, под конкретные задачи, при этом обладать большой гибкостью и «интеллектом» при управлении ресурсами.
А что же наши герои, которые сперва выступили в Ванкувере, а потом создали Nicira и первыми реализовали ряд коммерческих проектов? В середине 2012 года эта компания вместе со всеми наработками была куплена за 1,26 млрд $ VMware, что привело к буму покупок подобных стартапов SDN рынка в 2012 году – суммарно было потрачено ещё около 1 млрд $. На данный момент практически все ведущие мировые IT и телеком-вендоры поддерживают и предлагают те или иные решения на базе SDN, и, несмотря на 10 лет истории, эта технология еще считается перспективной и не показавшей всего, на что способна в построении высоконагруженных и безопасных решений. За первые пять лет концепция SDN прошла огромный путь – от небольшого доклада, до первенцев – компаний-первопроходцев, которые сумели доказать преимущества нового формата сети. Фактическим итогом принятия телеком-рынком этого принципа стала как миграция провайдеров, например, Google, так и признание и поддержка этого стандарта ведущим инфраструктурным телеком-вендором – Cisco.
Однако не всё было легко и просто, тут были и сложности – представьте, что такое играть на фактически монополизированном рынке, подрывая главенство и верховенство общепризнанного лидера. Обучение новых специалистов, появление архитекторов сетей другого уровня, которые будут видеть потенциал и структуру сетей совершенно по-новому, визуализировать и воплощать с учётом новых вводных. Кроме того, всё равно, прежде чем приносить прибыль за счёт экономии и полноценной загрузки сети, SDN требует вложений, если и не в железо, то в проектирование, расчёт и реализацию. Это всё требовало времени, усилий, должного уровня понимания рынка. Об этом, а также о практических случаях реализации мы и напишем дальше, в следующих материалах.
Автор: SAFEDATA
