SDN: чего хотят заказчики

Согласно собранной информации, на данный момент подавляющее большинство заказчиков (72%) проявляют лишь теоретический интерес к технологиям SDN. Но при этом немало и компаний (16%), которые рассматривают возможность практического внедрения таких технологий. 4% опрошенных уже тестируют решения SDN, а три компании — федеральный оператор связи, представитель гостиничного бизнеса, а также инжиниринговая компания, специализирующаяся на комплексном оснащении предприятий общественного питания, — используют отдельные элементы SDN.

Заметим, что число специалистов, которые вообще не знают, что такое SDN, за два года радикально снизилось: если в 2013 году таковых было 30%, то в текущем — только 3,5% (см. рис. 1). Это неудивительно, поскольку вопросы SDN в последнее время обсуждаются буквально на всех конференциях, так или иначе связанных с ИТ. Что же касается Ethernet-форума, то SDN стала его основной темой — впору менять название на SDN-форум.

Рис. 1. Изменение отношения заказчиков к SDN с 2013 года

SDN: ПРЕМУЩЕСТВА И ПРОБЛЕМЫ

Когда концепция SDN только появилась, было распространено мнение, что ее реализация позволит существенно снизить стоимость сетей: недорогой (а возможно, и бесплатный) программный контроллер, в котором сосредоточен весь «интеллект» сети, плюс «неинтеллектуальные» коммутаторы, которые будут производиться в массовом масштабе, в том числе по модели white box, и стоить очень дешево. Однако со временем иллюзии рассеялись, и стало понятно: существенного снижения стоимости вряд ли удастся достичь. Традиционные производители сетевого оборудования совсем не заинтересованы в реализации описанной выше модели, а они диктовали, диктуют и, по-видимому, будут формировать «повестку дня» в сетевом мире. Да и потребность решать ряд технических задач, таких как обработка большого числа потоков и поддержка «продвинутых» механизмов QoS, не позволяет сделать совсем уж дешевый коммутатор.

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

В последнее время среди некоторых российских экспертов бытует мнение, что SDN позволит ликвидировать зависимость от западных производителей сетевого оборудования (что чрезвычайно важно в силу общей тенденции к импортозамещению). Мы решили выяснить отношение к этому мнению заказчиков. Но оно нашло поддержку лишь у 16,7% специалистов, имеющих практический интерес к SDN (см. рис. 2).

Рис. 2. Причины интереса к SDN

Главной проблемой SDN наши респонденты считают сложность интеграции нового SDN-оборудования в сети, построенные по традиционным технологиям, — на это указали 61,2% ответивших (см. рис. 3). В этой связи хотелось бы отметить, что, как показал проведенный OSP Data анализ конкретных решений SDN, все ведущие производители уделяют повышенное внимание вопросам внедрения SDN-продуктов в существующие сети. У большинства имеются готовые решения для гибридных сетей, в которых сочетаются новые (SDN) и старые (традиционные сетевые протоколы) технологии. Такое «совместное существование», как правило, обеспечивается за счет параллельной поддержки сетевым оборудованием двух режимов работы: традиционная коммутация/маршрутизация и SDN. Подробнее про стратегии миграции к SDN и построение гибридных сетей вы можете прочитать в статье автора «SDN: от концепции к решениям», опубликованной в сентябрьском номере «Журнала сетевых решений/LAN» за текущий год.

Рис. 3. Проблемы SDN

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

Лишь около 16% указали на невостребованность SDN («Технология SDN не нужна для решения актуальных сетевых задач»). И это вселяет оптимизм по поводу того, что уже в ближайшее время теоретический интерес большей части специалистов к этой технологии перейдет в практическую плоскость.

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

В качестве «других» проблем были указаны недостаточная надежность и слабые средства защиты информации. К слову, роль систем безо-пасности в среде SDN нами была изучена дополнительно. Лишь треть опрошенных считают, что инфраструктура ИТ-безопасности может быть полностью независимой от внедренного решения SDN. Большинство же (63%) уверены в том, что решения ИТ-безопасности должны быть внедрены на всех участках ИТ-инфраструктуры предприятия, причем с самого начала использования решений SDN. Лишь немногие специалисты, примерно каждый десятый, полагают, что при внедрении SDN достаточно использовать решения ИТ-безопасности только в ЦОДе.

Составляя опрос, мы, естественно, решили поинтересоваться, какой производитель, по мнению заказчиков, является лидером в области решений SDN. Однако низкий уровень практического знакомства специалистов с такими решениями означает, что в данном случае фактически они выбирали самого известного (хорошо знакомого) им вендора в области продуктов для сетевых инфраструктур. На это указывает и тот факт, что на данный вопрос ответили даже те, кто вообще «не знает, что такое SDN». Вполне предсказуемо больше всего «очков», 55%, в таком голосовании набрала Cisco. На втором месте — HP, ее в качестве лидера видит каждый седьмой респондент. Примерно одинаковое число голосов (от 5 до 7%) получили три компании: NEC, Huawei и Brocade. Далее идут Juniper Networks (4,3%) и Extreme Networks (3,6%). Из оставшихся двух компаний, которые мы включили в список, за Nuage Networks (в составе Alcatel-Lucent) высказались трое специалистов (2,1%), а за Dell — один (0,7%). Вместе с тем сразу несколько заказчиков в категории «другое» указали компанию VMware, упомянув также приобретенные ею компании Nicira и DynamicOPs. Укажи мы VMware явным образом, скорее всего, она бы набрала еще больше голосов. Кроме того, в качестве «лидера в области SDN» один специалист указал компанию Arista.

ОТНОШЕНИЕ К BMS

В настоящее время большинство поставщиков решений SDN стремятся включать в их состав собственные коммутаторы, как правило, с фирменными операционными системами (см. упомянутую статью «SDN: от концепции к решениям»). Но при этом эксперты все чаще обсуждают возможность применения так называемых bare-metal switch — открытых аппаратных коммутационных платформ, поставляемых без операционных систем. Использование таких решений устраняет зависимость заказчиков от поставщика коммутаторов, позволяя им (заказчикам) выбирать различные операционные системы сторонних разработчиков (Cumulus Linux и др.). Кроме того, такой подход сулит существенную экономию, поскольку коммутаторы с ОС стороннего разработчика, согласно обещаниям их поставщиков, обойдутся значительно дешевле традиционных полнофункциональных коммутаторов.

Но, как показало наше исследование, лишь треть российских заказчиков проявляют интерес к коммутаторам без предустановленной ОС, несколько — тестируют такое оборудование и только одна компания (специализирующаяся в области консалтинга и системной интеграции) уже использует такие устройства. И это несмотря на то, что подобные решения активно продвигаются в России, например, компанией ETegro Technologies. Каждый третий специалист вообще не знает, что такое bare-metal switch, и примерно столько же не видят целесообразности их использования (см. рис. 4).

Рис. 4. Отношение к коммутаторам bare-metal switch

Среди тех, кто имеет практический интерес к коммутаторам типа bare-metal switch, каждый второй надеется на то, что их применение позволит снизить капитальные затраты на сетевую инфраструктуру. Каждый третий полагает, что доступность таких коммутаторов будет способствовать внедрению отечественных контроллеров SDN и тем самым снижению зависимости от западных производителей. На рынке уже имеются подобные предложения — например, на базе отечественного SDN-контроллера Runos, разработанного Центром прикладных исследований компьютерных сетей (ЦПИКС). В качестве одного из вариантов эта организация предлагает внедрять контроллер Runos вместе с коммутаторами bare-metal switch, на которые устанавливаются операционная система Open Networking Linux и разработанный в ЦПИКС агент OpenFlow 1.3. Другой вариант — использование коммутаторов, построенных на основе серверов x86. В этом случае применяются традиционные серверы Intel с большим числом сетевых интерфейсов, а коммутация осуществляется специальным ПО за счет ресурсов центрального процессора.

SDN-ПРИЛОЖЕНИЯ

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

Мы решили выяснить, SDN-приложения с какой функциональностью наиболее востребованы заказчиками. Для этого было выделено четыре задачи (см. рис. 5), выполнение которых сегодня (в традиционных сетях) требует большого объема ручного труда, а потому нуждается в автоматизации. Наши респонденты подтвердили актуальность этих задач. Так, 77% ответивших на этот вопрос проявили заинтересованность в приложении, которое бы позволило автоматизировать настройку новых сетевых устройств. При наличии такого приложения контроллер SDN способен самостоятельно выявить вновь подключенное устройство (например, коммутатор) и сконфигурировать его.

Рис. 5. Наиболее востребованные SDN-приложения

Примерно 60% не отказались бы от системы, помогающей настраивать алгоритмы приоритизации и обеспечивать качество обслуживания (QoS), необходимое для существующих и новых приложений (в данном случае имеются в виду традиционные бизнес-приложения, коммуникационные приложения и пр., а не собственно SDN-приложения). При развертывании нового приложения, скажем телефонии или видеосвязи, система автоматически (по определенным правилам) назначает ему тот или иной класс обслуживания, который характеризуется определенными параметрами QoS, например по уровню приоритета. Затем контроллер применяет эти правила, но не по отдельности к каждому сетевому устройству, а сразу ко всей сети. Такой подход значительно сокращает время развертывания новых приложений, обеспечивает согласованное конфигурирование сетевых устройств, снижает вероятность ошибки, связанной с человеческим фактором.

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

Из сказанного можно сделать однозначный вывод, что возможности архитектуры SDN быстро и относительно просто расширить функциональность сети — за счет программных средств, без установки специализированных устройств — чрезвычайно востребованы. И это хорошо понимают производители, активно формируя вокруг своих SDN-решений экосистемы с привлечением сторонних разработчиков. В частности, отметим созданный HP онлайн-магазин SDN-приложений HP SDN App Store — как утверждают в компании, пользователи могут одним кликом мышки загрузить SDN-приложение из магазина на контроллер, сразу же его запустить и начать немедленно использовать. Или, например, экосистему NEC SDN Partner Space, в рамках которой разработан и протестирован большой набор приложений по оптимизации сети, анализу ее производительности, управлению правами доступа (DPI), безопасности и т. д.

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

Александр Барсков — ведущий редактор «Журнала сетевых решений/LAN». С ним можно связаться по адресу: ab@lanmag.ru. Статья подготовлена по материалам исследования аналитической группы OSP Data, проведенного при поддержке компании Fortinet.