RAID в серверах: какие бывают и какой выбрать

Почему вопрос «какой RAID выбрать» сложнее, чем кажется

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

В 2026 году RAID — это уже не только «RAID5 или RAID10». На практике вы выбираете подход, а уже потом — уровень:

• Аппаратный RAID (контроллер с прошивкой и кэшем)
• Software RAID (например, Linux mdadm, Windows Storage Spaces — массив собирает ОС)
• RAID внутри файловой системы (ZFS: зеркала и RAIDZ)

Ниже — «матрица выбора» уровней, разбор скрытых рисков (кэш, write hole, rebuild/URE, SMR-диски, прошивки), а также чек-листы, чтобы RAID работал предсказуемо и не превращался в иллюзию защиты.

Что такое RAID в сервере — из чего он «состоит»

Мини-словарь

• Stripe / полоса — данные режутся на блоки и распределяются по дискам для скорости.
• Chunk size (stripe size) — размер блока, который RAID пишет на один диск в полосе (влияет на эффективность чтения/записи).
• Mirror / зеркало — одинаковые данные на двух (или более) дисках.
• Parity / паритет — «контрольные данные», позволяющие восстановить информацию при отказе диска (ов).
• Hot spare — горячий резервный диск, который автоматически включается в массив при отказе.
• Rebuild / resync — восстановление массива после замены/подключения диска.
• Patrol read / scrub — фоновая проверка чтения (и/или целостности) для раннего выявления проблем.
• Write-back / write-through — политика записи кэша (быстрее vs безопаснее при потере питания).
• BBU / CacheVault — защита кэша контроллера (батарея/суперконденсатор + флэш-память для защиты кэша), чтобы не потерять «недописанные» данные при отключении питания.

Где «живёт RAID»

Аппаратный RAID

RAID собирается на контроллере: firmware + кэш (обычно DRAM), часто есть защита кэша (BBU/CacheVault). В связке работают контроллер, бэкплейн/экспандер, hot-swap корзины. Плюс — «железный» кэш может сильно ускорить запись, минус — вы зависите от модели, прошивки и формата метаданных массива.

HBA + software RAID

Контроллер работает в режиме HBA/IT (по сути «прозрачный» адаптер), а массив собирает ОС. Это проще переносить между серверами и легче диагностировать, но требует дисциплины по мониторингу и правильной настройке rebuild/алёртов.

ZFS (зеркала и RAIDZ)

RAID — часть пула ZFS: файловая система сама контролирует целостность данных, умеет скраб (scrub), и в целом «думает» про хранение шире, чем классический RAID-контроллер. RAIDZ бывает с 1/2/3 паритетами (raidz1/2/3).

Что влияет на результат сильнее, чем «номер RAID»

• Тип дисков и их поведение под нагрузкой. HDD/SSD/NVMe — это разные профили задержек и отказов. Для HDD критичны CMR vs SMR; для SSD — ресурс (TBW/DWPD) и качество прошивок.
• Тип нагрузки. Случайная запись (random write), последовательная запись (sequential), latency-sensitive сервисы (VM/БД) — это разные требования. Один и тот же RAID может быть «идеальным» для архива и провальным для базы данных.
• Окно восстановления (rebuild time) и риск второй ошибки. Чем больше диски (и сложнее RAID) — тем дольше rebuild. А чем дольше rebuild — тем выше шанс поймать второй отказ/ошибку чтения во время восстановления.

Уровни RAID: какие бывают и что реально использовать

RAID 0

Самая простая конфигурация - данные " размазываются " страйпами по разным дискам. Минимальное количество дисков - один. Когда допустим: временные данные, кэш, scratch, тестовые стенды, где потеря массива — ожидаемая история.Когда нельзя: всё, что хоть как-то «жалко». RAID 0 не переживает отказ ни одного диска.

RAID 1

Простая и понятная надёжность: один диск «зеркалирует» другой. Минимальное количество дисков - два.Хорошо: OS/boot, небольшие БД, критичные сервисы с умеренным объёмом.Ограничение: эффективность по ёмкости ~50%, медленнее работает на запись, но в ряде случаев - быстрее на чтение.

RAID 10 (1+0)

Зеркала, объединённые в RAID 0: обычно лучший «универсал» для продакшена, совмещает скорость RAID 0 и надёжность RAID 1, переживает потерю 2 дисков (но не любых).Хорошо: виртуализация, БД, смешанная нагрузка, высокий IOPS, предсказуемая латентность.Цена: по ёмкости - 50% от общего объёма, требуется минимум 4 диска.

RAID 5 / RAID 6

Паритетные уровни: экономят ёмкость, но имеют «цену» на запись и риски при rebuild на больших HDD.

• RAID 5 переживает отказ 1 диска. На больших HDD rebuild может быть долгим и рискованным: вы работаете в режиме degraded, и любая вторая проблема может стать катастрофой, при этом в процессе восстановления скорость доступа существенно снижается. Минимальное количество дисков - 3, цена - потеря ёмкости, равной одному диску в массиве и это единственный его плюс.
• RAID 6 переживает 2 отказа — заметно безопаснее на ёмких полках, но ещё тяжелее по записи (read-modify-write), требует аккуратной настройки кэша/полосы и более произволительного контроллера, в ряде случаев - отдельной лицензии. Минимальное количество дисков - 4, цена - потеря ёмкости, равной двум дискам.

RAID 50 / RAID 60 (nested)

Практика для больших дисковых полок: несколько групп RAID5/6 объединяются в RAID0 сверху.Когда уместно: много дисков, важно совместить ёмкость и отказоустойчивость, и вы осознанно управляете группами.Важно: это не «магическая пуля» — rebuild и риски никуда не исчезают, просто меняется профиль.

JBOD / single disk

Иногда правильное решение — не «классический RAID», а отдельные диски, если сверху работает распределённое хранение (Ceph), или если вы строите ZFS-пул из отдельных дисков/зеркал и хотите максимальную прозрачность управления.

RAID-уровни — минимум дисков / переживаемые отказы / производительность / куда ставить

(Определения уровней и распределения данных соответствуют общим индустриальным подходам и спецификациям формата метаданных RAID-групп, включая SNIA DDF.

Аппаратный RAID vs software RAID vs ZFS/RAIDZ: что выбрать и почему

Аппаратный RAID (контроллер)

Плюсы

• Кэш записи может резко ускорить random write (особенно на HDD-массивах).
• Offload части логики на контроллер, привычная эксплуатация (hot-swap, алармы, утилиты).
• Часто понятный путь для классических серверов и «традиционных» СХД.

Минусы и риски

• Зависимость от модели/прошивки/метаданных массива: «переехать» на другой контроллер иногда не так просто.
• Миграция массива: даже в пределах одного бренда могут быть нюансы совместимости поколений.
• Кэш без защиты при внезапном отключении питания — прямой риск повреждения данных.

Write-back vs write-through — почему это важно

• Write-through: запись считается завершённой после фактической записи на диски. Медленнее, но безопаснее при потере питания.
• Write-back: запись подтверждается после попадания в кэш контроллера. Быстрее, но требует защиты кэша (BBU/CacheVault) и желательно UPS.

Важно: многие MegaRAID-контроллеры автоматически переводят кэш в write-through, если батарея/CacheVault не готов (а) или есть проблема со здоровьем модуля — именно чтобы не рисковать целостностью данных.

Software RAID (Linux mdadm / ОС-уровень)

Плюсы

• Прозрачность и переносимость: массив проще «прочитать» на другом сервере, меньше привязки к конкретному контроллеру.
• Часто дешевле (HBA вместо RAID-контроллера), особенно если кэш «железного» RAID не обязателен, при этом легче реализовать многослойное хранение (холодные данные на HDD, тёплые - на обычных SSD, горячие (или кэш) на скоростных NVME).
• Хорошо интегрируется с современными практиками мониторинга/автоматизации.

Минусы

• Нагрузка на CPU и чипсет, которые занимаются обработкой данных вместо отдельного контроллера (обычно терпима на современных серверах, но её надо учитывать).
• Требуется дисциплина: алёрты, регулярные проверки, корректные процедуры замены.
• Качество результата зависит от настроек и эксплуатации.

Практика эксплуатации (минимум, который должен быть):

• Мониторить состояние массива и деградации (mdstat/agent).
• Контролировать rebuild/resync и не «жить неделями» в degraded.
• Протестировать процедуру замены диска и убедиться, что алёрты реально приходят.

ZFS: зеркала и RAIDZ

Чем RAIDZ отличается концептуально

ZFS хранит контрольные суммы и умеет проверять целостность данных при чтении, а также регулярно «прочёсывать» пул через scrub. RAIDZ бывает:

• raidz1 — выдерживает 1 отказ
• raidz2 — 2 отказа
• raidz3 — 3 отказа

Важное ограничение по «перестройке схемы»

ZFS не про «поменять RAID5 на RAID6 в два клика». Архитектура пула и vdev’ов требует продуманного дизайна: расширения и изменения схемы имеют ограничения и зависят от версии/функций; «добавить паритет» или радикально перестроить схему обычно означает перепроектирование и миграцию. Для контекста развития темы полезно понимать направления работ по RAIDZ Expansion.

Тип RAID-реализации — критерии выбора

Как выбрать RAID под конкретные задачи

Виртуализация (VMware / Proxmox / Hyper-V)

Если на хранилище живут десятки/сотни VM и важна латентность, то выбирайте RAID 10 (или ZFS-зеркала).Почему: виртуализация даёт много мелких случайных операций, а RAID10 лучше держит random write и быстрее/предсказуемее восстанавливается после отказа диска.Уточнение: на NVMe — чаще зеркала/RAID10, потому что IOPS высокие, но деградацию и rebuild никто не отменял.

Базы данных (PostgreSQL / MySQL)

Если это production БД с требованиями к задержкам, то приоритет — RAID10/зеркала.Почему: БД чувствительны к «хвостам» задержек, а паритетные RAID5/6 на записи могут ловить read-modify-write и просаживать latency.RAID5 допустим только если нагрузка «в основном чтение», запись умеренная, есть защищённый кэш и вы осознаёте rebuild-риски.

Файловое хранилище / архив на HDD

Если нужна ёмкость и устойчивость на больших объёмах HDD, то чаще всего RAID6 или RAID60.Почему: большие диски долго восстанавливаются, и второй сбой во время rebuild — реальный риск. Двойной паритет снижает вероятность катастрофы.Но: производительность записи будет зависеть от кэша/полосы/нагрузки; для «много мелких файлов + запись» может понадобиться другой дизайн (например, tiering, SSD-журнал, зеркала для метаданных в ZFS и т.п.).

Бэкап-репозиторий

Если это хранилище резервных копий, то приоритет — целостность и предсказуемое восстановление, а не максимальная скорость.Типичный выбор: RAID6/RAIDZ2, плюс режимы, которые минимизируют риск повреждения при сбоях питания (UPS, корректная политика кэша).Ключевая мысль: не путайте storage под продакшн и storage под бэкапы — у них разные профили нагрузки и разные требования.

NVMe под high IOPS

Если цель — низкая латентность и высокий IOPS, то чаще всего RAID1/RAID10 (или зеркала ZFS).Почему: паритет на очень быстрых носителях может упереться в CPU/путь записи и дать «неровные» задержки. Кроме того, NVMe-среда обычно выбирается ради predictability latency, а RAID10 в этом проще.

Когда «лучше не RAID, а…»

Если у вас распределённая система хранения (Ceph и аналоги) и отказоустойчивость обеспечивается репликацией на уровне кластера, то часто разумнее использовать JBOD/HBA и подходить к архитектуре кластера правильно, чем пытаться «дублировать отказоустойчивость» RAID-контроллером (это не всегда плохо, но часто усложняет диагностику и восстановление).

Мини-алгоритм выбора

• Сколько простоя вы терпите (RTO)? Минуты → RAID10/зеркала. Часы → можно смотреть ёмкостные варианты.
• Сколько данных вы можете потерять (RPO)? Если «почти ничего» — думайте про бэкапы/репликацию в первую очередь, RAID лишь снижает простой.
• Что дороже: ёмкость или восстановление? Дешевле диски или дороже простой/инцидент.
• Какие диски? HDD/SSD/NVMe, CMR/SMR, ресурс SSD.
• Есть ли UPS и защищённый кэш? Нет → осторожнее с write-back и паритетными уровнями.
• Сколько займёт rebuild при вашей ёмкости? Если «очень долго» — закладывайте двойной паритет или зеркала.

«Скрытые грабли»: то, о чём не говорят в простых гайдах

Rebuild на больших дисках: долго и опасно

На ёмких HDD rebuild может длиться много часов или дней (в зависимости от нагрузки и политики контроллера). Всё это время массив:

• работает в degraded;
• испытывает дополнительную нагрузку чтения;
• становится уязвимее к второй проблеме (вплоть до полного отказа массива).

Отсюда практическое правило: RAID5 на больших HDD в продакшене часто — плохая идея, если вы не понимаете и не компенсируете риск временем восстановления и качеством дисков/мониторинга.

URE (ошибки чтения) во время rebuild — логика риска

При rebuild контроллер/ОС активно читает оставшиеся диски. Чем больше общий объём чтения и чем старее/нагруженнее диски, тем выше шанс поймать «нечитаемый сектор» или серию ошибок. На RAID5 это может закончиться потерей массива, потому что у вас уже «нет запаса» паритета. На RAID6 запас есть.

Write hole (особенно RAID5/6)

Write hole — класс проблем, когда при внезапном отключении питания часть полосы успела записаться, а часть — нет; паритет и данные могут рассинхронизироваться. Итог — тихая порча данных (особенно неприятная, потому что не всегда обнаруживается сразу).Что реально помогает:

• защищённый write-back (BBU/CacheVault) + UPS;
• корректная политика кэша;
• на уровне ZFS — контрольные суммы и scrub (но питание/UPS всё равно важны).

Кэш контроллера и защита (BBU/CacheVault)

Кэш — это производительность, но только если он безопасен. Без защиты write-back превращается в «ускоряем запись ценой целостности». Поэтому контроллеры и переводят политику в write-through, если батарея/модуль не готов — это нормальная защитная реакция.

SMR-диски: почему могут «убить» rebuild и латентность

SMR (shingled) плохо переносит длительную случайную запись и переписывание областей: rebuild, random write и «дёрганая» нагрузка могут привести к резкому росту задержек и непредсказуемому времени восстановления. Для серверных массивов под нагрузкой обычно выбирают CMR.

Hot spare: когда помогает, а когда даёт ложную уверенность

Hot spare полезен, если:

• у вас нет персонала 24/7 на площадке;
• простой критичен;
• нужно автоматически начать rebuild сразу после отказа.

Но он не заменяет мониторинг и запас дисков на складе, и не лечит проблему «диски одной партии умирают рядом». Иногда лучше иметь spare на полке, чем держать его постоянно в массиве, если среда агрессивная (вибрации/температуры) или диски склонны к «каскадным» отказам.

Stripe/chunk и выравнивание (4K/64K/1M): как не попасть в read-modify-write ад

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

Мониторинг: что именно смотреть

Минимум, который должен быть в алёртах/дашбордах:

• состояние массива: optimal / degraded / rebuilding
• предиктивные ошибки дисков (SMART, media errors, bad blocks)
• статус кэша: write-back/write-through, состояние BBU/CacheVault
• количество и рост ошибок чтения/записи, timeouts
• события замены диска, старт/конец rebuild, скорость rebuild

Практическая настройка и эксплуатация: минимальная гигиена RAID

Чек-лист: перед вводом в эксплуатацию

• Проверить актуальность прошивок: RAID-контроллер / backplane/expander / диски (и совместимость по рекомендациям вендора).
• Включить алёрты: SNMP/email/агент в мониторинг (и проверить, что уведомления реально доходят).
• Политика кэша:
• write-back — только при защищённом кэше (BBU/CacheVault) и желательно UPS;
• иначе — write-through.
• Прогнать тест процедуры отказа:
• симулировать отказ диска;
• проверить порядок замены и старт rebuild;
• убедиться, что деградация видна в мониторинге.
• Запустить первичный scrub/patrol read (если поддерживается) и проверить отчёт.

Чек-лист: регулярная эксплуатация

• Scrub / patrol read: как правило, раз в 2–4 недели для активных хранилищ и раз в 1–3 месяца для «холодных» архивов (подстройте под объёмы и нагрузку).
• Регулярно проверять состояние BBU/CacheVault, что контроллер не ушёл в write-through «по причине».
• Следить за деградациями и не оставлять массив в degraded «на потом».
• Иметь регламент замены дисков (особенно если диски одной партии и нарабатывают одинаковые часы).
• Чёткий план на инцидент: кто делает замену, где spare, как быстро, где смотреть прогресс rebuild.

Типичные ошибки выбора RAID

• RAID5 на больших HDD для production БД или VM-хранилища.
• Write-back без BBU/CacheVault и без UPS.
• «Собрали массив и забыли»: нет мониторинга, алёртов, проверки деградации.
• Нет бэкапов, потому что «у нас же RAID».
• Диски одной партии без стратегии: нет spare/запаса, нет плана замены, нет контроля ошибок.
• Использование SMR-дисков «потому что дешевле» в массиве под rebuild и нагрузку.
• Непродуманное выравнивание/stripe → внезапно плохая запись и «неровная» латентность.
• Жизнь в degraded неделями: «потом поменяем».
• Нет теста восстановления и процедуры замены — первый раз делаете это на проде.
• Слепая вера в «магический» уровень RAID без учёта RTO/RPO и времени rebuild.

При подборе сервера под RAID важно смотреть не только на «количество дисков», но и на контроллер, корзину/hot-swap, совместимость дисков и возможность защищённого кэша (BBU/CacheVault). Это напрямую влияет на производительность записи, поведение при сбоях питания и предсказуемость восстановления массива.

Чтобы инженеры ServerMall быстро предложили корректную конфигурацию, подготовьте:

• ваша задача (VM/БД/файлы/архив/бэкапы, профиль чтения/записи);
• желательно (но не обязательно, если что мы подскажем) тип и объём дисков (HDD/SSD/NVMe, CMR/SMR, требования по ресурсу SSD);
• желаемый уровень/подход RAID (HW RAID / mdadm / ZFS);
• требования к простою (RTO) и к потере данных (RPO);
• есть ли UPS и нужна ли защита кэша (BBU/CacheVault).

FAQ

Можно ли «поменять RAID5 на RAID6» без потери данных?

Иногда — да, но это зависит от реализации (контроллер/ПО), наличия свободного места/дисков и поддерживаемых миграций. В продакшене это планируют как проект: проверяют поддерживаемый путь, делают бэкап и закладывают окно риска.

Что лучше для Proxmox/VMware?

Чаще всего — RAID10 или зеркала: низкая латентность, хороший random write и более предсказуемый rebuild.

Нужен ли RAID, если есть бэкапы?

Если простой критичен — да, RAID снижает вероятность остановки сервиса из-за одного диска. Но бэкапы решают другую задачу — восстановление после логических ошибок, шифровальщиков и «человеческого фактора».

Можно ли смешивать диски разного объёма/модели?

Можно, но обычно массив «подстраивается» под самый маленький диск, а смешение моделей/партий может дать разный профиль отказов и производительности. В проде лучше унифицировать диски и прошивки.

Почему контроллер перевёл кэш в write-through?

Частая причина — батарея/CacheVault не готов (а), неисправна или требует обслуживания. Контроллер делает это, чтобы избежать потери данных при отключении питания.

Что важнее: RAID или UPS?

Для целостности данных часто критичнее питание и корректное завершение записи (UPS + защищённый кэш), особенно при write-back и паритетных RAID. RAID без резервного питания не спасает от «кривых» записей.

RAIDZ1 vs RAID5 — в чём разница по смыслу?

Оба — «один отказ переживаем», но ZFS добавляет модель контроля целостности и регулярный scrub, а RAIDZ — часть пула/файловой системы. При этом дизайн ZFS требует заранее продуманной схемы vdev и понимания ограничений расширения/перестройки.

Сколько дисков нужно минимум под RAID10?

Минимум 4 диска (две зеркальные пары, объединённые в stripe).

Можно ли жить без hot spare?

Можно, если вы гарантируете быстрый выезд/доступ к железу и у вас есть запас дисков. Hot spare полезен там, где важны минуты и нет дежурных рук рядом.

Software RAID — это «хуже», чем аппаратный?

Не обязательно. Software RAID часто выигрывает прозрачностью и переносимостью, а аппаратный RAID — кэшем и привычной эксплуатацией. Выбор зависит от задач, дисциплины мониторинга и требований к миграции/поддержке.

Источники

• SNIA — Common RAID Disk Data Format (DDF)
• Red Hat Docs — Managing RAID
• Broadcom MegaRAID — Cache/BBU/CacheVault guidance
• OpenZFS Docs — RAIDZ (raidz1/2/3), zpool concepts
• OpenZFS — RAIDZ Expansion (контекст развития/ограничений)