Хост-машина в виртуализации: железо, технологии и оптимизация производительности

Вы поставили гипервизор, создали десяток виртуальных машин, раздали доступы — и первую неделю всё летает. Через месяц начинается: VM подвисают, IOPS просели, а мониторинг рисует красные графики на дашборде. Знакомо? В 90% случаев причина не в софте, а в том, что железо для виртуализации подбирали по принципу «и так сойдёт».

Хост-машина — это не абстракция. Это физический сервер, чьи ресурсы гипервизор нарезает между виртуальными машинами. Процессор, память, диски, сетевые карты — всё это делится между гостями, и если сервер собран без учёта специфики виртуализации, никакие настройки ядра ситуацию не выправят. Гипервизор работает с тем, что ему дали. И если дали мало — он честно разделит это «мало» между всеми VM.

Зачем нужна аппаратная виртуализация

До появления аппаратного ускорения гипервизоры эмулировали процессорные инструкции программно. Это работало, но с двукратным (а то и пятикратным) падением производительности. Потом Intel выпустили VT-x, AMD ответили AMD-V — и правила изменились. Аппаратная виртуализация позволяет гипервизору выполнять код гостевых ОС напрямую на процессоре, без промежуточной трансляции.

Результат — производительность виртуальных машин достигает 85–95% от bare metal. А на некоторых веб-нагрузках бенчмарки показывают 113–129% от «голого железа» — за счёт оптимизаций планировщика и кэширования на уровне гипервизора.

Для Type-1 гипервизоров (ESXi, Proxmox VE, Hyper-V Server) аппаратное ускорение — обязательное требование. Без VT-x/AMD-V вы ограничены софтверной эмуляцией, а это потолок в 2–3 VM на хост с приемлемой латентностью. Type-2 гипервизоры (VirtualBox, VMware Workstation) работают поверх обычной ОС — для тестовых стендов сгодятся, для продакшена — нет.

Разница принципиальная: Type-1 получает прямой доступ к железу через VT-x/AMD-V и управляет им без посредников. Type-2 зависит от хостовой ОС — каждый системный вызов проходит через дополнительный слой, и этот слой стоит производительности. Поэтому, когда речь идёт о хосте для 8–15 виртуальных машин в продакшене, выбор гипервизора очевиден — «голый металл» и Type-1.

Отдельная тема — nested virtualization, запуск гипервизора внутри VM. Полезно для обучения, тестирования и CI/CD-пайплайнов. Работает на Intel (VT-x + VMCS shadowing) и AMD (NPT), но с ощутимым падением производительности — 20–40% overhead. Для продакшен-нагрузок вложенная виртуализация не подходит, но для dev-окружений экономит железо.

Процессор: ядра, потоки, nested paging

Выбор CPU для хоста — это не гонка за гигагерцами. Тут три параметра, которые решают всё.

Поддержка VT-x/AMD-V и EPT/NPT. Nested paging (EPT у Intel, NPT у AMD) — технология аппаратной трансляции адресов между гостевой и хостовой памятью. Без неё гипервизор тратит циклы на программный перевод адресов (shadow page tables), и overhead растёт с каждой VM. Ранние серверные Xeon плохо справлялись с этой задачей, но начиная с поколения Nehalem (Intel) и Opteron (AMD) ситуация выровнялась.

Количество ядер и Hyper-Threading. Каждая VM получает виртуальные ядра (vCPU), которые шедулер гипервизора маппит на физические. Hyper-Threading даёт прирост 15–30% на многопоточных нагрузках, но один HT-поток — это не полноценное ядро. Для хоста с 8–15 VM подходят процессоры от 16 физических ядер (Intel Xeon Scalable, AMD EPYC).

Выделение ядер хосту. Гипервизор тоже потребляет ресурсы. Proxmox и ESXi рекомендуют резервировать 1–2 ядра для хостовых процессов. Если отдать всё гостям, сам гипервизор начнёт «заикаться» при пиковых нагрузках.

Частая ошибка — overprovisioning vCPU. Администратор назначает каждой VM по 4–8 vCPU «с запасом», суммарно получается 60 vCPU на хосте с 32 физическими потоками. Шедулер вынужден ждать, пока все vCPU одной VM станут доступны одновременно — и латентность растёт у всех. Правило простое: суммарное количество vCPU не должно превышать физические потоки больше чем в 1,5–2 раза. Для баз данных и нагрузок с высоким CPU utilization — соотношение 1:1.

Ещё один нюанс — NUMA (Non-Uniform Memory Access). Если хост собран на двухсокетной платформе, каждый процессор имеет свой «ближний» банк памяти. VM, чьи vCPU размазаны по двум NUMA-нодам, получают штраф за доступ к удалённой памяти — до 20% деградации. Гипервизоры умеют привязывать VM к конкретной NUMA-ноде (CPU pinning, NUMA affinity), и для тяжёлых VM это стоит настроить вручную.

На веб-нагрузках VM могут обгонять bare metal на 13–29% благодаря оптимизациям гипервизора — кэшированию и планировке I/O.

Оперативная память: ECC, балунинг и дедупликация

RAM для виртуализации — это всегда «мало». Каждая VM съедает свой кусок, плюс гипервизор, плюс кэши, плюс резерв под снапшоты. Скупиться здесь — путь к свопу, а своп в виртуализации — это деградация для всех гостей сразу.

Минимальная планка для серьёзного хоста — 32 ГБ. Для Proxmox VE — 2 ГБ зарезервированы под сам гипервизор, плюс 1 ГБ на каждый терабайт ZFS-хранилища (ARC-кэш, без которого ZFS теряет смысл). В реальной эксплуатации хост с 4 ТБ ZFS-пула и десятком VM требует 64–128 ГБ.

ECC-память — не опция, а требование. Некорректированная ошибка в RAM может повредить данные сразу нескольким VM. В серверном сегменте ECC — стандарт, но если собираете хост на десктопной платформе (да, такое бывает), убедитесь, что контроллер памяти поддерживает ECC.

Технологии оптимизации памяти в виртуализации:

Все три механизма позволяют запускать VM, чья суммарная «выделенная» память превышает физическую RAM хоста. Это overcommit — рабочая стратегия, если вы понимаете паттерны нагрузки своих VM.

Хранилище: bottleneck, о котором забывают

Дисковая подсистема — узкое место виртуализации чаще, чем CPU или RAM. Десять VM, каждая пишет логи, обновляет базы, делает fsync — и вот IOPS закончились.

SSD/NVMe — стандарт для хоста. HDD допустимы только для холодного архива. NVMe-накопители с интерфейсом PCIe 4.0/5.0 дают 500 000–1 000 000+ IOPS на случайное чтение — это на два порядка выше, чем у SATA SSD (50 000–100 000 IOPS). Если бюджет позволяет, берите enterprise-накопители с защитой от потери питания (PLP — Power Loss Protection). Десктопные NVMe в серверном сценарии деградируют быстрее из-за постоянной записи.

Отдельный момент — размещение хранилища. Локальные диски проще и быстрее, но привязывают VM к конкретному хосту. Для кластера с live-миграцией нужно общее хранилище: SAN по iSCSI/FC, NFS-шара или распределённое хранилище типа Ceph. Каждый вариант — компромисс между скоростью, отказоустойчивостью и сложностью администрирования.

Выбор отказоустойчивости зависит от гипервизора и задач:

VirtIO SCSI — паравиртуализированный контроллер, который убирает эмуляцию IDE/AHCI и даёт VM почти нативный доступ к дискам. Включайте его для всех гостей с поддержкой VirtIO-драйверов (Linux из коробки, Windows — через ISO с драйверами от Red Hat).

Для борьбы с «шумными соседями» настраивайте лимиты IOPS и throughput на уровне гипервизора. В Proxmox это делается через параметры диска VM (mbps_rd, mbps_wr, iops_rd, iops_wr).

Сеть: два интерфейса — минимум

Одна сетевая карта на хосте — рецепт проблем. Управляющий трафик (SSH, веб-консоль), трафик VM и трафик хранилища (iSCSI, NFS, Ceph) конкурируют за один канал.

Рекомендация — два NIC и выше. Один для управления и трафика VM, второй — выделенный линк для хранилища. Proxmox VE прямо в документации указывает: 2+ сетевых интерфейса для разделения трафика.

Для СХД с сетевым доступом (iSCSI, NFS) 10GbE — уже не роскошь, а рабочая необходимость. Гигабитный линк даёт потолок ~120 МБ/с — этого мало для 10 VM с активным I/O. RDMA (Remote Direct Memory Access) на InfiniBand или RoCE снимает нагрузку с CPU при сетевых операциях, но требует соответствующих коммутаторов и адаптеров.

VLAN-ы и Linux bridges изолируют трафик разных VM и сегментов сети без физического разделения. На хосте с 15 VM из трёх разных подсетей VLAN — единственный адекватный способ не превращать сетевую конфигурацию в хаос.

Про безопасность: файрвол на уровне хоста — не роскошь. Proxmox предлагает встроенный pve-firewall с правилами для отдельных VM и кластера целиком. ESXi — distributed firewall в составе NSX. Минимальная гигиена — закрыть управляющие интерфейсы от гостевых сетей и ограничить доступ к API гипервизора по IP. Если злоумышленник получит доступ к хосту — он получит доступ ко всем VM разом.

Proxmox VE резервирует 1 ГБ RAM на каждый терабайт ZFS-хранилища. Хост с 10 ТБ ZFS-пулом «съест» 12+ ГБ только на гипервизор и кэш.

Мониторинг, HA и live-миграция

Запустить VM — полдела. Удержать инфраструктуру в рабочем состоянии при отказе ноды — задача поинтереснее.

DRS (Distributed Resource Scheduler) в VMware vSphere автоматически балансирует VM между хостами кластера. Если одна нода загружена на 90%, а соседняя — на 30%, DRS мигрирует VM без участия администратора. Аналоги в Proxmox — HA-менеджер с ручными правилами и приоритетами.

Live-миграция (vMotion у VMware, qm migrate в Proxmox) — перенос работающей VM на другой хост без остановки. Работает за счёт итеративного копирования памяти: сначала передаётся основной объём, потом «грязные» страницы, изменившиеся за время копирования. Условие — общее хранилище (shared storage) или репликация дисков между хостами. Для миграции между хостами с разными поколениями CPU используется EVC (Enhanced vMotion Compatibility), которая маскирует наборы инструкций до общего знаменателя.

Снапшоты — быстрый способ зафиксировать состояние VM перед обновлением или экспериментом. Не замена полноценному бэкапу (снапшот хранится на том же хранилище, что и VM), но спасает от неудачного apt upgrade. У снапшотов есть подводный камень: каждый активный снапшот создаёт дельта-файл, и I/O на запись проходит через цепочку таких дельт. Чем длиннее цепочка — тем выше нагрузка на хранилище. Удаляйте ненужные снапшоты в течение суток, не накапливайте их «на всякий случай».

Пара практических рекомендаций: выставляйте power management на хосте в режим «High Performance» — энергосбережение и виртуализация плохо дружат, C-states увеличивают латентность при выходе из простоя. И настройте мониторинг: CPU ready time, memory ballooning, disk latency — три метрики, по которым вы поймёте, что хосту плохо, раньше, чем это почувствуют пользователи.

CPU ready time особенно показателен: если VM ждёт физических ядер дольше 5% времени — у вас overprovisioning по vCPU. Disk latency выше 20 мс на NVMe — сигнал, что хранилище не справляется. Memory ballooning в активной фазе (драйвер забирает память у гостя) — значит, хост исчерпал RAM и пора либо добавлять модули, либо мигрировать часть VM.

Инструменты: esxtop для ESXi, pvesh и rrdtool в Proxmox, Zabbix или Prometheus/Grafana для унифицированного мониторинга нескольких хостов. Отдельно стоит настроить алерты на температуру CPU и состояние RAID/ZFS — деградация массива под нагрузкой виртуализации ускоряет выход дисков из строя.

Как не промахнуться с выбором

Виртуализация прощает ошибки конфигурации, но не прощает ошибки в выборе железа. Процессор без EPT, память без ECC, один гигабитный NIC — каждый из этих компромиссов превращается в проблему, которая проявится ровно тогда, когда нагрузка вырастет. А она вырастет.

Подбирайте железо для виртуализации с запасом по RAM (расширить потом проще, чем мигрировать на новый хост), с NVMe-хранилищем для основных VM и с раздельными сетевыми интерфейсами. Проверяйте поддержку IOMMU, если планируете пробрасывать устройства в VM (GPU passthrough, SR-IOV для сетевых карт). И тестируйте нагрузку до продакшена — бенчмарки fio, stress-ng, iperf3 покажут реальные пределы хоста до того, как это сделают пользователи.

Примерный ориентир по минимальному комплекту для хоста виртуализации на 10–15 VM:

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