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

+----------------------------------------------------------------------------+
| MICROSRV eBPF ARCHITECTURE: INDEPENDENT NETWORK IDENTITY                   |
+----------------------------------------------------------------------------+
|                                                                            |
|  [ВХОДНЫЕ ТОЧКИ]     SSH Gateway                 HTTPS / SNI API Gateway   |
|                      (ssh <vm>@microsrv.ru)   (https://<vm>.microsrv.ru)   |
|                             |                            |                 |
|                             +--------------+-------------+                 |
|                                            |                               |
|  [СЕТЕВОЙ eBPF-СЛОЙ]                       v                               |
|                      +------------------------------------------+          |
|                      |   eBPF MAPS: DYNAMIC ROUTE REBINDING     |          |
|                      +------------------------------------------+          |
|                             |                            |                 |
|  [ЧАСТНЫЙ VPC]              v                            v                 |
|                     +---------------+            +---------------+         |
|                     | ВМ A (10.42)  |            | ВМ B (10.42)  |         |
|                     +---------------+            +---------------+         |
|                                                          |                 |
|  [ФИЗИЧЕСКИЙ ХОСТ]  Host-17 (Прерывается)  ===>  Host-42 (Свободный Spot)  |
|                                                                            |
|  [СТАТУС СЕТИ]      Private IP: СОХРАНЁН  | Домен: АКТИВЕН  | TCP: АКТИВНЫ |
|                                                                            |
+----------------------------------------------------------------------------+

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Аппаратная защита от подмены IP и MAC (Anti-Spoofing)

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

Безопасный исходящий интернет (NAT)

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

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

Единый шлюз SSH-доступа

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

ssh -A <vm>@microsrv.ru

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

Встроенный L7/L4 API Gateway

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

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

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

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

Сетевой eBPF-слой microsrv синхронизирует состояние маршрутизации на границе миграции:

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

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

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

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

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

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

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

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