© 1995-2022 Компания «Инфосистемы Джет»
Камни преткновения и овраги на пути к SDN
Сетевые решения Сетевые решения

Судя по Gartner Networking hype cycle 2015, технология SDN, появившаяся на радаре уважаемой маркетинговой компании примерно в 2011 г., находится в самой нижней точке разочарования.

Главная>Сетевые решения>Камни преткновения и овраги на пути к SDN
Сетевые решения Тема номера

Камни преткновения и овраги на пути к SDN

29.03.2016

Посетителей: 52

Просмотров: 42

Время просмотра: 0.8 мин.

Авторы

Автор
Александр Гуляев Начальник отдела сетевых проектов компании «Инфосистемы Джет»

Вышел сеятель сеять семя свое, и когда он сеял, иное упало при дороге и было потоптано, и птицы небесные поклевали его; а иное упало на камень и, взойдя, засохло, потому что не имело влаги; а иное упало между тернием, и выросло терние и заглушило его; а иное упало на добрую землю и, взойдя, принесло плод сторичный…Лука 8:5-8

 

Судя по Gartner Networking hype cycle 2015, технология SDN, появившаяся на радаре уважаемой маркетинговой компании примерно в 2011 г., находится в самой нижней точке разочарования. (По моим наблюдениям, в течение двух лет.) Взбираться на плато продуктивности ей придется довольно долго. Самое время – провести некоторый анализ и выяснить, какие факторы определили ее нынешнее состояние, чего не хватает SDN для уверенной победы над доминирующими на рынке сетевыми решениями (кстати, в отличие от SDN, у доминирующих на сетевом рынке решений нет обобщенного названия. Их часто называют традиционными, что наводит на мысли о том, к какой категории относится SDN). Стоит отметить, что SDN – скорее собирательный термин для программно-управляемых сетей и не исчерпывается внедрением OpenFlow инфраструктуры.

 

 

Рис. 1. Gartner Networking Hype cycle 2015

Gartner Networking Hype cycle 2015

 

Гладко было на бумаге…

 

Технология SDN не является чем-то принципиально новым: попытки сделать сеть программируемой предпринимались неоднократно с середины 90-х гг. [1, 2]. Очередной всплеск интереса был вызван появлением в 2007–2010 гг. OpenFlow API, который перевел в практическую плоскость взаимодействие control и data-plane. А высокая степень этого интереса, приведшая к появлению большого количества продуктов, была вызвана сочетанием следующих факторов:

  • «взросление» средств виртуализации, развитие облачных услуг и повышение конкуренции между поставщиками. Конфигурацию сети теперь приходится менять часто, быстро, дешево и в соответствии с потребностями приложений. Администратор сети этого не умеет, и предпочтение отдается программному алгоритму. Кто сделал это своевременно – заработал больше. Решения с использованием программно-управляемых overlay-сетей – попытка преодолеть технологическую косность сети. Иными словами, проще сделать свою сеть;
  • нарастающее противоречие между сложностью и гибкостью сетевых технологий, длительным циклом реализации в «железе» новых запросов на функционал. Новые игроки рынка могут не инвестировать в дорогостоящую разработку ПО для поддержки колоссального объема сетевых протоколов и технологий, а разработать элегантное решение, лишенное «костылей», которые помогают обеспечить эффективность сети. Эта мотивация срабатывает и для калифорнийских стартапов, и для российских компаний, занятых решением проблемы замещения импорта высоких технологий с помощью SDN;
  • необходимость «перераскрутки» продуктовых линеек для крупных вендоров. Очередной индустриальный виток и желание вендоров не отстать от тенденций и конкурентов;
  • ставка на вертикаль власти и программистов. Не секрет, что многие сети используют небольшую часть функционала оборудования функций и обладают значительными тюнинговыми возможностями. Конфигурация сети, распределенная по сотням устройств, трудно поддается контролю. Тюнинг и наведение порядка – дорогостоящий процесс, сопряженный с рисками. В такой ситуации посещает мысль о «надмозге», который обеспечит порядок и выполнение запросов от бизнеса. Задача научить SDN-контроллер считать деньги выглядит более реалистичной, чем научить «сеть» из сотен устройств.

 

Сочетание этих факторов – драйвер SDN-индустрии. На практике они дополнялись завышенными ожиданиями, которые сопровождали появление технологии SDN. В числе таковых можно отметить:

 

  • возможность построения единой и повсеместной сети на SDN;
  • простоту внедрения и эксплуатации SDN-решения;
  • низкую стоимость оборудования для SDN и возможность использования имеющегося оборудования;
  • открытые технологии, исключающие vendor lock.

 

…но забыли про овраги

 

Развитие программно-определяемых сетевых технологий дало ответы на многие очевидные и неочевидные практические вопросы.

 

Масштабируемость и пригодность существующего оборудования

 

В настоящее время доступные к приобретению коммутаторы разделились на три основные группы:

  • коммутаторы, в которых не будет поддержки OpenFlow (как и прочих современных средств управления конфигурациями, к примеру NETCONF). К такому оборудованию относится большинство инсталлированных на сегодня коммутаторов;
  • коммутаторы, в которых поддержка OpenFlow реализована «для галочки». Как правило, это коммутаторы для ЦОД, разработанные на предыдущих поколениях чипов, которые поддерживают неактуальные версии OpenFlow и всего несколько сотен flow (Количество поддерживаемых flow – ключевая характеристика масштабируемости SDN-коммутатора, указывающая на число уникальных потоков, которыми он может одновременно управлять). Для серьезных задач в ЦОД (и тем более в сети сервис-провайдера) использовать такое оборудование рискованно. Это, пожалуй, самая многочисленная группа в данном сегменте оборудования;
  • коммутаторы, специально разработанные с учетом OpenFlow. Они не имеют ограничений по масштабированию, их выбор расширяется.

 

Стоимость оборудования для SDN Поддержка большого количества flow требует на коммутаторах большого объема памяти для организации TCAM. Высокая стоимость микросхем TCAM ограничивает возможность снижения стоимости оборудования. Кроме того, большинство коммутаторов поддерживают SDN и одновременно стандартные сетевые протоколы. А значит, производитель должен инвестировать в поддержку этого стека, что также не способствует снижению цены. В итоге цена коммутаторов различается не настолько, чтобы сыграть существенную роль при принятии решения.

 

Область применения В настоящее время это лишь серверная ферма ЦОД и нишевые решения, в которых SDN удачно дополняет другие технологии. Если толковать SDN как сети, организованные на принципах программного управления и виртуализации сетевых функций, то ряд продуктов, которые развиваются в направлении создания полноценного сетевого решения для ЦОД, скажем WAN (термин SD-WAN на графике Gartner появился и штурмует пик завышенных ожиданий), появляются.

 

Внедрение и эксплуатация Для сетевых инженеров мир SDN странен, непонятен и страшен. Странен, потому что его делали программисты, а не сетевые инженеры, при этом не доделали. Непонятен, потому что вместо задачи «сижу в CLI, настраиваю access VLAN на коммутаторе» SDN требует создания политик, описывания модели, правки файлов – и все это в удаленности от коммутатора и т. д. Точка приложения рук администратора становится сложной и непонятной абстракцией, скрытой за формальной моделью из политик, групп, списков и т. п. Страшен, потому что нет возможности понятным способом определить, почему же «оно вдруг не работает», и починить, не призывая на помощь программиста. Поэтому число энтузиастов SDN в среде эксплуатации корпоративных заказчиков, мягко говоря, невелико.

 

Открытость и вендоронезависимость SDN дает возможность использовать в сети любой коммутатор любого производителя, поддерживающий OpenFlow. На практике использование разного оборудования нежелательно, а vendor lock обеспечивается за счет SDN-контроллера. Это самый важный элемент сети, требующий поддержки, доработки, постоянного «докручивания» функционала – кто за это возьмется, если не вендор по контракту сервисной поддержки? Следует отметить, что доступные SDN-контроллеры больше напоминают конструктор, который непросто собрать, а сопровождение собственными силами потребует штата программистов. Чем-то это напоминает времена, когда программисты были на каждом предприятии и занимались автоматизацией внутренних ИТ-процессов, разработкой корпоративного ПО. (От схемы in-house разработки мучительно смещались в сторону коммерческих продуктов. Теперь она возвращается в виде концепции DevOps: «Хочешь быть эффективным – записывайся в программисты или проиграешь».)

 

Надежность Использование центрального управляющего узла делает архитектуру SDN уязвимой в случае аппаратного или программного сбоя даже при резервировании. Для подобной системы можно получить сценарий, с которым мы однажды столкнулись: если определенным образом настроить правила, можно перекрыть доступ и для управляющего трафика, изолировав оборудование от внешнего мира, в том числе собственно управляющий контроллер. Практические вопросы обеспечения и показатели надежности для SDN – предмет будущих исследований, сегодня немного желающих доверить business-critical трафик сетям, построенным на технологии SDN.

 

Все вышеперечисленное – это те самые пороги, которые нужно аккуратно обойти по дороге к SDN.

 

В поисках доброй земли

 

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

 

В настоящее время они таковы:

  • требование со стороны бизнеса – сеть должна часто и в произвольный момент изменять конфигурацию под управлением процессов и алгоритмов, обеспечивающих оркестрацию комплекса ИТ-инфраструктуры. Настолько часто, что этот процесс должен быть автоматизирован и не требовать участия человека;
  • основная инфраструктура организации – это сеть ЦОД, построенная на базе повсеместного применения технологий виртуализации;
  • задача создания SDN решается «с нуля», как правило, в комплексе с инфраструктурой нового ЦОД и без оглядки на унаследованные решения;
  • сеть решает типовой и ограниченный набор задач;
  • программное обеспечение написано или может быть оперативно адаптировано с учетом особенностей работы SDN;
  • архитектура систем построена на базе горизонтального масштабирования типовыми элементами, работоспособность системы в целом не зависит от отказа узла или сегмента за счет распределенной обработки данных;
  • организация постоянно решает задачи совершенствования средств и практик управления инфраструктура, использует DevOps, имеет в штате группу квалифицированных программистов, способных дорабатывать ПО.

 

Перечисленным требованиям в определенной степени соответствуют крупнейшие облачные сервис-провайдеры – пионеры и активные участники SDN-сообщества: Google, Facebook, Amazon и т. д. (В решениях эти компании используют не только протокол OpenFlow, но и зачастую нестандартные решения, адаптированные под свои задачи.) На российском рынке наиболее востребована технология SDN операторами публичных облаков. Стоит отметить, что компании, активно использующие SDN, необязательно применяют OpenFlow.

 

Одним из примеров реализации SDN является опыт компании Google. По данным из разрозненных источников, Google использует кастомизированные коммутаторы с поддержкой OpenFlow для серверной фабрики. Для управления коммутаторами в каждом ЦОД установлен кластер контроллеров OpenFlow, благодаря этому сеть функционирует как устройство с одной точкой управления. Между ЦОД используются классические протоколы BGP и IS-IS, реализованные в маршрутизаторах со специализированным API, разработанным Google для работы с централизованным контроллером управления трафиком. Централизованное управления трафиком реализуется специальным приложением Google Traffic Engineering Controller, которое загружает информацию о требуемых потоках в каждый контроллер и маршрутизатор. Таким образом обеспечивается управление сетевой инфраструктурой, отвечающей за сетевую связность между ЦОД.

Другой вариант – реализация BGP-based SDN, SDN-контроллеры используются для принятия решения о транспортировке пакетов и протокола BGP как средства управления трафиком. Данный подход продвигается Microsoft. Следует отметить, что в этом варианте реализации SDN об OpenFlow речь не идет.

 

Принцип малых дел

 

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

 

  • автоматизации создания и применения типовых настроек и управления конфигурациями оборудования на современном этапе развития технологий эффективно реализуется средствами типа Ansible/ Netconf /Yang. Упростите себе выполнение повседневных задач за счет DevOps;
  • используйте SDN для отдельных сетевых задач. Хороший пример – применение SDN совместно с решением для защиты от DDoS-аттак ( http://opennetsummit.org/archives/mar14/site/pdf/2014/sdn-idol/Radware-SDN-Idol-Proposal.pdf);
  • система мониторинга распределения трафика в сети на базе технологии sFlow –весьма эффективное средство, обеспечивающие наблюдение за сетью. Реализация простейших триггеров и управляющих воздействий через NETCOMF позволит в ряде случаев устранить известные проблемы в сети;
  • стандартные сетевые сервисы учета и инвентаризации сетевых ресурсов, такие как IPAM, CMDB, Performance monitoring, Radius/TACACS, повышают эффективность эксплуатации сети.

 

Конечно, в результате реализации подобных инициатив нельзя будет сказать, что вы построили «настоящий SDN как у Google». Но если решение управляет состоянием сети или ее элементом, используя показатели работы сети или приложений, значит, оно вполне соответствует этому определению.

 

Литература

 

1. The Road to SDN: An Intellectual History of Programmable Networks. Nick Feamster, Jennifer Rexfor, Ellen Zegura. https://www.cs.princeton.edu/courses/archive/fall13/cos597E/papers/sdnhistory.pdf

2. A Survey of Software-Defined Networking: Past, Present, and Future of Programmable Networks Bruno Nunes Astuto, Marc Mendon?ca, Xuan Nam Nguyen, Katia Obraczka, Thierry Turletti. https://hal.inria.fr/hal-00825087v5/document

Опубликовано: Connect, № 11, 2015

Уведомления об обновлении тем – в вашей почте

Что дают SDN-контроллеры операторам связи

Для начала отметим, что использование подходов SDN в магистральных сетях операторов связи не является чем-то особенным или революционным.

Что будет после коронавируса?

Как пандемия COVID-19 повлияла на цифровизацию бизнеса? Почему могут исчезнуть офисные здания? Каким ИТ-направлениям нужно уделять особое внимание в ближайшие годы?

Естественный отбор Дарвина, или тернистый путь развития дата-центров

Вопрос создания и эксплуатации программно-определяемых ЦОД (Software-Defined Data Center) сегодня в первую очередь заботит крупных провайдеров ИТ-услуг

Строили и построили, или Как избежать ошибок при проектировании облака

В настоящее время весьма актуальными являются вопросы, связанные с построением облачных решений

Программно-определяемый ЦОД - рецепт приготовления

Программную определяемость ЦОД можно обеспечить, используя ряд ИТ-технологий и инструментов. В этой статье мы рассмотрим некоторые из них

Тенденции развития облачных дата-центров

В последние 10–15 лет технологии дата-центров (DC) быстро развивались, рос объем их коммерческого использования.

Когда с SDN жить хорошо

Рассматриваются нюансы использования технологии SDN, виды сетевых коммутаторов с поддержкой протокола OpenFlow

Традиционный подход к сети скоро изживет себя

О состоянии и перспективах технологий SDN на российском рынке

Возможна ли ядерная война внутри отдельно взятого ЦОДа?

В 1957 г. СССР запустил первый искусственный спутник Земли, наглядно продемонстрировав всему миру свои способности в доставке ядерных боеголовок на любые расстояния.

Спасибо!
Вы подписались на обновления наших статей
Предложить
авторский материал





    Спасибо!
    Вы подписались на обновления наших статей
    Подписаться
    на тему







      Спасибо!
      Вы подписались на обновления наших статей
      Оформить
      подписку на журнал







        Спасибо!
        Вы подписались на обновления наших статей
        Оформить
        подписку на новости







          Спасибо!
          Вы подписались на обновления наших статей
          Задать вопрос
          редактору








            Оставить заявку

            Мы всегда рады ответить на любые Ваши вопросы

            * Обязательные поля для заполнения

            Спасибо!

            Благодарим за обращение. Ваша заявка принята

            Наш специалист свяжется с Вами в течение рабочего дня