Дисковые массивы для виртуальных машин: настройка и ускорение VMware vSphere, Hyper-V и KVM

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

Универсального протокола для всех виртуальных машин нет. Для VMware vSphere выбирайте VMFS на iSCSI или Fibre Channel, когда нужен общий блочный datastore, и NFS, когда удобнее работать с файловым экспортом. Для Hyper-V используйте LUN через iSCSI или Fibre Channel, затем создавайте NTFS или ReFS и добавляйте том в Cluster Shared Volumes. Для KVM подходят локальные NVMe и RAID, LVM, LVM-thin, NFS, iSCSI и распределенные хранилища, включая Ceph.

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

Протокол не исправит слабые диски, перегруженный контроллер, неправильный multipath или oversubscription в сети. Перед выбором измерьте IOPS, задержку, пропускную способность, долю чтения и записи, рост данных и требования к восстановлению. Для vSphere отдельно проверьте VAAI и VVol, для Hyper-V, ODX, для KVM, формат образа, режим кэша и возможности backend.

Если архитектура еще не определена, полезно сопоставить DAS, NAS, SAN и HCI в обзоре архитектур хранилищ. Ниже приведен алгоритм, который связывает требования виртуальных машин с конкретной конфигурацией СХД.

Матрица выбора по требованиям

Что проверить до проектирования

• Версии гипервизора, гостевых драйверов, HBA, сетевых адаптеров, прошивок массива и multipath-компонентов. Сверяйте совместимость всей связки, а не отдельного устройства.
• Количество хостов, топологию кластера, требования к HA, live migration, резервному копированию и аварийному восстановлению.
• Типы ВМ: базы данных, VDI, файловые серверы, веб-приложения, CI/CD, журналы и backup. Эти нагрузки создают разный профиль I/O.
• Пиковые значения IOPS, задержки и пропускной способности. Средняя загрузка скрывает короткие всплески, из-за которых ВМ начинают ждать диски.
• Поддержку массива для VMFS, NFS, NTFS, ReFS, VAAI, VVol, ODX, thin provisioning, UNMAP, дедупликации, сжатия и QoS.
• Запас емкости под рост виртуальных дисков, снапшоты, rebuild, миграции, временные файлы и восстановление после отказа.

Определение требований виртуальных машин к СХД

Проект начинайте с профиля нагрузки, а не с количества дисков в корпусе. Одинаковый объем виртуального диска может принадлежать архивной ВМ с редким чтением или базе данных, которая постоянно выполняет случайные записи.

IOPS, задержка и пропускная способность

IOPS показывают количество операций ввода-вывода за секунду. Пропускная способность показывает объем переданных данных. Связь между ними зависит от размера блока:

пропускная способность = IOPS x размер блока

Например, 20 000 IOPS при блоке 8 KiB дают примерно 156 MiB/s. Те же 20 000 IOPS при блоке 64 KiB дают около 1,25 GiB/s и создают совершенно другую нагрузку на сеть и контроллер.

Для баз данных и системных дисков чаще критична задержка случайного доступа. Для резервного копирования, потоковой обработки и миграции виртуальных дисков важнее последовательная пропускная способность. Записывайте среднюю задержку и 95-й и 99-й перцентили. Среднее значение 2 мс может скрывать короткие пики 50 мс, которые уже заметны приложению.

Емкость, резерв и рост данных

Расчет начинайте с полезной емкости после RAID, hot spare, служебного резерва, репликации и системных метаданных. Thin provisioning, дедупликация и сжатие могут увеличить логический объем, но не отменяют контроль физического свободного места.

В расчет включите:

• текущий объем виртуальных дисков и фактически занятые блоки;
• ежемесячный рост данных и расширение существующих дисков;
• свободное место для снапшотов, клонирования и временных файлов миграции;
• резерв под rebuild после отказа диска;
• место для резервных копий, если они используют тот же пул;
• запас для безопасной работы thin pool и дедупликации.

Для первичного планирования задайте порог предупреждения при заполнении около 70-80 процентов, а критический порог определите по документации конкретной СХД и результатам тестов. Пул, который постоянно работает почти без свободного места, хуже переносит снапшоты, reclaim и перестроение RAID.

Классы виртуальных машин и размещение

Базы данных, backup и VDI редко следует оставлять в одном пуле без QoS. Их пики совпадают, а очередь диска растет быстрее, чем показывает средняя загрузка. Разделяйте их отдельными пулами, storage policies или хотя бы лимитами IOPS.

Выбор протокола хранения: iSCSI, NFS или Fibre Channel

Блочный доступ предоставляет хосту LUN, поверх которого гипервизор создает VMFS, NTFS, ReFS или другой слой. Файловый доступ сразу предоставляет экспорт, например NFS datastore. Блокирование и файловые блокировки обрабатываются по-разному, поэтому настройки одного протокола нельзя механически переносить на другой.

Сравнение объектного, блочного и файлового подхода с критериями выбора собрано в отдельном руководстве по типам хранилищ.

iSCSI для виртуализации

iSCSI передает SCSI-команды через Ethernet. Массив публикует target и LUN, а хост подключается через initiator. Для отказоустойчивой конфигурации используйте минимум два физических сетевых пути, независимые коммутаторы или fabric-сегменты, два порта контроллеров и MPIO.

• Разделите storage-трафик отдельными VLAN или физическими сетями. Общий канал с пользовательским трафиком допускается только после расчета пропускной способности и oversubscription.
• Настройте два или больше initiator-порта на каждом хосте. Два интерфейса, подключенные к одному коммутатору и одному uplink, не дают полноценной защиты от отказа.
• Проверьте ALUA, если массив публикует оптимизированные и неоптимизированные пути. Неправильная политика может отправлять I/O через контроллер-посредник.
• Включайте jumbo frames только после согласования MTU на хосте, коммутаторе, VLAN-интерфейсе и массиве. Один участок с MTU 1500 ломает расчет для цепочки с MTU 9000.
• Контролируйте ошибки CRC, потери пакетов, retransmit, queue depth и загрузку портов.

iSCSI часто дает лучший баланс стоимости и гибкости. Его слабое место, общая Ethernet-инфраструктура, если ее не отделить и не контролировать.

NFS для datastore и образов KVM

NFS предоставляет файловый экспорт, внутри которого хранятся виртуальные диски, конфигурации и снапшоты. В vSphere NFS datastore подключается к каждому хосту кластера. В KVM NFS обычно монтируют на узлах и регистрируют как storage pool.

• Выберите NFSv3 или NFSv4.1 только после проверки совместимости массива, гипервизора и резервного ПО. Поддержка версии протокола не гарантирует поддержку всех функций.
• Задайте ACL или список разрешенных адресов для хостов. Не открывайте экспорт всей рабочей сети.
• Проверьте блокировки, восстановление соединения, поведение при отказе контроллера и доступность экспорта с каждого узла.
• Измерьте операции с метаданными: создание файлов, клонирование, включение и выключение ВМ, массовую работу со снапшотами.
• Разделите NFS-трафик ВМ, миграции и backup, если один канал не выдерживает суммарную нагрузку.

NFS удобен для управления виртуальными дисками и быстрых операций на стороне массива. При большом количестве мелких файлов и одновременных снапшотах контроллеры и сеть могут стать узким местом.

Fibre Channel в критичных средах

FC строится вокруг HBA, FC-коммутаторов и отдельной фабрики. Хост идентифицируется WWPN, а доступ к LUN ограничивается zoning и LUN masking. Рабочая схема использует две независимые fabric, два HBA-порта на хосте и подключения к контроллерам массива через обе fabric.

1. Соберите таблицу WWPN всех HBA и портов массива.
2. Создайте zoning по принципу один инициатор и нужные target-порты в зоне.
3. Настройте LUN masking на массиве для конкретных хостов или групп хостов.
4. Выполните rescan и убедитесь, что все узлы видят одинаковые идентификаторы устройств.
5. Проверьте multipath, ALUA и состояние оптимизированных путей.

FC оправдан при строгих требованиях к задержке, изоляции и предсказуемости. За это приходится платить отдельными HBA, коммутаторами, оптикой и более узкой специализацией команды.

Проектирование дискового массива для виртуализации

Массив проектируют по сочетанию I/O-профиля, емкости, времени восстановления и допустимого окна деградации. Число дисков само по себе не показывает итоговую производительность: ее ограничивают контроллер, кэш, backend, ширина полосы и алгоритм RAID.

RAID и отказоустойчивость

Для parity RAID мелкая запись часто требует чтения старых данных и четности, расчета новой четности и записи результата. Контроллер с защищенным кэшем уменьшает задержку, но не отменяет нагрузку на диски во время rebuild.

RAID защищает доступность пула при отказе диска. Он не заменяет резервное копирование, репликацию и проверку восстановления. Учитывайте тип дисков, их ресурс записи, размер группы, вероятность второго отказа и допустимое время работы в degraded-режиме.

Кэш записи и политика подтверждения операций

Write-back кэш подтверждает запись до ее полного размещения на дисках. Это ускоряет короткие операции и сглаживает bursts, но безопасен только при наличии battery-backed или flash-backed защиты, контроле состояния батареи и корректном завершении кэша после потери питания.

Write-through подтверждает запись после передачи на устойчивый носитель. Задержка выше, зато поведение проще прогнозировать. UPS полезен, но не заменяет защищенный кэш: отказ контроллера, кабеля или самого массива может произойти при работающем питании площадки.

• Проверьте состояние батареи, конденсаторов и flash-кэша на каждом контроллере.
• Убедитесь, что при неисправности защиты массив автоматически переключается в безопасный режим.
• Не отключайте flush и подтверждения записи ради красивых результатов синтетического теста.
• Сопоставьте кэш массива с кэшем гипервизора, QEMU и гостевой ОС.

Tiering, дедупликация и сжатие

Автоматическое распределение по уровням перемещает горячие блоки на SSD, а холодные, на HDD. Это экономит дорогую емкость, но создает фоновый трафик перемещения и меняет задержку в течение суток. Измеряйте hit ratio, объем перемещаемых данных, загрузку контроллеров и p95 latency.

Дедупликация эффективна для похожих виртуальных дисков, шаблонов и VDI. Для зашифрованных данных, сжатых файлов и случайных записей экономия может быть небольшой, а нагрузка на CPU и метаданные вырастет. Сжатие обычно помогает последовательным и повторяющимся данным, но его эффект зависит от процессоров контроллера и профиля I/O.

Включайте эти функции на тестовом пуле. Сравните показатели до и после: полезную емкость, IOPS, latency, CPU контроллеров, задержку операций snapshot и скорость восстановления.

Общие правила подключения хостов к СХД

Подключение считается отказоустойчивым, когда отказ любого одного кабеля, порта, HBA, сетевого коммутатора или контроллера не прекращает доступ к datastore. Проверяйте физическую топологию, а не только количество отображаемых путей.

Multipath, MPIO и ALUA

Multipath объединяет несколько путей к одному LUN и выбирает маршрут для каждого I/O. MPIO, термин Windows, выполняет ту же задачу в Hyper-V. ALUA сообщает, какие пути оптимальны для конкретного контроллера. Гипервизор должен использовать эти сведения, а не распределять трафик случайно.

Два порта на одном коммутаторе не защищают от отказа этого коммутатора. Две VLAN на одном физическом uplink тоже не создают независимый путь. Используйте раздельные коммутаторы или fabric, разные контроллеры и отдельные HBA или сетевые порты.

Практические параметры MPIO, диагностика путей и сценарии отказа собраны в руководстве по подключению внешних хранилищ к виртуальным серверам.

Сеть хранения и контроль перегрузки

• Выделите VLAN или физические сети под iSCSI, NFS, миграцию и backup.
• Проверьте скорость всех портов. Один uplink 10 Gb/s перед несколькими 25 Gb/s портами создает скрытое узкое место.
• Проверьте ошибки интерфейсов, drops, pause frames, retransmit и загрузку uplink.
• Согласуйте MTU на всей цепочке. Jumbo frames дают эффект только при одинаковой настройке всех участков.
• Задайте QoS для storage-трафика, если он проходит через общую сеть.

Теоретическая скорость 10 GbE составляет примерно 1,25 GB/s до учета протокольных накладных расходов. Два интерфейса не удвоят производительность, если массив ограничен одним контроллером или одной группой дисков.

Идентификация LUN и единая конфигурация хостов

Для каждого LUN фиксируйте имя, серийный номер, размер, назначение, группу хостов, владельца и резервную копию конфигурации. Не ориентируйтесь только на порядковый номер устройства, который может измениться после rescan.

• Проверьте zoning или ACL, LUN masking и список разрешенных initiator.
• Сверьте серийные номера и идентификаторы устройств на всех узлах кластера.
• Убедитесь, что каждый хост видит одинаковый набор общих ресурсов.
• Синхронизируйте время на хостах, массиве, коммутаторах и системах мониторинга.
• Документируйте версии драйверов, прошивок и параметры multipath перед изменениями.

Настройка хранилищ в VMware vSphere

Порядок для vSphere такой: проверить совместимость, подготовить LUN или NFS-экспорт, настроить доступ всех ESXi, выполнить rescan, проверить пути, создать datastore и провести тестовые операции. Все действия с форматированием и расширением выполняйте после проверки идентификатора тома и резервной копии.

VMFS на iSCSI или Fibre Channel

1. Создайте LUN на массиве и назначьте его группе ESXi-хостов. Проверьте размер, тип доступа, контроллер-владелец и policy ALUA.
2. Для iSCSI настройте initiator на каждом ESXi и подключите динамическое обнаружение target. Для FC проверьте WWPN, zoning и LUN masking.
3. На каждом хосте выполните rescan storage adapters. Убедитесь, что устройство имеет одинаковый NAA-идентификатор на всех узлах.
4. Проверьте число путей и их состояние. Для каждого LUN должны отображаться независимые соединения к нужным контроллерам.
5. Создайте VMFS6 на одном хосте, затем подключите datastore к остальным узлам. Не форматируйте устройство повторно на каждом хосте.
6. Создайте тестовую ВМ, проверьте чтение, запись, clone, snapshot, vMotion и восстановление доступа после отключения одного пути.

VMFS6 использует современный формат с фиксированной логикой блоков, поэтому старый выбор размера блока из VMFS3 не переносится на него. Перед расширением datastore проверьте правильность LUN, свободное место в пуле и поддержку операции массивом.

esxcli storage core device list
esxcli storage core path list

Эти команды помогают сопоставить устройство и пути, но итоговую оценку делайте по идентификаторам LUN, статусу paths и телеметрии массива.

NFS datastore в vSphere

1. Создайте экспорт на массиве, укажите адреса ESXi и разрешенный тип доступа.
2. Выберите NFSv3 или NFSv4.1 после проверки совместимости с версией vSphere, массивом и backup-системой.
3. Настройте VMkernel-интерфейс и маршрутизацию для NFS. При нескольких интерфейсах проверьте, действительно ли выбранная версия и массив поддерживают нужную схему multipath.
4. Подключите один datastore к тестовому ESXi, создайте ВМ и выполните операции clone, snapshot и миграции.
5. Подключите datastore к остальным узлам и убедитесь, что права, имена и доступность совпадают.

Не оценивайте NFS только по скорости копирования большого файла. Проверьте операции с множеством виртуальных дисков и снапшотов, потому что они сильнее нагружают метаданные и очереди контроллера.

Multipath и политики хранения в vSphere

Для блокового datastore проверьте SATP и PSP, активные и standby-пути, ALUA и выбранный режим Round Robin. Используйте профиль производителя, если массив требует специального claim rule. Изменение PSP на production-LUN выполняйте после проверки на тестовом устройстве.

Storage DRS распределяет ВМ между datastore по свободному месту и задержке. Он не заменяет QoS и не устраняет перегрузку контроллера. Storage policies связывают требования ВМ с уровнем RAID, tier, репликацией или лимитом IOPS, но политика должна соответствовать реальным возможностям массива.

vVol передает массиву больше информации о каждом виртуальном диске и позволяет применять granular snapshot, репликацию и QoS. Для работы нужны VASA Provider, поддержка массива, protocol endpoint и согласованные storage policies. Сначала проверьте резервное копирование и восстановление, затем переносите критичные ВМ.

Настройка хранилищ в Microsoft Hyper-V

Hyper-V использует другую модель доступа. Общий LUN подключают к узлам Failover Cluster, после чего том добавляют в Cluster Shared Volumes. Для файловых хранилищ можно использовать SMB 3.0, но его функции и производительность нужно проверять на конкретной версии Windows Server и NAS.

NTFS и ReFS для виртуальных дисков

Выбирайте файловую систему по версии Windows Server, требованиям резервного ПО и поддержке конкретных операций. ReFS не делает любой storage быстрее: при перегруженном LUN задержка останется высокой. NTFS удобнее там, где критична совместимость со старыми инструментами и гостевыми сценариями.

CSV и общие тома кластера

1. Подключите LUN к каждому узлу кластера через iSCSI или FC.
2. Проверьте одинаковый размер, серийный номер и число путей на всех узлах.
3. Добавьте диск в Failover Cluster Manager и переведите его в Cluster Shared Volumes.
4. Создайте на CSV NTFS или ReFS с учетом матрицы совместимости Windows Server и backup-системы.
5. Разместите тестовую ВМ, проверьте live migration, отказ одного пути и состояние CSV.

При проблемах с доступом CSV может перейти в redirected I/O. Тогда часть операций идет через другой узел, а задержка растет. Следите за событиями кластера и сетевой нагрузкой, чтобы не принять redirected I/O за неисправность дисков.

MPIO, iSCSI и Fibre Channel в Hyper-V

1. Установите компонент MPIO на каждом узле: Install-WindowsFeature -Name Multipath-IO.
2. Для iSCSI настройте Initiator, подключите все target-порты и включите persistent connections.
3. Для FC проверьте HBA, zoning, WWPN и LUN masking в обеих fabric.
4. В MPIO добавьте устройство по идентификатору производителя или выполните автоматическое обнаружение DSM.
5. Проверьте несколько активных путей, политику балансировки и состояние после перезагрузки.

mpclaim -s -d

Проверяйте Event Viewer, MPIO и Failover Cluster Manager. События lost path, reservation conflict, reset и timeout нужно сопоставлять со временем роста latency на массиве.

ODX и операции разгрузки на СХД

ODX переносит операции копирования, создания и некоторых преобразований данных на массив. Хост передает storage token, а СХД выполняет копирование внутри своих ресурсов. Это снижает нагрузку на CPU и сеть Hyper-V, если исходный и целевой тома поддерживают offload.

• Проверьте поддержку ODX на Windows Server, контроллере и конкретном типе тома.
• Запустите копирование тестового VHDX и измерьте время, загрузку CPU хоста, сетевой трафик и счетчики массива.
• Проверьте журнал Microsoft-Windows-OffloadedDataTransfers/Operational.
• Убедитесь, что fallback не маскируется под успешный offload. Несовместимый том может выполнить обычное копирование через хост.

ODX не ускоряет все операции. Шифрование, разные массивы, неподдерживаемая файловая система, ограничения backup-приложения и отсутствие совместимого пути приводят к обычной передаче данных.

Настройка хранилищ в KVM и libvirt

KVM не предлагает одну обязательную модель datastore. Производительность зависит от backend, формата образа, QEMU, virtio-контроллера, режима кэша и файловой системы хоста. Перед настройкой зафиксируйте, нужна ли общая емкость, live migration, локальная автономность или горизонтальный рост.

LVM, LVM-thin, NFS и iSCSI

LVM дает прямой доступ к блочному тому. LVM-thin требует мониторинга свободного места и metadata pool. При заполнении thin pool операции записи могут завершаться ошибками, даже если логический объем ВМ еще не исчерпан.

Для короткого тестового стенда без покупки отдельной СХД можно использовать облачную инфраструктуру Timeweb Cloud, но профиль дисков, сетевые лимиты и модель отказоустойчивости нужно измерить отдельно от production-массива.

QCOW2 и raw

Для production-базы на быстром локальном или SAN-хранилище часто выбирают raw или блочный LVM-том. QCOW2 удобен для лабораторий, шаблонов и сценариев с контролируемыми снапшотами. Длинные цепочки backing files регулярно объединяйте после резервного копирования и проверки свободного места.

qemu-img info vm01.qcow2
virsh domblklist vm01

Команды помогают проверить фактический формат и подключенные устройства. Конвертацию образов выполняйте только при наличии резервной копии и окна обслуживания.

Параметры QEMU и дисковый кэш

Virtio-blk подходит для простой конфигурации с небольшим числом дисков. Virtio-scsi удобнее для нескольких дисков, горячего подключения и настройки iothread. Выбирайте драйвер после теста гостевой ОС, а не по названию устройства.

• cache=none уменьшает двойное кэширование при корректной поддержке direct I/O на backend.
• cache=writeback может ускорить запись, но повышает требования к flush, защите питания и поведению гостевой ОС.
• discard=unmap позволяет гостю передавать информацию об освобожденных блоках, если это поддерживают QEMU, backend, массив и файловая система.
• iothread помогает вынести обработку очереди диска, когда одной ВМ нужны несколько виртуальных устройств и высокое число операций.
• Режим unsafe применяйте только для временных тестов, где потеря последних записей допустима.

Согласуйте flush и cache на четырех уровнях: гостевая ОС, виртуальный контроллер, QEMU и СХД. Противоречивые настройки дают либо лишнюю задержку, либо риск потери подтвержденных данных.

Распределенные хранилища и live migration

Общее хранилище позволяет перенести состояние ВМ между узлами без копирования всего диска. При локальных дисках используется block migration или репликация, поэтому требуются дополнительная пропускная способность, место для временной копии и контроль согласованности.

Для Ceph следите за состоянием MON, OSD, PG, свободным местом, recovery и backfill. Восстановление реплик конкурирует с I/O виртуальных машин. После отказа диска или узла временная задержка может вырасти, поэтому измеряйте p95 и p99, а не только средние IOPS.

Live migration проверяйте на ВМ с небольшим диском и затем на типичной production-конфигурации. Фиксируйте время переноса, объем переданных данных, задержку ВМ и реакцию приложения.

Аппаратное ускорение: VAAI, VVol, ODX и кэширование

Offload-функции сокращают работу хоста, но не создают производительность из ничего. Поддержка должна совпадать на уровне массива, гипервизора, драйвера, версии протокола и конкретного datastore.

VAAI в VMware vSphere

VAAI передает часть операций vSphere на массив:

• hardware-assisted copy, или XCOPY, ускоряет копирование и клонирование внутри поддерживаемого массива;
• block zeroing ускоряет заполнение блоков нулями;
• ATS помогает согласовывать блокировки VMFS;
• UNMAP возвращает массиву освобожденные блоки thin datastore.

Для NFS возможны отдельные NAS-плагины и операции file clone, reserve space и snapshot offload. Наличие флажка поддержки не доказывает фактическую работу функции.

1. Проверьте статус VAAI на конкретном устройстве и datastore.
2. Создайте тестовую ВМ и выполните clone или zeroing.
3. Сравните CPU и сетевой трафик ESXi до и после операции.
4. Проверьте счетчики операций на массиве и логи vSphere.

Если массив возвращает ошибку offload, vSphere может перейти к обычной обработке на хосте. Причины включают неподдерживаемый формат, разные пул или контроллер, неверный path, ограничение лицензии и несовместимость прошивки.

VVol и управление на уровне виртуального диска

VVol представляет виртуальные диски и связанные объекты как сущности, которыми управляет СХД. Политика vSphere может задавать QoS, снапшоты, репликацию и размещение для конкретной ВМ или диска, а не для большого общего VMFS.

Для VVol нужны VASA Provider, storage container, protocol endpoint и совместимые политики. Перед переходом проверьте:

• регистрацию и отказоустойчивость VASA Provider;
• создание и удаление виртуальных дисков;
• snapshot, clone, vMotion и восстановление из backup;
• поведение при недоступности одного контроллера;
• мониторинг QoS и отображение latency на уровне ВМ.

VVol оправдан, когда нужны granular-политики и операции массива для большого числа ВМ. При простом кластере с небольшим количеством datastore традиционный VMFS может быть проще для сопровождения.

ODX в Hyper-V

ODX ускоряет операции, где Windows Server и СХД могут обменяться токенами и выполнить копирование внутри массива. Проверяйте не только поддержку функции, но и конкретную пару томов, файловую систему, тип операции и резервное ПО.

Признак успешной разгрузки, резкое снижение сетевого трафика и CPU хоста при сохранении нормальной активности контроллеров. Если сетевой трафик остается высоким, сравните журнал offload, счетчики массива и результат копирования на тестовых VHDX.

Кэш, tiering и QoS для виртуальных машин

Storage QoS ограничивает noisy neighbor и позволяет выделить минимальные или максимальные IOPS для критичных ВМ. Не ставьте одинаковые лимиты всем дискам: база данных, backup и тестовая ВМ потребляют ресурсы по-разному.

• Кэш чтения помогает при повторяющемся доступе и горячих блоках.
• Кэш записи снижает latency bursts, если защищен от потери питания.
• Tiering перемещает данные между SSD и HDD, но создает дополнительный фоновой I/O.
• Дедупликация и сжатие экономят емкость, но увеличивают нагрузку на CPU и метаданные.

Измеряйте hit ratio, latency, загрузку контроллеров, объем фоновых операций и фактические IOPS каждой группы ВМ. Функция считается полезной только при измеримом улучшении для нужной нагрузки.

Проверка производительности и мониторинг после настройки

До запуска рабочих ВМ создайте базовую линию. Она нужна для сравнения после расширения пула, обновления прошивки, роста числа ВМ и отказа диска.

Базовая линия до запуска production

1. Проверьте пустой массив и каждый storage pool отдельно.
2. Измерьте случайный доступ блоками 4, 8 и 64 KiB при разных долях чтения и записи.
3. Измерьте последовательное чтение и запись блоками 1 MiB и крупнее.
4. Повторите тест при нескольких значениях queue depth.
5. Запустите синтетический тест на выделенном файле или тестовой ВМ, не используя raw production-диск.
6. Повторите замер с включенным snapshot, tiering или дедупликацией, если эти функции будут работать в production.

fio --name=vm-test --filename=/test/bench.dat --size=20G --rw=randrw --rwmixread=70 --bs=8k --iodepth=32 --numjobs=4 --runtime=300 --time_based --direct=1

Команду запускайте только на тестовом файле или отдельном томе. Результат fio нельзя переносить на прикладную нагрузку без пилота: база данных, VDI и backup создают разные очереди и размеры блока.

Мониторинг на уровнях СХД, гипервизора и ВМ

Сопоставляйте время события на всех уровнях. Высокая latency ВМ при нормальном массиве может возникать из-за очереди в гостевой ОС, virtio-драйвера или CPU ready. Высокая latency datastore вместе с queue depth и загрузкой контроллера указывает на storage path или сам массив.

Проверка отказоустойчивости

Проверяйте отказ одного компонента в согласованное окно с резервной копией и наблюдением за приложением:

• отключите один сетевой кабель или iSCSI-порт;
• проверьте отказ одного FC-порта или HBA;
• отключите один коммутатор в dual-fabric схеме;
• проверьте переключение контроллера массива;
• смоделируйте отказ одного диска и измерьте рост latency во время rebuild;
• проверьте возврат к штатной конфигурации после восстановления пути.

Зафиксируйте время переключения, потерянные I/O, рост p95 и p99 latency, сообщения гипервизора и состояние приложений. Не проверяйте одновременно несколько отказов, если это не отдельное DR-упражнение.

Типовые ошибки при настройке дисковых массивов

Один datastore или пул для всех нагрузок

Смешивание баз данных, VDI, backup и тестовых ВМ создает noisy neighbor. Backup начинает длинную последовательную запись, база данных формирует случайную очередь, а VDI добавляет короткие пики входа пользователей.

Признак: latency растет в часы backup, а CPU и сеть хоста остаются свободными.

Проверка: сравните IOPS и queue depth по ВМ, datastore, пулу и контроллеру за один временной интервал.

Исправление: разделите классы по пулам, задайте QoS или перенесите backup на отдельный ресурс и канал.

Неправильный multipath и отсутствие независимых путей

Частая ошибка, два интерфейса подключены к одному коммутатору, а MPIO или SATP отправляет трафик по неоптимизированному пути. При отказе кабеля ВМ продолжают работать, но задержка резко увеличивается.

Признак: часть путей отображается как dead, standby или non-optimized, хотя администратор считает схему резервной.

Проверка: сопоставьте path state, ALUA, WWPN или initiator IQN, коммутатор и контроллер массива.

Исправление: разделите fabric, настройте правильный DSM или PSP, исправьте zoning и повторите отказной тест.

В кластерах Hyper-V и KVM добавьте контроль quorum и fencing. При потере связи узлы не должны одновременно писать в один ресурс. Иначе возникает split-brain, который повреждает данные быстрее, чем отказ одного диска.

Избыточные snapshot, thin provisioning и переполнение

Старые snapshot удерживают блоки и увеличивают объем операций записи. При thin provisioning логический свободный объем может сохраняться, пока физический пул уже заполнен. Одновременный reclaim на нескольких datastore усиливает очередь.

Признак: задержка растет постепенно, snapshot становятся большими, а свободное место в pool уменьшается быстрее ожидаемого.

Проверка: посмотрите возраст и размер snapshot, заполнение data и metadata pool, эффективность дедупликации и очередь reclaim.

Исправление: установите срок жизни snapshot, удаляйте их через проверенный регламент, оставляйте резерв свободного места и не включайте агрессивный reclaim во время пиковых операций.

Непроверенные offload и настройки кэша

Включенный флажок VAAI или ODX не означает, что операция выполняется на массиве. Несовместимый datastore, firmware, путь или формат может переключить работу на хост.

Признак: clone или копирование потребляет CPU и сеть хоста так же, как до включения offload.

Проверка: сопоставьте счетчики массива, сетевой трафик, CPU и журналы конкретной операции.

Исправление: подтвердите поддержку на всей цепочке, обновите совместимые компоненты по плану и оставьте fallback, если функция нестабильна.

Jumbo frames, write-back, discard и cache=none проверяйте отдельно. Одновременное изменение нескольких параметров не позволяет понять причину улучшения или деградации.

Пошаговый план настройки и итоговый чек-лист

Переходите к рабочим ВМ после последовательной проверки ресурсов, путей и восстановления. Каждая стадия должна иметь контрольную точку и понятный план отката.

Чек-лист перед вводом в эксплуатацию

• Сверены версии гипервизора, драйверов, HBA, сетевых карт, прошивок и массива.
• Рассчитаны IOPS, latency, throughput, емкость, рост и запас под rebuild.
• Выбран RAID с учетом записи, размера дисков, времени восстановления и допустимой деградации.
• Защищен write-back cache, проверены батарея, конденсаторы и поведение при неисправности.
• Созданы независимые пути через разные кабели, порты, коммутаторы и контроллеры.
• Настроены zoning, LUN masking, ACL, MPIO, SATP, PSP, ALUA или multipathd.
• Каждый узел видит одинаковые LUN или NFS datastore с корректными идентификаторами.
• Проверены свободное место, thin pool, snapshot, дедупликация, сжатие и tiering.
• Создана базовая линия синтетической и пилотной нагрузки.
• Проверены live migration, clone, snapshot, backup и восстановление отдельного файла или ВМ.
• Выполнен отказной тест одного пути, порта, коммутатора, контроллера и диска.
• Зафиксированы метрики, владельцы алертов, порядок отката и окно обслуживания.

Чек-лист ежемесячной проверки

• Сравнивайте IOPS, throughput, среднюю latency, p95 и p99 с базовой линией.
• Проверяйте заполнение пулов, metadata, thin provisioning и рост snapshot.
• Проверяйте SMART, wear SSD, температуру, media errors и состояние rebuild.
• Ищите dead, degraded и non-optimized paths на всех хостах.
• Сверяйте загрузку контроллеров, cache hit ratio и фоновые операции tiering.
• Проверяйте сетевые ошибки, drops, MTU и oversubscription.
• Проводите тестовое восстановление из backup по утвержденному графику.
• Сверяйте конфигурацию с документацией после обновления прошивок и драйверов.

Когда пора менять архитектуру

Оптимизация отдельных параметров перестает помогать, когда первопричина связана с пределами архитектуры. Планируйте новую схему, если выполняется хотя бы один пункт:

• p99 latency постоянно превышает целевое значение даже после разделения нагрузок и исправления multipath;
• контроллеры, uplink или HBA работают у предела при обычной production-нагрузке;
• rebuild не укладывается в допустимое окно, а пул долго остается в degraded-состоянии;
• свободной емкости не хватает для роста, snapshot, миграции и восстановления;
• recovery-трафик распределенного хранилища регулярно вытесняет I/O ВМ;
• массив не поддерживает нужные функции VAAI, VVol, ODX, QoS или репликации;
• текущая сеть не позволяет создать независимые пути и выделить достаточную полосу;
• резервное копирование и DR не укладываются в заданное окно.

Рабочий алгоритм выглядит так: инвентаризация, расчет нагрузки, выбор протокола, проектирование RAID и путей, настройка массива, подключение тестового хоста, проверка multipath, создание VMFS, NFS datastore, CSV или KVM pool, нагрузочный тест, пилот, перенос production и мониторинг. Перед каждым необратимым действием проверяйте backup и точку возврата.

Главный критерий удачной конфигурации, предсказуемая задержка под реальной нагрузкой, сохранение доступа при отказе одного компонента и подтвержденное восстановление данных. Объем массива и заявленные IOPS имеют смысл только вместе с этими проверками.