Виртуализация сетей: время облаков

Сначала договоримся о терминах: облако – это пул ресурсов для облачных вычислений, к основным характеристикам которых, согласно определению Национального института стандартов и технологий США, относятся: самообслуживание по требованию; универсальный доступ по сети; возможность объединения ресурсов; эластичность; учет потребления.

Реализация этих характеристик невозможна без гибкой и автоматически настраиваемой сети, отвечающей ряду специфических требований:

Первое требование отражается в физической архитектуре сети. В отличие от трехуровневых систем, которые распространены в офисах и небольших корпоративных ЦОДах, в коммерческих ЦОДах, фокусирующихся на предоставлении облачных услуг, данные передаются преимущественно между серверами (горизонтальное направление, или «запад – восток»), а не от терминального устройства пользователя-человека к серверу и обратно (вертикальное, или «север – юг»). При этом задержки передачи сигнала критичны, что заставляет минимизировать количество промежуточных узлов сети. Это обусловило широкое применение в высокоскоростных сетях дата-центров двухуровневой архитектуры spine – leaf (технология Clos). Для обеспечения связи между отдельными модулями (pods) в машзале, между машзалами и даже ЦОДами добавляется еще один слой коммутаторов (super spine). При подключении к ним коммутаторов уровня spine используется тот же подход, что и уровнем ниже (рис. 1).

Необходимость обслуживать большое количество пользователей ограничивает применение VLAN, ведь их число в сети не может превышать 4096 и крупное облако на таком числе изолированных сетей не построишь. Требование отсутствия привязки виртуальных машин к их физическому расположению обусловливает применение работающих на уровнях L3 оверлейных сетей (GRE, MPLS VPN, VXLAN, GENEVE), имеющих возможность передавать пакеты через каналы с разными протоколами канального уровня (рис. 2).

В облаках, построенных на базе Ethernet, часто используется протокол VXLAN (Virtual Extensible LAN, виртуальная расширяемая локальная сеть). VXLAN – это туннельный протокол, который инкапсулирует кадры Ethernet уровня L2 в UDP-пакеты уровня L4, позволяя создавать виртуализированные подсети уровня L2, охватывающие сети уровня L3. Каждая сегментированная подсеть имеет уникальный сетевой идентификатор VXLAN (VNI), число которых может достигать 16 млн – вполне достаточно для облака.

Транспортный протокол TCP, на котором построен интернет, хорош при ненадежных каналах связи, но он медленнее, чем UDP. В ЦОДе каналы надежные, а скорость имеет первоочередное значение, поэтому на транспортном уровне VXLAN используется протокол UDP (рис. 3).

С помощью VXLAN можно объединить в локальную сеть виртуальные машины, находящиеся в разных сетях (рис. 4) и даже ЦОДах.

На базе физической ИТ-инфраструктуры в ЦОДе облачный провайдер разворачивает облачную платформу, включающую в себя средства виртуализации серверов, хранилищ данных и сетей, систему управления, учета потребления ресурсов и биллинга.

Основа облачной платформы – серверная виртуализация, когда на физическом сервере (ноде, хосте) устанавливается гипервизор (чаще всего ESXi или KVM), делящий ресурсы центрального процессора и память между виртуальными машинами. Каждой виртуальной машине и каждому из контейнеров, которые можно рассматривать как упрощенные виртуальные машины с общей операционной системой, назначаются свои IP- и MAC-адреса. По этим адресам развернутый на хосте виртуальный многоуровневый коммутатор (в решениях VMware – vSwitch, в OpenStack – OVS) осуществляет маршрутизацию. К «внешним портам» виртуального коммутатора подключаются физические сетевые карты хоста. 

Далее пакеты попадают на коммутатор уровня доступа, который в ЦОДе чаще всего расположен вверху стойки (Top of Rack, ToR).

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

Любой аппаратный шлюз, коммутатор или маршрутизатор можно рассматривать как компьютер, оптимизированный для выполнения специализированных задач. Сетевое устройство можно эмулировать, развернув соответствующий образ на виртуальной машине. Такой подход лежит в основе концепции виртуализации сетевых функций, предложенной Европейским институтом телекоммуникационных стандартов еще в 2012 г.

Принципы разработанного для телекома подхода с успехом применяются и в облачных средах. На стандартизированных вычислительных узлах (контейнерах, виртуальных машинах, виртуальных сетях и системах хранения) – инфраструктуре виртуализации сетевых функций (Network Functions Virtualization, NFV) – создаются виртуализированные сетевые функции (Virtualized Network Function, VNF), т.е. программные реализации сетевых функций (брандмауэры, балансировщики нагрузки, шлюзы широкополосных сетей). Вместо отдельных аппаратных решений для каждой сетевой функции используются программно настраиваемые VNF, которые могут включать несколько виртуальных машин, серверы, коммутаторы, хранилища и даже инфраструктуру облачных вычислений. Оркестрацию, масштабирование и балансировку нагрузки между отдельными VNF осуществляет система управления NFV (рис. 6).

Таким образом, у нас есть технологии построения виртуальных машин, виртуальных сетей и виртуальных сетевых устройств. Для построения облачной платформы не хватает механизма гибкого управления сетями для автоматизированной переконфигурации связей между всеми этими объектами.

На помощь приходит технология программно определяемых сетей (рис. 7, 8) – разделения уровней управления (Control Plane) и передачи данных (Data Plane).

Задача уровня Data Plane – быстрая пересылка трафика с входных интерфейсов в выходные в соответствии с таблицами маршрутизации. Здесь главное – скорость передачи, а медленно думающие «мозги» располагаются на уровне Control Plane, отвечающем за контроль состояния сети и заполнения таблицы маршрутизации. На этом уровне работает контроллер SDN, выполняющий функции управления, аналитики и оркестрации сети.

Разделение уровней передачи данных и уровня управления – основа построения сети в облаке, что можно проиллюстрировать на примере открытой облачной платформы OpenStack (рис. 9).

Для развертывания облачной платформы нужно минимум два сервера (хоста, ноды). Один – для вычислительных ресурсов (Compute Node), другой – для блока управления (Controller Node). На Controller Node в принципе может находиться и узел с сетевыми устройствами, но на практике, чтобы не терять в производительности, их размещают на отдельных серверах – Network Node.

На серверах Compute Node с помощью гипервизора создаются виртуальные машины. Для подключения виртуальной машины к физической сети на сервере запускается виртуальный роутер (vSwitch в решениях VMware, OVS – в OpenStack), подключающий на уровне L2 виртуальную машину к физической сетевой карте (которых для резервирования должно быть минимум две на каждый сервер). К этому виртуальному коммутатору подключаются (через эмулирующие порты для внутренней сети интеграционного моста br-int) и другие виртуальные машины пользователя, запущенные на этой ноде, образуя его собственную виртуальную локальную вычислительную сеть (VLAN).

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

Мост br-tun в виртуальном роутере сервера отвечает за создание туннелей между виртуальными машинами и сетевыми устройствами на Network Node и оверлейных сетей (VXLAN), связывающих виртуальные машины на разных хостах (Compute Node). Управление виртуальным роутером (OVS) осуществляется с помощью установленного на хосте агента (Neutron Open vSwitch Agent), который загружает получаемые по сети управления (еще как минимум две сетевые карты на каждый сервер) настройки и таблицы маршрутизации от расположенного на Controller Node контроллера сети (Neutron API Server).

В OpenStack на Controller Node в роли SDN-контроллера выступает Neutron API Server, поддерживающий сетевые топологии, включая развертывание и настройку сетей и подсетей, создание, обновление и удаление портов. Для оптимизации трафика в оверлейных сетях VXLAN и GRE используется специальный плагин (ML2 Plugin OVS Mecriver).

Ресурсоемкие сетевые сервисы разворачивают на выделенных нодах – сетевых узлах (Network Node). В числе таких сервисов – серверы DHCP, отвечающие за выделение IP-адреса в сети TCP/IP, и виртуальные роутеры. На Network Node располагается и мост к внешним сетям (br-ex). Дублирование сетевых функций на разных нодах позволяет легко переносить нагрузку между нодами и сохранять работоспособность виртуальной сети пользователя при отказе физических серверов.

На основе OpenStack создан ряд российских облачных платформ, в том числе VK и Selectel, и на этой же базе отечественные компании дорабатывают решения для виртуализации сети. 

«Наши продукты можно рассматривать как некий комплексный аналог VNF. Они представляют собой облачные сервисы, состоящие из множества виртуальных машин, состав которых может динамически меняться, например, при увеличении нагрузки. Все продукты – исключительно программные. В основе нашей облачной платформы лежит OpenStack, но не «ванильный», а доработанный для высокопроизводительных масштабируемых облачных вычислений. Использование open source позволило быстро запуститься, хотя параллельно мы работаем над собственным SDN-решением, переход на которое планируем осуществить в ближайшее время. Решение позволит объединить множество облачных платформ и обеспечить взаимодействие между ними», – дал комментарий нашему изданию главный архитектор сетевой инфраструктуры компании Cloud X Сергей Колесников.

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

Используя виртуализацию (например, платформу VMware NSX) для внешних сетей и дата-центров, можно создать единый центр управления сетями в распределенной виртуальной инфраструктуре – виртуальную облачную сеть, связывающую дата-центры головных компаний, отделений, edge-ЦОДы, публичные и частные облака и даже устройства интернета вещей (рис. 11).

Как и виртуальные машины, сети можно создавать и уничтожать по требованию, например, кратковременно предоставляя доступ к ЦОДу с архивом или для переноса нагрузки или расширения канала до резервного ЦОДа в случае аварии на основном. Виртуализация сетевых функций позволяет гибко управлять трафиком и обеспечивать оптимальную маршрутизацию, предоставлять сетевые соединения и канал требуемой пропускной способности по запросу. Появляется возможность предоставления сети как облачного сервиса (Network as a Service, NaaS). 

NaaS включает в себя предоставление из облака сервисов как локальных сетей (Lan as a Service, LANaaS), в том числе управление сетями и обеспечение их безопасности, так и внешних сетей (WAN as a Service, WANaaS), в том числе сервисы мультиплексирования WAN (MPLS) и SD-WAN. 

Все эти услуги набирают популярность в мире. По оценкам Market.us, мировой рынок NaaS вырастет c $14,6 млрд в 2023 г. до $115,5 млрд в 2032 г. 

Российский рынок решений NaaS отстает от мирового. По оценкам экспертов, отставание составляет два-три года. На карте российского ПО виртуализации уже появились вендоры, предлагающие решения SD-WAN, и их количество увеличивается. Правда, в реестре отечественного ПО пока нет решений российских вендоров SDN, зато много облачных платформ, использующих open source-решения для виртуализации сети, в основном на основе OVS.

Виртуализация сетей и их использование по сервисной модели привлекает мало внимания, но это перспективный рынок. Развитие отечественных ИТ в целом повторяет развитие мировых, поэтому можно полагать, что объем услуг NaaS в России будет расти.  

Заметили неточность или опечатку в тексте? Выделите её мышкой и нажмите: Ctrl + Enter. Спасибо!