Привет, Хабр! На связи Кирилл Савин, я — архитектор SDN в Облаке Рег.ру. Недавно мы с командой начали большой переезд OpenStack облака на OVN, который идет и сейчас. Это непростое путешествие, в котором мы пробовали разные решения, извлекали уроки из ошибок и продолжали двигаться вперед. Так появилась идея рассказать о рабочих кейсах и идеях, которые мы почерпнули.
Мыслей на этот счет получилось много, поэтому решил сделать серию статей об инструментах для сетевой виртуализации. В первой начнем с обзора OVN: об архитектуре, преимуществах и недостатках. Будет полезно тем, кто в контексте OpenStack работает с сетевой виртуализацией и уже «трогал» OVN. Поехали!
Навигация по тексту:
Что такое OVN
Сетевая виртуализация — ключевая составляющая современных облаков. Живые обсуждения и вопросы вызывает то, как обустроить ее работу. Традиционно в OpenStack используется связка Neutron и Open vSwitch (OVS) с набором агентов для реализации L2/L3/DHCP функциональности. При применении такого подхода всплывает ряд ограничений: сложность, высокая связанность компонентов и проблемы масштабирования.
С решением этих вопросов помогает OVN (Open Virtual Network) — система предлагает современный подход к архитектуре и повышенную отказоустойчивость. Это SDN (Software Defined Network), который использует Open vSwitch для процессинга сетевых пакетов и предоставляет полноценную сетевую виртуализацию (Overlay) на уровнях L2–L4:
виртуальные коммутаторы и маршрутизаторы (Logical Switches, Logical Routers);
NAT, ACL, балансировщики нагрузки;
встроенный DHCP-сервер;
поддержка IPv6, мультикаст, QoS.
В основе архитектуры OVN лежит несколько ключевых компонентов, каждый из которых отвечает за свой уровень управления сетью. Рассказываю, что здесь под капотом. Две базы данных — Northbound и Southbound. Они представляют собой конфигурационные хранилища с распределенной репликацией, содержащие high-level описание сети и low-level правила. Демон ovn-northd, преобразующий описание сети в правила. Локальный агент ovn-controller на гипервизоре применяет правила low-level к Open vSwitch. И CLI-инструменты: ovn-nbctl, ovn-sbctl.
Архитектура OVN с CMS Neutron
Посмотрим, что внутри. Предлагаю сравнить два подхода — начну со взаимодействия OpenStack (Neutron и Octavia) с SDN OVN (Open Virtual Network), которая обеспечивает виртуальную сетевую инфраструктуру. Выглядит это так:
Сетевой стек OVN строится по уровням, каждый из которых отвечает за свою часть логики — от общего описания сети до настройки правил на конкретных узлах. В верхней части находится слой управления облаком — Neutron/Octavia как CMS (Cloud Management System). Здесь работают два драйвера:
ML2 OVN Driver — отвечает за создание и управление сетями, подсетями и портами, передавая инструкции в OVN;
OVN Octavia Driver — занимается реализацией виртуальных балансировщиков нагрузки с использованием OVN.
В среднем блоке сосредоточен «мозг» системы — OVN Control. Здесь происходит слаженная работа трех элементов. Первым в игру вступает Northbound DB — он принимает инструкции от CMS. Например, создание виртуальной сети. Дальше демон ovn-northd интерпретирует эти инструкции и преобразует их в правила для нижнего уровня. Он записывает их в Southbound DB — базу данных, содержащую уже конкретные директивы для гипервизоров.
Нижний уровень — OVN Chassis. Он разворачивается на каждом compute- или network-узле. Сначала ovn-controller получает из Southbound DB инструкции и применяет их к локальному Open vSwitch (OVS) через Open vSwitch DB — создает правила перенаправления трафика. Отдельно работает Metadata Agent, который обеспечивает доступ виртуальных машин к метаданным инстансов. Это нужно для получения, например, ключей SSH и настроек сети при запуске.
В таком механизме каждый при деле: CMS инструктирует OVN, OVN управляет сетевыми объектами-маршрутизаторами и сетями, Open vSwitch обрабатывает трафик на хостах.
Архитектура SDN Neutron на базе Open vSwitch
В OpenStack Neutron при использовании драйвера ML2 с механизмом Open vSwitch (OVS) взаимодействие между компонентами реализовано через агентскую модель. На compute- и network-нодах работает Open vSwitch Agent, который взаимодействует с базой данных Open vSwitch DB и управляет виртуальными сетевыми интерфейсами через Open vSwitch. Metadata Agent обеспечивает доступ к метаданным инстансов, перенаправляя запросы к 169.254.169.254 через iptables из namespace маршрутизатора к локальному сокету агента.
Дальше все события и изменения передаются через RabbitMQ от ML2-плагина к агентам на нодах. Для организации сетевой связности и проброса пакетов между виртуальными машинами, маршрутизаторами и внешними сетями используется логика bridges и flows в Open vSwitch.
На стороне network-ноды также запускаются L3 Agent и DHCP Agent. L3 Agent управляет маршрутизаторами, которые создаются в отдельных Linux namespace’ах (qrouter, SNAT, FIP). DHCP Agent отвечает за предоставление IP-адресов из пулов сетей. Эти namespace взаимодействуют с виртуальными машинами через Open vSwitch — отсюда изоляция трафика, маршрутизация и сервисные функции для инстансов.
OVN vs Neutron+Open vSwitch: почему OVN побеждает
1. FullSync: Согласованность вместо полной синхронизации
Eventual Consistency — модель, когда обновления распространяются через события, а изменения применяются постепенно. Эту модель использует как Neutron + Open vSwitch, так и OVN.
Neutron + Open vSwitch использует агент neutron-openvswitch-agent, который реагирует на поступающие запросы путем обработки событий через RabbitMQ. В случае потери связи с брокером сообщений (RabbitMQ) агент может инициировать полную повторную синхронизацию (fullsync) — это приводит к удалению и повторной установке всех flows в Open vSwitch, что затрагивает как один гипервизор, так и потенциально всю инфраструктуру. Такое поведение критично при сбоях в underlay-сети и потере соединения с RabbitMQ.
OVN так же использует модель Eventual Consistency, где все изменения распространяются через транзакции в распределённых базах данных (OVN Northbound и Southbound). Локальный ovn-controller на каждом хосте синхронизирует свое состояние с базой, но в отличие от neutron-openvswitch-agent, при потере связи с OVN Southbound DB он не сбрасывает локальное состояние, а продолжает обрабатывать трафик по текущим flow'ам. Это делает OVN более устойчивым к временным сбоям control plane и потере связи с центральными компонентами.
2. Нативная балансировка нагрузки (L4 Load Balancing)
OVN поддерживает балансировку трафика на уровне Flow — это означает, что обработка осуществляется прямо в datapath Open vSwitch, без необходимости запускать отдельные виртуальные машины или контейнеры. В отличие от подхода с использованием Amphora в Octavia, где создается полноценная виртуальная машина с агентами и приложениями, OVN реализует балансировку легковесно и эффективно. Отсюда получаем:
экономию ресурсов: не требуется запуск отдельных ВМ для балансировки;
высокую производительность: логика реализуется на сетевом уровне, как OpenFlow-правила;
прозрачность для приложений: оригинальный source IP клиента сохраняется. Это важно для систем логирования, контроля доступа и приложений, зависящих от IP-идентификации.
Звучит неплохо, но всплывают и ограничения:
поддерживаются только L4-протоколы (TCP, UDP), без сложной логики на прикладном уровне;
трудности с балансировкой внешних ресурсов или сервисов вне виртуальной сети OVN;
меньше гибкости по сравнению с полноценными L7-балансировщиками (например, на базе HAProxy или Envoy).
3. Минимум агентов
В OVN нет отдельных агентов уровня L2, L3 и DHCP. Также почти отсутствует зависимость от RabbitMQ для взаимодействия между контроллером и агентами. На гипервизорах используются только два компонента: ovn-controller и ovn-metadata-agent (использует RabbitMQ).
Всё это снижает сложность, увеличивает отказоустойчивость и упрощает сопровождение.
4. Комбо из сетевых сервисов: Flow-based NAT, ACL и DHCP
Вместо привычных инструментов: iptables/nftables и dnsmasq, OVN реализует преобразование сетевых адресов (NAT) и правил файрвола через OpenFlow-правила. Протокол динамической настройки узла (DHCP) встроен в управляющий слой Control Plane.
5. Отказ от Network namespaces — новые подходы к диагностике
Одно из отличий OVN от классического Neutron с Open vSwitch — отказ от использования отдельных Network namespaces для компонентов вроде L3-агента, DHCP и Floating IP. OVN реализует маршрутизацию, NAT, DHCP и другие сетевые функции на уровне Open vSwitch с помощью Flow-правил, что дает нам ряд преимуществ:
снижение накладных расходов: ядро не тратит ресурсы на создание и обслуживание множества неймспейсов, интерфейсов и процессов, таких как
dnsmasq,keepalived,haproxy;упрощение архитектуры: меньше двоичных компонентов, меньше взаимодействия между ними, меньше точек отказа.
С отказом от Network namespaces получаем и новые подходы к диагностике OVN. В классической архитектуре для отладки можно было «зайти в роутер» или «в DHCP-сервер», выполнив ip netns exec, и воспользоваться привычными утилитами вроде ping, tcpdump, dig и т.п. В OVN же логические роутеры: NAT, DHCP и ACL — реализуются как абстракции, описанные в Northbound-базе, которые в итоге транслируются в OpenFlow-правила. Получается, нельзя просто «зайти в неймспейс роутера» — его больше нет. Это требует смены парадигмы при отладке.
Хочу отметить доступные инструменты для диагностики:
ovn-trace— симулирует прохождение пакета по логической топологии (по Northbound/Southbound правилам);ovs-appctl ofproto/trace— более низкоуровневый инструмент, симулирующий прохождение пакета в Open vSwitch;ovn-nbctl, ovn-sbctl— позволяют просматривать и анализировать правила маршрутизации, NAT, DHCP, ACL на логическом уровне.
Важно учесть: эти инструменты не заменяют живой сетевой стек — они симулируют поведение пакета. Поэтому диагностика требует большего понимания логических конструкций OVN и принципов их трансляции в OpenFlow.
Точки роста OVN: о недостатках
Казалось, при работе с OVN всё звучит отлично: есть нативная балансировка, современные подходы и удобные инструменты диагностики. Но и у этого проекта есть свои минусы:
1. Сложность отладки
Отладка требует понимания цепочки преобразований: от Northbound-абстракций до Southbound-правил и OpenFlow flows. Прямая визуализация состояния через ip netns, iptables — недоступна.
2. Чувствительность к версиям
Neutron, OVN и Open vSwitch должны быть совместимы. При использовании в OpenStack следует внимательно следить за соответствием версий ML2-плагина, OVN и базовых компонентов.
3. Молодость проекта и меньшее комьюнити
Хотя OVN развивается активно и уже используется в продакшене во многих инсталляциях, проект всё еще молод по сравнению с классическим стеком Neutron + Open vSwitch.
На этапе становления OVN можно выделить основные пойнты, повлиявшие на его развитие. Так, разработкой OVN занимается та же команда, что и Open vSwitch, — отсюда стабильное развитие базовой сетевой логики. Значительный вклад в развитие OVN внесли инженеры Red Hat, активно продвигая его в экосистемах OpenStack и Kubernetes.
Несмотря на связи с OpenStack, OVN — это независимый проект, представляющий собой полноценное SDN-решение. Он может использоваться вне OpenStack. Например, с Kubernetes (через ovn-kubernetes), Bare Metal сетями и другими системами.
Что касается официальной документации — она довольно подробная, но не всегда интуитивно понятная для новичков. Понимание архитектуры и диагностических утилит требует времени и практики. К этой теме мы скоро вернемся — в мыслях отдельная статья, где затронем эту проблему :)
По сравнению с Neutron+Open vSwitch, у OVN меньше публикаций, готовых решений и советов в сообществе, особенно в части отладки и эксплуатации.
Заключение
OVN — это логичное развитие идей Open vSwitch, предлагающее современную архитектуру сетевой виртуализации. Он убирает узкие места старого подхода, сокращает количество компонентов и повышает отказоустойчивость. Несмотря на сложность обучения и некоторые ограничения, OVN уже сегодня готов к использованию в продакшене и представляет собой мощный инструмент для построения облаков нового поколения.
Отмечу, что при переходе на OVN стоит учитывать, что он требует дополнительного погружения в архитектуру, OpenFlow-логику и внутренние механизмы. Однако его независимость от OpenStack делает его универсальным решением для построения сетей в самых разных сценариях.
Для себя я сделал выводы, что OVN стоит использовать в следующих случаях:
при развертывании нового облака с упором на масштабируемость и отказоустойчивость;
для использования легковесных L4 балансировщиков;
при необходимости унификации NAT, DHCP и ACL в рамках одной модели.
В этой статье посмотрели на OVN с теоретической точки зрения. Пора переходить к практике — в следующий раз расскажу, как мы с командой Облака Рег.ру переезжали на новую систему и с какими сложностями столкнулись. Мы глубже посмотрим на процесс миграции и поделимся техническими деталями. До связи!