СХД для виртуализации в 2026 году: как выбрать систему хранения под VMware и Proxmox

Что меняется в выборе СХД для виртуализации в 2026 году

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

Рабочий порядок такой. Считаете требуемые IOPS и допустимую задержку, выбираете протокол (NFS, iSCSI, Fibre Channel, NVMe-oF или гиперконвергентный слой vSAN и Ceph), проверяете поддержку консистентных снапшотов, и только после этого подбираете железо и лицензии. Статья идёт по этому же маршруту: метрики, протоколы, снапшоты, конфигурации, ошибки, чек-лист.

Три вопроса, на которые нужно ответить до выбора СХД

1. Какой профиль нагрузки у виртуальных машин? СУБД требуют блочного доступа с блоком 8-16 КБ и задержкой ниже 1 мс. VDI-десктопы генерируют тысячи мелких операций по 4 КБ. Файловые серверы упираются в пропускную способность. CI/CD-раннеры дают резкие пики на запись.
2. Какая платформа? VMware vSphere даёт VMFS, VAAI, vVols и vSAN. Proxmox VE работает с ZFS, Ceph, LVM-thin, NFS и iSCSI, а кластер и бэкапы входят в подписку без лицензирования по ядрам.
3. Какой бюджет и требования к отказоустойчивости? Нужны ли синхронная репликация, два независимых пути к данным, гарантированное время восстановления после отказа узла.

Ответы сужают выбор до 2-3 вариантов. Пятьдесят ВМ с PostgreSQL и 200 VDI-десктопов требуют разного хранилища: в первом случае критична стабильная задержка на мелких блоках, во втором - стоимость гигабайта и способность держать массовые случайные чтения.

Что изменилось в 2024-2026: Broadcom, Proxmox и NVMe-oF

Broadcom закрыла сделку по покупке VMware в ноябре 2023 года и перевела продукты на подписку. Изменились состав пакетов (vSphere Foundation, VMware Cloud Foundation), правила подсчёта ядер при лицензировании и условия поставки vSAN 8. Конкретные суммы зависят от редакции, числа ядер и договора, поэтому перед расчётом TCO запрашивайте актуальные прайсы у вендора или партнёра.

Реакция инфраструктурных команд: часть компаний оставила vSphere, но отказалась от vSAN в пользу внешнего массива, часть перевела тестовые и периферийные контуры на Proxmox VE. Ветка Proxmox VE 8.x работает на Debian 12, следующее поколение Proxmox VE 9 перешло на Debian 13. Обе версии поддерживают ZFS, Ceph, NFS, iSCSI и LVM-thin, а Proxmox Backup Server входит в подписку.

NVMe-oF перестал быть лабораторной темой. vSphere 8 поддерживает NVMe-oF через TCP и RoCE, производители массивов предлагают сертифицированные конфигурации. В Proxmox NVMe-oF настраивается на уровне ядра и требует сетевого адаптера с поддержкой RDMA либо хорошо настроенного TCP-стека на 25-100 GbE.

Ключевые метрики СХД: IOPS, задержка, пропускная способность

Три метрики описывают хранилище с разных сторон. IOPS показывают, сколько операций ввода-вывода в секунду обрабатывает массив. Задержка (latency) показывает, сколько миллисекунд ждёт ответа виртуальная машина. Пропускная способность (throughput) показывает объём данных в мегабайтах в секунду, и она упирается в интерфейс, когда блок крупный.

Как посчитать IOPS и задержку под конкретную нагрузку

Формула простая: требуемые IOPS = сумма IOPS всех ВМ × коэффициент одновременности. Коэффициент берут в диапазоне 0,6-0,8, потому что пиковая активность всех машин одновременно почти не встречается. Пример: 30 ВМ с СУБД по 500 IOPS каждая дают 30 × 500 × 0,7 = 10 500 IOPS.

Профиль нагрузки меняет расчёт. СУБД и брокеры сообщений дают около 70% чтения и 30% записи при блоке 8-16 КБ. VDI и терминальные фермы - примерно 80/20 при блоке 4 КБ. Бэкапы и репликация - последовательная запись крупными блоками, здесь важнее пропускная способность и стабильность, а не IOPS.

Задержка важнее пиковых IOPS. Массив на 20 000 IOPS с задержкой 15 мс проигрывает массиву на 12 000 IOPS с задержкой 2 мс: виртуальные машины на втором будут отзывчивее. Ориентиры: до 1 мс - комфортно для СУБД и кластерных сервисов; 1-5 мс - рабочий диапазон для большинства задач; 5-10 мс - заметно на интерактивных сервисах; выше 10 мс - деградация, рост очередей и таймауты приложений.

Как проверить реальную производительность СХД до ввода в эксплуатацию

Синтетический тест нужен с профилем, близким к боевой нагрузке. В fio задают режим randread или randwrite, iodepth 32-64, numjobs 4-8, размер блока 4 или 8 КБ, длительность от 5 минут. Смотрят на p95 и p99 задержки, а не на среднее. Средние 2 мс при p99 в 40 мс означают, что пользователи будут ловить паузы.

Порядок проверки: сначала один LUN или датастор и один хост, затем несколько хостов одновременно, затем тест с параллельно идущим бэкапом. Для VMware используют VMware I/O Insight и esxtop со счётчиками DAVG и KAVG, где DAVG показывает время ответа устройства, а KAVG - задержку внутри ядра гипервизора. Для Proxmox работают fio внутри ВМ и на хосте, плюс iostat и zpool iostat для ZFS.

Тесты без учёта кэша массива завышают результат: запись уходит в кэш СХД, а деградация начинается после его переполнения. Пятиминутный прогон честнее тридцатисекундного. Если массив выдаёт разные цифры на одном и на восьми потоках, он упирается в контроллер или в сеть, и запас IOPS здесь мнимый.

Протоколы доступа к СХД: NFS, iSCSI, Fibre Channel и vSAN

Протокол определяет, как гипервизор видит хранилище: файловый датастор, блочное устройство или распределённый слой внутри кластера. Разбор отличий NAS и SAN с цифрами по задержке и TCO собран в отдельном материале про выбор между NAS и SAN.

VMware использует VMFS поверх блочных LUN, а в Proxmox роль локального блочного слоя чаще играет ZFS или LVM-thin. Практические отличия этих схем, включая multipath и аппаратные ускорения, разобраны в руководстве по дисковым массивам для виртуальных машин.

NFS и iSCSI: что выбрать для Proxmox VE

В Proxmox VE оба протокола добавляются через Datacenter, Storage. NFS проще: монтируется, поддерживает снапшоты на стороне массива, подходит для ISO-образов, шаблонов и бэкапов. Минус в том, что файловый доступ накладывает ограничения на блокировки и работу некоторых СУБД.

iSCSI даёт блочный доступ и LUN, на котором создают LVM-thin или ZFS. Такой вариант ближе к СУБД: предсказуемая задержка, поддержка multipath, понятная деградация. Настройка сложнее: нужны target, initiator, multipath.conf и проверка всех путей. Если планируете ZFS поверх iSCSI, учитывайте двойной кэш: ARC на хосте и кэш массива конкурируют за одни данные, поэтому корректный recordsize и режим синхронизации важнее размера ARC. Пошаговый разбор с готовыми конфигурациями есть в статье про iSCSI-хранилище для Proxmox VE на TrueNAS и ZFS.

Рабочая схема выглядит так: NFS для ISO, шаблонов и бэкапов, iSCSI для дисков ВМ с СУБД. Смешивать протоколы на одном интерфейсе допустимо, но трафик стоит развести по VLAN, иначе бэкап в момент пика съест задержку у транзакционной базы.

Fibre Channel и vSAN: когда оправданы затраты

Fibre Channel даёт предсказуемую задержку, изоляцию трафика и дисциплину очередей, которую сложно получить на iSCSI. Цена: HBA в каждом хосте, два коммутатора, отдельная фабрика, лицензии и обучение персонала. FC оправдан там, где SLA требует задержки ниже 1 мс и уже есть SAN-инфраструктура.

vSAN 8 работает по гиперконвергентной модели: диски стоят в хостах, кластер минимум из трёх узлов, сети 25-100 GbE. Лицензия на vSAN входит в часть пакетов VMware, поэтому TCO считают вместе с лицензиями vSphere и сетевым оборудованием. В Proxmox ту же задачу закрывает Ceph: диски в узлах, сеть 25 GbE, минимум три узла, отдельная сеть для репликации.

NVMe-oF: перспективы в 2026 году

NVMe-oF переносит на сеть команды NVMe и снимает ограничения SCSI-стека. Задержка уходит ниже 1 мс, IOPS на один хост измеряются сотнями тысяч. Для vSphere 8 нужны сертифицированный массив и поддержка NVMe-oF TCP или RoCE на адаптерах. В Proxmox конфигурация собирается вручную: модуль ядра nvme-rdma или nvme-tcp, сеть без потерь, тюнинг очередей.

Массовым решением NVMe-oF пока не стал: дорогие адаптеры, требования к сети, ограниченный список проверенных сочетаний массива и гипервизора. Для нового проекта с требованием задержки ниже 1 мс его стоит протестировать до закупки классической FC-инфраструктуры, потому что разница в цене сокращается, а запас по IOPS заметно выше.

Консистентные снапшоты и резервное копирование

Консистентный снапшот требует квиесцинга файловой системы внутри ВМ: перед снятием снимка гостевые службы сбрасывают буферы и останавливают запись. Без квиесцинга копия СУБД может содержать незавершённую транзакцию, и восстановление превратится в часы ручной работы.

Как работают консистентные снапшоты в VMware

VMware Snapshot с включённой опцией quiesce опирается на VMware Tools и службу VSS внутри Windows либо на sync для Linux. Гипервизор просит гостя сбросить буферы, снимает снимок файловой системы, затем делает снимок диска. Условия: установленные VMware Tools, свободное место на датасторе, отсутствие уже открытых снапшотов той же ВМ.

Снапшот не заменяет бэкап. Он лежит на том же томе, растёт вместе с изменениями и при долгом хранении рвёт цепочку, замедляя запись. Рабочее правило: держать снапшоты от 24 до 72 часов, дальше только полноценная копия. Для бэкапа выбирают решения с интеграцией VSS и поддержкой VMware API, иначе консистентность не гарантируется и восстановление базы становится лотереей.

Как работают консистентные снапшоты в Proxmox VE

Proxmox VE вызывает QEMU Guest Agent, который внутри гостя выполняет fsfreeze, а после снятия снимка размораживает файловую систему. Снапшоты доступны на ZFS, Ceph и LVM-thin, то есть там, где слой хранения поддерживает снимки. Для ВМ с СУБД гостевой агент обязателен, а после настройки стоит проверить по журналам, что fsfreeze отрабатывает без ошибок: PostgreSQL и MySQL при проблемах с заморозкой пишут предупреждения.

Резервное копирование строят на Proxmox Backup Server: режим snapshot использует снапшот ZFS или Ceph, дедупликация уменьшает объём, команда verify подтверждает целостность копии. Расписание без регулярной проверки восстановления оставляет иллюзию защиты, поэтому раз в квартал стоит поднимать ВМ из копии на отдельном стенде и сверять контрольные суммы таблиц.

Практические конфигурации СХД под VMware и Proxmox

Ниже три рабочие конфигурации под разные бюджеты. Цифры IOPS даны как ориентир при типовом профиле нагрузки, реальные значения зависят от модели дисков, контроллера и сети. Разбор программных слоёв хранения (ZFS, Ceph, TrueNAS) с требованиями к железу есть в материале про программные системы хранения для виртуализации и контейнеров.

Бюджетный вариант: Proxmox VE + ZFS

Три хоста Proxmox VE, в каждом два NVMe в ZFS mirror под ВМ, отдельный SATA-пул под бэкапы и ISO. Репликация ВМ между хостами через ZFS send/receive по расписанию, в асинхронном режиме. Бэкап - на отдельный сервер с Proxmox Backup Server, желательно вне основной стойки.

Ожидаемые цифры: 50 000-100 000 IOPS на хост при задержке ниже 1 мс на локальных NVMe, 30-50 ВМ средней нагрузки. Ограничения честные: общей СХД нет, при отказе хоста ВМ поднимается на другом узле с задержкой относительно последней репликации, часть данных при аварии теряется. Стоимость за терабайт полезной ёмкости здесь минимальная, потому что не нужны двойные контроллеры и фабрика. Для внешней площадки под копии подойдут облачные серверы и объектное хранилище, например Timeweb Cloud, где ресурсы меняются под объём бэкапов.

Средний вариант: VMware + iSCSI all-flash

Три или четыре хоста ESXi, внешний all-flash массив с iSCSI, multipath в режиме round-robin, отдельная сеть 10 или 25 GbE под storage-трафик, jumbo frames на всех узлах пути. Датастор VMFS размещают на LUN, для критичных ВМ включают VAAI.

Ожидаемые цифры: 100 000-300 000 IOPS, задержка 1-3 мс, 100-200 ВМ. Критичные настройки: два независимых пути к массиву, политика round-robin с ограничением числа операций на путь, отдельные VLAN, проверка MTU запросом ping с запретом фрагментации. Ошибки в multipath и MTU дают больше проблем, чем выбор вендора массива. Готовые рецепты настройки MPIO и диагностики собраны в руководстве по интеграции дисковых массивов с VMware, Hyper-V и Proxmox.

Enterprise-вариант: Fibre Channel или vSAN

Fibre Channel: два HBA на хост, две независимые фабрики, all-flash массив, задержка ниже 1 мс, IOPS выше 500 000 на кластер. Такой контур выбирают под СУБД с жёстким SLA и большие VDI-фермы, где пауза в 20 мс видна сотням пользователей сразу.

vSAN 8: четыре и более хоста, NVMe под кэш и ёмкость, сеть 25 или 100 GbE, отдельные дисковые группы. В Proxmox аналог - Ceph на NVMe с сетью 25 GbE и отдельным сегментом для репликации. В обоих случаях планировать нужно сеть и диски, а не только лицензии: разбалансированный Ceph или vSAN падает по производительности при выходе одного узла, потому что вся нагрузка перераспределяется на оставшиеся.

Типичные ошибки, ведущие к деградации виртуальных машин

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

Ошибки конфигурации сети хранения

Jumbo frames должны быть настроены на всех узлах пути: гипервизор, коммутаторы, порты массива. Если MTU 9000 стоит только на хостах, пакеты дробятся, и производительность падает ниже, чем при обычных 1500 байтах. Проверка простая: ping с флагом запрета фрагментации и размером пакета 8972 байта. Молчание означает проблему на одном из узлов.

Multipath для iSCSI и Fibre Channel обязателен. Без второго пути отказ адаптера или порта коммутатора останавливает доступ к данным, и кластер теряет узлы. Отдельные VLAN для storage-трафика защищают задержку от бэкапов, репликации и служебного трафика. Если метрики задержки нужно разбирать автоматически по логам esxtop и iostat, для анализа аномалий можно подключить модель через агрегатор API, например AiTunnel, и не держать ручной разбор выгрузок.

Ошибки в снапшотах и бэкапах

Снапшот без квиесцинга - главный источник повреждённых баз. Копия снимается на работающей файловой системе, буферы не сброшены, и восстановленная база требует ручного восстановления журналов. Второй риск - долгоживущие снапшоты: они увеличивают цепочку, замедляют запись и незаметно съедают место на датасторе.

Третий риск - бэкап без проверки восстановления. Копия, которая ни разу не разворачивалась, защиты не даёт. Практика: раз в квартал восстановить одну ВМ на изолированном стенде, сверить целостность данных, зафиксировать время восстановления и сравнить его с целевым RTO.

Как выбрать СХД под свою задачу: пошаговый алгоритм

1. Определите профиль нагрузки и целевые IOPS с задержкой по каждой группе ВМ.
2. Зафиксируйте платформу: VMware vSphere или Proxmox VE, включая требования к кластеру.
3. Выберите протокол: NFS, iSCSI, Fibre Channel, NVMe-oF или гиперконвергентный слой vSAN и Ceph.
4. Проверьте поддержку консистентных снапшотов и совместимость с вашей системой резервного копирования.
5. Оцените TCO: стоимость за терабайт, лицензии VMware или подписка Proxmox, сеть, обучение персонала.
6. Проведите пилот на реальном профиле нагрузки с измерением p95 и p99.
7. Запланируйте мониторинг задержки, занятости датасторов и состояния путей до запуска в продуктив.

Ориентир по соответствию нагрузки, протокола и типа хранилища:

Чек-лист перед покупкой СХД

• Протокол поддерживается платформой без обходных схем и проверен в матрице совместимости.
• Есть интеграция с гипервизором: VAAI для VMware, корректная работа с QEMU Guest Agent для Proxmox.
• Консистентные снапшоты работают с вашими СУБД и подтверждены тестом.
• Массив масштабируется по ёмкости и по производительности без пересборки кластера.
• Вендор даёт документацию, поддержку и возможность пилота на своём оборудовании.
• Сеть соответствует требованиям: 10 или 25 GbE для iSCSI, 25-100 GbE для vSAN и Ceph.
• Расчёт TCO включает лицензии, сеть, диски, обучение и стоимость обслуживания на 3-5 лет.

Начните с расчёта IOPS и задержки для двух крупнейших групп ВМ, затем прогоните fio на тестовом LUN с профилем из пункта один. Если задержка p99 укладывается в целевые 5 мс с запасом на рост, выбор протокола и массива можно фиксировать. Если нет, меняйте сначала протокол и топологию сети, а не вендора: чаще всего именно сеть и multipath определяют, получит ли инфраструктура предсказуемую задержку.