Раз в несколько месяцев всплывает спор «аппаратный RAID vs программный RAID». Потому что кто-то где-то только что поймал инцидент с хранилищем и теперь узнает много нового… очень быстро.
Иногда стек хранения выглядит как свадебный торт, который десять лет проектировали три разные команды. И однажды это становится вашей проблемой.
Окей, мы тут не для того, чтобы судить или злиться. Большую часть времени мы учимся на ошибках. Поэтому вот что мы выяснили про вопрос аппаратного vs программного RAID.
RAID снижает простой, когда выходит из строя диск. Он не защищает от логической порчи данных, удаления, ransomware, ошибок оператора или ситуаций «стерли не тот диск». Для это нужны бэкапы.
Так, мы сказали это, теперь к теории.
RAID-архитектура в серверах объединяет несколько дисков в один логический блок и использует разные технологии распределения данных между дисками, обеспечивая разные уровни избыточности и производительности.
RAID-контроллер управляет массивом, контролируя распределение данных, избыточность и отказоустойчивость всей системы. Он объединяет диски в один объект, который может использовать операционная система.
Это могут быть либо аппаратные RAID-карты, установленные в сервер, либо программные RAID-конфигурации, где управление выполняет CPU.
Аппаратный RAID — это отдельный RAID контроллер внутри сервера, который сам управляет массивом. Часто у него есть кэш write-back и защита питания (BBU/CacheVault). Для ОС это один или несколько логических/виртуальных дисков.
Программный RAID — массив, собираемый ОС или стеком файловой системы (mdadm, ZFS, Storage Spaces и т. п.). Метаданные обычно хранятся на самих дисках, а логика и восстановление обрабатываются ОС.
FakeRAID или BIOS RAID — когда конфигурация и метаданные задаются в BIOS/UEFI (или на чипсете/контроллере), но обработка часто выполняется драйвером ОС. Это нередко приводит к проблемам с переносимостью и диагностикой.
Возьмите аппаратный или программный RAID либо опробуйте оба варианта на изолированных ресурсах физического сервера.
HBA (Host Bus Adapter) — адаптер, который не управляет массивом и не пытается быть «умнее» ОС. Его задача — подключить SAS/SATA-диски (часто через expander) и передать их наверх как отдельные устройства.
Это дает программному RAID, ZFS или Storage Spaces прямой доступ к дискам и их сигналам (ошибки, идентификатор диска).
HBA часто используют команды, которые работают с ZFS-пулами, Ceph или другими SDS-решениями, mdadm-RAID, и в любых сценариях, где избыточность и политики записи должны жить в стеке ОС или файловой системы.
IT mode (Initiator Target mode) — режим или прошивка (чаще в экосистемах LSI и Broadcom), при котором RAID-карта перестает быть RAID-контроллером и ведет себя как HBA: передает диски как есть, без сборки массивов на уровне контроллера. И железо используется, и достигается нужная прозрачность для ZFS/SDS.
Passthrough — общий термин для проброса устройства «как есть», без обработки и абстракций на промежуточном уровне. В контексте дисков и RAID это означает, что ОС (или VM) получает прямой доступ к физическому диску, а не к виртуальному диску, собранному контроллером.
JBOD (Just a Bunch Of Disks) в самом общем смысле — это просто набор дисков без RAID-логики. То есть нет зеркала/паритета, нет массива как единого объекта.
Но JBOD все равно может выглядеть как RAID для ОС и валидаторов — из-за того, как устройство классифицируется драйвером. Если драйвер контроллера возвращает устройства как RAID-класс (в Windows это часто отражается в BusType), платформа может решить, что диски не «raw», и отклонить их. Некоторые стеки прямо требуют «физические SATA/SAS/NVMe-устройства» и отсекают все, что похоже на RAID-абстракцию, даже если диски пробрасываются по одному.
Аппаратный RAID — это уровень RAID, прошивка, кэш и политики записи, которые меняют поведение системы при сбоях. Обычно внутри контроллера есть RAID engine/ASIC, который считает паритет и управляет очередями, и прошивка, которая решает, когда считать запись завершенной и как восстанавливаться после ошибок.
Кэш write-back ускоряет запись, потому что контроллер подтверждает I/O сразу после того, как данные попали в DRAM, а на диск сбрасывает их чуть позже. Это дает заметный прирост производительности на RAID-5/6 и на мелких sync-writes, но при потере питания завершенные и подтвержденные записи могут физически не оказаться на дисках.
Именно поэтому существуют BBU или CacheVault. Их задача — защитить кэш контроллера при отключении питания (либо поддерживая питание DRAM, либо успевая перенести данные во flash или NAND).
ОС видит именно виртуальные устройства. Вместо /dev/sdX для каждого диска вы получаете Virtual Disk/Logical Drive — единое блочное устройство, которое скрывает состав массива, порядок дисков и метаданные контроллера.
Из-за этой абстракции телеметрия может искажаться: SMART, серийные номера, температура, детальные media errors. То есть видимость зависит от модели контроллера, драйвера и режима passthrough. На практике это часто всплывает в мониторинге: «в массиве все OK», но понять, какой диск генерирует ошибки, сложнее.
Если ломается контроллер или прошивка, восстановление может потребовать совместимый контроллер/firmware, а иногда даже то же поколение у того же вендора. Тут vendor lock-in превращается в проблему закупки прямо во время инцидента.
Кроме того, контроллер постоянно выполняет фоновые задачи, которые могут проявляться как деградация производительности или неожиданные проблемы. Rebuild, patrol read, consistency check — все это создает I/O и влияет на «поверхность» дисков.
Программные типы RAID-контроллеров (конфигураций) могут быть на уровне ОС или на уровне файловой системы.
Уровень ОС — классический вариант, например Linux md/mdadm: ОС объединяет несколько устройств в одно md-устройство, поверх которого вы ставите ext4/xfs и используете это как обычный диск.
Windows Storage Spaces похож по концепции: есть storage pool, из которого нарезаются виртуальные диски с mirror/parity.
Уровень файловой системы, или ZFS (и частично btrfs), — это когда один механизм покрывает RAID-подобную избыточность, управление томами и возможности файловой системы.
ZFS предпочитает прямой доступ к дискам, потому что ей нужен контроль над путями данных и сигналами об ошибках. ZFS хранит checksums, проверяет блоки и, если есть избыточность, может выполнять “self-repair” (прочитать правильную копию и перезаписать поврежденную).
Программный RAID и ZFS обычно смещают восстановление в сторону переносимости дисков и метаданных, которые живут вместе с пулом.
Типичное поведение при восстановлении: если сервер умер, вы переносите диски (или HBA) на другой хост и импортируете массив/пул.
Нюанс в том, что «переносимость» все равно требует совместимых контроллеров/HBA/драйверов, конкретного понимания того, как стек хранения идентифицирует устройства, и понятных runbooks.
Современные платформы хранения часто хотят raw disks, потому что именно они отвечают за распределение данных, отказоустойчивость и проверки целостности. Поэтому практическое правило для Proxmox и ZFS — не ставить ZFS поверх аппаратного RAID со своим управлением кэшем и структурой записи. Вместо этого используйте HBA или IT mode, где контроллер просто отдает диски как есть.
Чем больше слоев контролируют диски, тем сложнее предсказать сбой и тем дороже становится восстановление. Давайте поговорим про стек хранения, который регулярно обсуждают в тредах.
Вид такой:
Это может выглядеть разумно: больше емкости, больше гибкости, меньше движущихся компонентов, которые видит ОС. К сожалению, один сбой на нижнем уровне может сломать все, что выше. А при восстановлении вы должны угадать какой слой сейчас знает "правду".
Только один слой должен владеть избыточностью. Либо это контроллер (и вы принимаете controller-centric recovery), либо стек ОС/файловой системы (и вы проектируете под видимость raw-disk).
Конфликт «аппаратный vs программный RAID» редко проявляется как «чистая» поломка. Чаще, если ваш стек хранения движется в сторону слоеного пирога, это выглядит как предупреждения, ошибки валидации или операционные “edge cases”, которые внезапно становятся блокерами для продакшена.
Выбирайте подход, который ваша реальная команда умеет мониторить и чинить, и не наслаивайте два уровня, которые оба пытаются умничать с кэшированием, порядком записи и избыточностью. И спросите себя: “Что будет, когда это сломается, и насколько неприятным окажется восстановление?”
Если у вас нет очень специфического ограничения — по умолчанию выбирайте raw disks + software stack. Этот вариант подойдет, если вам важны целостность данных, предсказуемое восстановление и удобство эксплуатации на дистанции (особенно для Proxmox/TrueNAS/Linux storage boxes). Используйте HBA / IT mode / passthrough mode контроллера. OpenZFS прямо рекомендует использовать HBA вместо RAID controller по соображениям надежности.
Выбирайте mdadm (программный RAID на уровне ОС), если вам нужен простой, переносимый RAID без подхода ZFS «весь стек целиком» (например, ext4/xfs сверху), и вы все равно хотите избежать controller lock-in. Массивы mdadm хранят metadata на дисках, поэтому обычно можно перенести диски в другой Linux-бокс и собрать массив заново (через --assemble/--scan, плюс порядок в mdadm.conf). Этот вариант лучше всего подходит для обычных Linux-серверов, простой избыточности (RAID1/10) и сред, где snapshots или checksumming не в приоритете.
Выбирайте аппаратный RAID, если:
Но что бы вы ни выбрали, вам все равно нужны протестированные бэкапы и offsite copies.