Короткий ответ

Сначала сколько дисков можете потерять одновременно и какая запись: случайная (SQL, VM) vs последовательная (файлы, бэкап). Для ОС и SQL на SSD — RAID 1 или RAID 10. Для «полок HDD под файлы» — RAID 6 / RAIDZ2, не RAID 5 на дисках >4–8 ТБ из-за длинного rebuild и URE. ZFS: зеркала для IOPS, raidz2 для ёмкости. RAID 0 — только кэш/scratch, не vd0 учёта. Не кладите ZFS на hardware RAID-кэш.

Симптомы и как отличить

Выбираете не «самый большой % ёмкости». Задачи:

НагрузкаОбычно
Windows Server boot + SQL logRAID 1 SSD
SQL data случайная записьRAID 10
NAS файлы, архивRAIDZ2 / RAID 6
Видеонаблюдение потокRAID 6 / raidz2, проверить write
Зеркало VM на NASiSCSI zvol на mirrors, не raidz

Уже есть degraded RAID 5 — это аргумент мигрировать, не «ещё один диск в тот же уровень».

Возможные причины

  1. RAID 5 «так всегда делали».
  2. RAID 0 «быстрее» на прод.
  3. Один raidz из 12 дисков: resilver ад, IOPS записи низкие.
  4. Смешали SSD и HDD в одном DG.
  5. Hardware RAID + ZFS checksum двойной кэш.

Диагностика

Запишите: число дисков, объём, HDD vs SSD, нужен ли hot spare, RPO (есть ли backup), IOPS write, можно ли downtime на rebuild (долгий rebuild).

Ёмкость полезная:

  • RAID 1: 1 диск из 2
  • RAID 10: 50%
  • RAID 5: n-1 (избегайте на больших HDD)
  • RAID 6: n-2
  • RAIDZ1/Z2/Z3: аналогично 1/2/3 parity

Не забудьте spare и 20% запас ZFS.

Решение

Сценарий A. Два диска

Только RAID 1 / ZFS mirror. RAID 0 недопустим для данных. Один диск + backup — это не RAID.

Сценарий B. Четыре SSD под SQL01

RAID 10. Запись без parity penalty RAID 5/6. vd0 под data, отдельное зеркало под log если бюджет.

Сценарий C. Восемь–двенадцать HDD NAS01 файлы

ZFS: несколько vdev mirror (лучше IOPS) или raidz2 из групп по 6–8, не один raidz2×12 если важны мелкие файлы. Hardware: RAID 6 + spare. Не RAID 5.

Сценарий D. Смешанно

Разные DG/пулы: быстрый SSD, ёмкий HDD. Не «всё в один vd0».

Сценарий E. Уже RAID 5 на 10 ТБ×8

План миграции на RAID 6 или ZFS raidz2: новый массив или backup+recreate. Жить на Dgrd RAID 5 во время замены — максимальный риск.

Сценарий F. ZFS vs MegaRAID

Предпочтение TrueNAS: HBA + ZFS. Если остаётесь на MegaRAID — не включайте ещё и RAIDZ на одном vd0. Либо JBOD/HBA, либо один слой RAID.

SSD wear: RAID 5/6 на SSD увеличивает записи — износ.

Запишите решение в паспорт сервера: уровень, размер stripe, политика кэша WB только с BBU или CacheVault, spare dedicated или global. Для ZFS: ashift 12 на современных дисках, recordsize под нагрузку — мельче для случайной записи, крупнее для файлов. Не ставьте recordsize 1M на zvol SQL.

RAID 50 и 60 имеют смысл на широких полках и понимающей команде; для типичного NAS01 это лишняя сложность. Семантику RAID 1E на трёх дисках читайте в manual конкретного MegaRAID, не в рекламе.

Смена нагрузки убивает хороший выбор: файловый NAS превратили в datastore на десятки VM. Тогда не «добавить диск в raidz», а вынести VM на зеркала. Пересмотр уровня раз в год — норма, не признание ошибки.

Как проверить, что проблема устранена

Документ: уровень, члены, spare, ожидаемая ёмкость, тест записи (fio/CrystalDisk не на проде без окна). После внедрения: контрольный отказ на стенде (вынос одного диска) и успешный rebuild. Мониторинг VD/zpool health. SQL latency в SLA.

Если не помогло

  • IOPS низкие на raidz: вы выбрали ёмкость, это физика parity. Перенос SQL на mirrors.
  • Ёмкости не хватило: забыли parity+spare+служебное ZFS.
  • Контроллер не умеет RAID 10 на этих слотах: читайте manual, не «RAID 50 как 10».
  • Вендор «RAID 5 OE» — всё равно считайте rebuild hours.

Профилактика

  • Запрет RAID 5 на HDD > определённого объёма в стандарте организации.
  • Spare в спецификации, не «потом докупим».
  • Разные пулы под разные SLA.
  • Планирование ёмкости сразу с уровнем RAID.
  • Репетиция замены диска раз в год.

Hot spare считается в закупке, не «если останется слот». На RAID 6 из восьми HDD spare — девятый диск в спецификации, иначе rebuild начнётся после поездки в магазин. Для ZFS spare (zpool add spare) — отдельная дисциплина: он не расширяет ёмкость и не заменяет второй vdev.

Не смешивайте в одном vdev диски разной скорости «временно на месяц»: vdev работает со скоростью худшего, SMART и rebuild предсказуемо портятся. Временное становится тремя годами.

Если бюджет режет RAID 10 для SQL, честный ответ — RAID 1 на SSD нужного IOPS, а не RAID 5 на HDD «зато терабайты». Ёмкость и задержка — разные валюты.

Проверьте ограничение контроллера на число VD и PD в одной DG до закупки полок. «Купим ещё корзину» не всегда клеится к существующему RAID 10 без нового VD и миграции данных. Это часть выбора уровня, не сюрприз на монтаже.

FAQ

RAID 10 «теряет половину» — жалко?

Платите IOPS и быстрый rebuild. Для SQL обычно дешевле простоя.

RAIDZ1 vs RAIDZ2?

На NAS с большими дисками RAIDZ2. RAIDZ1 ≈ RAID 5 по риску rebuild.

Нужен ли RAID на boot Ubuntu с ZFS root?

Зеркало boot — отдельное решение. Не RAID 0 boot.

MegaRAID RAID 00?

Stripe из групп — сложность без выигрыша для SMB. Обычно нет.

Можно ли начать с RAID 1 и добавить диски в 10?

Зависит от контроллера (migration). Часто проще backup и новый VD. Не обещайте онлайн-магию без документации этой Smart Array/MegaRAID.