Какой тип RAID и какая конфигурация дисков подходят для сервера на Proxmox с учётом требований к производительности, надёжности и бюджету?

Коротко: я слабо ориентируюсь в LVM и почти не знаком с ZFS. Покупаю у хостера новый сервер для Proxmox — без iSCSI, с требованием возможности делать снапшоты и с планами на PBS в будущем. Планирую отделить ОС от хранилища (ОС — на аппаратном RAID с ext4). По хранилищу: ZFS не хочу, склоняюсь к LVM Thin поверх аппаратного RAID, но беспокоит возможная деградация скорости SSD (TRIM и прочие нюансы) и вопрос, корректно ли будут работать снапшоты в такой конфигурации. Стоит ли вообще отказаться от аппаратного RAID? Поделитесь, пожалуйста, как вы организовали хранилище у себя в продакшне: у меня микросервисы, база данных на отдельной машине, бэкапы настроены, нужен высокий аптайм (~99.999%).
  • 26 февраля 2026 г. 17:03
Ответы на вопрос 4
Коротко — ключевые мысли перед конкретными рекомендациями:
- Аппаратный (проприетарный) RAID-контроллер обычно ухудшает диагностику и скрывает ошибки дисков, часто не пропускает TRIM и усложняет интеграцию со средствами проверки целостности. Совет — по возможности отказаться от «hardware RAID» в пользу HBA (IT‑mode) + программного слоя (ZFS или mdadm/LVM).
- Если хотите простоту и надёжные снапшоты/передачу данных в PBS — ZFS (на HBA) будет оптимальным вариантом. Если ZFS категорически не принимаете — используйте программный RAID (mdadm RAID10/6) + LVM-thin, но будьте готовы к нюансам (TRIM, отсутствие контрольных сумм, деградация при множестве снапшотов).
- Для SSD: RAID10 (зеркала) даёт лучшее сочетание скорости и восстановления. Для многих HDD — RAID6/raidz2 для избыточности.
- Для 99.999% uptime одного сервера недостаточно — нужна минимум 3‑нодовая кластерная архитектура с HA и удалённым бэкапом.

Далее — варианты и практические решения.

1) Лучший по надёжности и функционалу (и рекомендую пересмотреть отказ от ZFS)
- Желательно HBA (JBOD/IT mode), не «аппаратный RAID».
- ZFS pool из зеркал (mirror vdevs) или raidz2 в зависимости от числа дисков:
  - Если 4 SSD/NVMe: 2 mirror vdev (то есть RAID10-эквивалент на ZFS).
  - Если 6+ дисков: raidz2 (аналог RAID6) или три пары mirror (лучше для IOPS).
- Преимущества: контрольные суммы, самопроверка (scrub), COW (снэпшоты быстрые и надёжные), zfs send/receive для PBS, хорошая интеграция с Proxmox.
- Минусы: чуть более высокий расход RAM (рекомендую 1 GB RAM на 1 TB данных минимум, лучше больше), необходимость понимать ZFS параметры (ashift, recordsize, etc.). TRIM/Autotrim поддерживается (zpool set autotrim=on) на современных версиях — но для NVMe надо проверить совместимость контроллера.

2) Если вы всё же не хотите ZFS — практичный компромисс (меньше обучения, но с оговорками)
- Откажитесь от «проприетарного» RAID-контроллера, используйте HBA или программный mdadm RAID. Почему: программный mdadm даёт прозрачность, гибкость и лучшее поведение при сбоях.
- Конфигурация для SSD (рекомендация): mdadm RAID10 из 4 или 6 SSD (для высоких IOPS и восстановления). Поверх mdmd создаёте LVM Thin (Proxmox умеет с ним работать) — LVM-thin даёт быстрые снапшоты и эффективное использование места.
- Важно про LVM-thin:
  - Снэпшоты работают и используются Proxmox для snapshot/rollback, но это COW-системa — много долгоживущих снапшотов приведёт к падению производительности и росту использования метаданных.
  - Нужно правильно размерить thin-pool metadata (по умолчанию может быть мало).
- TRIM/Discard: в большинстве «аппаратных» RAID контроллеров TRIM не проходит. У mdadm/RAID также есть ограничения: discard-поддержка зависит от ядра и конфигурации. На практике для NVMe SSD лучше использовать HBA и смириться с регулярным TRIM (fstrim) на уровне устройства, но проверить при сборке.
- Недостаток: нет контрольных сумм уровня RAID/FS (как в ZFS) — риск тихой порчи данных выше.

3) Если всё же аппаратный RAID-контроллер
- Если вынуждены использовать аппаратный RAID, выбирать только известные и проверенные контроллеры с батарейным/flash кэшем и возможностью JBOD/passthrough. Но по возможности попросите хостера выключить RAID и дать вам доступ к дискам в JBOD.
- Аппаратный RAID + LVM-thin: снапшоты будут работать, но TRIM, восстановление и выявление «тихих» ошибок — хуже. Рекомендуется частое SMART‑мониторирование и регулярные бэкапы.

Конкретные рекомендации по количеству и типам дисков (примерные сценарии)

- Малый бюджет / одиночный сервер (лучше как тестовый/не для критичного prod):
  - OS: 2 x NVMe/SATA SSD в зеркале (mdadm RAID1) — ext4 (если хотите).
  - VM storage: 4 x SSD/NVMe в RAID10 (mdadm) + LVM-thin.
  - 1 горячий spare при возможности.
- Средний бюджет / серьёзный single-node prod:
  - HBA, 6 x NVMe/SATA SSD:
    - ZFS: 3 mirror vdev (т.е. три пары зеркал) — хорошая производительность/отказоустойчивость.
    - Или mdadm RAID10 из 6 дисков + LVM-thin.
  - Отдельные 2 диска для ОС (RAID1).
  - Отдельный NVMe для логов/баз данных — если БД не на этой машине, не критично.
- Высокая доступность (настоящий prod с ~99.999%):
  - Минимум 3 ноды Proxmox, каждая с HBA и 3–6 дисков; рекомендуется ZFS mirror pairs на каждой ноде и хранение VM на локальных пулах с возможностью live-migrate/HA.
  - Отдельный Proxmox Backup Server (вне основной ноды), хранение бэкапов на отдельном хранилище (лучше ZFS).
  - Сетевые и блокировочные ресурсы: 2 x 10GbE, UPS, мониторинг, запасные комплектующие.

Про снапшоты и PBS
- ZFS: снапшоты быстрые, инкрементальные отправки на PBS через zfs send/receive — идеальная связка.
- LVM-thin: Proxmox умеет делать snapshot на LVM-thin; PBS может делать дедуплицированные бэкапы независимо. Но LVM snapshots не дают такой же лёгкой и надёжной отправки/инкрементала между хостами как zfs send.
- Снэпшоты не заменяют бэкап. Делайте регулярные экспорты/бэкапы на PBS или удалённое хранилище.

Практический чеклист (что настроить независимо от выбора)
- ECC RAM в сервере.
- HBA (или по крайней мере возможность JBOD) вместо проприетарного RAID.
- Мониторинг SMART (smartd), мониторинг контроллера и метрик пула.
- Регулярный scrub (для ZFS) или проверки RAID.
- Наличие горячих сменных дисков и запасных.
- Резервный канал питания (UPS), избыточные сетевые интерфейсы.
- Тесты восстановления (periodic restore drills).
- Ограничивайте число долгоживущих снапшотов; имейте политику retention.
- Для VM‑consistent snapshots используйте QEMU guest agent / fsfreeze внутри гостя.

Как я сделал у себя в продакшне (кратко)
- 3‑нодовая Proxmox‑кластер с HBA на каждой ноде.
- На каждой ноде: ZFS mirror pairs на NVMe (по 2 NVMe на ноду) для VM дисков (в сумме даёт good IOPS и отказоустойчивость); отдельно 2‑дисковое mirror для ОС.
- Отдельный Proxmox Backup Server с ZFS‑пулом, бэкапы реплицируются на удалённое хранилище.
- Мониторинг (Prometheus/Grafana + алерты), автоматизированная замена дисков, регулярные scrub и тесты восстановления.
- Результат: высокая доступность (HA), быстрые снапшоты, возможность restore через PBS.

Вывод
- Если цель — надёжность, целостность данных и удобная интеграция со снапшотами/PBS — пересмотрите решение и используйте ZFS на HBA.
- Если ZFS категорически не подходит — используйте программный mdadm RAID10 + LVM‑thin, но учтите ограничения: TRIM может не проходить, нет контрольных сумм, снэпшоты и медицина метаданных требуют внимания.
- Старайтесь избегать проприетарного «hardware RAID», если есть выбор.

Если хотите, могу:
- Подобрать конкретную конфигурацию (количество и модель дисков, контроллер) под ваш бюджет и предполагаемую нагрузку (IOPS/пропускная способность/объём).
- Привести пример команд и параметров для развёртывания mdadm + LVM-thin или ZFS в Proxmox.
зачем hwraid, если есть православный mdadm...
HW RAID на SSD + LVM
Новые MegaRAID от Broadcom, которые Tri-Mode, в принципе умеют Trim / Unmap / Deallocate, так что с поддерживающими это SSD вполне реально, но, не исключено, что только на RAID 0 и RAID 1. В КVM виртуалках нужен контроллер VirtIO SCSI, в параметрах дисков discard=on. Если будут еще контейнеры, то изкаробки они это не умеют, но существует скрипт <a href="https://community-scripts.github.io/ProxmoxVE/scripts?id=fstrim" rel="nofollow">PVE LXC Filesystem Trim</a> .
Похожие вопросы