Гипервизор Yandex Cloud: архитектура разработки

Мы используем привычный стек QEMU/KVM, но управляем им иначе. Вместо того чтобы задействовать libvirt, обращаемся к гипервизору напрямую по QMP. Поверх этого работают собственные компоненты Compute Node — Scheduler — API, поэтому инфраструктура остаётся гибкой и полностью под контролем.

Главное отличие архитектуры — мультиверсионность. На каждом хосте одновременно установлено несколько сборок QEMU, а оркестратор blue/green переводит ВМ между ними, следит за метриками миграции и при первом сбое мгновенно останавливает релиз.

Такая схема сужает зону риска: если возникает проблема, релиз отматывается за минуты, а простой остаётся минимальным — это поддерживает надёжность сервисов.

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

Что такое гипервизор

Технология виртуализации возникла в 1960‑х годах, когда потребовалось эффективнее использовать аппаратные ресурсы дорогостоящих мейнфреймов. Со временем именно виртуализация стала фундаментом облачных вычислений. Она позволяет запускать на одном физическом сервере несколько изолированных друг от друга виртуальных сред, каждая из которых работает безопасно и стабильно.

Гипервизор (virtual machine monitor, VMM) — это слой программного обеспечения, который эмулирует аппаратные ресурсы и распределяет их между независимыми виртуальными машинами (ВМ). Таким образом, на одном физическом сервере параллельно работают несколько полноценных вычислительных сред, которые при этом изолированы друг от друга и от хоста, что критически важно для обеспечения безопасности и стабильной работы приложений в облачной инфраструктуре и ЦОД. Гипервизор обеспечивает масштабируемость, то есть позволяет легко наращивать или сокращать ресурсы под текущие потребности приложений.

Как внедрение гипервизора может влиять на бизнес:

• Консолидация и снижение TCO (Total Cost of Ownership). Гипервизор позволяет достичь уровня загрузки серверов 60–80% вместо типичных 10–15% для монолитных инсталляций. Это напрямую уменьшает капитальные и операционные затраты.
• Быстрое развёртывание и снижение time to market. Новая виртуальная машина под тестирование или запуск пилота разворачивается за считаные минуты. Не нужно докупать дополнительное оборудование — это существенно ускоряет вывод новых продуктов на рынок.
• Управляемая изоляция и усиленная безопасность. Ошибки или компрометация одной виртуальной машины не влияют на остальные ВМ на том же сервере. Это облегчает выполнение требований Zero Trust и отраслевых стандартов безопасности.

Особенности архитектуры гипервизора Yandex Cloud

Существуют два типа гипервизоров:

• Первый тип работает прямо на железе, без промежуточной операционной системы. Он даёт минимальные накладные расходы и высокую изоляцию, поэтому подходит для ЦОД, публичных и частных облаков, а также сценариев с высокой плотностью виртуализации.

• Второй тип (hosted) устанавливается поверх существующей ОС как обычное приложение. Его проще развернуть, но дополнительный слой абстракции может снизить производительность. Такой вариант выбирают для сред разработки, тестирования, учебных проектов и локальных стендов.

Наш гипервизор основан на открытом решении QEMU/KVM. KVM (Kernel‑based Virtual Machine) относится к гипервизорам первого типа и работает непосредственно на уровне ядра ОС Linux. Такой подход позволяет ему напрямую взаимодействовать с аппаратными ресурсами физического сервера, обеспечивая высокую производительность и эффективное распределение ресурсов между виртуальными машинами.

Таким образом, наше решение сочетает преимущества гипервизоров первого типа на основе KVM — высокую производительность и надёжность — с собственными разработками.

Отказ от libvirt и прямое управление через QMP

Мы убрали libvirt, исключив лишний слой абстракции, и обращаемся к QEMU напрямую через QMP. Такой подход даёт полную гибкость: собственные QMP‑команды встраиваются прямо в код QEMU, а ресурсы на поддержку libvirt больше не требуются.

Вместо libvirt задачи запуска виртуальных машин, подключения дисков и сетей выполняет Compute Node. Compute Scheduler распределяет нагрузки по хостам и балансирует ресурсы. Внешние запросы из консоли или Terraform принимает Compute API, после чего передаёт их в кластер. Вместе эти сервисы закрывают весь жизненный цикл ВМ, поэтому отдельный демон libvirt системе не нужен.

Обычно на хосте разрешена только одна версия QEMU, но наша схема blue/green хранит несколько сборок одновременно. Оркестратор постепенно переводит виртуальные машины на новую версию, следя за паузами миграции и фоновыми ошибками. Если метрики выходят за допустимые значения, процесс сразу останавливается, а ВМ возвращаются к стабильной сборке.

Каждая новая сборка проходит автоматический цикл «обновление — миграция — откат — повторная миграция». Благодаря этой регулярной проверке механизм отката остаётся готовым к любому сбою.

Мультиверсионность QEMU и подход Blue/Green Deployment

В типичной поставке дистрибутивов Linux (Ubuntu, RHEL и других) на хост устанавливается только одна версия QEMU. Если в ней обнаруживается дефект, для отката приходится переустанавливать пакет и перезапускать все ВМ, что даёт минуты простоя для всего хоста.

Мы решили эту проблему, внедрив «мультиверсию» QEMU по принципу Blue/Green Deployment: на каждом хосте хранятся несколько пакетов QEMU, а внутренний оркестратор через API быстро переключает конкретную ВМ между версиями без переустановок ПО. Это сокращает время простоя и число пострадавших машин в случае, если что-то идёт не так.

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

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

Как управляются компоненты

Для оптимального размещения и работы виртуальных машин мы применяем собственные сервисы:

• Compute Node — на каждом хосте получает конфигурацию ВМ, запускает QEMU, монтирует диски и подключает сетевые интерфейсы.
• Compute Scheduler — выбирает подходящий хост для новой ВМ с учётом текущей нагрузки.
• Compute API — единая точка управления, принимает gRPC‑запросы из Yandex Cloud Console, Yandex Cloud CLI, модулей Terraform и других инструментов автоматизации.

Оркестратор мультиверсии QEMU

Мы отделили управление версиями гипервизора от Compute и создали собственный оркестратор. Его задача — разворачивать новые сборки QEMU и при необходимости мгновенно откатывать их.

На каждом хосте хранится несколько версий QEMU. При переключении оркестратор сразу меняет «дефолтную» сборку — переустанавливать пакеты не нужно. Сразу после переключения он запускает локальную миграцию виртуальных машин, отслеживает паузы синхронной фазы и фоновые ошибки. Если метрики выходят за пределы пороговых значений, релиз приостанавливается: оркестратор возвращает стабильную версию и ограничивает влияние только затронутыми ВМ.

Каждая новая сборка проходит автоматический цикл: установка, миграция в тестовом контуре, откат и повторная миграция. Такой прогон гарантирует совместимость пары «новая ↔ старая» для локального отката.

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

Технические новшества: выкатка и обновление QEMU в Yandex Cloud

QEMU — надёжный гипервизор, который активно используют и тестируют разработчики по всему миру. Мы усиливаем эту экспертизу собственными регламентами и ловим баги, не попавшие в основной проект. Сбои в новых релизах случаются редко, но синтетика на стендах улавливает их не всегда — поэтому свежие версии внедряем поэтапно.

Обновление QEMU состоит из двух ключевых этапов:

1. Установка новой версии на хост. На каждый сервер добавляем свежую сборку QEMU, сохраняя рядом текущую. «Дефолтную» версию можно переключить мгновенно — без переустановок пакетов. Такой мультиверсионный подход ограничивает радиус возможного инцидента до выбранного набора виртуальных машин.

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

Эта схема сокращает время на откат и снижает риски при обновлениях, сохраняя высокую доступность сервисов.

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