SDN и «окружающая среда»

«Software-defined Networking (SDN) собирается изменить все в ИТ» — этот тезис настойчиво внушается потенциальным покупателям производителями сетевого оборудования. На маркетинговую притягательность термина «software-defined» полагаются и многие производители других ИТ-продуктов. Вслед за SDN появляются Software-defined Security, Software-defined Data Centers, Software-defined Storage. И, по-видимому, на этом не закончится. Как же в действительности воспринимается SDN корпоративными покупателями?

В 2013 г. журнал InformationWeek провел опрос 267 ИТ-профессионалов в Северной Америке. Некоторые его результаты могут заинтересовать и наших читателей.

По словам автора отчета Итона Бэнкса, возникло два лагеря. В первом — немногие сетевики-энтузиасты. Они рассматривают SDN как перспективную технологию, которая позволяет им гибко виртуализировать сети. Однако результаты опроса показали, что большинство специалистов относятся к SDN прохладно. Так, 33% опрошенных не планируют даже тестировать технологию, тогда как другие 25% говорят, что пройдет не меньше года, прежде чем они начнут что-либо делать в этом направлении. Здесь следует отметить, что 45% респондентов сказали, что они знакомы только с базовыми понятиями технологии, а 15% считали, что хорошо в ней разбираются.

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

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

За этой логикой стоят низкие бюджетные ассигнования организаций, выделяемые на SDN: 26% респондентов, которые имеют или планируют ввести SDN в эксплуатацию, говорят, что в 2014 г. на это будет выделено только от 1% до 5% бюджета. Для организаций проще купить более новые версии того, что уже работает. Если коммутатор не справляется с трафиком, купи более мощный, если дисковой памяти не хватает, купи больше. Конечно, покупка «большего» не всегда решает проблемы. Однако если компания не осознает, как их может решить SDN, маловероятно, что она будет выделять на это ресурсы. Кроме этого, многих технических специалистов не столько заботит то, является ли их сеть программно-управляемая или нет, сколько сервисы, которые в действительности предоставляются. Это не уменьшает важность SDN как технологии, но снижает ее конкурентоспособность в долгосрочной перспективе.

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

Недостаток в стандартизации SDN является другим существенным барьером для принятия технологии. На протяжении многих лет стандартные протоколы обеспечивали интероперабельность. Хотя и существовало множество исключений, но если производитель поддерживал протоколы Spanning Tree, OSPF, BGP или MPLS, тогда его продукты могли работать совместно с продуктами конкурента на основе одинаковых протоколов. Для SDN на сегодня нет официального стандарта. В то время как впечатление и ощущение от использования SDN становятся привычными (приложения, говорящие с контроллером, который программирует сетевую инфраструктуру), детали каждой реализации существенно различаются среди предложений производителей. По большей части, в промышленности сейчас не ведутся разговоры о совместимости продуктов, хотя и есть несколько светлых пятен.

Первое из них — OpenDaylight (ODL). Это проект Linux Foundation с открытым кодом. ODL создает стек SDN, который определяет контроллер, а также API для потоков север—юг. Хотя в мире имеется множество проектов с открытым кодом, ODL выделяется тем, что собрал вместе нескольких известных производителей, среди которых Brocade, Cisco, HP, IBM, Juniper, Microsoft, NEC, Red Hat и VMware.

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

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

Вторая попытка стандартизации — это протокол OpenFlow, разработку которого курирует Open Networking Foundation (ONF). Протокол получил широкую поддержку индустрии, хотя ее уровень существенно различается от производителя к производителю. Одно время он разрабатывался ONF довольно интенсивно. За первым релизом OF 1.0 последовали спецификации 1.1 и 1.3.

Различия между версиями OF 1.0 и OF 1.3 весьма существенные. Большинство производителей коммутаторов обнаружили, что невозможно реализовать все операции OF 1.0 в кремнии. Это означало, что некоторые из них должны выполняться ЦП коммутатора. Такие операции снижали производительность коммутаторов, что вызывало проблемы с масштабируемостью.

Более сложный список возможностей OF 1.3 только усугубило эту ситуацию, поскольку производители столкнулись с более трудными проблемами для существующих микросхем.

ONF стремится продвинуть OpenFlow вперед и активно работает над спецификацией OF 1.4. Чтобы помочь с реализацией протокола на чипе, был создан «Совет производителей микросхем», в задачи которого входит предоставить компаниям площадку для обсуждения. Они должны помочь ONF сделать стандарт OpenFlow дружественным к аппаратной реализации. Однако какой из стандартов примет индустрия, покажет время.

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

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

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

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

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

Вдобавок, некоторые существующие устройства, которые не имеют SDN-возможностей сегодня, могут получить их в будущем. OpenFlow является одним из таких примеров. Cisco обещает снабдить некоторые из существующих линеек своих продуктов API посредством инициативы ONE.

Сегодня многие продукты уже имеют API, даже если заказчики об этом не знают. Коммутаторы Ethernet от таких производителей, как Avaya и Brocade уже дружественны к SDN. В связке с популярными платформами виртуализации от VMware и OpenStack они позволяют им сообщать о своих нуждах «по запросам» к базовой сетевой инфраструктуре без ручного вмешательства.

Данный обзор побудил ветерана ИТ-индустрии Курта Марко рассмотреть некоторые SDN-стратегии упомянутых в нем производителей. Таковых (производителей) оказалось 11. Однако для понимания ситуации нет необходимости рассматривать все. Ниже представлены продукты наиболее узнаваемых в Украине компаний.

Cisco. Хотя Cisco «игралась» с технологиями SDN в течение многих лет, ей не хватало согласованного плана, как ИТ-команды могут принять ее видение программно-управляемой инфраструктуры и услуг при сохранении инвестиций в широкий спектр уже развернутых аппаратных решений.

Все изменилось в ноябре, когда компания объявила о своей Application Centric Infrastructure (ACI), грандиозном проекте, который выходит за рамки управления потоком на низком уровне и управления виртуальной сетью, чтобы включить в масштабах всего предприятия регулирование и автоматизацию использования приложений, производительности и политик безопасности, оркестровку виртуальных сетевых сервисов и управление физической и виртуальной сетевой конфигурацией.

Это достигается за счет нового Application Policy Infrastructure Controller (APIC), который включает в себя длинный перечень поддерживаемых интерфейсов и протоколов, в том числе OpenFlow, OVSDB (Open vSwitch), onePK (API для управления и автоматизации), NETCONF (конфигурация сети), Application Virtual Switch, эволюционное продолжение Nexus 1000V, а также недавно объявленный OpFlex. Cisco также представила новую линейку коммутационного оборудования, Nexus 9000, которое тесно интегрировано с системой управления ACI и APIC с помощью нового поколения прошивки.

Поскольку ACI/APIC было недостаточно, Cisco также выпустила первую коммерческую версию контроллера проекта OpenDaylight. Названный Extensible Network Controller, он поддерживает OpenFlow и onePK для управления южным трафиком и конфигурацией коммутатора с новым Java API для северного потока для интеграции с другими сетевым службами.

НР. Компания твердо придерживается физического уровня OpenFlow и имеет самый широкий выбор совместимых продуктов. OpenFlow поддерживается в пяти линейках коммутаторов масштабом от филиала до ЦОД.

Управляющим устройством является Intelligent Management Center, который включает модуль, выполняющий мониторинг и управление тремя ключевыми слоями SDN-архитектуры: (1) аппаратной инфраструктурой; (2) уровнями управления и приложений и (3) топологией OpenFlow, контроллером, устройствами и трафиком.

Dell. Этот производитель придерживается более агрессивного подхода к SDN, чем его конкуренты. Поддержка особенностей SDN разделяется на три категории: физический уровень SDN, использующий контроллер OpenFlow и совместимые коммутаторы; оверлеи виртуальных сетей, поддерживающие NVGRE (гипервизоры Microsoft) и VXLAN (VMware и Citrix), и набор API автоматизации, ориентированный на популярные скриптовые языки, включая TCL, Perl и Python.

Наиболее наглядным эволюционным подходом Dell являются гибридные коммутаторы, которые поддерживают OpenFlow в гибридном режиме. Это значит, что коммутаторы могут использоваться как для SDN, так и для традиционного продвижения пакетов на уровнях L2 и L3. Dell также сотрудничает с ONF (OpenFlow) и OpenDaylight, чтобы разработать стандарты для API с целью объединения OpenFlow и интероперабельных API северного потока в единый инфраструктурный контроллер.

Juniper. Стратегия SDN компании не строится на OpenFlow, а, скорее, использует смесь ее ПО для управления сетью (JunOS Space) и контроллера оверлейных сетей приобретенной в 2012 г. Contrail Systems (оверлейные сети используют протоколы, такие как VXLAN и STT для создания виртуальной сети между гипервизорами). Ее оверлейный подход подобен NSX от VMware и другим виртуальным сетям, которые строятся с использованием протоколов туннелирования через TCP/IP.

Juniper предлагает программируемость своих сетевых устройств, особенно граничных маршрутизаторов MX и серий коммутаторов EX и QFX, с отрытыми API, обеспечивающими средства для автоматического управления сетью и конфигурации. То, что Juniper открыла коды Contrail, позволяет думать, что компания, скорее всего, сосредоточится на обеспечении сетевых сервисов прикладного уровня для своих традиционных фабрик коммутации, а не на централизованном управлении потоком на физическом уровне.

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

Ready, set, buy! Посібник для початківців - як придбати Copilot для Microsoft 365