Виртуальное хранилище данных — программное решение, которое объединяет локальные диски нескольких серверов в общий пул хранения для виртуальных машин. Вместо покупки отдельного аппаратного СХД вы используете диски внутри каждого хоста гипервизора.
Такая архитектура упрощает масштабирование: добавили сервер — увеличили объём хранилища и вычислительную мощность одновременно. Но есть нюансы с производительностью, отказоустойчивостью и выбором железа.
Что такое виртуальное хранилище данных
Виртуальный СХД (Software-Defined Storage, SDS) — это слой абстракции между физическими дисками и операционной системой. Программа забирает диски из серверов и создаёт единое логическое хранилище, доступное всем узлам кластера.
Типичные примеры:
- VMware vSAN — встроен в vSphere, работает с Flash и HDD
- Microsoft Storage Spaces Direct (S2D) — часть Windows Server, требует минимум два узла
- Ceph — open-source решение, популярно в OpenStack-облаках
- Nutanix — коммерческая платформа гиперконвергентной инфраструктуры
Основная идея: данные реплицируются между узлами. Если один сервер выходит из строя, виртуальные машины продолжают работать с копий на других хостах.
Принцип работы виртуального СХД
Виртуальное хранилище состоит из трёх компонентов:
- Локальные диски — SSD для кэша и горячих данных, HDD для холодного хранения
- Программный слой — распределяет блоки данных, управляет репликацией и восстановлением
- Сетевая фабрика — связывает узлы кластера, обычно 10/25 Гбит/с Ethernet
Когда виртуальная машина записывает данные, они попадают на локальный SSD (кэш первого уровня). Программа синхронно копирует блоки на диски других узлов — обычно две или три реплики. После подтверждения записи гостевая ОС получает статус успешной операции.
Чтение работает так: если данные есть в локальном кэше — отдаём сразу. Если нет — запрашиваем по сети с ближайшего узла.
Архитектурные особенности
vSAN и S2D используют дисковые группы. Каждая группа включает один SSD для кэша и несколько HDD для хранения. Минимальная конфигурация узла — один кэширующий диск плюс один диск ёмкости.
Ceph работает иначе: назначает роли OSD (Object Storage Daemon) каждому диску. Один сервер может содержать десятки OSD. Метаданные хранятся на отдельных мониторах (MON-узлах).
Nutanix объединяет оба подхода: использует CVM (Controller VM) на каждом хосте. Эта служебная виртуальная машина управляет дисками и трафиком репликации.
Когда нужен виртуальный СХД
Виртуальное хранилище решает несколько задач:
| Сценарий | Почему виртуальный СХД подходит |
|---|---|
| Небольшой кластер (3-8 узлов) | Нет смысла покупать отдельный массив за миллионы. Проще использовать диски внутри серверов |
| Линейное масштабирование | Добавляете узел — растут CPU, RAM и дисковое пространство одновременно. Удобно для растущих нагрузок |
| Edge-локации и филиалы | Нет места и бюджета на SAN. Компактный кластер из двух-трёх серверов решает задачу |
| VDI (виртуальные рабочие столы) | vSAN хорошо справляется с burst-нагрузками при загрузке сотен десктопов утром |
| Тестовые и dev-среды | Быстрое развёртывание без зависимости от СХД-команды |
Когда виртуальный СХД не подходит
Есть ситуации, где аппаратный массив надёжнее:
- Критичные БД с высокими IOPS — Oracle RAC, SAP HANA лучше работают на All-Flash массивах с FC или NVMe-oF
- Большие объёмы (сотни терабайт) — управлять дисками в десятках серверов сложнее, чем одним СХД
- Разделение compute и storage — если хотите масштабировать вычисления отдельно от хранения
- Мультипротокольный доступ — нужен NFS, SMB, iSCSI, FC одновременно. Виртуальные СХД обычно работают с блоками внутри гипервизора
Виртуальные СХД vs аппаратные: сравнение
Разбираем основные отличия:
| Критерий | Виртуальный СХД | Аппаратный СХД |
|---|---|---|
| Стоимость входа | Ниже. Платите за лицензии vSAN/S2D + диски внутри серверов | Выше. Отдельная полка с контроллерами, дисками, кабелями |
| Масштабирование | Горизонтальное. Добавили узел — получили CPU+RAM+диски | Вертикальное (больше полок) или горизонтальное (новый массив) |
| Производительность | Зависит от сети и дисков в серверах. Латентность выше из-за репликации | Выделенные контроллеры, кэш NVRAM, FC. Ниже задержки |
| Отказоустойчивость | Зависит от количества реплик (обычно 2-3). Потеря узла = rebuild по сети | Dual-контроллеры, BBU, RAID. Потеря диска = rebuild локально |
| Управление | Из интерфейса гипервизора. Один инструмент для VM и storage | Отдельная консоль СХД. Нужны навыки администрирования массива |
| Сетевая нагрузка | Высокая. Репликация, vMotion, VM-трафик идут по одним линкам | Низкая. Storage-трафик идёт по FC/iSCSI, отдельно от VM-сети |
Гибридные варианты
Можно комбинировать: использовать виртуальный СХД для рабочих нагрузок, а критичные БД держать на внешнем массиве. Например, vSAN для VDI и веб-серверов, а Oracle — на FC SAN.
Выбор оборудования для виртуального хранилища
Требования к железу жёстче, чем для обычного кластера с внешним СХД.
Серверы
Нужны модели с большим количеством отсеков для дисков. Стандартные 1U-серверы с 4-8 слотами не подходят — места хватит только на ОС и один-два диска ёмкости.
Оптимальные варианты:
- 2U с 8-12 отсеками — баланс плотности и ёмкости
- 2U с 24-25 отсеками — максимум дисков на юнит высоты
- Гибридные шасси с NVMe на фронте и SATA на бэкплейне
Обязательно: резервные блоки питания, RAID-контроллеры в режиме HBA (pass-through), минимум два порта 10GbE.
Процессоры и память
vSAN и S2D потребляют ресурсы хоста. Рекомендации VMware для vSAN:
- Минимум 1 физическое ядро на дисковую группу
- 32 ГБ RAM + 10 ГБ на каждую дисковую группу
Для Storage Spaces Direct:
- Минимум 2 процессорных сокета
- 64 ГБ RAM на узел для небольших кластеров, 128+ для крупных
Выбирайте процессоры с высокой частотой, а не максимальным количеством ядер. Софт виртуального СХД плохо параллелится на 40+ ядер.
Диски и контроллеры
Кэширующий уровень:
- NVMe SSD — лучший вариант для write-intensive нагрузок (vSAN требует минимум 600 DWPD для кэша)
- SATA/SAS SSD — допустимы для read-cache, но медленнее
Уровень ёмкости:
- SATA HDD 7200 RPM — для холодных данных, архивов, бэкапов
- SAS HDD 10K/15K — для баз данных средней нагрузки
- SATA/SAS SSD — для all-flash конфигураций
Контроллеры нужны в режиме JBOD или HBA. RAID на контроллере блокирует прямой доступ к дискам, который необходим vSAN и S2D.
Сетевое оборудование
Виртуальный СХД чувствителен к сетевым задержкам. Требования:
- Скорость: минимум 10 Гбит/с, рекомендуется 25 Гбит/с
- Резервирование: минимум два порта на узел, LACP или active-active
- Коммутаторы: managed L2/L3 с поддержкой Jumbo Frames (MTU 9000)
- Латентность: до 1 мс между узлами
Используйте сетевые карты с аппаратной разгрузкой (TOE, RDMA). Это снижает нагрузку на CPU при репликации.
Типовые конфигурации
| Сценарий | Узлов | CPU | RAM | Диски | Сеть |
|---|---|---|---|---|---|
| Малый офис / ROBO | 2-3 | 1×8 core | 64 ГБ | 2x480GB SSD + 4x2TB HDD | 2x10GbE |
| VDI на 100 пользователей | 4 | 2×12 core | 128 ГБ | 2x960GB NVMe + 6×1.92TB SSD | 2x25GbE |
| Средний кластер | 6-8 | 2×16 core | 256 ГБ | 4×1.6TB NVMe + 8×7.68TB SSD | 2x25GbE |
| All-flash для БД | 5-6 | 2×20 core | 512 ГБ | 6×3.84TB NVMe | 2x100GbE |
Для сборки сервера под vSAN или S2D подбирайте ОЗУ, блоки питания и системы охлаждения с запасом. Виртуальный СХД создаёт постоянную фоновую нагрузку на все компоненты.
Совместимость и HCL
Проверяйте железо по официальным спискам совместимости:
- vSAN — VMware Compatibility Guide (VCG)
- Storage Spaces Direct — Windows Server Catalog
- Nutanix — Hardware Compatibility List на портале поддержки
Использование несертифицированных дисков или контроллеров лишает вас техподдержки вендора.
Альтернативы виртуальному СХД
Если виртуальное хранилище не подходит, рассмотрите:
Локальные диски с vMotion Storage
Держите VMDK на локальных SSD каждого хоста. При отказе узла vSphere HA перезапускает VM на другом сервере, но данные теряются. Подходит для stateless-приложений (контейнеры, веб-фронтенды).
NAS/SAN начального уровня
Компактные массивы типа Synology, QNAP, Dell PowerVault дешевле enterprise-СХД. Предоставляют NFS/iSCSI для 3-5 хостов. Минус — один контроллер, нет FC.
Облачное хранилище
S3-совместимые объектные хранилища (Wasabi, Backblaze) для бэкапов и архивов. Не подходят для постоянного подключения к VM, но снижают требования к локальной ёмкости.
Гиперконвергентные appliance
Готовые решения (Nutanix, Dell VxRail, HPE SimpliVity) — серверы, ПО и поддержка в одной коробке. Дороже самосборки, но проще в эксплуатации.
Часто задаваемые вопросы
Можно ли использовать vSAN с двумя узлами?
Да, но нужен третий компонент — witness (свидетель). Это может быть виртуальная appliance на удалённой площадке или физический сервер. Witness не хранит данные, только метаданные кворума. Без него кластер из двух узлов не определит, какая реплика актуальна при split-brain.
Какой объём сети нужен для репликации?
Зависит от нагрузки на запись. Формула: write IOPS × размер блока × количество реплик. Например, 10 000 IOPS по 8 КБ с двумя репликами = 10000 × 8 × 2 = 160 МБ/с (~1.3 Гбит/с). Добавьте 30-50% на overhead и пиковые нагрузки. Для такого сценария достаточно 10 Гбит/с, но лучше взять 25 Гбит/с с запасом.
Что происходит при выходе диска из строя?
Виртуальный СХД запускает rebuild: копирует данные с реплик на оставшиеся здоровые диски в кластере. Процесс идёт по сети, загружает CPU и диски всех узлов. Время восстановления зависит от объёма данных и скорости сети. Для 4 ТБ при 10 Гбит/с — около 1-2 часов. В это время производительность кластера снижается на 20-40%.
