Виртуализация сетей ЦОДов

Технологии программируемых сетей сравнительно молоды, а виртуализация сети может быть реализована несколькими способами. Многие крупные компании имеют значительную инсталлированную базу сетевого оборудования, не поддерживающего OpenFlow. Чтобы такие заказчики могли воспользоваться преимуществами сетевой виртуализации / SDN, целый ряд вендоров предлагают решения для развертывания наложенных сетей. Такой подход предполагает организацию логической сети поверх имеющейся физической инфраструктуры. Перенося интеллект на границу сети, наложенные сети позволяют получить функциональность программно определяемых сетей без замены физического сетевого оборудования (хотя, ввиду возрастающих требований к пропускной способности и изменения картины трафика, такая замена желательна или даже необходима).

Как утверждает Кевин Дейерлинг, вице-президент по маркетингу компании Mellanox, первоначальный замысел по реализации принципиально новой централизованно управляемой сетевой архитектуры в рамках развертывания программно определяемых сетей удалось воплотить лишь частично. По его мнению, тотального перехода на OpenFlow ожидать не стоит. За исключением разве что самых крупных облачных провайдеров все остальные внедряют SDN в урезанном виде, при этом широкое применение получают наложенные сети на основе технологий VXLAN, NVGRE и GENEVE (см. подробнее его статью «Семь прогнозов на 2017 год» в предыдущем номере «Журнала сетевых решений/LAN»).

Впрочем, как заявил в своем выступлении на форуме RUS.NET, хотя и несколько по другому поводу, Александр Кренев, руководитель направления сетевой виртуализации в московском офисе VMware,

«пока никто не понимает, как дальше будут развиваться технологии SDN».

Согласно опросу SDXcentral, закрытые проприетарные решения пока преобладают над открытыми. Это связано с тем, что качественное работающее решение, которое можно внедрить на производстве, сложно собрать из компонентов с открытым исходным кодом, к тому же кто-то должен его поддерживать. Тем не менее открытые компоненты получают все более широкое распространение, а решения на базе открытого исходного кода и открытых стандартов развиваются достаточно интенсивно. Соответственно, многие производители, будь то поставщик сетевого оборудования или разработчик программного обеспечения, развивают параллельно два направления — собственные закрытые разработки и поддержку открытого кода.

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

В данной статье представлен взгляд на сетевую виртуализацию и SDN компаний VMware и Mellanox — по материалам докладов Александра Кренева, руководителя направления сетевой виртуализации, VMware Russia & CIS, и Александра Петровского, системного инженера Mellanox, на форуме RUS.NET 2016.

ЧТО ТАКОЕ СЕТЕВАЯ ВИРТУАЛИЗАЦИЯ

Дополнительную неразбериху вносят множество терминов и акронимов. До сих пор сохраняется путаница в понятиях: что такое сетевая виртуализация, SDN и NFV — одно и то же ли это? SDN означает OpenFlow или его поддержка необязательна? SDN представляет собой полностью программную реализацию? Если да, то как она связана с коммутаторами (физическим оборудованием)? Александр Кренев проводит следующее различие между SDN и сетевой виртуализацией.

Программно определяемые сети — это подход к архитектуре, который заключается в разделении плоскостей данных, контроля и управления (data, control&management planes). Сетевая же виртуализация представляет собой продукт, который на этой архитектуре базируется.

Причем функции плоскости данных воспроизводятся полностью на программном уровне, а не на уровне коммутаторов. Последние упрощаются и становятся просто физическим транспортом, тогда как вся функциональность и логика реализуются программно.

Исторически для сетевой виртуализации основным драйвером развития было создание облачной инфраструктуры по запросу. В ЦОДе главенствуют прикладные системы, а не инфраструктура. Соответственно, требования к инфраструктуре зависят от приложений, а не наоборот. Приложения должны быть защищенными, обеспечивая целостность и сохранность данных, быстро развертываться и заменяться, если это требуется. И быть доступными: если произошел сбой, то восстановление должно происходить быстро, желательно автоматически. Эти требования — безопасность, быстрое развертывание и высокая доступность — остаются прежними (см. рис. 1).

Рис. 1. Преимущества сетевой виртуализации

Исходя из опыта использования заказчиками платформы NSX от VMware, Александр Кренев выделяет три основных сценария применения для сетевой виртуализации: безопасность, автоматизация и повышение доступности.

«Открытость и программируемость — хорошо, но это чисто академический, технический подход.

Любое внедрение любой технологии в коммерческой организации должно быть подкреплено бизнес-требованиями, как правило коммерчески адекватными», — говорит он. Так, например, обеспечение непрерывности для виртуализированных сред является реальной практической задачей. Сетевая виртуализация позволяет перемещать между ЦОДами и резервировать вместе с приложением не только данные, но и все сетевые настройки.

Однако если задачи остаются неизменными, то условия для их решения уже поменялись. Для все большего числа приложений внешний доступ приходится обеспечивать отовсюду, что ведет к изменению шаблонов взаимодействия с приложениями. Архитектура последних тоже претерпевает изменения в результате распространения таких технологий, как контейнерная виртуализация. Наконец, трансформируется и инфраструктура, поскольку классическая архитектура сети не отвечает архитектуре приложений. Как результат, все производители сетевого оборудования предлагают те или иные варианты для реализации L3-фабрик. А классическое растягивание сетей L2 уступает место наложенным сетям.

Все это отражается в решениях для виртуализации сети. Раньше, когда сетевая виртуализация только появилась, высокий уровень доступности — на уровне пяти девяток — был необходим лишь для плоскости данных. Для плоскости управления требования были ниже. Сейчас ситуация изменилась, поскольку все большую роль в компаниях, например в Сбербанке, играют разработчики.

Даже плоскость управления должна быть резервируемой, распределенной, очень быстро реагирующей на изменения.

Центр исследований VMware разработал технологию улучшения распределенности для плоскости управления Corfu DB (проект с открытым исходным кодом). Это распределенный журнал транзакций, который позволяет реализовать плоскость управления по распределенной зарезервированной архитектуре, то есть в режиме «активный-активный».

Следующее направление развития VMware NSX — поддержка DPDK. Нагрузки становятся все больше, операторы связи хотят перенести сетевые функции на стандартные серверы, поэтому требования к производительности виртуальных коммутаторов, как и к задержкам, стали расти. Intel разработала набор библиотек и драйверов для быстрой обработки пакетов, который получил название «Комплект разработчика для плоскости данных» (Data Plane Developer Kit, DPDK). Как заявил Александр Кренев, VMware планирует применять эту технологию для подключения к физической сети: «Только там это и нужно, потому что в виртуальной среде у нас все распределенное — мы достигаем производительности методом распределения всей нагрузки. Соответственно, у нас появятся граничный кластер в NSX в режиме «активный-активный» и средства быстрого оповещения физической сети о сбоях».

ТРИ ВАРИАНТА РЕАЛИЗАЦИИ SDN

Предлагаемый VMware способ реализации SDN посредством наложенных сетей является, естественно, не единственно возможным. В своем докладе Александр Петровский рассмотрел три варианта реализации программно определяемых сетей в ЦОДе.

Во-первых, это реализация SDN в виде программируемой фабрики, что предполагает низкоуровневое программирование коммутаторов фабрики с использованием открытого протокола OpenFlow. Логика сети централизованно выносится в контроллер, который и программирует сеть в соответствии с заданной политикой. Этот «классический» подход отличается наибольшей гибкостью и универсальностью, но одновременно является наиболее затратным, так как предполагает замену унаследованного оборудования во всей сети — фактически сеть придется построить заново, поскольку на всем сетевом оборудовании должны поддерживаться определенные API. Один из примеров открытой SDN — это, конечно, OpenFlow. При использовании OpenFlow все коммутаторы должны его поддерживать. Целый ряд вендоров, в частности BigSwitch, реализуют подобный подход, но у некоторых он особый — например, у Cisco в Application Centric Infrastructure.

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

Как отмечает Александр Петровский, основной областью применения данного подхода являются центры обработки данных. SD-WAN — еще один пример реализации подобного подхода в сетях WAN, хотя одно другого не исключает. Данная модель (overlay) нашла воплощение в решениях VMware NSX, Nuage Networks (теперь часть Nokia), VSP, PLUMGrid ONS, OpenContrail и Midokura MidoNet. Наложенные сети реализуются полностью программно на сервере (на базе виртуальных коммутаторов) или выносятся в сетевую фабрику (на коммутаторы в стойке, ToR) (см. подробнее раздел «Ускорение наложенной сети»).

И наконец, SDN через API. «Не самый очевидный вариант. Раньше его никто не называл SDN, — говорит Александр Петровский, — но сейчас в какой-то степени можно отнести к DevOps, который используется как средство автоматизации и унификации управления». Идея состоит в использовании единой модели данных для описания конфигурации, а также стандартных интерфейсов управления, имеющихся у сетевых устройств, — это классический SNMP, Netconf, XML, REST и др. Различные программируемые API позволяют вместо управления через Web-интерфейс и через СLI использовать автоматизированные сценарии. Модель предполагает наименьшие затраты. Однако функциональность ограничивается возможностями CLI на конкретном устройстве. Тем не менее она часто используется как дополнение к первой и второй моделям, тем более что на рынке есть целый ряд средств автоматизации, например Chef, Puppet и Ansible.

OPEN ETHERNET КАК ДОПОЛНЕНИЕ К SDN

Если раньше сетевые устройства представляли собой некий «черный ящик» со своей аппаратной архитектурой и программным обеспечением, то сейчас этот подход постепенно уходит в прошлое.

Инициатива Open Ethernet предполагает использовать сетевое устройство в качестве открытой платформы для запуска ОС и приложений.

«Покупая сервер от HPE, вы же не будете устанавливать на него только определенную ОС? — замечает Александр Петровский. — Вы можете поставить Windows, Linux — все что угодно. То же возможно и в случае Open Ethernet: приобретя коммутатор, вы можете установить любую ОС с необходимым набором приложений для поддержки выбранного варианта реализации программируемой сети».

Использование только Open Ethernet не приносит столь ощутимых преимуществ, как в связке с SDN. Дополняя SDN, он дает существенное увеличение свободы действий: пользователь больше не привязан к конкретному производителю оборудования и программного обеспечения. Как объясняет Александр Петровский, это достигается целым набором средств. Прежде всего это использование открытой аппаратной платформы. Микросхема ASIC — сердце коммутатора, она должна поддерживать открытые интерфейсы, обеспечивающие управление коммутатором. Иначе говоря, интерфейсы должны быть открыты, общедоступны, описаны и документированы.

Примером такого интерфейса может служить интерфейс абстракции коммутатора (Switch Abstraction Interface, SAI). Это набор библиотек, которые позволяют создать мультивендорную абстракцию для управления различными чипами: с помощью одного и того же кода можно управлять чипом Mellanox, чипом Marvell и др. Между тем под эгидой Linux Foundation, внутри самого сообщества Linux, ведется разработка Switchdev. Эта прослойка представляет собой полностью открытый драйвер внутри ядра Linux для коммутаторов. Благодаря поддержке Switchdev, на коммутаторы Mellanox, как и на обычный сервер, можно установить операционную систему Linux (см. рис. 2). Главное, чтобы версия ядра соответствовала.

Рис. 2. Открытый драйвер Switchdev позволяет использовать стандартные инструменты Linux для реализации различных сетевых функций

По своей архитектуре коммутатор является упрощенным сервером, состоящим из процессора, памяти, диска, у которого на PCI-шине имеется еще и ASIC. Если для ASIC есть драйвер, которым мы можем управлять, то для установки любой ОС достаточно воспользоваться открытым загрузчиком. Он был создан в рамках проекта Open Compute и называется ONIE. По сути, это аналог BIOS/UEFI в сервере на коммутаторе. С его помощью можно установить любую ОС, после чего использовать любые приложения. Таким образом, наблюдается встречная тенденция: серверы превращаются в (виртуальные) коммутаторы, а коммутаторы — в серверы.

УСКОРЕНИЕ НАЛОЖЕННОЙ СЕТИ

Как следует из названия, логическая сеть организуется посредством туннелей между конечными узлами, а туннели «накладываются» на имеющуюся физическую сеть. Наиболее известными протоколами туннелирования являются Virtual eXtensible LAN (VXLAN), Network Virtualization using GRE (NVGRE) и Generic Network Virtualization Encapsulation (GENEVE). В случае VXLAN конечные точки туннелей называются VXLAN Tunnel End Points (VTEP). Контроллер наложенной сети SDN взаимодействует с VTEP, которые часто (но не всегда) представляют собой виртуальные коммутаторы и маршрутизаторы на серверах.

На практике наложенная сеть может быть реализована двумя способами. Первый — исключительно программный, когда сами туннели и логическая сеть организуются виртуальными коммутаторами, функционирующими на серверном гипервизоре. Этот подход использует VMware c NSX, Nuage, OpenStack. Как уже отмечалось, замены сетевого оборудования не требуется. Потенциальный недостаток такого подхода очевиден — использование процессорного времени для инкапсуляции трафика и его разбора, если не применять специальных мер для разгрузки.

Второй вариант — аппаратный VTEP на коммутаторах в стойке (ToR), когда туннели организуются не гипервизорами, а коммутаторами. Для этого коммутатор ToR должен получать информацию о виртуальных машинах, осуществлять преобразование MAC-адресов для ВМ, поддерживать большие таблицы для переадресации. Проблема такого решения в том, что высокая производительность достигается за счет потерь в гибкости: чип коммутатора не может поддерживать всю ту функциональность, которую можно реализовать программно.

Однако снижение производительности в первом варианте можно компенсировать, например, путем установки в сервере сетевых адаптеров с поддержкой разгрузки VXLAN (offload) и других протоколов инкапсуляции (см. рис. 3). В результате производительность программной реализации наложенной сети приближается к аппаратной, а гибкость и функциональность повышаются. Как показало тестирование, проведенное в компании Mellanox, при включении инкапсуляции VXLAN реальная пропускная способность канала между двумя серверами с интерфейсом 40 Гбит/с падает с 35–37 до 5 Гбит/с — почти на порядок. Это связано с тем, что большую часть времени процессор тратит на перерасчет контрольных сумм и частично на инкапсуляцию.

Рис. 3. Реализация наложенной сети на базе решений Mellanox Spectrum

Применение VXLAN offload — технологии, благодаря которой вычисление контрольных сумм для инкапсулированных пакетов осуществляет не процессор, а сетевая карта, — позволяет увеличить производительность до 36 Гбит/с.

Причем, как отмечает Александр Петровский, чем больше ВМ запущено, тем меньше разница между пропускной способностью без инкапсуляции VXLAN и с использованием VXLAN offload. Иначе говоря, один лишь перерасчет контрольных сумм на сетевой карте позволяет достичь производительности наложенной сети, близкой к номинальной скорости интерфейса (wire-speed), при этом еще освобождаются ресурсы процессора — их можно отдать имеющимся ВМ или даже запустить больше ВМ на том же хосте.

Чип современной сетевой карты представляет собой мини-коммутатор: он умеет собирать информацию о MAC-адресах (MAC learning), инкапсулировать различные пакеты, осуществлять обработку потоков. Помимо простейшего расчета контрольных сумм, сетевые карты Mellanox ConnectX-4 обеспечивают выгрузку всей плоскости данных виртуального коммутатора в чип карты. Например, в случае Open Virtual Switch (OVS) все правила могут быть загружены на сетевую карту, в результате на обработку сложных сетевых правил процессорное время вообще не тратится. Эту технологию можно использовать для ускорения критически значимых ВМ, очень активно взаимодействующих с сетью. Стандартный пример — виртуальные сетевые функции NFV, которые действительно пропускают через себя большой объем трафика. Они могут быть значительно ускорены с помощью этой платформы.

Терминирование туннелей VXLAN на коммутаторах ToR чаще всего применяется в рамках гибридной схемы, когда большинство виртуальных хостов строят между собой туннели напрямую, программно, с помощью механизмов акселерации. Однако в сети есть невиртуализированные хосты, например базы данных и различные платформы на UNIX. Чтобы их включить в наложенную сеть, можно использовать аппаратный шлюз на базе коммутатора и организовать на нем либо L2 VTEP, либо L3 VTEP.

СЕТЕВАЯ ФАБРИКА ДЛЯ SDN

Прежде чем запускать все необходимые сервисы, следует правильно выстроить инфраструктуру. Если сеть построена неэффективно (теряет пакеты, на портах происходят ошибки и т. д.), SDN работать не будет. Ключевая идея — объединение классических универсальных устройств в двухуровневую топологию Leaf-Spine, когда каждый коммутатор первого уровня (leaf) связан с каждым коммутатором второго уровня (spine). Эта топология была предложена Чарльзом Клозом в 50-х годах прошлого века для построения масштабируемых телефонных сетей.

Коммутаторы доступа (leaf, или «лист») обеспечивают подключение конечных узлов: серверов, систем хранения, различных сетевых устройств, таких как коммутаторы, балансировщики нагрузки, межсетевые устройства и т. д. Коммутаторы ядра (spine, или «ствол») осуществляют межсоединение листьев: каждый лист соединен со всеми другими стволами. Между листьями, как и между стволами, соединений нет. Это позволяет организовать множество избыточных путей между листьями. Отказ одного из коммутаторов приводит лишь к незначительному снижению производительности сетевой фабрики.

Многие вендоры предлагают проприетарные решения для реализации топологии Клоза. Однако, как подчеркивает Александр Петровский, актуальны стандартные варианты реализации ECMP-фабрики. Ввиду доступности нескольких маршрутов, необходимо распределять трафик между ними, для чего используется протокол равноудаленных маршрутов (Equal Cost MuptiPathing, ECMP). Для поддержки наложенной сети достаточно соединить все коммутаторы по топологии Клоза и настроить на них маршрутизацию в соответствии со стандартными протоколами OSPF/BGP. (В принципе, поверх той же физической топологии можно реализовать и программируемую сеть на базе протокола OpenFlow.)

В качестве примера Александр Петровский приводит схему реальной сети на базе коммутаторов Spectrum — практически такая же схема неоднократно использовалась в проектах Mellanox. Она позволяет построить сеть, содержащую свыше 5 тыс. портов по 25 Гбит/с (или 10 Гбит/с) с минимальной передподпиской 2,5 к 1 для подключения 64 стоек на 2,5 тыс. серверов (см. рис. 4). При высокоплотном размещении серверов — примерно 40 серверов на одну стойку — в одну стойку устанавливается по два коммутатора SN2100 половинчатого исполнения. Серверы подключаются к каждому из них через два порта по 25 Гбит/с. При этом каждый SN2100 имеет 4 порта для каскадирования по 100 Гбит/с, что, таким образом, дает переподписку 2,5 к 1.

Рис. 4. Схема распределенного ядра для подключения 64 стоек

Для соединения стоек строится распределенное ядро на 16 spine-коммутаторов и 32 leaf-коммутатора, в качестве которых используются устройства серии 2700, соединенные в неблокируемую фабрику топологии Клоза. Одна половина портов на каждом leaf-коммутаторе служит для подключения коммутаторов в стойке, другая — для подключения к spine-коммутаторам.

Такой виртуальный модульный коммутатор (Virtual Modular Switch, VMS) позволяет обеспечить подключение 512 портов по 100 Гбит/с.

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

ЧТОБЫ СЛОЖНОЕ СТАЛО ПРОЩЕ

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

Дмитрий Ганьжа, главный редактор «Журнала сетевых решений/LAN»