В первой части мы разобрали, почему Aeza ушла со сторонней платформы и как AVM устроен в общих чертах. Здесь уровень ниже: путь запроса от вызова до задачи на конкретной ноде, устройство конвейеров, поведение при сбоях и то, где система хранит состояние виртуальных машин.
Любой запрос клиента заканчивается цепочкой задач на ноде: скачать образ, создать диск, поднять машину. Этими цепочками управляет AVM — собственная система управления виртуализацией.
Коротко о том, что было в первой части
Виртуализация Aeza раньше держалась на решении стороннего разработчика. Сроки исправления инцидентов задавал поставщик, свою логику в чужой продукт встроить было нельзя, а лицензия добавляла ещё одну точку зависимости. Отсюда требования к AVM: надёжность, работа в геораспределённой инфраструктуре и собственная команда, которая сразу разбирает инцидент.
Как проходит создание VM
AVM управляет созданием, переустановкой, удалением и миграцией VM, резервными копиями и IP‑адресами. Биллинг остаётся за пределами системы: он вызывает методы AVM через REST API, а обратных запросов не получает.
Внутри AVM есть control plane и агенты на вычислительных нодах. Control plane принимает вызовы и раздаёт работу агентам по gRPC. Каждый агент выполняет команды на своей ноде и служит высокоуровневой обвязкой над libvirt. Основные сервисы написаны на Python, а для отдельных участков с высокой нагрузкой команда использует Rust.
Упрощённо путь одного запроса выглядит так:
Внешний сервис вызывает создание VM и передаёт кластер
AVM сравнивает доступные vCPU, память и место на диске → выбирает наиболее свободную ноду кластера
API возвращает идентификатор задачи
Агент на выбранной ноде выполняет конвейер
Вызывающий сервис опрашивает состояние по идентификатору: этап, статус, журнал выполнения
На третьем шаге ответ уже получен, хотя машины ещё нет. Все операции асинхронные, и ответ приходит раньше, чем машина создана: вызывающая сторона получает не результат, а способ его дождаться. Кластер система не выбирает, его передаёт вызывающий сервис.
Свободный IP‑адрес AVM ищет в пуле или подсети. Выделение проходит внутри транзакции и под блокировкой: пока первая транзакция держит найденный адрес, вторая до него не доберётся и получит следующий. Так исключается ситуация, когда два параллельных запроса уносят один и тот же IP. Разные бэкенды хранилищ система пока не поддерживает.
Что происходит при переустановке VM
Переустановка состоит из нескольких действий на ноде:
Скачать образ выбранной ОС на ноду
Создать из образа диск виртуальной машины
Расширить диск до заказанного размера
Выполнить внутри ОС команды настройки системы и сети
Каждый шаг здесь отдельная задача. Если конвейер оборвётся на третьем шаге, второй уже оставил после себя диск, и его нужно убрать. Именно поэтому операция разбита на атомарные части: система должна знать, какие шаги успели пройти, чтобы отменить только их.
Почему пришлось переписать диспетчер задач
Первая версия диспетчера запускала задачи последовательно и давала слабые гарантии. Если выполнение прерывалось, последствия иногда приходилось устранять вручную. Выбор такого диспетчера был сознательным временным решением, так как на нём быстрее выходили первые функции. Но для управления большим числом нод и VM требовалась другая обработка сбоев.
Задачей в AVM называют атомарный участок кода на стороне агента, отвечающий за одну конкретную операцию. Новый диспетчер объединяет такие задачи в конвейеры. Последовательность может ветвиться, а история выполнения сохраняется.
Разработчики описывают получившуюся модель как exactly once. Достигается она двумя механизмами: серверная и клиентская дедупликация отсекает повторные сообщения, а сами операции сделаны идемпотентными. Идемпотентность означает, что повторный вызов приводит к тому же результату, что и первый: вторая попытка создать уже созданный диск не создаёт второй диск. В распределённой системе это обязательное дополнение к дедупликации, потому что сеть всегда может доставить сообщение дважды, а подтверждение потерять.
Переписанный диспетчер не превратил систему в AVM v2. По словам команды, архитектурно это всё ещё первая версия AVM, а серьёзно изменились именно механизм исполнения и сами задачи.
Поведение при сбоях
Реакция зависит от того, можно ли продолжить конвейер:
Временная ошибка libvirt:
→ повтор задачи по заданной стратегии
→ успех: конвейер идёт дальше
Продолжить нельзя:
→ запускаются компенсирующие задачи
→ каскадный откат снимает уже внесённые изменения
(например, удаляет созданный диск)
Компенсация нужна там, где обычная транзакция не работает. Запись в базе можно откатить одним движением, а скачанный на ноду образ и созданный диск существуют вне базы, и отменять их приходится встречным действием. Для разных шагов AVM использует то и другое: транзакции там, где изменения внутри базы, компенсирующие задачи там, где они снаружи.
Отдельный случай — недоступный агент. Задача при этом не считается провалившейся:
Агент недоступен:
→ задача остаётся в конвейере, состояние сохраняется
Агент вернулся:
→ выполнение продолжается с прерванного шага
Сколько длится пауза, неважно. Даже если агент был недоступен месяц, задача дождётся его и выполнится, а не потеряется и не завершится ошибкой.
Конфликтующие команды блокирует машина состояний. Она не принимает две одновременные переустановки одной VM и не запускает несовместимые изменения параллельно.
Где хранится состояние VM
В базе control plane лежит то, что нужно машине состояний: на каком шаге операция и что с ней происходит дальше. Фактическое состояние домена libvirt там не хранится — его агент получает от гипервизора динамически, собирает по виртуальным машинам на ноде и передаёт в control plane.
У этих данных разные роли:
Control plane: на каком этапе операция, допустима ли следующая команда
Гипервизор: фактическое состояние домена libvirt
Агент: снимает второе и передаёт в первое
Отсюда ответ на вопрос, чему верить при расхождении базы и гипервизора. В AVM источником правды остаётся гипервизор. Если агент перестаёт передавать актуальные сведения, статус машины меняется на неизвестный. Дальше нужна ручная проверка ноды: control plane знает, чем система занималась, но не знает, чем это закончилось.
Самой сложной задачей на этом уровне команда называет машину состояний: она должна оставаться понятной инженеру и одновременно не допускать несогласованных переходов на всём парке машин.
Как изменения проверяют и сопровождают
В проекте есть unit‑тесты и интеграционные тесты. Команда использует ещё и staging‑окружение, где новые функции проверяют вручную. Конкретные сценарии зависят от того, что входит в релиз.
В эксплуатации AVM собирает метрики vCPU, памяти, диска и сети виртуальных машин, а выполнение задач на агентах записывается в журналы. Если операция не выполнена, API обычно возвращает понятное описание причины, без необходимости идти в логи. Журнал открывают, когда нужно уточнить этап и обстоятельства сбоя.
Доступ к control plane разграничен: сотрудники и внутренние сервисы получают разные права. Сервисные учётные записи можно ограничить, а действия сотрудников журналируются и требуют подтверждения. Control plane и агенты обмениваются зашифрованными данными внутри закрытого контура. Токены и пароли периодически меняются.
Как систему вводили в эксплуатацию
Первую VM под управлением AVM запустили 4 сентября 2025 года. К середине декабря на новую систему полностью перевели первый промо‑тариф, а в середине марта 2026 года миграцию завершили в Хельсинки, Стокгольме и США. Частичный переход на новый диспетчер начался 1 апреля. К концу месяца все серверы уже находились под управлением AVM, а полный переход на новый диспетчер завершился в конце июня.
Во время миграции работали обе системы сразу:
Запрос биллинга → нода под управлением AVM?
да → запрос уходит в AVM
нет → запрос уходит в прежнюю платформу
Решение принимал биллинг, а не сама платформа виртуализации, и это упрощало откат. VM не убирали из старой системы окончательно, поэтому отдельную ноду можно было вернуть назад. Всю инфраструктуру одним релизом команда не переключала.
Ограничения текущей версии
Слабым местом текущей версии команда называет панель управления: пока она недостаточно информативна и неудобна в повседневной работе. Если бы AVM начинали заново с нынешним опытом, разработчики иначе организовали бы кодовую базу: сейчас в работе над AVM задействовано более десяти репозиториев.
Крупных архитектурных просчётов команда не называет: основные допущения были сделаны сознательно и позже устранены, а до продакшена доходили лишь отдельные мелкие ошибки.
Планы развития
В ближайших планах инкрементальные резервные копии для сокращения занимаемого места, VXLAN для виртуальных сетей между VM, межсетевой экран и оптимизация VM.
Заметных узких мест на текущем объёме команда не наблюдает, поэтому следующим ориентиром названы миллионы виртуальных серверов.
Команда AVM
Основную работу над AVM вели четыре инженера. На ранних этапах подключались и другие сотрудники. От первой машины в продакшене до полного перехода прошло меньше десяти месяцев.
Собственная система не добавила клиентам новых операций, зато передала контроль над их выполнением внутренней команде Aeza. На парке такого масштаба это означает, что за код, обработку сбоев и дальнейшее развитие отвечает та же компания, что и за инфраструктуру.