СХД для виртуализации: требования, расчёт IOPS и настройка multipath

Систему хранения для виртуализации выбирают по задержке и IOPS, а объём ставят на третье место. Практический ориентир: средняя задержка ниже 10 мс, пиковая не выше 20 мс. Массив на 5 000 IOPS с откликом 5 мс даёт более отзывчивые виртуальные машины, чем массив на 10 000 IOPS с откликом 30 мс, потому что каждая операция ждёт в очереди и гость это чувствует.

Расчёт нагрузки строится из профилей ВМ: суммируйте IOPS всех машин, примените коэффициент пиковой нагрузки 1,5-2 и добавьте запас 30-50% на рост. Для 50 ВМ средней нагрузки это 10 000 IOPS в среднем, около 15 000 в пике и 20 000 в проектной конфигурации.

Настройка сводится к трём приёмам: multipath для iSCSI и Fibre Channel, кэширование с защитой от потери питания и тонкий провижининг с постоянным контролем заполнения. Ниже методика расчёта, рабочие конфигурации и диагностика узких мест, которые проявляются только под реальной работой.

Требования к СХД для гипервизоров: что действительно важно

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

Требования зависят от типа нагрузки. База данных чувствительна к задержке записи, VDI переживает всплески при массовом входе пользователей, файловый сервер упирается в пропускную способность, веб-сервер нередко довольствуется кэшем в оперативной памяти. Ориентиры для приёмки массива выглядят так:

Задержка и IOPS: почему это важнее объёма

Задержка измеряется в миллисекундах и показывает, сколько времени занимает обработка одной операции ввода-вывода. Для виртуализации комфортным считается отклик ниже 10 мс, допустимым до 20 мс. В диапазоне 20-50 мс гостевые системы заметно тормозят: удлиняются транзакции, растёт время отклика RDP и веб-приложений, очереди копируются и множатся. Свыше 50 мс начинаются таймауты SCSI и сбросы команд, операционные системы переходят к повторным попыткам, что добавляет нагрузку и ускоряет деградацию по спирали.

IOPS зависят от профиля операций. Самый тяжёлый вариант для массива: случайные операции блоками 4 КБ со смешанным чтением и записью. Последовательные блоки 64-128 КБ загружают пропускную способность, но требуют меньше операций в секунду. Смотреть нужно на оба показателя: задержка скажет, справляется ли массив, IOPS покажет, сколько работы он успевает обработать.

Практический ориентир: 100 ВМ средней нагрузки (веб-сервисы, лёгкие приложения, инфраструктурные роли) генерируют 5 000-10 000 IOPS в пике. Массив с паспортными 50 000 IOPS на 4 КБ random read под смешанным профилем 70/30 покажет заметно меньше: производители измеряют параметры на идеальных условиях, а жёсткий профиль не даёт контроллеру объединять запросы.

Пример сравнения. Массив А выдаёт 5 000 IOPS с откликом 5 мс, массив Б выдаёт 10 000 IOPS с откликом 30 мс. На массиве Б виртуальные машины будут работать хуже, хотя запас по операциям вдвое больше. Именно поэтому в проектах под БД с синхронной записью выбирают накопители и интерфейсы с низкой задержкой, даже если по IOPS они проигрывают.

Поддержка снапшотов и интеграция с гипервизором

Снапшоты на уровне массива создаются мгновенно и не нагружают гипервизор: контроллер строит карту указателей на неизменённые блоки. Программные снапшоты в VMFS, ReFS или ZFS работают иначе: они создают дельта-диски, а при откате или консолидации гипервизор читает и записывает данные, расходуя процессор хоста и IOPS хранилища. На массиве с 500 ГБ изменений в сутки консолидация программного снапшота легко занимает десятки минут и ухудшает отклик соседних ВМ.

Интеграция с гипервизором снимает часть работы с хостов. В VMware vSphere это набор VAAI: Full Copy (XCOPY) ускоряет клонирование ВМ, Block Zeroing (WRITE SAME) ускоряет создание толстых дисков, Hardware Assisted Locking (ATS) снижает конфликты при запуске ВМ с общего LUN, Thin Provisioning Stun сообщает хосту, что массив исчерпал свободные блоки. В Hyper-V аналогичную задачу решают ODX для копирования и VSS для консистентных снапшотов при резервном копировании.

Статус VAAI на хосте ESXi проверяется командой esxcli storage core device vaai status get. Если поле Status показывает unsupported, клонирование диска на 100 ГБ займёт минуты и создаст полный объём записи на массив. На хранилищах без VAAI затирание нулями VMDK на 500 ГБ может отнять десятки минут и ощутимо просадить отклик для остальных машин в кластере.

Совместимость по платформам выглядит так: VMware vSphere ждёт VAAI и корректных ALUA-приоритетов, Proxmox VE на LVM и iSCSI работает без VAAI, но выигрывает от поддержки discard и тонких LUN, Hyper-V опирается на ODX и VSS, а для кластерных дисков требует правильно настроенного MPIO. Без этих функций виртуализация работает, но теряет время на операциях обслуживания: клонировании шаблонов, создании дисков, бэкапах, миграциях. Там и появляются окна деградации.

Тип доступа влияет на задержку сильнее, чем модель массива. Сравнение вариантов, которые чаще всего встречаются в проектах под виртуализацию:

Подробное сравнение протоколов и сценариев с расчётом IOPS и задержки собрано в материале о выборе СХД для виртуализации под VMware и Proxmox.

Расчёт нагрузки на СХД при плотном размещении виртуальных машин

Методика состоит из четырёх шагов: определить профиль каждой ВМ, умножить на количество, применить коэффициент пиковой нагрузки и добавить запас. Расчёт опирается на метрики продакшена, а не на паспортные цифры массивов.

Профили нагрузки виртуальных машин

Профиль определяется приложением и размером блока, который оно читает и пишет. Ориентиры для планирования:

Измеряйте профиль на своих данных, а не по таблицам. В VMware это esxtop в режиме disk device, в Linux - iostat -x 1 с колонками r_await, w_await, aqu-sz и %util, в Hyper-V - счётчики LogicalDisk\Avg. Disk sec/Transfer и LogicalDisk\Current Disk Queue Length, на ZFS - zpool iostat -v 5. Снимайте статистику не меньше 30 дней и берите 95-й процентиль: среднее значение скрывает пики, из-за которых и происходят деградации. Одна ВМ с SQL Server выдаёт до 1 000 IOPS, и десять таких машин дают уже 10 000 IOPS только от одной группы серверов баз данных.

Коэффициент консолидации и запас производительности

Коэффициент консолидации - это отношение пиковой нагрузки к средней. Для инфраструктуры виртуализации типично значение 1,5-2. Оно вырастает до 3 и выше, когда совпадают резервное копирование, обновление операционных систем, антивирусное сканирование и вход пользователей VDI утром. Средняя нагрузка в 8 000 IOPS при коэффициенте 1,5 превращается в 12 000 IOPS в пике.

Запас на рост и непредвиденные пики составляет 30-50%. Меньший запас экономит диски сегодня и приводит к очередям через полгода, когда добавляются новые сервисы. Очередь на массиве поднимает задержку, а задержка бьёт по всем ВМ сразу, включая те, что напрямую не нагружали хранилище.

К расчётным IOPS добавляются накладные расходы контроллера. Штраф записи зависит от уровня RAID: RAID 10 и RAID 1 умножают каждую запись на 2, RAID 5 на 4, RAID 6 на 6. Если профиль нагрузки содержит много записи, RAID 5 на HDD становится ловушкой. Пределы накопителей по случайным операциям 4 КБ: NL-SAS 7200 об/мин выдаёт 75-100 IOPS, SAS 10K около 130-150, SAS 15K около 180-200, SATA и SAS SSD в смешанном профиле 10 000-30 000, NVMe U.2 от 100 000.

Полный пример для 50 ВМ. Десять серверов с базами данных по 600 IOPS дают 6 000 IOPS. Двадцать файловых и прикладных серверов по 120 IOPS дают 2 400 IOPS. Двадцать веб-сервисов и инфраструктурных ролей по 80 IOPS дают 1 600 IOPS. Итого 10 000 IOPS в среднем. Умножаем на коэффициент 1,5 и получаем 15 000 IOPS в пике. Добавляем запас 30% и получаем проектное значение 20 000 IOPS.

Перевод в железо: чтобы получить 20 000 IOPS случайного доступа, нужны 4-6 SSD в RAID 10 плюс HDD-полка для ёмкости, если данные редко запрашиваются. Вариант только на NL-SAS потребует более 200 дисков, что нереализуемо ни по цене, ни по полкам. Дополнительные факторы, которые стоит учесть при планировании ёмкости, уровней хранения и восстановления после отказа, разобраны в руководстве о проектировании системы хранения для инфраструктуры предприятия.

Практическая настройка: multipath, кэширование, тонкий провижининг

Настройки зависят от гипервизора и модели массива, поэтому проверяйте их на тестовом стенде до продакшена. Ниже конфигурации, которые работают в большинстве проектов на iSCSI и Fibre Channel.

Настройка multipath для iSCSI: пошагово

1. Установите пакет: apt install multipath-tools или yum install device-mapper-multipath. Для Fibre Channel этот шаг обязателен, для iSCSI он даёт отказоустойчивость и агрегацию полосы.
2. Заполните /etc/multipath.conf. Базовый шаблон для массива с поддержкой ALUA:

defaults {
    path_selector "service-time 0"
    path_grouping_policy group_by_prio
    prio alua
    path_checker tur
    failback immediate
    no_path_retry 30
    user_friendly_names yes
}
blacklist {
    wwid 3600508b400105e210000900000490000
}

1. Внесите локальные диски хоста в blacklist по WWID, иначе multipath соберёт их в отдельные устройства и это заблокирует загрузку.
2. Включите службу: systemctl enable --now multipathd, при необходимости пересоберите конфигурацию командой multipath -r.
3. Проверьте результат: multipath -ll покажет устройства, группы путей и приоритеты. Для ALUA-массива активная группа должна иметь приоритет выше, чем неактивная, а число путей совпадать с числом сессий в iscsiadm -m session.
4. Выберите политику маршрутизации. round-robin с ограничением iops=1 подходит для активных ALUA-портов, queue-length и service-time дают лучший результат при равнозначных путях, а для VMware на ALUA-массивах используйте PSP Round Robin с лимитом операций 1. Для Windows в MPIO выбирайте Least Queue Depth для симметричных путей или Round Robin with Subset для ALUA.
5. Проверьте отказоустойчивость: отключите один путь на коммутаторе или командой iscsiadm -m session -u, убедитесь, что запись продолжается без ошибок в dmesg и в журнале гипервизора.

Типичные ошибки: пустой blacklist, из-за которого multipath перехватывает системный диск; параметр no_path_retry в значении fail, из-за которого ввод-вывод падает сразу при потере пути вместо ожидания восстановления; отсутствие теста failover, который выявляет неработающий второй путь только во время аварии. Разбор multipath вместе с VAAI, ODX и различиями VMFS, ReFS, LVM и QCOW2 собран в статье о настройке дисковых массивов для VMware, Hyper-V и KVM.

Кэширование: когда ускоряет, а когда вредит

Кэш чтения на SSD ускоряет доступ к активно используемым блокам и почти всегда полезен, если рабочий набор данных укладывается в объём кэша или ускоряющего уровня. Кэш записи даёт больший выигрыш и больший риск: кэшированные данные существуют только в энергозависимой памяти контроллера до сброса на диск. Без батареи или суперконденсатора отключение питания за секунды до сброса означает потерю этих данных.

Практические правила: включайте write-back кэш только при работающей защите питания и следите за состоянием батареи, включайте write-through для баз данных, где потеря нескольких последних транзакций недопустима, и проверяйте попадание в кэш. При попадании ниже 80% ускоряющий уровень перестаёт помогать и начинает работать как узкое место, потому что каждый промах добавляет задержку. Для ZFS разделяйте кэш чтения (L2ARC) и журнал синхронной записи (SLOG): SLOG с защитой питания ускоряет базы данных, а L2ARC без точного анализа рабочего набора только съедает память. Как настраивать политики кэша и tiering на массивах, включая метрики попаданий и контроль состояния батарей, описано в материале о кэшировании, tiering и мониторинге метрик массивов.

Тонкий провижининг: экономия без риска

Тонкий провижининг выделяет виртуальные блоки по требованию. Допустимая переподписка (overprovisioning) обычно составляет 1,5-2 от физической ёмкости, для архивных данных до 3. Выше начинается игра на грани: свободные блоки заканчиваются в самый неподходящий момент.

Последствия переполнения разные, но одинаково неприятные. В VMware при исчерпании свободного места на datastore срабатывает механизм thin provisioning stun, и все ВМ на этом datastore приостанавливаются, пока не появится место. В Hyper-V динамический VHDX почти заполненного тома даёт ошибки записи и сбои в гостевой системе. СХД с тонкими LUN может уйти в режим только для чтения.

Защита строится из трёх шагов. Настройте алерты на 80% и 90% заполнения и отправляйте их ответственному, а не в общий поток. Держите резерв физических дисков, которые можно подключить в течение часа. Включите возврат блоков: UNMAP для VMFS и iSCSI, discard для Linux, дедупликацию и компрессию там, где массив их поддерживает. Пример: выделено 10 ТБ, физически 6 ТБ. При заполнении 4,8 ТБ (80%) нужен алерт, при 5,4 ТБ (90%) пора подключать диски, а при 5,5 ТБ включать аварийный протокол расширения. Если массив расширяется на ходу, заранее проверьте, работает ли это без потери доступа к томам. Стенд для проверки multipath, кэша и переполнения удобно собрать отдельно от продакшена, например на облачных серверах и дисках Timeweb Cloud, где окружение можно пересоздать после любого эксперимента.

Типичные узкие места под нагрузкой и их диагностика

Проблемы, которые не видны на стенде, обычно проявляются в трёх местах: накопители и контроллеры массива, пути ввода-вывода и сеть для iSCSI или NFS. Каждому узкому месту соответствует своя метрика.

Диагностика задержек и очередей

В VMware esxtop в режиме disk device показывает четыре задержки: DAVG (время на устройстве), KAVG (время в стеке ядра), GAVG (время, которое видит гость) и QAVG (время в очереди). Если DAVG больше 20 мс, проблема на стороне СХД, а не гипервизора. Если растёт QAVG, массив не успевает обрабатывать операции, и добавление путей не поможет. В Linux колонки iostat -x читаются так: await показывает среднюю задержку, aqu-sz длину очереди, %util загрузку устройства.

Пример последовательности разбора: задержка растёт вместе с нагрузкой, QAVG держится около 3, %util на дисках 95%. Вывод: накопители не выдерживают число операций. Решения по убыванию эффекта: вынести горячие данные на SSD-уровень, разнести ВМ с тяжёлой записью по разным томам, ограничить параллельные задачи обслуживания. Если задержка высокая, а очередь пустая и загрузка дисков низкая, ищите проблему в путях, портах или сети. Смежные причины, связанные с настройками хоста, разобраны в руководстве об оптимизации производительности виртуальных машин и настройке аппаратной виртуализации.

Проблемы сети для iSCSI/NFS

Для блочного и файлового доступа по сети нужен отдельный VLAN без маршрутизации, отдельные физические или логические интерфейсы и одинаковый MTU на всём пути. Jumbo frames с MTU 9000 снижают нагрузку на процессор, но несовпадение настроек между хостом, коммутатором и массивом даёт фрагментацию и падение скорости. Проверка выполняется командой ping -M do -s 8972: если пакет не проходит, где-то по пути MTU меньше.

Потери пакетов влияют на задержку сильнее, чем кажется. Потеря 1% пакетов приводит к повторам TCP и росту задержки на десятки процентов, а на NFS добавляет таймауты и повторные запросы. Диагностика: iperf3 между хостом и массивом, счётчики ошибок CRC и отброшенных пакетов на коммутаторах, статистика retransmit в netstat -s, счётчики ошибок на интерфейсах гипервизора. Для NFS проверьте опции монтирования: размеры rsize и wsize 1 МБ, actimeo, число соединений nconnect для распараллеливания. Для iSCSI не смешивайте MPIO и LACP на одних интерфейсах: агрегация каналов даст один путь для каждой сессии, а балансировку выполняет multipath.

Заключение: чек-лист для проектирования СХД под виртуализацию

1. Соберите профили нагрузок с продакшена за 30 дней, используйте 95-й процентиль, а не среднее.
2. Посчитайте IOPS: сумма по всем ВМ, коэффициент пика 1,5-2, запас на рост 30-50%.
3. Проверьте задержку под нагрузкой: цель ниже 10 мс, предел 20 мс; выше 50 мс получите таймауты SCSI.
4. Учтите штраф записи RAID (RAID 10 равен 2, RAID 5 равен 4, RAID 6 равен 6) и пределы накопителей по случайным операциям.
5. Настройте multipath с ALUA, выберите политику round-robin, queue-length или service-time и обязательно протестируйте failover.
6. Включите VAAI для VMware, ODX и VSS для Hyper-V, проверьте статус на каждом хосте.
7. Включайте кэш записи только при работающей защите питания и контролируйте состояние батареи.
8. Используйте тонкий провижининг с переподпиской не выше 1,5-2 и алертами на 80% и 90% заполнения.
9. Настройте мониторинг DAVG, QAVG, %util, попадания в кэш, состояния путей и ошибок сети.
10. Зафиксируйте baseline и повторите нагрузочный тест после каждого изменения конфигурации массива или кластера.

Начните с пункта 1: снимите метрики с работающего кластера, подставьте свои числа в формулу расчёта и сравните результат с текущими возможностями хранилища. Расхождение в два раза и больше означает, что следующий рост числа ВМ приведёт к деградации, и планировать расширение нужно заранее.