Как рассчитать ресурсы сервера для виртуализации: vCPU, RAM, диски
2026-08-06 11:08
Сайзинг — это перевод списка будущих ВМ в конкретную конфигурацию железа: сколько ядер, памяти и каких дисков купить. Расчет ресурсов начинается не с прайс-листа, а с понимания нагрузок. Ошибка в любую сторону стоит денег: недобор оборачивается тормозами и срочной докупкой, перебор — замороженным бюджетом. Ниже — методика расчета по шагам и сквозной пример для кластера на 30 ВМ.
С чего начинается сайзинг: инвентаризация нагрузок
Составьте список будущих ВМ
Первый документ проекта — таблица будущего парка: роль, операционная система, требования приложения, ожидаемое число пользователей. Уже на этом шаге выясняется, что половину запросов можно уплотнить, а у пары систем требования к железу жестко прописаны вендором.
Разделите машины по критичности
Каждая виртуальная машина в списке получает класс: критичная для бизнеса, рабочая, вспомогательная. Класс определяет коэффициенты переподписки, место на быстром хранилище и очередность восстановления после аварии. Без этой разметки кластер считается «по максимуму» целиком — и выходит вдвое дороже.
Снимите реальные метрики
Если системы уже работают на старом железе или физических серверах, две-четыре недели учета нагрузки дадут честную картину: загрузку процессора, потребление ОЗУ, операции ввода-вывода. Паспортные требования из документации почти всегда завышены — вендор перестраховывается.
Считайте по пикам, а не по средним
Усредненные значения скрывают часы максимальной активности: утренний вход сотрудников, закрытие месяца в учетной системе, ночные выгрузки. Конфигурация, рассчитанная по средним цифрам, будет проседать ровно тогда, когда бизнесу нужнее всего.
Не пропустите скрытые зависимости
Учетная система тянет за собой СУБД, та — резервное копирование, а все вместе — службу каталога. Зависимости определяют, что обязано подняться первым после сбоя и какие сервисы нельзя селить на один узел. Эта карта пригодится и при миграции, и при настройке правил размещения.
Расчет процессора: коэффициенты переподписки vCPU
Виртуальных ядер всегда продается больше, чем есть физических, — машины редко нагружают процессор одновременно. Это похоже на абонементы в спортзал: проданных карт втрое больше, чем тренажеров, и конфликтов почти не бывает. Вопрос лишь в коэффициенте.
Какие коэффициенты брать
Коэффициенты переподписки vCPU по типам нагрузки
Тип нагрузки
vCPU на физическое ядро
Комментарий
СУБД, 1С, ERP
1:1 — 1:2
Постоянно нагружают процессор, переподписку почти не терпят
Корпоративные приложения, веб
1:3 — 1:5
Рабочая классика для смешанного офисного пула
Тестовые среды, разработка
1:6 — 1:8
Простаивают большую часть времени
NUMA: не размазывайте тяжелую ВМ по сокетам
Процессор быстрее всего обращается к планкам собственного сокета. Если тяжелой системе выдать больше виртуальных ядер, чем есть в одном сокете, гипервизор разнесет ее через границу NUMA — и обращения через соседний сокет затормозят работу на 10-20%. Правило простое: держите ВМ в пределах сокета, а когда не помещается — выравнивайте по топологии узла.
GPU и проброшенные устройства
Видеокарта в виртуализации не переподписывается: проброшенный целиком GPU принадлежит одной ВМ, а технология vGPU делит его на фиксированные профили без уплотнения. Машины с проброшенными устройствами к тому же привязаны к своему узлу и выпадают из живой миграции — для них в кластере резервируют отдельный сценарий обслуживания.
Частота против числа ядер
Учетным системам и старым приложениям важнее скорость одного потока: процессор на 16 ядер с базовой частотой 3,5 ГГц обслужит 1С быстрее, чем 32-ядерный на 2,1 ГГц. Веб-фермам и аналитике, наоборот, выгоднее ядра числом. Смешанному пулу берут золотую середину — 16-24 ядра на сокет с частотой от 2,8 ГГц.
Лицензии тоже считаются по ядрам
Число ядер тянет за собой не только цену железа. Windows Server и большинство коммерческих СУБД лицензируются по физическим ядрам хоста, и разница между 32-ядерной и 16-ядерной конфигурацией в лицензиях порой превышает разницу в стоимости самих процессоров. Поэтому сайзинг сверяют с моделью лицензирования прикладного ПО: иногда дешевле взять меньше ядер с высокой частотой и закрыть ту же нагрузку.
Расчет памяти: почему RAM не переподписывают
Формула простая: сумма плюс резервы
В отличие от процессора, память либо есть, либо нет — ballooning спасает в аварии, но строить на нем план нельзя. Складываете аппетиты всех гостевых систем, добавляете 8-16 ГБ самому гипервизору и закладываете 20-25% на пики и новые ВМ.
Технические детали, которые забывают
Память обязана быть ECC — ошибки в неконтролируемых модулях ловятся слишком поздно. Планки расставляют по всем каналам CPU: пустые каналы режут пропускную способность на десятки процентов. И заранее смотрят потолок платформы, чтобы апгрейд не уперся в замену всего комплекта.
Расчет дисков: IOPS важнее терабайтов
Сложите операции ввода-вывода
Каждый гость генерирует поток операций: офисный сервис — десятки IOPS, нагруженная база — тысячи. Сумма и есть требование к массиву, причем с разбивкой на чтение и запись — у них разная цена.
Учтите RAID-штраф
Запись в массив с избыточностью обходится дороже одной операции: RAID 10 тратит две, RAID 5 — четыре, RAID 6 — шесть. Массив на 10 000 IOPS чтения при RAID 5 выдаст лишь 2 500 IOPS записи. Для смешанных нагрузок виртуализации практичный выбор — RAID 10 на SSD.
Разделите уровни хранения
Активные тома держат на NVMe или SSD, архивы и образы — на емких HDD. Если планируется внешняя система хранения данных, пропускную способность путей до нее считают вместе с дисками: быстрый массив за медленным линком бесполезен. Целевая латентность для СУБД — до 1-2 мс, для остального — до 5-10 мс.
Гиперконвергенция или внешний массив
Для площадок до десятка узлов гиперконвергентная схема — практичный выбор: быстрые накопители стоят в самих серверах, а репликация между узлами заменяет выделенную СХД. Это экономит стойко-место и упрощает закупку, но съедает часть процессора и сети на служебный трафик. Внешний массив выигрывает на крупных инсталляциях и там, где хранилище живет дольше вычислителей. Гибрид тоже законен: горячие тома локально, архивные — на массиве.
Емкость под резервные копии
Дисковую подсистему считают вместе с местом под копии — об этом забывают чаще всего. Практический ориентир: цепочка с месячной ретенцией занимает двух-трехкратный полезный объем. В нашем примере 12 ТБ данных потребуют 25-35 ТБ на отдельной емкости — и она не должна жить на том же массиве, что и боевые тома.
Сеть и отказоустойчивость кластера
Сеть: от 10GbE
Живая миграция, трафик хранилища и резервное копирование делят одни линки. Минимум для продакшена — 10GbE в два порта, для кластера из трех узлов и больше — 25GbE. Сети управления и данных разводят по разным интерфейсам.
Правило N+1
Кластер должен переживать отказ одного хоста: его гости перезапускаются на оставшихся. Отсюда главное следствие для сайзинга — рабочая загрузка каждого узла не выше 60-70%. Звучит как расточительность, но это цена непрерывности: заполненный под завязку кластер при аварии не поднимет и половины упавших сервисов.
Не забудьте про сеть резервного копирования
Ночные бэкапы гоняют терабайты, и если они идут по той же паре линков, что и трафик хранилища, утренние пользователи почувствуют это первыми. Для копирования выделяют отдельные порты или окно, не пересекающееся с нагрузкой. До внешней СХД настраивают multipath — два независимых пути на случай отказа коммутатора.
Сквозной пример: кластер под 30 виртуальных машин
Исходные данные
Компания консолидирует зоопарк из старых серверов: 30 ВМ — учетная система с СУБД, файловые и почтовые сервисы, веб-приложения, тестовый контур. По метрикам набегает 90 vCPU, 350 гигабайт ОЗУ и 9 000 IOPS при доле записи 30%.
Считаем процессор и память
Тяжелая база заберет 8 ядер без переподписки, остальные 82 vCPU при коэффициенте 1:4 уложатся в 21 физическое ядро. Итого 29 ядер — берем два узла по паре 16-ядерных CPU: 64 ядра суммарно, с запасом под N+1. По ОЗУ: 350 ГБ плюс гипервизоры и резерв — пара узлов по 512 ГБ закрывает задачу даже при отказе одного из них.
Считаем диски и проверяем отказоустойчивость
9 000 IOPS с 30% записи на RAID 10 превращаются в 11 700 операций на массив — шесть серверных NVMe справляются с многократным запасом. Финальная проверка: гасим в уме любой узел — выживший тянет все тридцать на 70% загрузки. План работает.
Спецификация по итогам примера
В закупку идут два двухпроцессорных узла 2U — например, YADRO VEGMAN R220 или Аквариус Т50 D212: по 32 ядра, 512 ГБ ECC и шесть NVMe в каждом, два порта 10GbE на узел под межузловой трафик. Внешняя СХД на старте не обязательна — локальные диски с репликацией закрывают объем, а массив добавится, когда парк перевалит за полсотни гостей.
Если бюджет жмет: что резать безопасно
Когда спецификация не влезает в смету, режут в правильном порядке: сначала переводят архивные тома на HDD, затем сужают тестовый контур, в последнюю очередь трогают резерв N+1. Процессоры и ОЗУ боевых систем не трогают вовсе — именно там живет производительность, ради которой все затевалось.
Частые ошибки сайзинга
Расчет по паспортным требованиям
Документация запрашивает максимум — так вендор страхует себя от жалоб. Реальные метрики обычно вдвое-втрое скромнее, и без их снятия площадка выходит дороже необходимого.
Переподписка памяти
Надежда на ballooning и дедупликацию заканчивается свопом и деградацией всего парка разом. Память считают честно, по сумме.
Забытые накладные расходы
Гипервизор ест свое, снапшоты плодят дельта-файлы, резервное копирование на ходу добавляет нагрузку на диски. Если эти статьи не учтены, «свободные» 20% емкости испаряются в первый квартал.
Кластер без запаса на рост
Площадка, заполненная на сто процентов в день запуска, потребует докупки через полгода. Закладывайте 20-30% свободных ресурсов и предел расширения по ОЗУ — рост числа ВМ редко идет по плану.
Что еще влияет на итоговую конфигурацию
Методика выше покрывает арифметику, но финальное решение зависит от контекста. Требования к простою диктуют глубину резервирования: где-то хватит N+1, где-то нужен растянутый кластер на две площадки. Тип сервера виртуализации подбирается под выбранную платформу — zVirt, Proxmox VE или Базис.DynamiX предъявляют схожие, но не идентичные требования. И всегда полезен взгляд на 2-3 года вперед: мониторинг покажет реальное потребление, но потолок масштабирования закладывается при покупке.
Запуск и проверка плана
Сайзинг не заканчивается покупкой. Первый месяц мониторинг сверяет прогноз с фактом: какие машины переели, какие простаивают, где всплески ввода-вывода. По итогам коэффициенты переподписки подкручивают — это нормальная часть процесса, а не ошибка проектирования. Пересматривать сайзинг целиком стоит при росте парка на треть или при появлении новой тяжелой системы.
Три счетчика ловят девять из десяти проблем сайзинга. CPU ready выше 5% — гость подолгу ждет физическое ядро, переподписка велика. Любой своп гипервизора — сигнал немедленно добавлять ОЗУ. Латентность томов выше целевой — пора разбираться с массивом или соседями по нему.
Рассчитаем кластер под ваш список ВМ
Пришлите перечень планируемых машин или доступ к метрикам — мы переведем их в конфигурацию: ядра, память, хранилище, сеть. Подберем серверы под виртуализацию с честным резервом N+1 и запасом под рост, чтобы докупка не понадобилась через полгода. Оставьте заявку — расчет пришлем с обоснованием каждой цифры, для вас он бесплатный.
Часто задаваемые вопросы (FAQ)
Сколько vCPU можно разместить на одном физическом ядре?
Для СУБД — одно-два, для офисных приложений — три-пять, для тестовых сред — до восьми. Точный коэффициент подтверждают метриками после запуска.
Можно ли переподписывать оперативную память?
В продакшене — нет. Аварийные механизмы гипервизора не заменяют честный расчет: своп убивает производительность всех машин сразу.
Как посчитать IOPS для виртуальных машин?
Снять счетчики операций со всех существующих систем за две-четыре недели, взять пиковые значения и просуммировать с разбивкой чтение/запись. К записи применить RAID-штраф выбранного уровня массива.
Что такое RAID-штраф?
Число внутренних операций массива на одну входящую запись: две у зеркала, четыре у пятого уровня, шесть у шестого. Чтения это не касается.
Сколько ОЗУ оставлять гипервизору?
8-16 ГБ на узел в зависимости от платформы, плюс общий резерв 20-25% на пики и новые машины.
Что значит резерв N+1?
Кластер выдерживает отказ одного узла: уцелевшие принимают его нагрузку. Для этого каждый хост в обычном режиме загружают не выше 60-70%.
Какой запас закладывать на рост?
20-30% по ядрам и ОЗУ плюс свободные слоты под модули и диски. Дешевле купить платформу с потолком повыше, чем менять ее целиком через год.
Какой сервер нужен под 30 виртуальных машин?
Ориентир из примера выше: два узла по два 16-ядерных CPU и 512 ГБ ОЗУ с накопителями NVMe. Точная конфигурация зависит от доли тяжелых баз в пуле.