> For the complete documentation index, see [llms.txt](https://kb.pvhostvm.ru/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://kb.pvhostvm.ru/hostvm-server/rukovodstvo-po-administrirovaniyu/vychislitelnaya-infrastruktura/klastery/rukovodstvo-po-upravleniyu-perepodpiskoi-vcpu-i-planirovaniyu-klasterov.md).

# Руководство по управлению переподпиской vCPU и планированию кластеров

В отличие от VMware ESXi, подход к планированию ресурсов процессора в KVM имеет свои особенности, которые необходимо учитывать для обеспечения стабильной работы критически важных приложений. Особое внимание уделено политике переподписки vCPU, интерпретации метрик загрузки и стратегии разделения нагрузок по кластерам.

### Переподписка vCPU: почему KVM и VMware работают по-разному

Переподписка процессора (CPU overcommit) — механизм виртуализации, позволяющий выделять виртуальным машинам больше vCPU, чем имеется физических ядер на хосте. Это делается для повышения плотности размещения ВМ и эффективного использования ресурсов, но требует осторожности.

Если в VMware ESXi переподписка 3,9:1 может работать стабильно для смешанных нагрузок, в KVM (и, следовательно, HOSTVM) такая практика без разделения нагрузок приводит к проблемам с производительностью. Корень различий кроется в алгоритмах планировщиков:

* VMware ESXi использует VMkernel с механизмом co-scheduling. Он может приостанавливать менее приоритетные vCPU и агрессивно управлять координацией vCPU внутри ВМ, что позволяет выдерживать более высокий коэффициент переподписки в смешанных средах.
* KVM (и HOSTVM) опирается на планировщика Linux Completely Fair Scheduler (CFS). В CFS каждое vCPU представлено процессом или потоком ядра, и планировщик стремится одинаково распределять процессорное время между всеми потоками. При высоком overcommit CFS вынужден часто переключать контекст между большим числом vCPU. Это увеличивает накладные расходы на планирование и приводит к ожиданиям в очереди на физическое ядро.  Внешне хост может показывать умеренную загрузку (например, 20–30%), но внутри гостевой ОС наблюдаются «зависания» или задержки из-за длительного ожидания получения слотов CPU. Планировщик тратит время на активное перераспределение ресурсов между ВМ, что и создает иллюзию низкой загрузки при высокой конкуренции за CPU.

Проблема чаще связана не с физической загруженностью процессора, а с поведением планировщика и конкуренцией потоков. Хотя в Linux есть механизмы контроля квот и приоритетов (cgroups, CPU shares, CPU quotas), они не заменяют грамотного архитектурного разделения нагрузок.

### Метрики использования CPU в HOSTVM

HOSTVM рассчитывает загрузку CPU через соотношение потреблённой частоты к общей доступной частоте узла. Процентная метрика ВМ отражает долю выделенного ей времени, а не долю всего хоста.

Избыточное выделение vCPU, не соответствующее реальной потребности ВМ, создает лишнюю нагрузку на планировщика хоста. Если нагрузка на ВМ составляет менее 20-30%, возможно, ей выделено слишком много ядер, что создает дополнительные накладные расходы.

### Стратегия разделения нагрузок по кластерам

Главная архитектурная рекомендация для HOSTVM — не смешивать разные типы нагрузок в одном кластере. Смешение серверных приложений с равномерным потреблением CPU и VDI/тестовых сред c импульсным характером потребления ресурсов заставляет планировщик постоянно переключаться между потоками, увеличивая время ожидания CPU для всех ВМ. Это правило актуально для всех производителей, включая VMware и Citrix, но для KVM оно критично.

Рекомендуется разделять ВМ по профилям на отдельные кластеры:

1. Кластер А - серверные нагрузки: для критичных приложений (SQL, 1С, Exchange, файловые серверы). Рекомендуемый коэффициент переподписки — от 1:1 до 2:1. Для баз данных (SQL/1С) строго рекомендуется 1:1, чтобы избежать задержек при интенсивной работе с памятью и дисками.
2. Кластер Б - VDI/RDS-фермы: для виртуальных рабочих столов и терминальных серверов. На одну ВМ рекомендуется выделять 1-2 vCPU. Допустимый коэффициент переподписки — 4:1, 6:1 и выше. Это позволяет эффективно утилизировать ресурсы, так как нагрузка на рабочих столах обычно пиковая и непостоянная.
3. Кластер В - инфраструктурный: для AD, DNS, брокеров, систем лицензирования. Рекомендуемый коэффициент — 1:1 – 2:1, с обязательным резервом физических мощностей (не менее 20%), так как важно доступность и предсказуемость.

Такое разделение позволяет изолировать проблемы производительности VDI от бизнес-критичных приложений. Важно отметить, что симптомы переподписки зачастую не видны в стандартных системах мониторинга, поэтому упреждающее проектирование кластеров является ключевым условием стабильности.

### Настройка политик кластера в HOSTVM

HOSTVM управляет балансировкой и переподпиской на уровне кластера через политики. Ниже перечислены типичные политики и рекомендации по их использованию.

Балансировочные политики:

* none: балансировка отключена. Рекомендуется для изолированных или специальных сред, где важна предсказуемость ручного управления.
* evenly\_distributed: равномерно распределяет ВМ по хостам, не допуская перегрузки отдельных узлов.  Позволяет задать порог CPU (по умолчанию 80%) — при превышении запускается миграция. Рекомендуется для серверных кластеров с умеренной переподпиской.
* power\_saving: концентрирует ВМ на минимуме хостов, выключая неиспользуемые в непиковые часы. Подходит для сред с сильными периодами простоя, таких как тестовые и часть VDI.
* vm\_evenly\_distributed: распределяет по количеству ВМ на хост, а не по CPU. Имеет параметры HighVmCount и MigrationThreshold. Подходит для VDI, где важен предел числа ВМ на хосте.

Политики миграции:

* Minimal downtime (минимальное время простоя): оптимально для критичных сервисов — минимизирует недоступность при миграции.
* Suspend workload if needed (приостановить ВМ при необходимости): используется для очень нагруженных ВМ, где живая миграция может не завершиться быстро; допускает короткую паузу в работе ВМ для успешной миграции.

Настройка этих политик позволяет автоматизировать управление ресурсами в соответствии с выбранной стратегией для каждого кластера.

### Заключение

Успешная эксплуатация платформы HOSTVM требует понимания фундаментальных различий в планировании ресурсов между KVM и VMware. Основные выводы:

1. Рекомендованный коэффициент переподписки 2:1 — архитектурная рекомендация, а не жесткое ограничение, позволяющая избежать проблем с производительностью.
2. Причина многих проблем в KVM — поведение планировщика CFS: при сильном overcommit он активно управляет очередями и вызывает «зависания» внутри ВМ при низкой видимой загрузке хоста.
3. Разделяйте нагрузки по кластерам: выделите отдельные кластеры для серверных приложений (1:1 – 2:1), для VDI (4:1 и выше) и для инфраструктурных служб (1:1 – 2:1 с резервом).
4. Используйте встроенные политики балансировки HOSTVM (evenly\_distributed, power\_saving, vm\_evenly\_distributed) для автоматического поддержания заданного уровня производительности.
5. Настройте мониторинг на уровне runqueue, scheduler latency и percentiles загрузки, чтобы обнаруживать проблемы на ранней стадии.

Своевременное внедрение предложенного распределения позволит исключить сценарии, при которых пользователи VDI могут сталкиваться с задержками интерфейса, а бизнес-приложения — с непредсказуемыми замедлениями.