Виртуализация в корпоративной инфраструктуре. Как устроен гипервизор, что ограничивает производительность и как обеспечить катастрофоустойчивость при миграции с VMware на KVM
- 13 мин.
Содержание статьи:
- Что такое гипервизор и почему от его архитектуры зависит производительность всего кластера
- Распределение ресурсов и дисковая подсистема гипервизора 1 типа
- Механика живой миграции (Live Migration)
- Обзор корпоративных платформ виртуализации
- На что смотреть при выборе платформы
- Переход с VMware: что усложняет миграцию
- Высокая доступность и катастрофоустойчивость
- Что определяет успех перехода
Виртуализация серверов — это разделение ресурсов физического сервера между несколькими изолированными виртуальными машинами, каждая из которых работает как отдельный компьютер со своей операционной системой. На уровне одного сервера задача сводится к изоляции. На уровне ЦОД к ней добавляются другие: разместить больше ВМ на том же оборудовании, не теряя предсказуемости отклика, и сохранить работу сервисов при отказе узла или переносе нагрузки между площадками.
Как система виртуализации решает эти задачи, зависит от ее архитектуры — от того, как гипервизор распределяет процессорное время и память, как организовано хранилище и как устроено восстановление после сбоя. Для российских инфраструктур к этому добавился еще один вопрос: переход с VMware на платформы на базе KVM, который у большинства команд идет поэтапно и надолго оставляет среду разнородной. Ниже разберем, как устроены гипервизоры, где теряется производительность, чем различаются корпоративные платформы на российском рынке и как обеспечить катастрофоустойчивость при миграции между несовместимыми средами.
Что такое гипервизор и почему от его архитектуры зависит производительность всего кластера
Гипервизор — программный слой (VMM — Virtual Machine Monitor), который разграничивает физические ресурсы сервера и контролирует доступ гостевых систем к оборудованию. Его главная задача — изоляция среды. Сбой приложения или падение ядра в одной виртуальной машине не должны влиять на работу соседних ВМ или вызывать сбой самого хоста.
Гипервизоры 1 типа (Bare-metal) и 2 типа (Hosted) различаются местом в программном стеке, способом доступа к оборудованию, зависимостью от хостовой ОС и базовыми сценариями применения. В таблице ниже приведены ключевые критерии обоих архитектурных классов. При этом конкретный набор функций, ограничения и метрики производительности все равно придется сверять с документацией конкретного продукта и выбранной редакции.
| Критерий сравнения | Гипервизор 1 типа (Bare-metal) | Гипервизор 2 типа (Hosted) |
|---|---|---|
| Архитектурный уровень и классификация | Работает непосредственно на аппаратном уровне. KVM интегрирован в ядро Linux, что превращает ОС в полноценный гипервизор. | Устанавливается поверх стандартной ОС (Windows, macOS). Зависит от планировщика и драйверов хостовой операционной системы для управления ресурсами. |
| Прямой доступ к оборудованию | Использует аппаратные расширения (Intel VT-x, AMD-V) для прямого исполнения инструкций. Управление ресурсами интегрировано в ядро гипервизора или модули ядра хоста (для KVM). | Может использовать аппаратное ускорение, но запросы к периферии и ввод-вывод (I/O) проходят через драйверы и API хостовой операционной системы. |
| Накладные расходы (Overhead) | Производительность зависит от специфики нагрузки, модели CPU, драйверов (VirtIO), типа СХД, использования SR-IOV и настроек энергосбережения. | Зависят от драйверов (VMXNET3), эффективности планировщика хостовой ОС и задержек стека I/O при прохождении через компоненты основной системы. |
| Кластеризация и HA | Поддерживает объединение узлов в кластеры, живую миграцию (live migration), высокую доступность (HA) и автоматическую балансировку нагрузки (DRS), которые обеспечиваются платформой управления. | Ограничен одиночным физическим узлом. Встроенные средства кластеризации и живой миграции на уровне гипервизора отсутствуют, однако участие в кластерах возможно через внешние инструменты. |
| Требования к совместимости (HCL) | Жесткие требования к списку совместимого оборудования (Hardware Compatibility List). Требуются встроенные драйверы под конкретные RAID-контроллеры, HBA и NIC. | Базовые требования. Используется оборудование, которое корректно распознано и поддерживается хостовой операционной системой. |
| Примеры решений и назначение | Модуль KVM, отечественные платформы из реестра ПО (zVirt, РЕД Виртуализация, ПК СВ «Брест»), а также VMware ESXi и Hyper-V. Промышленные ЦОД и корпоративные кластеры. | Oracle VirtualBox, VMware Workstation, Parallels Desktop, QEMU. Применяется для локальной разработки, тестирования ПО и запуска изолированных песочниц. |
Выбор архитектуры упирается в чувствительность сервисов к задержкам ввода-вывода и необходимость кластеризации. Гипервизоры 1 типа (bare-metal) требуют подтвержденной совместимости с оборудованием и часто являются предпочтительным выбором для промышленных ЦОД благодаря наличию развитых средств управления. Hosted-гипервизоры снимают проблемы с драйверами, но обычно не рекомендуются для высоконагруженных production-сред без предварительного анализа рисков, хотя могут применяться в отдельных специфических сценариях.
Согласно документации Red Hat, KVM является гипервизором 1 типа, так как модуль ядра предоставляет Linux возможности управления виртуализацией и прямого доступа к ресурсам, делая ОС частью самого гипервизора.
Распределение ресурсов и дисковая подсистема гипервизора 1 типа
Внедрение гипервизора 1 типа требует баланса между плотностью размещения виртуальных машин (ВМ) и гарантированным качеством обслуживания (QoS). Ниже разобраны ключевые механизмы платформы и эксплуатационные ограничения.
Планирование процессора и топология vNUMA
Переподписка процессора (CPU overcommit) позволяет оптимизировать использование оборудования. Приведенные ниже коэффициенты соотношения виртуальных процессоров к физическим потокам (vCPU:pCPU) следует рассматривать как начальные эвристики для первичной оценки, которые требуют обязательной верификации путем нагрузочного тестирования для каждой конкретной инфраструктуры:
- Инфраструктурные сервисы (веб-серверы, контроллеры домена, легкие микросервисы): до 4:1.
- Среды виртуальных рабочих мест (VDI): до 8:1.
- Высоконагруженные транзакционные СУБД (PostgreSQL, MS SQL): строго 1:1.
Превышение коэффициента переподписки вызывает рост задержек: ВМ готова выполнять инструкции, но физические такты заняты другими процессами. Для среды VMware это выражается в росте метрики CPU Ready Time, тогда как для KVM релевантным показателем является CPU steal time. Оба значения сигнализируют об увеличении задержек на уровне приложений (application latency).
Для ресурсоемких (широких) ВМ критична точная настройка топологии vNUMA. Если vCPU обращается к памяти соседнего физического узла процессора, это приводит к существенному увеличению задержки доступа (memory latency), конкретный масштаб которой зависит от архитектуры оборудования.
Управление оперативной памятью и подкачка (Ballooning)
Механизм ballooning работает за счет специального драйвера в гостевой ОС: драйвер искусственно занимает память внутри виртуальной машины, вынуждая гостевую ОС высвобождать страницы и возвращать их гипервизору.
Для критичных СУБД и JVM-приложений под высокой нагрузкой использование ballooning может быть нежелательным, так как при нехватке физической памяти он может спровоцировать активное использование файла подкачки (swap) в гостевой ОС, что увеличивает задержки. Резервирование оперативной памяти и отключение динамического управления — это решение, принимаемое на основе конкретных требований к SLA и результатов тестирования, а не универсальное ограничение.
Дисковая подсистема и форматы виртуальных дисков
Дисковая подсистема — критический узел производительности. Пропускную способность и задержки определяют выбранный протокол доступа и архитектура:
- Блочные протоколы (FC, iSCSI): обеспечивают низкие накладные расходы при доступе к СХД, однако итоговые IOPS определяются характеристиками дискового массива и пропускной способностью сети.
- Файловый протокол NFS: сочетает простоту настройки с достаточной производительностью для большинства задач.
- Программно-определяемые хранилища (SDS): распределяют данные по локальным дискам узлов. Требования к сети (часто от 25 Гбит/с и выше) зависят от конкретного продукта, профиля ввода-вывода и схемы репликации данных.
Выбор формата диска балансирует между производительностью и функциональностью:
- Raw: обеспечивает высокую производительность за счет минимизации слоев метаданных и отсутствия механизмов copy-on-write.
- qcow2 и VMDK: поддерживают тонкое выделение (thin provisioning) и снапшоты, однако требуют ресурсов на трансляцию метаданных.
Ограничения снимков дисков: Снапшот не является средством резервного копирования. Длинные цепочки снимков увеличивают накладные расходы на обработку метаданных, что может негативно влиять на задержки ввода-вывода. Операции консолидации крупных снимков под высокой нагрузкой могут приводить к заметным задержкам или кратковременной остановке (stun) ВМ; длительность паузы зависит от реализации платформы, объема изменений (delta) и текущей интенсивности нагрузки.
Механика живой миграции (Live Migration)
Живая миграция позволяет перемещать запущенную ВМ между физическими узлами без остановки сервисов. Процесс основан на итерационном предварительном копировании оперативной памяти (pre-copy):
- Гипервизор переносит страницы памяти на целевой хост и параллельно фиксирует измененные данные (dirty pages bitmap).
- Когда объем оставшихся измененных страниц снижается до минимума, исходная ВМ приостанавливается на доли секунды для передачи остатка данных.
- ВМ возобновляет работу на новом узле.
Ограничения: если скорость изменения оперативной памяти ВМ превышает пропускную способность сетевого канала (характерно для высоконагруженных СУБД), миграция может не завершиться (fail to converge). В таких случаях применяются различные стратегии: ограничение производительности CPU гостевой системы, изменение лимитов миграции, использование методов stop-and-copy или post-copy (при поддержке платформой), либо перенос ВМ в запланированное окно работ. Успех миграции также критически зависит от совместимости CPU, сетевых настроек, конфигурации устройств и отсутствия несовместимых режимов (например, passthrough-устройств), которые блокируют перенос.
Обзор корпоративных платформ виртуализации
Все перечисленные решения — гипервизоры 1 типа, применяемые в промышленной эксплуатации; гипервизоры 2 типа (hosted) здесь не рассматриваются. Ниже приведено сравнение корпоративных платформ виртуализации на российском рынке: их архитектурная основа, ключевые особенности и статус в условиях импортозамещения.
| Платформа | Тип и архитектурная основа | Особенности | Статус на рынке РФ |
|---|---|---|---|
| VMware ESXi | Тип 1, проприетарный | Зрелая экосистема, широкая совместимость с прикладным ПО, отлаженные процессы эксплуатации | Уход вендора, пересмотр лицензирования; основной источник миграции |
| KVM | Тип 1, open source (модуль ядра Linux) | Основа большинства отечественных платформ; в «чистом» виде требует внешней обвязки для управления и кластеризации | Базовый стандарт корпоративного стека |
| РЕД Виртуализация | Тип 1, на базе KVM | Сертификация ФСТЭК, управление в логике, привычной инженерам vSphere | В реестре российского ПО |
| zVirt | Тип 1, на базе oVirt/KVM | Функциональная замена vSphere: аналоги HA и DRS, низкий порог переобучения | В реестре российского ПО |
| Hyper-V | Тип 1, проприетарный (Microsoft) | Нативная интеграция с Windows Server и Active Directory | Ограниченный вендорский риск, зависимость от Windows-экосистемы |
С уходом зарубежных вендоров KVM стал общей технологической основой российского рынка виртуализации: на нем построена большая часть отечественных платформ, а альтернативы на bhyve (vStack) или в виде виртуализации внутри Kubernetes (KubeVirt) занимают узкие ниши.
На что смотреть при выборе платформы
При проектировании кластера выбор платформы основывается на базовом техническом чек-листе:
1. Совместимость с оборудованием (HCL)
Поддержка серверов, HBA-адаптеров и сетевых карт на уровне ядра Linux.
2. Реестровый статус и сертификация ФСТЭК
Наличие записи в Реестре российского ПО и сертификата безопасности не обеспечивают соответствие требованиям КИИ/ПДн автоматически. Необходимо учитывать границы сертификации, версию документа, а также наличие модели угроз и комплекса мер защиты в инфраструктуре.
3. Совместимость с прикладным ПО
Официальная вендорская поддержка работы ключевых бизнес-систем (1С, СУБД Postgres Pro, отечественные ОС).
4. Вендорский SLA и техподдержка
Доступность круглосуточной поддержки 24/7 с гарантированным временем реакции на критичные инциденты.
5. API резервного копирования (CBT)
Поддержка механизмов отслеживания измененных блоков для интеграции с российскими СРК (Киберпротект, RuBackup и др.).
6. Отказоустойчивость и кворум
Наличие механизмов изоляции (Fencing/STONITH) для предотвращения сценариев Split-Brain и исключения одновременного доступа или запуска ВМ на нескольких узлах при отказах.
Но выбор целевой платформы — только первая часть задачи. Сложнее оказывается сам переход на нее.
Переход с VMware: что усложняет миграцию
Многие организации продолжают работать на VMware, в том числе на истекающих лицензиях, возможность продления которых зависит от условий договора, юрисдикции, санкционных ограничений и доступных каналов поставок. По нашему опыту, в первую очередь мигрируют простые контуры. Осталась самая тяжелая база — нагруженные СУБД, монолитные приложения и системы с жесткими требованиями к времени простоя. Именно эти нагрузки составляют основной объем оставшейся работы по миграции.
Замена VMware в крупном бизнесе — это пересборка трех слоев инфраструктуры: регламентов и инструментов резервного копирования под KVM-стек, программно-определяемых сетей (SDN) и логики взаимодействия с СХД. Каждый из них тянет за собой пересмотр эксплуатационных практик, а не просто замену продукта. Дополнительный триггер для тех, кто до сих пор оставался на VMware, — изменения в лицензировании после сделки с Broadcom: переход на подписную модель и укрупнение пакетов оцениваются многими компаниями как экономически нецелесообразные даже для организаций, которых напрямую не коснулись санкционные ограничения.
Переход почти никогда не происходит одномоментно. На практике инфраструктура надолго застревает в гетерогенном состоянии: унаследованные контуры на VMware продолжают обслуживать критичные сервисы, рядом поднимаются новые кластеры на KVM, часть нагрузок уезжает в частное или публичное облако. Эта смешанная среда стала рабочей реальностью на весь срок миграции. И именно в ней резко усложняется главная задача — сохранить непрерывность бизнеса, когда разные части инфраструктуры живут на несовместимых платформах.
Высокая доступность и катастрофоустойчивость
Обеспечение непрерывности бизнеса требует разделения понятий высокой доступности (High Availability, HA) и катастрофоустойчивости (Disaster Recovery, DR).
Механизмы высокой доступности отрабатывают локальные сбои: при отказе физического узла гипервизор автоматически перезапускает ВМ на оставшихся хостах кластера. В этом случае RTO (Recovery Time Objective) включает в себя обнаружение сбоя, таймауты и изоляцию узла, решение кворума, запуск ВМ, загрузку гостевой ОС и восстановление приложения. Значение 2–5 минут является лишь ориентиром, который требует уточнения по результатам замеров в конкретной инфраструктуре.
Катастрофоустойчивость (DR) — это защита от потери целого ЦОД. В однородной среде (VMware to VMware) репликация обычно требует использования отдельных продуктов и лицензий из экосистемы VMware (например, vSphere Replication или Site Recovery). При переходе на новую платформу возникает задача кросс-платформенного DR: как поддерживать на резервной площадке готовую к запуску реплику работающей ВМ, если целевой гипервизор — другой. За этой задачей стоит цепочка несовместимостей: разные форматы дисков (хотя KVM способен читать VMDK в ряде сценариев, поэтому конвертация не всегда обязательна), паравиртуальные драйверы VMware вместо ожидаемых KVM VirtIO-драйверы, а также загрузчик, сетевая конфигурация, initramfs, привязанные к исходному гипервизору. Конвертация формата здесь — только входной этап; сервис не поднимется на резервной площадке, пока в гостевую систему не внедрены нужные драйверы и не пересобрано окружение под целевую платформу.
Такие задачи закрывают специализированные инструменты кросс-платформенной репликации. Один из них — Хайстекс Акура: решение интегрируется на уровень гипервизоров и ведет фоновую репликацию на уровне блоков (block-level) без простоя критичных сервисов. При переносе оно предоставляет оркеструемые функции трансляции форматов дисков, внедрения VirtIO-драйверов, пересборки загрузчика и сетевой топологии на резервной площадке. Возможность выполнения этих операций и их успешность зависят от совместимости с конкретной гостевой ОС, целевой KVM-платформой, настроек Secure Boot, типа RAID и других факторов среды. Успешность применения данных механизмов необходимо проверять по матрице поддерживаемых конфигураций и версий ОС, а сам продукт выступает как инструмент автоматизации в рамках заданных технических ограничений. Это позволяет держать на резерве консистентную копию инфраструктуры с минимальными RPO (Recovery Point Objective) и RTO (Recovery Time Objective) даже в разнородной среде — и сохранять данные на всем протяжении поэтапной миграции.
Что определяет успех перехода
Переподписка ресурсов, топология vNUMA, сходимость живой миграции, разграничение HA и DR — за каждым из этих механизмов стоит архитектура платформы и ее настройка. От них зависят предельная нагрузка, предсказуемость отклика и поведение сервисов при отказе оборудования. Эти границы платформа задает для всех рабочих нагрузок и прикладных систем, функционирующих в виртуальной среде.
Переход с западных проприетарных систем на решения на базе KVM требует от инженерных команд пересмотра базовых практик — от проектирования дисковых подсистем и сети до процессов резервного копирования и отказоустойчивости.
Миграция корпоративных ЦОД проходит через этап гетерогенности, когда унаследованные контуры на VMware какое-то время работают параллельно с новыми отечественными платформами. На этом этапе основная задача — сохранить непрерывность сервисов и удержать параметры RPO и RTO на каждом шаге переноса.
Эту задачу закрывают специализированные инструменты автоматизации миграции и репликации. Решения класса Хайстекс Акура ведут фоновую репликацию данных и обеспечивают кросс-платформенное аварийное восстановление между гипервизорами. Продукт выступает как инструмент автоматизации миграционных процедур (таких как инъекция драйверов или настройка сети), успех которых определяется техническими ограничениями среды: совместимостью гостевой ОС, настройками Secure Boot и целевой платформой, что требует сверки с официальной матрицей поддерживаемых конфигураций.