Proxmox VE 8.1: обновляем кластер клиента и пробуем встроенный SDN вместо внешнего коммутатора

Proxmox VE 8.1 вышел в ноябре, и главное изменение, которое нас интересовало - доработанный встроенный SDN. Не потому что мы фанаты SDN как концепции, а потому что у одного из клиентов давно висел запрос: сегментировать сеть виртуальных машин между несколькими арендаторами без покупки дополнительного управляемого коммутатора. Железо дорогое, сроки поставки непредсказуемые, а задача реальная. Посмотрели, что предлагает 8.1.

Что изменилось в 8.1

Базовая система переехала с Debian 11 Bullseye на Debian 12 Bookworm - это ядро 6.5, свежий QEMU 8.1, обновлённый Corosync. Само по себе хорошо: меньше backport-патчей, более актуальные драйверы для современного железа.

Но нас интересовал SDN. В Proxmox он существует давно, но до версии 8 был помечен как «технологическое превью» и в production его использовали осторожно. В 8.0 и 8.1 SDN переехал в основной интерфейс и стал поддерживаться официально. Реализован через EVPN/VXLAN поверх Linux-стека или через более простой VLAN-режим. Для нашей задачи смотрели именно на VLAN-зоны - они проще, без оверлейного туннелирования, работают на стандартном L2-железе.

Кластер клиента: что было

Три физических хоста Proxmox VE 8.0, объединённых в кластер через Corosync. Ceph-хранилище на тех же нодах. Несколько десятков виртуальных машин, принадлежащих двум разным проектам клиента - условно «проект А» и «проект Б». До сих пор они жили в одном бридже vmbr0, разделение было чисто административным: никаких сетевых барьеров между ними не было.

Клиент хотел, чтобы ВМ проекта А физически не видели трафик проекта Б. Без managed-коммутатора с поддержкой VLAN это не решалось средствами физической сети. С Proxmox SDN - потенциально решается программно.

Обновление до 8.1

Обновляли поочерёдно, нода за нодой. Proxmox предоставляет стандартный apt-путь:

apt update && apt dist-upgrade

Перед обновлением каждой ноды мигрировали с неё все ВМ на соседние. После апгрейда и перезагрузки - проверяли кластерный статус и только потом переходили к следующей. Занял процесс полдня с запасом на проверки.

Один нюанс специфичен для Debian 12: если на хостах стоят кастомные модули ядра (у нас был ZFS из репозитория Proxmox), нужно убедиться, что они пересобраны под новое ядро до перезагрузки. pve-headers нужной версии должны быть установлены заранее. Не критично, но если забыть - после перезагрузки ZFS-пулы не смонтируются.

Настройка SDN: VLAN-зоны

SDN в Proxmox настраивается через раздел Datacenter -> SDN в веб-интерфейсе. Структура трёхуровневая: зоны (Zone), сети VNet и подсети (Subnet).

Для нашей задачи создали две VLAN-зоны:

• zone-project-a - привязана к физическому интерфейсу enp3s0f0, VLAN ID 10
• zone-project-b - тот же интерфейс, VLAN ID 20

Под каждую зону - отдельный VNet с нужными подсетями. Proxmox автоматически создаёт Linux bridge для каждого VNet (в нашем случае vnet-a и vnet-b), ВМ назначаются в нужный bridge при настройке сетевого интерфейса.

После применения конфигурации (кнопка Apply в SDN-разделе, которая раскатывает изменения на все ноды кластера) - проверили изоляцию. ВМ из zone-project-a пингуют друг друга, ВМ из zone-project-b - друг друга. Кросс-зонального трафика нет. Работает.

Где всё-таки нужен коммутатор

Честная ремарка: VLAN-зоны Proxmox SDN решают задачу изоляции на уровне хоста. Но если трафик между ВМ уходит на физический коммутатор (например, ВМ на разных нодах общаются по L2), то коммутатор должен понимать тегированные VLAN-фреймы. У клиента стоит неуправляемый свитч с 10GbE-аплинками - и это ограничение.

Пока хватает того, что трафик между ВМ одного проекта остаётся внутри кластера через внутренние бриджи. ВМ разных проектов не взаимодействуют между собой напрямую. Но если понадобится L2-изоляция на уровне физической сети между нодами - без управляемого коммутатора не обойтись. SDN в режиме EVPN/VXLAN решил бы это через оверлей поверх неуправляемого железа, но клиент такой задачи не ставил.

EVPN: посмотрели, отложили

Заодно изучили EVPN-режим - полноценный оверлей с BGP между нодами, не требующий тегирования на физическом уровне. Конфигурация заметно сложнее: нужен BGP-процесс (FRRouting), настройка peer между нодами, отдельный IP для loopback. Документация в 8.1 стала лучше, но «просто нажал кнопку» там не будет.

Для текущей задачи клиента EVPN избыточен. Но понимание, что инструмент встроен в платформу и не требует отдельной лицензии - уже что-то.

Итог

Обновление до 8.1 прошло без неожиданностей. SDN в VLAN-режиме закрыл реальную задачу изоляции без покупки управляемого коммутатора - CAPEX сохранили. Ограничение известно: L2-изоляция на физическом уровне между нодами потребует либо управляемого железа, либо перехода на EVPN/VXLAN.

Клиент в рамках управляемой инфраструктуры получил настроенное SDN-разделение и мониторинг кластера. Пока наблюдаем за стабильностью - версия свежая.