Как выбрать storage для виртуализации: локальные NVMe, SAN, Ceph, vSAN, NFS или iSCSI

Storage для виртуализации нужно выбирать по профилю нагрузки и требованиям к доступности: локальные NVMe подходят для максимальной скорости на одном сервере, SAN и iSCSI — для общего блочного хранилища в кластере, NFS — для более простого файлового подключения, Ceph и vSAN — для распределенного хранилища на нескольких узлах. Универсально лучшего варианта нет: для небольшого стенда важны цена и простота, для кластера с миграцией виртуальных машин — общее хранилище и отказоустойчивость, для баз данных — низкая задержка и стабильная запись, а для роста инфраструктуры — архитектура, которую можно расширять без полной замены.

Storage часто становится главным узким местом виртуализации. На одном физическом сервере может работать десятки виртуальных машин, и каждая из них постоянно обращается к дискам: загружает операционную систему, пишет журналы, обновляет приложения, использует временные файлы, создает резервные копии, работает с базами данных и файловыми сервисами. Если хранилище отвечает медленно, быстрый процессор и большой объем памяти не спасают: виртуальные машины будут запускаться дольше, приложения начнут «подвисать», а резервное копирование станет занимать слишком много времени.

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

Какие параметры важны при выборе storage

Виртуализация чувствительна не только к скорости в мегабайтах в секунду. Для нее важнее сочетание нескольких параметров.

Latency — задержка ответа хранилища. Это время между запросом виртуальной машины и ответом storage. Чем ниже задержка, тем быстрее система реагирует на мелкие операции. Для баз данных, VDI, терминальных серверов и нагруженных приложений задержка часто важнее пиковой скорости.

IOPS — количество операций ввода-вывода в секунду. Этот показатель важен там, где много мелких чтений и записей: базы данных, рабочие столы, почта, корпоративные ERP-системы, большое количество небольших ВМ.

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

Отдельно нужно учитывать предсказуемость. Storage может показывать хорошую среднюю скорость, но давать резкие скачки задержек во время backup, восстановления RAID, resync, snapshot consolidation или массового запуска виртуальных машин. Пользователь замечает не среднюю цифру, а момент, когда приложение зависло.

Что нужно понять до выбора хранилища

Перед сравнением NVMe, SAN, Ceph, vSAN, NFS и iSCSI нужно описать саму инфраструктуру, ответив себе на несколько вопросов:

• Сколько виртуальных машин работает сейчас и сколько будет через год?
• Какие нагрузки там будут: офисные сервисы, базы данных, VDI, веб-приложения, файловые серверы, аналитика, тестовые среды?
• Нужна ли живая миграция виртуальных машин между узлами?
• Какой простой допустим при отказе сервера или хранилища?
• Как будут организовано резервное копирование?

Важно заранее понять, будет ли кластер отказоустойчивым. Если виртуальные машины должны переезжать между гипервизорами без долгого простоя, обычно нужно общее или распределенное хранилище. Если это один сервер без требований к высокой доступности, локальные NVMe могут быть проще и быстрее.

Нужно оценить рост данных. Storage часто покупают «под текущий объем», а через год выясняется, что место занято снимками, резервом под восстановление, журналами, новыми виртуальными машинами и тестовыми копиями. Для Ceph, vSAN и других распределенных систем нужно считать не только полезный объем, но и реплики, резерв под восстановление и свободное место для нормальной работы.

Также нужно честно оценить компетенции команды. Простое хранилище, которое команда умеет обслуживать, часто лучше сложной архитектуры, которую никто не понимает. Распределённые хранилища могут быть мощными решениями, но они требуют мониторинга, правильного проектирования и дисциплины эксплуатации.

Немаловажным вопросом будет и стоимость лицензии и вендорской поддержки, при использовании пропиетарных решений вроде vSAN.

Локальные NVMe: максимальная скорость на одном узле

Локальные NVMe — это накопители, установленные прямо в сервер виртуализации. Виртуальные машины работают с дисками своего физического узла без обращения к внешней системе хранения по сети. Поэтому такой вариант обычно дает минимальную задержку и очень высокую скорость.

Это хороший выбор для одиночного сервера виртуализации, лаборатории, тестовой среды, временных данных, кэша, edge-сценариев и высокопроизводительных ВМ, где высокая доступность организована средствами самих прирожений. Например, база данных может использовать локальные NVMe, если отказоустойчивость реализована на уровне самой базы, а не на уровне гипервизора.

Преимущество локальных NVMe — простая физическая схема. Нет внешней СХД, нет отдельной storage-сети, нет зависимости от коммутаторов. Меньше компонентов — меньше мест, где можно ошибиться. Но за эту простоту приходится платить архитектурными ограничениями.

Если сервер выходит из строя, виртуальные машины на его локальных дисках становятся недоступны. Живая миграция между узлами невозможна или ограничена, если нет репликации, общего хранилища или специальных механизмов миграции гипервизора, которые могут лицензироваться отдельно. Масштабирование тоже идет по серверам: добавили новый узел — получили новые локальные диски, но не единый общий storage-пул.

Локальные NVMe быстрые, но они не решают задачу общей доступности. Для production нужно заранее понимать, как будет работать backup, как быстро можно восстановить ВМ, что произойдет при отказе сервера и как обслуживать узел без простоя. Также важно использовать серверные NVMe, а не потребительские диски. У enterprise-накопителей выше ресурс записи, стабильнее задержки, лучше защита от потери питания и предсказуемее работа под длительной нагрузкой.

SAN: классическое общее хранилище

SAN — это специализированная система блочного хранения, к которой серверы виртуализации подключаются как к общему дисковому ресурсу. Обычно речь идет о Fibre Channel, iSCSI или более современных вариантах на базе NVMe over Fabrics. Для гипервизора такой storage выглядит как набор блочных устройств или LUN, на которых размещаются виртуальные машины.

SAN хорошо подходит для среднего и крупного кластера виртуализации, где нужна живая миграция ВМ, централизованное хранение, управляемая отказоустойчивость и понятные процедуры обслуживания. У зрелых СХД есть задублированные контроллеры, свой кэш, разные варианты RAID, snapshots, репликация, тонкое выделение емкости, дедупликация и другие функции. Broadcom в документации по vSphere Storage описывает разные технологии хранения для ESXi и vCenter, включая блочные, файловые и программно-определяемые варианты storage.

Но SAN не означает автоматическую надежность. Нужно смотреть всю цепочку: контроллеры массива, полки дисков, питание, коммутаторы, пути от серверов, multipath, прошивки, настройки LUN и нагрузку на контроллеры. Если все серверы подключены к одной СХД, но сама СХД не имеет резервных контроллеров или репликации, она становится единой точкой отказа.

SAN обычно дороже простых вариантов. Требуются совместимые адаптеры, коммутаторы, лицензии, поддержка производителя и специалисты, которые умеют работать с zoning, multipath, LUN masking, очередями и производительностью массива. Ошибка в настройке может повлиять не на одну виртуальную машину, а на весь кластер.

iSCSI: блочное хранилище по IP-сети

iSCSI, как один из вариантов SAN, позволяет подключать блочные дисковые ресурсы по обычной IP-сети. Это делает его более доступным вариантом по сравнению с классическим Fibre Channel: можно использовать Ethernet-инфраструктуру, сетевые карты 10GbE или 25GbE и стандартные коммутаторы.

Для небольшого и среднего кластера iSCSI часто выглядит разумным компромиссом. Он дает общее блочное хранилище, поддерживается многими гипервизорами и СХД, позволяет настроить несколько путей к storage и не требует отдельной Fibre Channel-инфраструктуры.

Но iSCSI нельзя подключать «как получится». Для production нужна отдельная storage-сеть или хотя бы выделенные VLAN и интерфейсы. 1GbE подходит только для тестовых сред. Для нормальной виртуализации стоите рассматривать 10GbE как базовый уровень, а при большом числе ВМ или активной записи — 25GbE и выше.

Важно настроить multipath, очереди, jumbo frames, MTU и резервирование путей. Один iSCSI target без отказоустойчивости остается точкой отказа. Write cache без защиты питания тоже может быть опасен: при сбое питания можно потерять данные, которые считались уже записанными.

iSCSI хорош там, где нужно общее блочное хранилище без дорогого Fibre Channel, есть нормальная сеть и команда понимает, как отделить storage-трафик от пользовательского и backup-трафика.

NFS: проще в администрировании, но зависит от NAS

NFS — это файловый протокол. Гипервизор подключает сетевой каталог как datastore и хранит там файлы виртуальных машин. В отличие от блочного LUN, администратор работает с файловой моделью: проще видеть структуру ВМ, проще расширять объем на стороне NAS, проще использовать функции файлового хранилища.

NFS часто выбирают там, где важны простота, понятное управление и умеренная нагрузка. Он подходит для многих офисных сервисов, тестовых сред, файловых ВМ, небольших и средних кластеров. Для VMware NFS давно является рабочим вариантом: в рекомендациях VMware по NFS для vSphere прямо указано, что NFS может быть жизнеспособным вариантом для многих виртуализационных развертываний при правильной настройке.

Но NFS сильно зависит от качества NAS и сети. Слабое NAS-устройство с одним контроллером и подключением по 1GbE — это не то же самое, что отказоустойчивый enterprise-NAS с несколькими контроллерами, кэшем, быстрыми SSD и резервными сетевыми путями.

Для NFS нужно проверять задержки, настройки таймаутов, блокировки, права доступа, версию протокола, поддержку гипервизора и поведение при отказе контроллера. Snapshot на NAS полезен, но не заменяет полноценное резервное копирование. Если пользователь удалил данные или приложение повредило файлы, snapshot может помочь, но для защиты от аварии всего хранилища backup должен быть отдельно.

Ceph: распределенное хранилище для роста

Ceph — это распределенная storage-система, которая может давать блочное, файловое и объектное хранилище. В виртуализации чаще всего используют блочный слой для виртуальных дисков. Ceph интересен тем, что позволяет собрать storage из локальных дисков нескольких серверов и распределять данные между ними.

Ceph хорошо подходит для инфраструктур, где нужно горизонтальное масштабирование, отказоустойчивость на уровне storage-кластера и гибкость. Его используют в Proxmox, OpenStack, Kubernetes и частных облаках. Red Hat описывает архитектуру Ceph через объектное хранилище, OSD-демоны и алгоритм CRUSH, который помогает распределять данные без центральной таблицы размещения.

Сильная сторона Ceph — масштабирование и отсутствие классической единой СХД как центральной точки. Данные реплицируются между узлами, а при отказе диска или сервера система может восстановить нужное количество копий. Но это не означает, что Ceph превращает любые диски и любую сеть в быстрый надежный storage.

Ceph требователен к архитектуре. Ему нужна быстрая и стабильная сеть, правильное число узлов, подходящие диски, достаточный CPU и RAM, мониторинг заполненности, задержек, состояния OSD, recovery, rebalance и degraded placement groups. На маленьком числе узлов Ceph может быть сложнее и менее выгоден, чем внешняя СХД, NFS/iSCSI или локальные NVMe с понятным backup.

При восстановлении после отказа Ceph активно использует сеть и диски. Если кластер и так перегружен, recovery может ухудшить задержки для виртуальных машин. Поэтому для Ceph нужно считать не только нормальную работу, но и режим отказа.

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

vSAN: распределенное хранилище внутри VMware

vSAN объединяет локальные диски серверов VMware ESXi в общее распределенное хранилище для кластера. Это не внешняя СХД, а программно-определяемый storage внутри VMware-инфраструктуры. Для компаний, которые уже используют vSphere, vSAN может быть удобным вариантом: управление встроено в знакомую платформу, а политики хранения задаются на уровне виртуальных машин.

vSAN подходит для VMware-кластеров, где хочется использовать локальные диски как общее хранилище, сохранить живую миграцию и управлять отказоустойчивостью через политики. Он масштабируется добавлением узлов и дисков, но требует совместимого оборудования, лицензий, правильной сети и понимания логики resync, fault domains, witness и storage policies.

Сеть для vSAN критична. Задержки и пропускная способность напрямую влияют на виртуальные машины. Broadcom в документации по vSAN отдельно описывает требования к пропускной способности и задержкам сети, а также особенности stretched cluster и witness-компонентов.

vSAN не стоит воспринимать как «RAID по сети». При отказе узла или диска начинается пересинхронизация, которая нагружает сеть и накопители. Нужно считать полезный объем с учетом политик хранения, количества допустимых отказов, резервного места под rebuild, snapshots и будущий рост. Если кластер заполнен почти полностью, восстановление после отказа может стать проблемой.

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

Сравнение вариантов storage

Эта таблица показывает направление выбора, но не заменяет тестирование. Один и тот же NFS может быть медленным домашним NAS или отказоустойчивой enterprise-системой. Один и тот же Ceph может работать стабильно на продуманном кластере и плохо на трех узлах со слабой сетью. В storage важна не только технология, но и конкретная реализация.

Как выбирать storage по типу нагрузки

Для офисных виртуальных машин и внутренних сервисов обычно важнее предсказуемость и простота восстановления, чем рекордная скорость. Здесь подходят NFS, iSCSI, SAN, vSAN, иногда локальные NVMe. Главное — нормальный backup, понятная отказоустойчивость и отсутствие перегруженного дешевого NAS.

Для баз данных важны низкая задержка, стабильная запись, защита кэша и понятное восстановление. Если ожидается высоконагруженная база данных - лучше использовать локальные NVMe и настраивать репликацию на уровне базы. Для средних нагрузок сетевые хранилища вроде SAN, быстрого iSCSI, vSAN при правильном sizing вполне подойдут. Ceph тоже возможен, но требует грамотного проектирования и проверки на реальной нагрузке.

Для VDI storage особенно чувствителен к мелким операциям и пикам. Утром пользователи входят в систему, запускают приложения, открывают браузеры и офисные файлы. Если хранилище не выдерживает пик, рабочие столы начинают тормозить. Для VDI лучше использовать быстрые SSD/NVMe, хорошую сеть, контроль задержек и IOPS. Слабый NAS или HDD под активные рабочие столы — рискованный выбор.

Для тестовой среды можно использовать локальные NVMe, NFS или простой iSCSI. Но тестовая архитектура не должна автоматически становиться production. То, что работает на пяти ВМ, может плохо работать на пятидесяти.

Для кластера с живой миграцией нужно общее или распределенное хранилище: SAN, iSCSI, NFS, Ceph или vSAN. Локальные NVMe подходят только если есть репликация, shared-nothing migration или приложения сами обеспечивают отказоустойчивость.

Сеть для storage

Для NFS, iSCSI, Ceph и vSAN сеть является частью storage, а не второстепенной деталью. Если сеть дает задержки, теряет пакеты или перегружена backup-трафиком, виртуальные машины видят это как медленный диск.

1GbE допустим для небольших тестов, резервных задач или очень легкой нагрузки. Для production лучше рассматривать 10GbE как минимум, в частности vSAN просто не сможет построится на гигабитной сети. Для Ceph, vSAN, активной репликации, VDI и большого числа ВМ часто нужен 25GbE. В некоторых сценариях — выше.

Storage-трафик лучше отделять от пользовательского трафика, резервного копирования и управления. Нужны резервные пути, производительные коммутаторы, продуманная схема VLAN, MTU, multipath и мониторинг сетевых ошибок. Нельзя рассчитывать только среднюю загрузку сети: короткие пики записи, snapshot consolidation, rebuild или backup могут вызвать задержки, которые сразу заметят ВМ.

Где появляются точки отказа

Общее хранилище не всегда означает отказоустойчивое хранилище. Один сервер с локальными NVMe — точка отказа. Один NAS без резервного контроллера — точка отказа. Один iSCSI target, один коммутатор, один сетевой путь, один RAID-набор без горячего резерва, маленький Ceph-кластер без запаса — все это может остановить виртуальные машины.

Нужно смотреть всю цепочку: диск, контроллер, кэш, питание, сеть, гипервизор, datastore, виртуальная машина. Для блочного storage нужен multipath. Для NFS/NAS — резервные контроллеры и сетевые пути. Для Ceph и vSAN — правильное число узлов, failure domains и свободное место под восстановление.

Backup не равен высокой доступности. Он помогает восстановиться после аварии, но не всегда быстро. Репликация тоже не равна полноценной защите: если данные удалены или повреждены, ошибка может быстро уехать на вторую площадку. Snapshot удобен для короткого отката, но не заменяет резервную копию.

Почему дешевый storage может стать дорогим

Цена за терабайт — плохой единственный критерий. Нужно считать диски, серверы или СХД, сетевые карты, коммутаторы, лицензии, поддержку, электроэнергию, охлаждение, стойко-место, работу инженеров, резервное копирование и стоимость простоя.

Локальные NVMe могут быть дешевле на старте, но требуют отдельной схемы отказоустойчивости. NFS и iSCSI могут быть дешевле SAN, но зависят от качества NAS или storage-сервера. Ceph может быть выгодным на масштабе, но дорогим по инженерным компетенциям. vSAN удобен в VMware, но требует лицензий и совместимого железа. SAN дороже, но часто дает предсказуемость и привычную модель поддержки.

Дешевый storage становится дорогим, если из-за него простаивают виртуальные машины, срываются резервные копии, невозможно обновлять гипервизоры без риска или каждый инцидент требует ночной ручной диагностики.

Масштабирование через год

Storage нужно выбирать не только под текущий объем. Через год обычно растет и количество данных, и нагрузка. Появляются новые ВМ, тестовые копии, снимки, логи, backup, репликация, аналитика.

Локальные NVMe масштабируются апгрейдом на более объёмные\производительные диски, добавлением их количества или количества серверов, но не всегда дают единый пул. SAN масштабируется полками, дисками, контроллерами и лицензиями. NFS и iSCSI растут в пределах возможностей NAS или СХД и сети. Ceph масштабируется добавлением узлов и дисков, но требует rebalance и контроля сети. vSAN масштабируется добавлением дисков и хостов, но зависит от совместимости, лицензий и политик хранения.

Расширение storage — это тоже нагрузка. Rebuild, resync, rebalance и миграции могут заметно влиять на виртуальные машины. Поэтому нужно оставлять свободное место и проектировать рост заранее. Если storage уже занят на 85–90%, любое восстановление после отказа становится опасным.

Backup, snapshots и репликация

Snapshot удобен для короткого отката перед обновлением или изменением, но не заменяет backup. Если основное хранилище потеряно, snapshot внутри него тоже может быть недоступен. Backup должен храниться отдельно от основного storage.

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

Для критичных виртуальных машин нужно заранее определить RPO и RTO. RPO показывает, сколько данных можно потерять. RTO — за какое время нужно восстановиться. Эти требования напрямую влияют на выбор storage, backup-системы, сети и бюджета.

Backup сам создает нагрузку на storage. Если резервное копирование запускается в рабочее время или одновременно с тяжелыми операциями, виртуальные машины могут замедлиться. Поэтому окна backup, сеть и хранилище для резервных копий нужно планировать отдельно.

Какой storage выбрать под сценарий

Частые ошибки при выборе storage

• Выбирать storage только по цене за терабайт. В виртуализации важны задержки, надежность, восстановление и обслуживание, а не только объем.
• Сравнивать только IOPS без latency. Высокие IOPS на бумаге не гарантируют быстрый отклик реальных виртуальных машин.
• Использовать только HDD под активные ВМ. Для архивов и холодных данных HDD еще уместны, но для production-виртуализации с большим числом мелких операций они часто становятся узким местом, в тоже время гибридное хранилище - HDD+SSD под кэш - могут быть вполне неплохим и бюджетным решением.
• Ставить production на NAS без отказоустойчивости. Один контроллер, один сетевой порт и один блок питания — это не надежная архитектура.
• Подключать iSCSI и NFS по общей офисной сети. Storage-трафик должен быть отделен и резервирован.
• Не настраивать multipath для блочного storage. Один путь к хранилищу превращает любой сетевой или портовый сбой в простой.
• Считать snapshot резервной копией. Snapshot полезен, но backup должен жить отдельно.
• Строить Ceph на слишком малом числе узлов и слабой сети. Ceph требует масштаба, мониторинга и опыта.
• Запускать vSAN на неподходящем железе. Совместимость, диски, контроллеры и сеть здесь критичны.
• Не оставлять свободное место под rebuild, resync и рост. Хранилище, заполненное почти до конца, хуже переживает отказ и восстановление.

Как тестировать storage перед вводом

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

Стоит проверить последовательное чтение и запись, случайное чтение и запись, задержку под смешанной нагрузкой, поведение при заполнении 70–80%, отказ одного сетевого пути, отказ диска, восстановление RAID, Ceph или vSAN, работу backup и скорость восстановления ВМ.

После тестов нужно смотреть не только среднюю скорость, но и пики latency. Если storage иногда дает задержки в сотни миллисекунд, это может быть заметнее для приложений, чем разница в максимальной пропускной способности.

Как принять решение

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

Дальше нужно проверить сеть, поддержку гипервизора, совместимость оборудования, backup и restore. Стоимость нужно считать не только по дискам, но и по коммутаторам, сетевым картам, лицензиям, поддержке, электроэнергии и времени инженеров. Proxmox в документации по storage показывает, что виртуальные машины могут храниться как на локальных хранилищах, так и на shared storage вроде NFS и iSCSI, а также использовать Ceph — это хорошо иллюстрирует, что выбор зависит от архитектуры, а не от одного протокола.

Финальное решение лучше принимать после пилота на реальной нагрузке. Storage, который хорошо выглядит в спецификации, может не подойти из-за сети, кэша, особенностей гипервизора или профиля приложений.

Что в итоге выбрать

Выбор storage для виртуализации — это выбор архитектуры, а не только дисков. Локальные NVMe дают максимальную скорость, но требуют отдельной схемы отказоустойчивости. SAN и iSCSI подходят для общего блочного хранилища, если правильно настроены сеть, multipath и резервирование. NFS хорош простотой, но зависит от качества NAS и сети. Ceph и vSAN позволяют строить распределенное хранилище, но требуют грамотного проектирования, мониторинга и поддержки.

Лучший вариант — тот, который соответствует нагрузке, бюджету, компетенциям команды, требованиям к восстановлению и плану роста. Если инфраструктура небольшая, не всегда нужен сложный распределенный storage. Если кластер критичный и должен расти, экономия на сети, дисках и архитектуре быстро превращается в простой. Поэтому storage нужно выбирать не по обещанным IOPS, а по тому, как он поведет себя при реальных нагрузках, отказах, backup, обновлениях и расширении.