Сетевая архитектура KeyStack¶

Обзор сетевой архитектуры¶

В референсной архитектуре KeyStack предлагается использовать OpenvSwitch (OVS) или Open Virtual network (OVN) для управления сетевой инфраструктурой в OpenStack-облаке. OVS работает по классической схеме с использованием L2/L3/DHCP агентов на каждом узле и взаимодействием через RabbitMQ. OVN является «надстройкой» над OVS и управляет сетью через собственную распределённую базу данных без использования отдельных агентов, что сокращает нагрузку на RabbitMQ и повышает масштабируемость.

	OVS (ML2/OVS)	OVN (OVS+OVN)
Плюсы	Зрелое, проверенное решение Большое сообщество и документация Хорошо поддерживается в OpenStack	Проще архитектура Отсутствует влияние на RabbitMQ Лучшая масштабируемость Более современный подход к SDN
Минусы	Зависимость от агентов (L2/L3/DHCP) Высокая нагрузка на RabbitMQ Ограничения по масштабированию Более сложная архитектура	Менее зрелое решение Меньше практического опыта у операторов Возможны недоработки в граничных сценариях

Фильтрация трафика на портах виртуальных машин¶

Фильтрация трафика на портах виртуальных машин в KeyStack обеспечивается группами безопасности. Способ применения их правил зависит от выбранного сетевого механизма и его настроек.

ML2/OVS — драйвер iptables_hybrid¶

В стандартной конфигурации OVS правила фильтрации реализуются через iptables-nft на Linux bridge (qbr), который создаётся для каждого порта виртуальной машины. Между узлами трафик передаётся через VXLAN-туннель. Процесс настройки приведён в разделе Настройка ML2/OVS.

Фильтрация трафика на портах ВМ — ML2/OVS (iptables_hybrid)¶

ML2/OVS — драйвер openvswitch¶

При использовании драйвера openvswitch правила фильтрации реализуются внутри OVS-коммутатора br-int. Архитектура сети при этом остаётся прежней. Подробнее о переключении драйвера см. в разделе Настройка ML2/OVS.

Фильтрация трафика на портах ВМ — ML2/OVS (openvswitch)¶

ML2/OVN¶

В OVN правила групп безопасности реализуются через списки контроля доступа (ACL), которые локальный контроллер OVN на каждом Compute-узле применяет к трафику. Туннелирование между узлами выполняется через Geneve. Процесс настройки приведён в разделе Настройка ML2/OVN.

Маршрутизация трафика виртуальной инфраструктуры во внешние сети¶

Для примера на схеме отображены два варианта маршрутизации:

Трафик VM1, VM6 маршрутизируется через Gateway-узлы при помощи SNAT.
На виртуальные машины VM3, VM4, VM5 назначен Floating IP (назначаемый внешний адрес), и их трафик проходит напрямую во внешнюю сеть без Gateway-узлов.

Схема маршрутизации трафика в KeyStack — Маршрутизация трафика виртуальной инфраструктуры¶

Дополнительные сетевые функции KeyStack¶

Фильтрация трафика¶

Фильтрация сетевого трафика между узлами и сервисами в KeyStack работает на основе nftables — современного инструмента для управления сетевым трафиком в Linux. Единая архитектура и гибкая модель построения правил nftables обеспечивают эффективный контроль и ограничение трафика в соответствии с политиками безопасности и требованиями инфраструктуры.

Примечание

Фильтрация трафика на Compute-узле выполняется аналогично за исключением отсутствия правил для External VIP и Internal VIP.

Официальная страница проекта: https://wiki.nftables.org.

Более подробно об управлении правилами фильтрации для узлов и сервисов описано в разделе Настройка механизма фильтрации трафика.

Сервис LBaaS¶

В KeyStack реализован сервис LBaaS. Сервис LBaaS построен на основе OpenStack Octavia и предоставляет сетевые балансировщики как сервис.

Octavia позволяет создавать балансировщики в виртуальных машинах, контейнерах или на baremetal, а также поддерживает следующие типы балансировки:

HTTP-балансировка
HTTP-балансировка с health-монитором
Session-persistent HTTP-балансировка
TCP-балансировка
UDP-балансировка
QoS ruled-балансировка
Балансировка с ACL по IP
Non-terminated HTTPS-балансировка
TLS-terminated HTTPS-балансировка
TLS-terminated HTTPS-балансировка с SNI
TLS-terminated HTTPS-балансировка с аутентификацией
HTTP/2-балансировка с ALPN TLS-расширением
Другие режимы балансировки