Как посчитать, сколько виртуалок влезет на сервер

MAATRIX

Вопрос «сколько виртуалок влезет на этот сервер» звучит просто, но частый ответ «поделим RAM на объём одной VM» — это только треть расчёта, причём не всегда самая узкая. Реальный лимит определяется тремя ресурсами по отдельности — памятью, процессором и диском, — и итоговое число VM равно минимуму из трёх, а не среднему и не сумме. Ниже — рабочая методика, как считать каждый ресурс и что с этим расчётом делать на практике.

Почему нельзя просто поделить RAM на объём VM

Первое, что приходит в голову: взять 128 ГБ хоста, поделить на 8 ГБ на VM — получить 16 машин. Это работает как первое приближение, но у него есть два слепых пятна.

Первое — вы забыли резерв для самого гипервизора. Proxmox, VMware ESXi, любой KVM-хост тратит память на себя: процессы гипервизора, кэш, буферы ввода-вывода, а на ZFS-хостах ещё и ARC-кэш, который может съедать десятки гигабайт по умолчанию. Если не вычесть этот резерв заранее, машины будут падать по OOM в самый неподходящий момент — обычно ночью, когда админа рядом нет.

Второе — вы посчитали только память, а забыли про CPU и диск. Хост с щедрой памятью, но с четырьмя ядрами процессора, физически не потянет 30 виртуалок с нагрузкой хотя бы средней интенсивности, даже если памяти формально хватает на все тридцать. Три ресурса считаются отдельно, и берётся самый тесный.

Дальше — по порядку: память, процессор, диск, а затем — как свести это в одно число и не попасть в типичную ловушку планирования «впритык».

Расчёт по памяти: самый простой из трёх

Формула на первый взгляд действительно линейная:

Доступно VM = Общая RAM хоста − Резерв хоста
Число VM по памяти = Доступно VM / RAM на одну VM

Резерв хоста — это не «сколько-то мегабайт», а конкретная сумма нескольких статей:

• Гипервизор и ОС хоста. Для Proxmox на голом Debian закладывайте от 2 до 4 ГБ на типичный хост, больше — если крутится веб-интерфейс панели, кластерные службы (corosync, pmxcfs), мониторинг.
• ZFS ARC, если хранилище на ZFS. По умолчанию ARC может занять до половины RAM хоста — это не утечка, а сознательный кэш чтения, но его нужно либо ограничить параметром zfs_arc_max, либо честно вычесть из расчёта.
• Буфер на всплески. Даже без оверкоммита оставляйте 5-10% от общего объёма памяти как амортизатор — миграции VM между узлами, снапшоты, резервное копирование потребляют память сверх обычного.

Пример: хост на 256 ГБ RAM, резерв под гипервизор и ZFS ARC — 32 ГБ, буфер — 16 ГБ. Остаётся 208 ГБ. Если каждая VM получает по 8 ГБ — это 26 машин по памяти. Если по 16 ГБ — 13 машин.

Отдельно стоит оверкоммит памяти — техника, когда VM суммарно выделяется больше памяти, чем физически есть на хосте, в расчёте на то, что не все машины используют выделенный объём на 100% одновременно. Гипервизоры поддерживают это по-разному: у KVM/Proxmox есть механизмы вроде balloon-driver и KSM (Kernel Samepage Merging, дедупликация одинаковых страниц памяти между VM), у VMware — Transparent Page Sharing и подобные техники. Работает это неплохо для однотипных лёгких VM (много одинаковых Linux-контейнеров с похожим ПО), но плохо для баз данных и других процессов, которые агрессивно используют весь выделенный объём — там оверкоммит быстро упирается в своп хоста и деградацию отклика у всех машин разом. Если хотите разобраться в этом отдельно и осознанно применять — это тема для отдельного расчёта, а не строчка «на всякий случай» в конфиге.

Для базового планирования на новом сервере разумно вообще не закладывать оверкоммит по памяти — переходите к нему только когда увидите реальную статистику использования RAM на уже работающих VM.

Расчёт по CPU: почему тут всё иначе, чем с памятью

Память — ресурс, который либо занят, либо свободен: гигабайт нельзя временно одолжить у соседней VM без остановки процессов. Процессорное время устроено иначе — оно естественным образом делится по времени между VM планировщиком гипервизора (в KVM это делает планировщик ядра Linux CFS/EEVDF применительно к vCPU-потокам). Поэтому у CPU есть понятие, которого нет у RAM в чистом виде: нормальный, ожидаемый оверкоммит по умолчанию.

Общее число виртуальных ядер (vCPU), выделенных всем VM суммарно, почти всегда превышает число физических ядер (точнее — потоков, если считать с Hyper-Threading/SMT) хоста, и это не ошибка планирования, а стандартная практика. Логика та же, что у авиакомпаний с овербукингом: не все пассажиры приходят на рейс одновременно, не все VM грузят CPU на 100% одновременно.

Практические коэффициенты (условные ориентиры, не измеренные бенчмарком — у вас будет иначе в зависимости от профиля нагрузки):

Формула по CPU выглядит так:

Число VM по CPU = (Физические ядра хоста × Коэффициент оверкоммита) / vCPU на одну VM

Пример: хост на 32 физических ядра, коэффициент 3:1 для смешанной нагрузки — это 96 «виртуальных» ядер в пуле. Если каждая VM получает 4 vCPU — это 24 машины по процессору.

Важно понимать последствия: при полной одновременной нагрузке всех VM производительность каждой пропорционально снизится — гипервизор не создаёт вычислительную мощность из ничего, он лишь размазывает существующую по времени между претендентами. Если 24 машины с 4 vCPU каждая одновременно упрутся в 100% CPU, каждая реально получит долю от 96 виртуальных ядер, поделённых на актуальный спрос — то есть заметно меньше заявленных 4 ядер производительности. Это нормально для случайных пиков, но недопустимо, если у вас SLA на отклик под постоянной высокой нагрузкой у всех клиентов разом. Подробнее о том, где именно и почему виртуализация теряет производительность на CPU и вводе-выводе, разобрано в статье про потери производительности при виртуализации.

Расчёт по диску: прямая арифметика плюс thin-provisioning

Дисковое пространство считается проще всего, без сюрпризов с разделением по времени:

Доступно под VM = Общий объём хранилища − Резерв (снапшоты, бэкапы, служебное)
Число VM по диску = Доступно под VM / диск на одну VM

Резерв под хранилище обычно включает:

• Место под снапшоты — если делаете снапшоты перед обновлениями, закладывайте минимум 10-20% свободного места сверх занятого VM, иначе снапшот не создастся или переполнит том.
• Локальные бэкапы, если они хранятся на том же хосте (для vzdump в Proxmox это отдельный том или тот же пул — уточните, куда падает архив).
• Файловую систему и метаданные — на ZFS и Btrfs реальный полезный объём меньше номинального объёма дисков из-за служебных структур и (если используете) избыточности RAID/RAIDZ.

Плюс к этому — thin-provisioning (тонкое выделение места): диски VM создаются с номинальным размером (скажем, 100 ГБ), но физически на хранилище занимают только реально записанные данные, пока файловая система VM не заполнится под завязку. Это позволяет «обещать» VM суммарно больше места, чем реально есть на хранилище, аналогично оверкоммиту по памяти. Riск тот же: если много VM одновременно начнут активно писать данные, физическое хранилище может закончиться раньше, чем ожидалось по номинальным размерам дисков, — и тогда упадут уже все VM на этом томе, а не только та, что переполнилась. Какой тип хранилища в Proxmox поддерживает thin-provisioning, а какой — нет (LVM-thin, ZFS, директория с qcow2 ведут себя по-разному), разобрано в статье про типы хранилищ Proxmox.

Практический совет: если используете thin-provisioning, обязательно настройте мониторинг реального заполнения физического пула, а не только номинального объёма выданных дисков — иначе о нехватке места узнаете уже по алертам о падении VM.

Как свести три расчёта в одно число

Правило простое: реальное число VM на хосте равно минимуму из трёх посчитанных лимитов — по памяти, по CPU и по диску, а не их среднему значению и не сумме.

Возвращаясь к примерам выше:

Итог — 24 виртуалки, потому что процессор оказался самым узким местом, хотя по памяти и диску запас ещё был. Если бы каждой VM выделили не 4, а 2 vCPU, лимит по CPU сдвинулся бы до 48 машин — и узким местом стала бы уже память с её 26 машинами.

Отсюда практический вывод: чтобы выжать максимум VM из конкретного хоста, выгоднее подгонять профиль ресурсов каждой VM под тот ресурс хоста, которого больше всего в избытке, а не выделять всем одинаковый шаблон «на глаз». Для типичных общих нагрузок (панели, боты, небольшие сайты, тестовые окружения) чаще всего узким местом оказывается именно память — люди щедро выделяют RAM «с запасом», а CPU и диск просят скромнее. Но для CPU-интенсивных профилей (рендеринг, кодирование, сборки CI, инференс моделей) узким местом почти всегда становится процессор, и тут расчёт по памяти вообще может быть не главным. Присмотритесь к статье про расчёт конфигурации сервера под конкретную нагрузку — там разобрано, как профилировать саму нагрузку до того, как считать вместимость хоста.

Практика: не планировать впритык

Даже когда расчёт по всем трём ресурсам сходится красиво, оставлять систему на 100% загруженной по всем фронтам одновременно — плохая идея. Причины простые и проверены на практике:

• Реальная нагрузка колеблется. Расчёт на основе средних показателей систематически недооценивает пики — обновление ОС внутри нескольких VM одновременно, резервное копирование по расписанию, скачок трафика на одном из сайтов легко создают одновременный спрос выше плановой отметки.
• Нужен буфер на аварийное восстановление. Если один узел кластера Proxmox выйдет из строя, а VM с него должны мигрировать на оставшиеся хосты (или вы просто разворачиваете временную VM для диагностики) — без запаса мигрировать будет некуда.
• Обновления и обслуживание тоже требуют ресурсов. Установка патчей на гипервизор, ребилд RAID-массива после замены диска, ресинк ZFS — всё это временно ест CPU, память и I/O сверх обычного профиля.

Разумный ориентир — планировать так, чтобы при типичной (не пиковой) нагрузке все три ресурса были загружены не более чем на 70-80%, оставляя 20-30% на пики и аварийные ситуации. Это не строгий стандарт, а практика, проверенная на количестве инцидентов «сервер лёг в пятницу вечером» — у вас цифра может быть иной в зависимости от того, насколько предсказуема ваша нагрузка и насколько быстро вы готовы реагировать на алерты. О том, сколько запаса закладывать конкретно по оперативной памяти на растущем проекте, отдельно разобрано в статье про запас по оперативной памяти.

Чек-лист перед покупкой или апгрейдом сервера

Собранная методика в виде последовательности шагов:

1. Зафиксируйте профиль типичной VM в вашем парке — сколько RAM, vCPU и диска реально просят, а не «с запасом».
2. Посчитайте резерв хоста отдельно для памяти (гипервизор, ZFS ARC, буфер) и для диска (снапшоты, бэкапы, служебные данные).
3. Рассчитайте лимит по памяти без оверкоммита — это ваш безопасный базовый уровень.
4. Оцените коэффициент оверкоммита CPU исходя из реального профиля нагрузки (легкие VM — выше, тяжёлые — ниже) и посчитайте лимит по процессору.
5. Посчитайте лимит по диску, отдельно отметив, включён ли thin-provisioning и настроен ли мониторинг физического заполнения.
6. Возьмите минимум из трёх чисел — это реалистичная вместимость хоста.
7. Вычтите 20-30% как буфер на пики и аварийные ситуации — получите плановое число VM для повседневной эксплуатации.
8. Периодически пересчитывайте — профиль нагрузки VM меняется со временем, и то, что было «CPU-щедрым» хостом полгода назад, может стать узким местом сегодня.

Частые вопросы