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

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

Лука 8:5–8

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

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

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

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

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

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

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

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

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

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

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

Стоимость оборудования для SDN

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

Область применения

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

Внедрение и эксплуатация

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

Открытость и вендоронезависимость

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

Надежность

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

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

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

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

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

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

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

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

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

• автоматизация создания и применения типовых настроек и управления конфигурациями оборудования на современном этапе развития технологий эффективно реализуется средствами типа Ansible/Netconf/Yang. Упростите себе выполнение повседневных задач за счет DevOps;
• используйте SDN для отдельных сетевых задач. Хороший пример – применение SDN совместно с решением для защиты от DDoS-аттак[6];
• система мониторинга распределения трафика в сети на базе технологии 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

[1] Кстати, в отличие от SDN у доминирующих на сетевом рынке решений нет обобщенного названия. Их часто называют традиционными, что наводит на мысли о том, к какой же категории относится SDN.

[2] Количество поддерживаемых flow – ключевая характеристика масштабируемости SDN-коммутатора, указывающая на число уникальных потоков, которыми он может одновременно управлять.

[3] Термин «SD-WAN» на графике Gartner появился и штурмует пик завышенных ожиданий.

[4] От схемы in-house разработки мучительно смещались в сторону коммерческих продуктов. Теперь она возвращается в виде концепции DevOps: «Хочешь быть эффективным – записывайся в программисты или проиграешь».

[5] Эти компании используют не только протокол OpenFlow, но и зачастую нестандартные решения, адаптированные под свои задачи.

[6] http://opennetsummit.org/archives/mar14/site/pdf/2014/sdn-idol/Radware-SDN-Idol-Proposal.pdf