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

Локальное взаимодействие ВМ на одном хосте¶

Взаимодействие виртуальных машин (ВМ) по сети внутри одного хоста KVM с использованием Open vSwitch (OvS) происходит через программный коммутатор (bridge), который обеспечивает высокую производительность и гибкость по сравнению с традиционными Linux-бриджами.

Основные компоненты:

• OvS Bridge (ovs-br0) — виртуальный коммутатор, работающий в ядре, к которому подключаются виртуальные машины
• TAP-интерфейсы (vnetX) — KVM/QEMU создает TAP-устройство для каждой сетевой карты ВМ. Эти устройства подключаются к портам OvS-бриджа
• Порты OvS — интерфейсы на коммутаторе. При запуске ВМ libvirt автоматически добавляет её TAP-интерфейс в OvS-bridge

Механика взаимодействия на одном хосте:

1. Пакет покидает ВМ и выходит из виртуальной сетевой карты ВМ (например, eth0), проходя через TAP-интерфейс (vnet0) хост-системы
2. Пакет попадает в OvS-бридж, который проверяет MAC-адрес назначения в своей таблице коммутации (MAC learning)
3. Если вторая ВМ находится на том же OvS-бридже, OvS коммутирует пакет напрямую с одного TAP-интерфейса (vnet0) на другой (vnet1) в рамках ядра, минуя физическую сеть

Особенности настройки локальной коммутации:

• Интеграция с libvirt — в XML-описании сети ВМ указывается <virtualport type=“openvswitch“/> и <bridge name=“ovs-br0“/>
• VLAN/Тегирование — OvS позволяет назначать теги (VLAN tags) портам
• Безопасность — OvS позволяет использовать OpenFlow-правила для изоляции ВМ, предотвращая ARP/MAC-спуфинг
• Производительность — благодаря поддержке ядра Linux, OvS обеспечивает быструю передачу трафика между ВМ

Взаимодействие ВМ между разными хостами (без выхода за пределы платформы)¶

Взаимодействие виртуальных машин между разными хостами в KVM организуется на уровне сети, где хосты (физические серверы) обеспечивают транспорт для трафика ВМ. Основной подход заключается в создании общего сетевого пространства для ВМ, размещенных на разных физических узлах, без выхода трафика за пределы облачной платформы.

### Мостовое подключение (Bridged Networking)

Виртуальные машины подключаются к физическому сетевому интерфейсу хоста (NIC) через программный мост (br0), работающий на уровне 2 (L2).

• Принцип: ВМ получают IP-адреса из той же подсети, что и хост-машины
• Настройка: На каждом хосте создается мост (br0), в который добавляется физический интерфейс
• Плюсы: Простота настройки, высокая производительность, ВМ видны в локальной сети как отдельные устройства
• Ограничения: Требует наличия свободных IP-адресов в локальной сети

### Программно-определяемые сети (SDN) и VXLAN

Если ВМ находятся в разных подсетях или хосты разделены маршрутизируемой сетью, используется инкапсуляция VXLAN.

• Принцип: Трафик ВМ (L2) упаковывается в UDP-пакеты (L3), которые передаются между хостами
• Применение: Позволяет растянуть L2-сеть поверх L3-инфраструктуры, что критично для миграции ВМ
• Преимущество: Трафик остается внутри туннелей платформы, не выходя во внешние сети

### Использование Open vSwitch (OVS)

Вместо стандартного Linux Bridge используется более мощный виртуальный коммутатор Open vSwitch.

Преимущества: * Поддержка VLAN, VXLAN, GRE * Улучшенное управление трафиком * Возможность создания сложных сетевых топологий * Интеграция с SDN-контроллерами

Методы ускорения сетевого взаимодействия¶

### Open vSwitch (OVS) + DPDK

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

Ограничения: Достижимая пропускная способность пакетов ограничена пропускной способностью пересылки сетевого стека Linux, что не подходит для сценариев NFV/Telco, требующих высокой скорости обработки пакетов.

DPDK (Data Plane Development Kit) позволяет создавать высокопроизводительные приложения для обработки пакетов с помощью драйверов, обеспечивающих прямую передачу пакетов между пользовательским пространством и физическим интерфейсом, минуя сетевой стек ядра.

### Open vSwitch (OvS) + CPU offload (Mellanox ASAP²)

Недостатком метода OvS+DPDK является большая загрузка CPU, работающего в режиме постоянного опроса.

Технология Mellanox ASAP² использует адаптеры Mellanox ConnectX-4 и более поздних версий (Mellanox Embedded Switch или eSwitch), сохраняя плоскость управления OvS неизменной. Плоскость передачи данных переносится на аппаратное обеспечение NIC.

Сравнение производительности¶

|------------|——————-|-----------------|———-| | ASAP² (Hardware Offload) | Скорость линии связи (100 Гбит/с) | Минимальная (разгрузка на NIC) | Низкая | | OvS-DPDK | ~33% от скорости линии для мелких пакетов | Высокая (постоянный опрос) | Средняя | | Стандартный OvS | Базовая | Средняя | Высокая |

Основные выводы¶

• Задержка: ASAP² снижает задержку до 20 раз по сравнению со стандартным Open vSwitch
• Масштабируемость: Идеально подходит для рабочих нагрузок NFV и 5G, где критически важны высокая пропускная способность и низкая стабильная задержка
• Гибкость: Несмотря на аппаратное ускорение, сохраняется плоскость управления SDN Open vSwitch
• Локализация трафика: Все методы обеспечивают передачу трафика между ВМ на разных хостах без выхода за пределы облачной платформы, используя внутреннюю сеть инфраструктуры