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

• «взросление» средств виртуализации, развитие облачных услуг и повышение конкуренции между поставщиками. Конфигурацию сети теперь приходится менять часто, быстро, дешево и в соответствии с потребностями приложений. Администратор сети этого не умеет, и предпочтение отдается программному алгоритму. Кто сделал это своевременно – заработал больше. Решения с использованием программно-управляемых 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