Расчёт размеров СХД для виртуализации: требования, IOPS и подбор конфигурации

Кластер из 100 виртуальных машин с дисками по 100 ГБ и средним профилем 30 IOPS на ВМ создаёт нагрузку около 3000 операций ввода-вывода в секунду и требует 15-20 ТБ полезной ёмкости с запасом на снапшоты и рост. Эти два числа определяют закупку: объём задаёт количество дисков, IOPS задают их тип. Расчёт только по гигабайтам даёт массив, который упирается в очереди при первом же пике нагрузки, а расчёт только по производительности оставляет кластер без места через полгода.

Размер СХД для виртуализации считается в три шага. Сначала собираются профили ВМ и считается требуемая ёмкость, затем считается производительность в IOPS, после чего оба показателя переводятся в количество дисков, их тип и уровень RAID. Методика одинакова для VMware vSphere, Proxmox VE и Hyper-V, различия лежат в протоколах доступа, поддержке аппаратного ускорения (VAAI, ODX) и в том, как гипервизор хранит снапшоты.

С чего начать расчёт СХД для кластера виртуализации

Расчёт начинается с инвентаризации, а не с выбора модели массива. Нужны пять групп исходных данных.

• Профили ВМ: количество, vCPU, RAM, число и размер виртуальных дисков, заявленный тип диска (thin или thick).
• Класс нагрузки каждой ВМ: VDI, веб-приложение, файловый сервис, СУБД, почта, инфраструктурные роли (AD, DNS, мониторинг, бэкап-прокси).
• Метрики с работающего кластера, если он есть: в vSphere это vCenter performance charts и Aria Operations, в Proxmox - Grafana с InfluxDB или данные pvesh, в Hyper-V - Performance Monitor со счётчиками LogicalDisk и Avg. Disk sec/Read. Минимальный интервал сбора: 2-4 недели, обязательно с захватом пиковых дней (утренний вход VDI в понедельник, окно резервного копирования, закрытие месяца для учётных систем).
• Требования бизнеса: целевая латентность по классам ВМ, RTO и RPO, срок хранения снапшотов, план роста на 3 года.
• Ограничения физического размещения: доступные юниты стойки, питание, охлаждение, число свободных портов коммутаторов. Как плотность хранения связана с юнитами стойки, разобрано в материале про габариты СХД и плотность хранения данных.

Без инвентаризации любая конфигурация подбирается наугад. Системный администратор, который берёт один NVMe на 7.68 ТБ «на всякий случай», обычно получает либо нехватку места на второй год, либо переплату за диски, загрузка которых не превышает 5%.

Как рассчитать требуемый объём хранилища для виртуальных машин

Полезная ёмкость массива считается по формуле:

Полезная ёмкость = ((Σ заявленных дисков ВМ × коэффициент фактического заполнения) + снапшоты + резервные копии) × коэффициент запаса

Разберём на цифрах. 100 ВМ по 100 ГБ дают 10 000 ГБ заявленного логического объёма. При тонком провижининге фактически занято 60-75% от заявленного, то есть 6000-7500 ГБ. Дальше добавляется снапшот-пространство: 10-20% от фактического объёма, то есть 750-1500 ГБ. Если резервные копии лежат на том же массиве (чего лучше избегать, но так делают в небольших контурах), добавляется ещё один полный объём, 7000-9000 ГБ с инкрементами и цепочками. Финальный запас на рост берётся 20-30%, а для проектов со сроком жизни 3+ года его поднимают до 40%.

Для примера из 100 ВМ получается: (7000 + 1000) × 1.25 = 10 000 ГБ, то есть около 9.8 ТБ полезной ёмкости без учёта резервных копий. Это то, что должен увидеть гипервизор после RAID и накладных расходов файловой системы.

Физическая ёмкость получается умножением полезной на коэффициент RAID:

Полезная ёмкость 9.8 ТБ на RAID 10 требует почти 20 ТБ сырой ёмкости. На четырёх дисках по 7.68 ТБ получается 15.36 ТБ полезной, чего для этого примера достаточно с небольшим запасом.

Учёт тонкого провижининга и снапшотов

Тонкий провижининг разрешает выделить логически больше места, чем есть физически, и это главный источник аварий. Соотношение overprovisioning выше 2:1 без мониторинга свободного места заканчивается остановкой ВМ или отказом снапшотов. Рабочее правило: держать загрузку тонкого пула ниже 75%, а на датастор с включёнными снапшотами выделять отдельный резерв 15-20%.

Снапшоты у гипервизоров работают по-разному, и это влияет на расчёт. В VMware снапшот создаётся как delta-диск в том же datastore, поэтому при долгой жизни снапшота (больше суток) и интенсивной записи он легко вырастает до размера базового диска. В Proxmox снапшоты на ZFS и LVM-thin расходуют только изменённые блоки, но на qcow2 требуют поддержки на уровне файловой системы, а фрагментация снижает производительность. В Hyper-V checkpoint создаёт файл AVHDX, а слияние (merge) требует свободного места и времени, поэтому производственные контрольные точки отключают и работают с бэкапом.

Планирование по уровням хранения (hot, warm, cold, archive) и расчёт стоимости по слоям описаны в отдельной статье про проектирование СХД предприятия. Разделение слоёв уменьшает требуемый объём дорогих NVMe в два-три раза при том же обслуживании.

Расчёт IOPS для системы хранения: методика и примеры

IOPS - количество операций ввода-вывода в секунду. Итоговая метрика зависит от блочного размера, глубины очереди и соотношения чтения и записи. Пропускная способность считается как IOPS × блочный размер: 7000 IOPS блоками по 32 КБ дают около 220 МБ/с, а те же 7000 IOPS блоками по 4 КБ - всего 27 МБ/с. Для СУБД и VDI критична не суммарная производительность, а латентность: OLTP на дисках с откликом выше 5 мс деградирует даже при свободном запасе по IOPS.

Формула расчёта:

Требуемые IOPS = Σ (IOPS профиля × число ВМ) × коэффициент пика × коэффициент запаса

Пиковый коэффициент берётся 1.5-2, для VDI с одновременным входом сотрудников допускается 2.5-3. Запас на рост и непредвиденные нагрузки - 20-30%. Для массивов с чётностью считается отдельная величина: IOPS записи = IOPS записи, делённые на штраф (4 для RAID 5, 6 для RAID 6).

Типовые профили нагрузки и их IOPS

Значения в таблице растут вместе с числом пользователей и интенсивностью операций. Для OLTP с журналом в режиме write-through ориентируются на 300-500 IOPS на инстанс, для аналитического хранилища профиль смещается в сторону последовательных чтений и измеряется в мегабайтах в секунду. Уточнять профили удобнее по фактическим метрикам: команды для нагрузочного тестирования дисков с помощью fio и разбор реальных показателей NVMe, SATA SSD и HDD собраны в материале про производительность дисковых подсистем.

Учёт пиковых нагрузок и коэффициента запаса

Пиковая нагрузка превышает среднюю в 2-3 раза в предсказуемые часы: утренний вход в VDI, ночное резервное копирование, отчётный период. Пример: средняя нагрузка 5000 IOPS, коэффициент пика 2 даёт 10 000 IOPS, запас 30% поднимает требование до 13 000 IOPS.

Практика показывает, что массив, спроектированный строго по средним значениям, в пик уходит в очередь глубиной 20-50 команд, и латентность чтения вырастает с 0.5 мс до 8-15 мс. Виртуальные машины с базами данных в такой ситуации получают таймауты, а VDI-сессии - фризы приложения.

Как форм-фактор и число дисков влияют на производительность и ёмкость

Тип накопителя определяет потолок производительности одного слота, форм-фактор определяет, сколько таких слотов помещается в юнит стойки. Пересчёт в IOPS и задержки для конкретных моделей приведён в таблице.

Сравнение NVMe, SAS и SATA для виртуализации

NVMe передаёт команды напрямую по PCI Express и работает с глубокой очередью без ограничений старых протоколов, поэтому подходит для СУБД, VDI и любых ВМ с высокой интенсивностью случайного доступа. SAS SSD даёт умеренную производительность и поддержку dual-port, что упрощает построение отказоустойчивых путей без программного multipath. SATA SSD дешевле, но лишён dual-port и быстрее упирается в потолок интерфейса при смешанной нагрузке. Накопители на магнитных пластинах остаются для архивов, бэкапов и холодных данных: 150 IOPS на диск против 500 000 у NVMe - разница в три тысячи раз.

Примеры корпоративных NVMe в форм-факторе U.2: Memblaze PBlaze7 7946 объёмом 3.2 ТБ, PBlaze7 7940 объёмом 3.84 ТБ и PBlaze7 7A40 объёмом 7.68 ТБ с поддержкой горячей замены. Все три модели рассчитаны на непрерывные операции чтения и записи и позиционируются для виртуализации, баз данных и аналитических платформ.

Расчёт количества дисков под требуемые IOPS и объём

Количество дисков считается как максимум из двух условий:

Число дисков = max(требуемые IOPS / IOPS одного диска, требуемая ёмкость / ёмкость одного диска с учётом RAID)

Результат округляется вверх до чётного значения для RAID 10 и до числа, кратного ширине группы для RAID 5 и RAID 6. Пример: нужно 10 000 IOPS и 20 ТБ полезной ёмкости. По производительности хватает одного NVMe на 500 000 IOPS, по ёмкости требуется 20 / 7.68 = 2.6, то есть 3 диска. RAID 10 из четырёх дисков даёт только 15.36 ТБ, чего мало, поэтому берутся 6 дисков и получается 23.04 ТБ полезной ёмкости с производительностью выше требуемой в сотни раз.

В RAID 10 производительность растёт почти линейно от числа дисков (реально 80-90% от суммы), в RAID 5 и RAID 6 чтение масштабируется линейно, а запись делится на штраф за чётность. Массив из 8 HDD по 150 IOPS в RAID 6 выдаёт около 1200 IOPS на чтение и всего 200 IOPS на запись. Как выбрать уровень RAID под СУБД и виртуализацию, подробно разобрано в руководстве про выбор и настройку RAID.

Пошаговый пример подбора конфигурации стоечной СХД под кластер

Ниже два расчёта от исходных данных до конкретного списка дисков. Их можно повторить со своими числами, подставив профили из инвентаризации.

Пример 1: Кластер VDI и БД на 60 ВМ

Исходные данные: 50 виртуальных рабочих мест с профилем 15 IOPS и диском 80 ГБ, 10 серверов СУБД с профилем 200 IOPS и диском 500 ГБ. Тонкий провижининг 1.5, снапшоты 10%, целевой срок службы 3 года.

1. Ёмкость VDI: 50 × 80 ГБ × 1.5 = 6000 ГБ заявленного объёма, фактическое заполнение около 4000 ГБ.
2. Ёмкость БД: 10 × 500 ГБ = 5000 ГБ, снапшоты и журналы проверяются отдельно, для расчёта берётся полный объём.
3. Сумма 9000 ГБ, снапшоты 10% дают 900 ГБ, запас 25% поднимает итог до 12 375 ГБ, то есть 12.1 ТБ полезной ёмкости.
4. IOPS VDI: 50 × 15 × 2 = 1500. IOPS БД: 10 × 200 × 2 = 4000. Сумма 5500, запас 30% даёт 7150 IOPS при латентности до 5 мс для СУБД.
5. Выбор дисков: NVMe U.2 7.68 ТБ. По IOPS достаточен один диск, по ёмкости нужно 12.1 / 7.68 = 1.6, то есть 2 диска. RAID 10 из четырёх дисков даёт 15.36 ТБ полезной ёмкости и кратный запас производительности.

Итоговая конфигурация: 4 NVMe U.2 по 7.68 ТБ в RAID 10, например Memblaze PBlaze7 7A40 с горячей заменой, плюс один диск в резерве на полке. Полезная ёмкость 15.36 ТБ покрывает расчётные 12.1 ТБ, а производительность массива перекрывает требование 7150 IOPS с запасом на рост кластера.

Пример 2: Кластер общего назначения на 200 ВМ

Исходные данные: 200 ВМ смешанного назначения (веб, файловые, инфраструктурные) со средним профилем 30 IOPS и диском 100 ГБ, тонкий провижининг 1.5, запас 25%.

1. Ёмкость: 200 × 100 ГБ × 1.5 = 30 000 ГБ заявленного объёма, фактическое заполнение около 20 000 ГБ.
2. Запас 25% с учётом снапшотов 10% даёт около 27 500 ГБ, то есть 26.9 ТБ полезной ёмкости.
3. IOPS: 200 × 30 × 1.5 (пик) = 9000, запас 30% даёт 11 700 IOPS.
4. Вариант A, SAS SSD 1.92 ТБ: по ёмкости нужно 27.5 / 1.92 = 14.3, то есть 15 дисков, RAID 10 требует 30 дисков и даёт 28.8 ТБ и около 3 000 000 IOPS.
5. Вариант B, NVMe U.2 7.68 ТБ: по ёмкости нужно 27.5 / 7.68 = 3.6, то есть 4 диска, RAID 10 требует 8 дисков и даёт 30.7 ТБ полезной ёмкости.

Вариант B выигрывает по числу слотов (8 против 30), энергопотреблению и обслуживанию, при этом вдвое перекрывает требование по IOPS. Вариант A имеет смысл, когда нужен dual-port и уже есть шасси с большим числом SAS-бэев. Для Proxmox с ZFS добавляется нюанс: RAIDZ2 на восьми NVMe 7.68 ТБ даёт около 46 ТБ полезной ёмкости, но требует держать пул заполненным не выше 80% и учитывать slop space.

Если часть нагрузки можно вынести из собственной стойки, разумно сравнить расчёт с облачным размещением: виртуальные машины и хранилище в Timeweb Cloud снимают вопросы по закупке дисков, но требуют отдельного расчёта по сети и стоимости гигабайта в месяц.

Чек-лист проверки совместимости СХД с гипервизорами

• Наличие модели массива в VMware Compatibility Guide для нужной версии ESXi. Отсутствие в списке лишает права на поддержку при инциденте.
• Наличие контроллера и дисков в списке совместимого оборудования Proxmox VE или в каталоге вендора для Linux-ядер целевой версии.
• Проверка по Windows Server Catalog для Hyper-V, включая поддержку ReFS и CSV.
• Поддержка протоколов, которые планируются к использованию: iSCSI, NFS v3/v4.1, Fibre Channel, NVMe-oF или NVMe/TCP.
• Наличие VAAI для VMware (блочное копирование, zeroed thick, атомарные блокировки) и ODX для Hyper-V. Ускорение аппаратных операций снижает нагрузку на хосты при клонировании и снапшотах.
• Поддержка VVols, если планируется управление на уровне отдельных ВМ.
• Поддержка консистентных снапшотов и интеграция с VSS для Hyper-V, quiescing через VMware Tools для ESXi.
• Горячая замена дисков и горячая замена контроллеров без остановки кластера.
• Корректная работа multipath и ALUA, поддержка двух независимых путей до данных.
• Настройка MTU 9000 для iSCSI и NFS, если используется выделенная сеть хранения.
• Совместимость версии прошивки СХД с драйверами гипервизора из матрицы вендора.
• Проверка блокировки тонкого провижининга на уровне массива: гипервизор и СХД не должны одновременно перераспределять свободное место.

Разбор протоколов доступа, настройки VMFS, NTFS и ReFS, а также тесты производительности приведены в руководстве про дисковые массивы для виртуальных машин.

Типичные ошибки при расчёте и внедрении СХД

• Расчёт по средним IOPS без пикового коэффициента. Массив уходит в очередь в часы пик, латентность растёт в 10-20 раз. Решение: умножать средние значения на 1.5-2 и проверять результат нагрузочным тестом.
• Запас ёмкости меньше 20%. Снапшоты, журналы и рост данных съедают остаток за месяцы. Решение: закладывать 25-30% и пересчитывать после первого квартала работы.
• Использование SATA SSD или HDD под интенсивные нагрузки. Потолок 100 000 IOPS на NVMe против 150 у HDD объясняет, почему база данных на семи тысячных дисках не проходит по латентности. Решение: NVMe или SAS SSD под горячие данные, HDD под архив.
• RAID 5 или RAID 6 под СУБД. Штраф на запись 4 и 6 соответственно и длительная перестройка на дисках большой ёмкости. Решение: RAID 10 для OLTP и журналов.
• Отсутствие мониторинга тонкого пула. Пул заполняется до 100%, снапшоты перестают создаваться, ВМ останавливаются. Решение: алерт на 70% и 80% заполнения.
• Экономия на дисках в ущерб отказоустойчивости. Один NVMe без резерва и горячей замены превращает отказ накопителя в простой кластера.
• Игнорирование оверхеда снапшотов и резервных копий. Цепочка снапшотов на интенсивной записи вырастает до размера базового диска. Решение: ограничить срок жизни снапшота сутками.
• Расчёт без учёта латентности. Суммарные IOPS могут быть достаточными, а отклик выше 10 мс всё равно ломает работу СУБД.
• Отсутствие проверки совместимости. Массив, не внесённый в HCL, лишает вендора обязательств по поддержке.
• Некорректная настройка кеша. Включённый кеш записи без батарейного питания даёт потерю данных, а кеш NVMe поверх ZFS с включённым sync расходует ресурс диска на write amplification.

Практические рекомендации по выбору накопителей для виртуализации

Для кластеров виртуализации берут корпоративные SSD с интерфейсом NVMe в форм-факторе U.2: они дают низкую латентность, поддержку горячей замены и предсказeyмый ресурс. Критерии выбора при закупке: IOPS на случайном чтении и записи блоками 4 КБ, латентность при смешанной нагрузке, показатель DWPD (для виртуализации достаточно 1-3 перезаписи в день), суммарный TBW, наличие защиты от потери питания и объём overprovisioning.

Линейка Memblaze PBlaze7 покрывает типовые задачи виртуализации: 7946 на 3.2 ТБ и 7940 на 3.84 ТБ подходят для массивов с большим числом слотов, 7A40 на 7.68 ТБ с горячей заменой удобен там, где важна плотность на юнит стойки и минимум дисков на кластер.

Для больших объёмов рабочая схема - двухуровневое хранение: NVMe под горячие ВМ и журналы СУБД, SAS или SATA HDD под бэкапы, архивы и редко используемые данные. Расчёт начинается с инвентаризации, продолжается определением ёмкости и IOPS, а завершается проверкой по чек-листу совместимости и нагрузочным тестом выбранной конфигурации до ввода в продуктив.