Созданные почти четверть века назад виртуальные локальные сети VLAN были для своего времени неплохим способом управления узлами сети. Но в условиях массового перехода на облачные технологии и повсеместным внедрением виртуальных машин возможностей традиционных VLAN для современных ЦОД стало явно недостаточно. Причем самыми болезненными вопросами стало ограничение доменов второго уровня на четырех тысячах VLAN при невозможности переноса виртуальных машин через границы L2.
В рамках стандартной модели сети решение было сравнительно очевидным: сеть надо тоже виртуализировать, создавая виртуальные оверлейные сети поверх существующих.
И как это делается?
На текущий момент существует три распространенных протокола построения оверлейных сетей: VXLAN, NVGRE и STT. Эти три протокола весьма схожи в общем принципе: все они подразумевают существование виртуального коммутатора на базе гипервизора и терминирование туннелей в виртуальных узлах. В итоге на базе этих технологией становится возможным построение логических L2-сетей в рамках уже существующих L3-сетей. Различие между протоколами состоит, в основном, в методах инкапсуляции трафика. Ну и еще в том, что VXLAN продвигается VMware, за NVGRE стоит Microsoft, а STT поддерживается Nicira. Мы не будем говорить, о том, какой протокол лучше, а какой хуже, заметим лишь, что на текущий момент явно лучшей поддержкой со стороны производителей сетевого оборудования обладают стандарты VXLAN и NVGRE, довольно часто попадающие в строчки о поддерживаемых стандартах парой.
Виртуальные сети
В дальнейшем мы будем говорить о VXLAN, но большая часть применима и к остальным стандартам в силу их схожести.
Начнем с главного — с чисел, тем более, что именно количественные ограничения обычных VLAN послужили поводов для создания им замены. В этом плане новая технология значительно расширяет возможности сетей. Для идентификации виртуальной машины в VXLAN-сетях используется два параметра: MAC-адрес машины и VNI — VXLAN Network Identifier. Последний имеет 24-битный формат, что повышает количество возможных виртуальных сетей до 16 миллионов, так что на ближайшее время вопрос количества возможных виртуальных сетей вроде как решен.
На что похожи виртуальные сети?
В рамках концепции OpenStack вся система виртуализации выглядит следующим образом:
Концепция Open Stack
Здесь компонент Nova, являющийся контроллером вычислительных ресурсов, как только дело заходит о создании сети, передает управление на плагин Neutron, который, в свою очередь, уже и занимается созданием виртуальных свитчей, организацией пространства имен и дальнейшим управлением сетью.
Первоначально виртуальный свитч на гипервизоре на самом деле не являлся коммутатором или вообще сетевым устройством. Корректнее всего его можно описать как программно управляемую контрольную панель, которая позволяет подключать сетевые порты виртуальных серверов (vNIC) к реальным физическим портам. Но ведь мы можем соединить их виртуальными туннелями на основе VXLAN и получить… да, удобную управляемую виртуальную сетевую структуру, обеспечивающую взаимодействие виртуальных же серверов.
В итоге выглядит все это примерно так:
Базовая структура
Организация туннелей
за предоставленные картинки благодарим неплохую английскую статью
В целом, все выглядит весьма эстетично, а если к этому добавить еще и какое-нибудь облачное хранение данных, то можно не только перенасытить свою речь словом «виртуальный», но и сказать, что датацентр соответствует современной концепции Software Defined Data Center (SDDC).
Осталось определиться с тем, кто и как будет организовывать сеть из виртуальных туннелей.
Одним из вариантов построения такой структуры является решение VMware NSX, представленное осенью 2013 года.
VMware NSX
Эта платформа включает в себя следующие компоненты:
- Controller Cluster — система, состоящая из виртуальных или физических машин (как минимум трех), обеспечивающая развертывание виртуальных сетей. Эти машины работают в кластере высокой доступности и через API принимают команды от структур VMware vCloud или OpenStack. Кластер осуществляет управление объектами vSwitches и Gateways, котороые и отвечаают за реализацию функций виртуальных сетей. Именно этот компонент определяет топологию сети, анализирует поток трафика и принимает решения о конфигурации сетевых компонентов.
- Hypervisor vSwitches (NSX Virtual Switches) — те самые виртуальные коммутаторы, о которых шла речь выше. Они отвечают за работу с трафиком виртуальных машин, обеспечение туннелей VXLAN и получают команды от Controller Cluster.
- Gateways — компоненты, предназначенные для сопряжения виртуальных и физических сетей. Они отвечают за такие сервисы, как IP routing, MPLS, NAT, Firewall, VPN, Load Balancing и многое другое.
- NSX Manager — это централизованное средство управления виртуальными сетями датацентра (с веб-консолью), которое взаимодействует с Controller Cluster.
Помимо вышеперечисленного, в систему на уровнях L4-L7 могут быть интегрированы виртуальные модули партнеров.
Сама компания VMware в пользу своего решения выдвигает следующие аргументы:
- обеспечивает автоматизацию сетей для SDDC;
- воспроизводит сетевое обслуживание на L2/L3-уровнях, работу L4-L7-сервисов;
- не требуется вносить какие-либо изменения в приложения;
- обеспечивается масштабируемая и распределенная маршрутизация с разделением сетевых ресурсов;
- позволяет безболезненно встроить обеспечение сетевой безопасности приложений.
Стоит добавить, что в качестве серверных гипервайзоров в инфраструктуре NSX нет каких-либо жестких ограничений: могут использоваться как решения VMware vSphere, так и KVM или Xen.
Конечно, вся эта многоуровневая красота вызывает очевидный вопрос: насколько велико пенальти по производительности, вызываемое инкапсуляцией трафика. И тут все упирается в 2 пункта: поддержку VXLAN на уровне коммутационной матрицы и качество программной реализации интеграции виртуальной сети (в случае NSX — это работа службы NSXd и протокола OVSDB).
Наши постоянные читатели наверняка догадались к чему мы клоним: все верно, открытые сетевые операционные системы типа Cumulus на коммутаторах без ОС имеют здесь существенные бонусы за счет выбора хардварной платформы (матрицы Broadcom) и гибкости на уровне построения программной части.
Интеграция NSX и Cumulus
Такая схема организации взаимодействия и совместная разработка программной части в плотном сотрудничестве с VMware позволило Cumulus создать виртуальное решение, работающее с минимальным пенальти:
Пенальти? Где?!
Вторым явным достоинством становятся широкие возможности по контролю. Судите сами:
Возможности по контролю
Мы не будем говорить, что объединение BMS, Cumulus и VMware NSX является идеальным вариантом для всех случаев, но, на наш взгляд, оно дает во многом уникальное, весьма востребованное сочетание следующих особенностей:
- программируемая открытая архитектура, обеспечивающая отличную экосистему;
- широкие возможности по автоматизации управления как виртуальной, так и физической сети;
- единая точка управления как виртуальной, так и физической инфраструктурой;
- неблокируемая базовая сетевая структура с высокоскоростными VXLAN шлюзами
Ну а в список достоинств в итоге можно записать следующее:
- удобство — удобная работа в крупномасштабных ЦОД за счет мощной автоматизации;
- производительность и масштабирование — высокая производительность сетей, wire-rate подключение виртуальных сетей, масштабируемая аренда;
- снижение Opex и Capex — уменьшение операционных затрат за счет автоматизации и быстрого резервирования, уменьшение капитальных расходов за счет экономии на оборудовании.
Автор: ETegro_Technologies
