В первой части мы разобрали, почему Aeza ушла со сторонней платформы и как AVM устроен в общих чертах. Здесь уровень ниже: путь запроса от вызова до задачи на конкретной ноде, устройство конвейеров, поведение при сбоях и то, где система хранит состояние виртуальных машин.Любой запрос клиента заканчивается цепочкой задач на ноде: скачать образ, создать диск, поднять машину. Этими цепочками управляет AVM – собственная система управления виртуализацией. Читать далее
Мы продолжаем рассказывать, как создавали AVM собственную платформу управления виртуальными машинами Aéza. В этой части разберём, как обновляем систему без остановки клиентских VM, выполняем живую миграцию, переживаем сбои и масштабируем инфраструктуру а также расскажем, с какими проблемами столкнулись по пути. Читать далее
Некоторое время назад потребовалось решить задачу по переносу виртуальных машин KVM с одного кластера Proxmox VE на другой с минимальным временем простоя. В PVE «из коробки» такой возможности нет, но, как оказалось, онлайн-миграцию виртуальных машин между кластерами можно выполнить средствами KVM. Процедуру переноса я подробно опишу в этом руководстве. Читать далее
До AVM виртуализацией управляла сторонняя платформа. Иногда она зависала и переставала принимать задачи. Нагрузку распределили между несколькими экземплярами платформы, но зависания продолжились. До вмешательства операции клиентов не шли. Читать далее