Архитектура KVM (Kernel-based Virtual Machine)

KVM является уникальным решением в мире виртуализации. В отличие от ESXi, который представляет собой отдельную специализированную ОС, KVM — это модуль, встроенный прямо в ядро стандартной ОС Linux. Превращение обычного Linux-сервера в гипервизор 1-го типа происходит простой загрузкой модуля ядра (kvm.ko). Это означает, что KVM наследует все преимущества Linux: поддержку огромного парка оборудования, продвинутое управление памятью и планировщик процессов.

С архитектурной точки зрения каждая виртуальная машина в KVM представляет собой обычный процесс (процесс Linux) в операционной системе хоста. А каждый виртуальный процессор (vCPU) виртуальной машины — это отдельный поток (thread) внутри этого процесса. За эмуляцию аппаратного обеспечения (сетевых карт, дисковых контроллеров, видеокарт) для виртуальной машины отвечает пользовательская утилита QEMU. Поэтому связку часто называют QEMU/KVM.

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

Распределение vCPU и проблема Steal Time

Мы уже обсуждали понятие оверкомиттинга (переподписки) ресурсов. В KVM выделение виртуальных процессоров (vCPU) больше, чем физических ядер (pCPU), является нормальной практикой. Коэффициент переподписки зависит от типа нагрузки: для VDI (виртуальных рабочих столов) он может составлять 4:1 (4 vCPU на 1 физическое ядро), для обычных серверов — 2:1, а для высоконагруженных баз данных строго 1:1.

Но что происходит, когда администратор допускает ошибку и создает слишком сильный оверкомит? Начинается эффект «Шумного соседа» (Noisy Neighbor). Несколько виртуальных машин одновременно пытаются выполнить ресурсоемкие задачи. Планировщик Linux CFS не может мгновенно предоставить физическое ядро всем желающим потокам vCPU. В результате виртуальная машина вынуждена «ждать» в очереди, пока гипервизор выделит ей физическое процессорное время.

Для диагностики этой проблемы внутри гостевой ОС Linux (внутри виртуальной машины) используется метрика Steal Time (st). Если вы зайдете в ВМ по SSH и запустите утилиту top, в строке состояния процессора вы увидите параметр %st (например, 15.0 st). Steal Time — это процент времени, которое виртуальный процессор хотел работать, но не мог, потому что гипервизор «украл» (steal) у него это время для обслуживания других виртуальных машин на том же физическом сервере. Если Steal Time стабильно превышает 5-10%, это критический инцидент: сервер перегружен, и необходимо либо мигрировать часть ВМ на другой узел кластера, либо физически добавлять процессоры.

Управление памятью в KVM и защита хоста (OOM Killer)

При распределении оперативной памяти в KVM необходимо помнить о критически важном правиле: Никогда не отдавайте 100% физической RAM виртуальным машинам. Гипервизор KVM — это ОС Linux, которой тоже нужна память для работы ядра, сетевого стека, файловой системы (особенно если используется ZFS, чей кэш ARC очень прожорлив) и процессов управления.

Если администратор выделит виртуальным машинам всю доступную память, и они начнут ее активно использовать, физическая память сервера (хоста) исчерпается. В этот момент ядро Linux активирует механизм защиты последней надежды — OOM Killer (Out Of Memory Killer). OOM Killer начинает сканировать все запущенные процессы и принудительно убивать (отправлять сигнал SIGKILL) те из них, которые потребляют больше всего памяти. Так как виртуальные машины в KVM — это просто процессы (qemu-system-x86_64), OOM Killer безжалостно завершит их работу. Для пользователя это выглядит как внезапное жесткое выключение сервера по питанию, что может привести к разрушению баз данных.

Правило хорошего тона (Best Practice): На хост-систему (гипервизор) всегда необходимо резервировать минимум 4-8 ГБ оперативной памяти (в зависимости от общего объема RAM и используемой файловой системы). В Proxmox и других системах на базе KVM это настраивается путем ограничения максимального пула выделяемой памяти, оставляя «запас прочности» для стабильной работы самого гипервизора.