Когда платформа переставала отвечать
До AVM виртуализацией управляла сторонняя платформа. Иногда она зависала и переставала принимать задачи. Нагрузку распределили между несколькими экземплярами платформы, но зависания продолжились. До вмешательства операции клиентов не шли.
Зависимость от поставщика
Ручных операций не было: жизненный цикл VM платформа обслуживала сама. Однако команда Aeza не могла сама исправить ошибку или изменить внутреннюю логику. Сбой выглядел одинаково при любой причине: операция не проходила, а команда могла лишь передать симптом в стороннюю поддержку. Срок исправления задавал контрагент, и ожидание оборачивалось проблемами с клиентским сервисом. Платформа не была рассчитана на такое число виртуальных машин, а изменить её поведение изнутри было нельзя.
Почему готовую платформу не заменили другой
Замена одной готовой платформы на другую не устранила бы главную проблему: инженеры по-прежнему зависели бы от сроков поставщика. Готовые платформы поддерживают их разработчики: своя логика туда не встраивается, а лицензия добавляет расходы и ещё одну зависимость. Собственная система давала контроль над кодом: причину сбоя команда искала сама. При этом AVM должен был работать в географически распределённой инфраструктуре и управлять сотнями тысяч VM.
Чем управляет AVM
AVM отвечает за жизненный цикл виртуальных машин: создание, переустановку, удаление, миграцию, резервное копирование и выдачу IP-адресов. Биллинг остаётся отдельной системой: он обращается к AVM через API, тогда как AVM к биллингу не обращается. Единого слоя для разных бэкендов хранилищ в AVM пока нет. Работа с образами ограничена установкой: образ скачивается на ноду, из него создаётся диск нужного размера.
Control plane, агенты и планировщик
Агенты на KVM-нодах вызывают libvirt, а control plane управляет ими по gRPC. Сервисы Aeza обращаются к AVM через REST API. Код написан на Python, а для участков с высокой нагрузкой используется Rust.
Ноды объединены в кластеры. Внешний сервис указывает кластер, а AVM выбирает узел по свободным vCPU, памяти и месту на диске. Свободный IP подбирается из пула или подсети; транзакции и блокировки исключают двойное выделение. Операции асинхронны: API возвращает идентификатор задачи, по которому видны этап, статус и журнал. Права сотрудников и сервисов разграничены, действия логируются и требуют подтверждения. Control plane и агенты передают зашифрованные данные по закрытой сети.
Как переделали систему задач
В первом диспетчере задачи шли последовательно, а последствия сбоев устраняли вручную. Теперь операцию делят на атомарные задачи, последовательность которых может ветвиться. Система хранит историю выполнения и при ошибке откатывает изменения. Дедупликация сообщений и идемпотентные операции не дают выполнить команду дважды.
Если агент недоступен, задача ждёт его и продолжается с прерванного шага. При временной ошибке libvirt задача запускается повторно. Если продолжить нельзя, компенсирующие задачи откатывают уже внесённые изменения. Машина состояний блокирует конфликтующие действия над VM.
Как AVM вводили в продакшен
Первую VM запустили 4 сентября 2025 года. Биллинг направлял запрос в ту платформу, которая управляла нужной нодой. Пока VM оставалась в прежней платформе, её можно было вернуть обратно. К концу апреля 2026 года AVM управлял всеми серверами, а в конце июня завершился переход на новый диспетчер задач.
В августе 2026 года AVM управляет примерно 200 тысячами VM, обрабатывает около 60 тысяч операций в сутки и 200 запросов в секунду. Одновременно выполняется от 100 до 400 задач.
Команда и сроки
Над AVM работали три разработчика и тестировщик. Все серверы перевели на AVM за восемь месяцев. Команда планирует добавить инкрементальные резервные копии, VXLAN и межсетевой экран. В дальнейшем AVM планируют масштабировать до миллионов VM.
