Архитектура eBPF-сети в microsrv: как сохранить IP, сокеты и шлюзы при миграции ВМ

Виртуальная машина может сменить физический сервер, но её сетевой адрес и открытые соединения должны оставаться неизменными.

В традиционных облаках миграция прерываемой ВМ или её перезапуск на новом хосте почти всегда сопровождаются сетевым сбоем: меняется частный IP-адрес, рвутся установленные TCP-соединения, а внешние клиенты теряют связь, пока не обновятся записи DNS и правила маршрутизации.

Платформа microsrv решает эту проблему на уровне ядра. Сетевой слой на базе eBPF отделяет IP-адрес, доменное имя и открытые сокеты виртуальной машины от конкретного физического сервера. Пока оркестратор переносит оперативную память и процессы, eBPF перенаправляет трафик на новый хост. Приложение и внешние пользователи ничего не замечают.

Коротко: сетевой слой microsrv отделяет сетевую идентичность ВМ от физического сервера. После живой миграции у машины сохраняются тот же частный IP, доменное имя и открытые TCP-соединения, без логики переподключения в приложении.

Ниже — как устроен сетевой слой, что он даёт по умолчанию и почему обработку сетевых сбоев не придётся писать в приложении.

1. В чём проблема традиционной сети при миграции

Когда виртуальной машине приходится менять физический хост из-за планового обслуживания или отзыва прерываемого (Spot) сервера, приложение сталкивается с целым рядом сетевых проблем:

Смена частных IP-адресов. Машина получила новый адрес в локальной сети, и правила межсетевых экранов, списки доступа (ACL) и настройки связанных сервисов перестают работать.
Разрыв долгоживущих TCP-соединений. Открытые SSH-сессии, репликация баз данных, WebSocket-каналы и длинные HTTP-запросы аварийно завершаются.
Задержки обновлений DNS. Даже с доменными именами клиенты продолжают отправлять запросы на старый IP из-за кэширования DNS (TTL).
Привязка к публичному IP. Отдельный публичный адрес на сетевом интерфейсе ВМ привязывает её к конкретному физическому серверу и увеличивает расходы.

Обходить эти ограничения приходится в коде приложения: повторные подключения с экспоненциальной задержкой, внешние балансировщики, сложные сценарии переключения трафика. eBPF-сеть в microsrv решает эти задачи на уровне платформы.

2. Принцип работы eBPF-сети в microsrv

eBPF (Extended Berkeley Packet Filter) — технология ядра Linux, позволяющая выполнять высокопроизводительные программы обработки пакетов прямо в сетевом стеке, без переключений в пространство пользователя.

В microsrv технологии eBPF образуют виртуальный data plane (слой передачи данных). Главная архитектурная идея проста:

Сетевая идентичность (IP-адрес, доменное имя, открытые сокеты) принадлежит самой виртуальной машине, а не серверу, на котором она запущена.

Когда оркестратор выполняет живую миграцию ВМ с одного прерываемого хоста на другой:

сетевой стек виртуальной машины вместе с таблицей сокетов переносится в оперативную память нового хоста;
eBPF-программы обновляют карты маршрутизации, перенаправляя входящие и исходящие пакеты на новый физический адрес;
трафик сразу идёт на новый хост, а открытые TCP-соединения не сбрасываются.

3. Ключевые возможности для разработчиков и сервисов

Изолированные частные сети (VPC)

Все виртуальные машины пользователя объединяются в изолированную частную сеть (VPC) и общаются по стабильным частным IP-адресам без выхода в публичный интернет.

Каждая машина получает фиксированный адрес (например, 10.42.0.5), который не меняется весь жизненный цикл ВМ, сколько бы раз она ни переезжала между серверами.

Защита от подмены IP- и MAC-адресов на уровне ядра

Подлинность сетевых пакетов проверяется прямо в ядре, на сетевом интерфейсе ВМ. Отправить пакет с чужим IP- или MAC-адресом машина не может. Клиенты изолированы друг от друга без громоздких цепочек правил iptables/nftables на хосте-гипервизоре.

Безопасный доступ в интернет (NAT)

Виртуальным машинам нужен исходящий доступ: загрузка зависимостей, сторонние API, отправка метрик. В microsrv исходящий трафик проходит через исходящий NAT.

ВМ выходит в интернет, но прямого публичного IP-адреса у неё нет, поэтому её сервисы недоступны для сканирования и сетевых атак извне.

SSH-шлюз

Для подключения к виртуальным машинам по SSH не нужно публиковать порт 22 в интернет или арендовать публичные IP. Доступ идёт через SSH-шлюз:

ssh -A <vm>@msrv.space

Шлюз проверяет SSH-ключи пользователя и направляет соединение к нужной ВМ внутри VPC. Адрес подключения не меняется при миграциях. Зачем убирать открытый 22-й порт с виртуальных машин и чем шлюз отличается от классического бастиона, рассказано в статье SSH без публичного IP.

HTTPS-шлюз

Для публикации веб-приложений и сервисов наружу microsrv предоставляет HTTPS-шлюз с поддержкой TLS/SNI:

HTTPS-маршрутизация: трафик автоматически распределяется по доменным именам вида <vm>.msrv.space.
Маршрутизация TCP / TLS-SNI: позволяет безопасно публиковать сервисы, не использующие HTTP (например, СУБД PostgreSQL или MySQL):
```
psql "host=<vm>.msrv.space sslmode=require"
```
Автоматические TLS-сертификаты: шлюз берёт на себя шифрование и управление сертификатами.

4. Сохранение TCP-соединений при живой миграции

Самый ответственный момент миграции — сохранение открытых сетевых сокетов. Если сбросить соединения при переносе памяти и процессов, клиенты получат ошибку Connection Reset by Peer.

Сетевой eBPF-слой microsrv синхронизирует состояние маршрутизации в момент финального переключения (cutover):

Во время переезда: eBPF-программа временно буферизует трафик или направляет его на целевой хост.
После завершения: карты eBPF на всех узлах обновляются атомарно.
Результат: открытые SSH-сеансы, WebSocket-каналы и активные транзакции в базах данных продолжают работу так, словно машина и не меняла физический сервер.

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

5. Главные преимущества для инженерных команд

Минимум дополнительной сетевой инфраструктуры. Не нужно разворачивать и поддерживать внешние балансировщики, сервис-меш (service mesh) или сценарии перерегистрации DNS.
Никаких изменений в коде. Приложения работают в обычном окружении Linux и не требуют специальных SDK для работы с сетью.
Стабильная работа на прерываемых ресурсах. Экономия около 25% на облачной инфраструктуре больше не оборачивается регулярными обрывами соединений и сбоями у клиентов.
Безопасность из коробки. Прямых публичных IP на виртуальных машинах нет, защита от подмены адресов встроена: защищённый контур по умолчанию.

6. Единая система: память, тома и сеть

Сетевой eBPF-слой — часть трёхуровневой системы надёжности microsrv:

Оркестратор сохраняет оперативную память и запущенные процессы (живая миграция).
Распределённое хранилище сохраняет тома и файловую систему (репликация томов).
eBPF-сеть сохраняет IP-адреса, маршруты и открытые сокеты.

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

Источники и что почитать дальше

eBPF — ebpf.io — What is eBPF? и документация BPF (kernel.org)
Cilium — eBPF Maps (как карты eBPF перепривязывают потоки)
Cloud NAT / VPC — Google Cloud VPC (стабильность приватных IP)
Сопутствующие статьи: живая миграция и репликация томов — два других ключевых компонента

Как проверяли: в microsrv приватный IP 10.42.0.5 и активные сессии ssh/psql переживают virsh migrate --live; проверка — ping + ss -tan показывают тот же сетевой сокет (4-tuple) после переключения. При внезапном отказе (kernel panic) — холодный перезапуск из реплики, см. §4.

FAQ

Переживут ли WebSocket и стримы БД миграцию? Да, при штатной живой миграции: eBPF буферизует или перенаправляет пакеты и атомарно обновляет карты. При внезапном отказе TCP рвётся, и клиент переподключается на тот же <vm>.msrv.space после холодного перезапуска.

Может ли гостевая ОС подделать IP другой ВМ? Нет. Защита от спуфинга работает в ядре хоста на vNIC ВМ (eBPF), а не через iptables гостевой системы.