Можно ли ставить ZFS на отдельные RAID 0 по одному диску?

Да, такая схема иногда используется, когда контроллер не предоставляет полноценный JBOD или passthrough. Однако для ZFS она допустима только при подтверждённых свойствах конкретной комбинации контроллера, firmware, драйвера и накопителей. Нужно установить, остаются ли для ОС стабильными идентификаторы дисков, передаются ли сведения о состоянии накопителя и не фильтруются ли необходимые команды. Отдельно проверяют процедуру замены: контроллер не должен требовать непредсказуемого удаления и создания нового виртуального RAID-объекта, из-за которого устройство будет представлено иначе. Созданный на одном диске RAID 0 всё равно является логическим объектом контроллера и может содержать его метаданные. Поэтому его нельзя автоматически приравнивать к прямому подключению или полноценному HBA. Для ZFS типовой и более прозрачный вариант — отдельные физические диски через HBA, прямые порты либо документированный поштучный passthrough/JBOD.

Как понять, что Write-Back кэш RAID-контроллера можно включать?

Сначала проверьте наличие и текущий статус защиты кэша, которую поддерживает конкретный RAID-контроллер: аккумуляторной батареи BBU, CacheVault, flash-backed cache или суперконденсатора. Защита должна быть не просто установлена, а определяться контроллером как исправная. Затем убедитесь, что для нужного логического диска действительно действует политика Write-Back, а не Write-Through. При проблемах с защитой многие контроллеры сами переходят на сквозную запись или отключают Write-Back. Такое переключение нельзя обходить принудительно, пока не установлена причина неисправности. Также не следует считать Write-Back гарантированным ускорением: эффект зависит от профиля ввода-вывода, модели контроллера, настроек кэша, накопителей и состояния массива. Для решения важны и производительность, и план обслуживания защиты кэша, включая её проверку и своевременную замену.

Увидит ли обычный SAS/SATA HBA NVMe-диски?

Нет, обычный SAS/SATA HBA сам по себе не становится NVMe-контроллером. Для NVMe нужно отдельно подтвердить PCIe-топологию сервера, линии PCIe, корзину, кабели, backplane и поддержку платформы. Tri-mode-контроллер может работать с NVMe, но это не подтверждает совместимость всего тракта.

Какие идентификаторы нужны mdadm, чтобы не перепутать диски?

Для mdadm нужны отдельные стабильные идентификаторы устройств: серийный номер, WWN или другой документированный идентификатор. Полагаться только на имена вида /dev/sdX нельзя, поскольку они могут меняться. Также важно, чтобы мониторинг позволял сопоставить устройство ОС с физическим слотом корзины.

Нужно ли проверять TRIM/UNMAP для SSD за контроллером?

Да, для SSD нужно проверять передачу TRIM/UNMAP именно в конкретной связке контроллера, firmware, драйвера и SAS/SATA-накопителя. Название режима JBOD, passthrough или HBA mode не гарантирует прохождение этих команд. Одновременно следует проверить доступность S.M.A.R.T., температуры и счётчиков ошибок.

Можно ли загрузить ОС с дисков в JBOD или HBA mode?

Зависит от конкретной модели и конфигурации. Перед настройкой нужно подтвердить поддержку выбранного режима прошивкой контроллера, BIOS/UEFI, установщиком ОС и драйвером. Для загрузочного массива также проверяют, что сервер способен загружаться именно с устройства, представленного в этом режиме.

HBA или RAID-контроллер: выбор для ZFS, Ceph, mdadm и RAID

Для ZFS, Ceph и mdadm обычно выбирают схему, в которой ОС получает отдельно идентифицируемые накопители: через полноценный HBA, прямое подключение или документированный режим контроллера. Аппаратный RAID разумен, когда ОС нужен готовый логический том, а функции конкретного RAID-контроллера, его защищённый кэш и порядок обслуживания соответствуют нагрузке. Названия IT mode, HBA mode, JBOD и passthrough сами по себе не доказывают одинаковое поведение.

Выбор по сценарию: что должна видеть ОС

Схема подключения важнее названия режима контроллера.

Сценарий	Что должна видеть ОС	Предпочтительный способ	Оговорка
ZFS-пул	Отдельные физические диски с доступными идентификаторами и состоянием	Полноценный HBA, прямые SATA/SAS-порты или документированный passthrough/JBOD	Аппаратный RAID-том возможен лишь после проверки требований конкретной реализации и версии ZFS.
Ceph OSD	Отдельные устройства для OSD; при необходимости отдельно data, DB и WAL	HBA, прямое подключение или подтверждённое поштучное представление дисков	Контроллер не должен скрывать отказ диска и усложнять его замену.
Linux RAID через mdadm	Отдельные стабильные блочные устройства	HBA, прямое подключение, JBOD или HBA mode с проверенным поведением	Проверяют S.M.A.R.T., идентификаторы, обработку ошибок, TRIM/UNMAP и загрузку.
Обычный аппаратный RAID для ОС, гипервизора или приложения	Один или несколько готовых логических дисков	RAID-контроллер с нужными функциями и исправной защитой кэша	Преимущество Write-Back зависит от модели, политики и состояния защиты кэша.

Выбор между программным и аппаратным RAID как владельцем избыточности рассмотрен отдельно в статье «Программный или аппаратный RAID: что выбрать для Linux-сервера». Здесь важен вопрос ниже: передаёт ли контроллер ОС отдельные накопители или уже собранный массив.

HBA и RAID-контроллер: какие устройства увидит ОС

Полноценный HBA обычно не формирует аппаратные RAID-массивы: ОС видит каждый подключённый HDD или SSD как отдельное блочное устройство. Контроллер передаёт команды к накопителю, а RAID, файловая система или кластерный слой работают выше. Это не означает, что любой адаптер с надписью HBA обладает одинаковой поддержкой SATA, SAS, телеметрии и служебных команд.

Аппаратный RAID-контроллер объединяет физические диски в массив и предоставляет ОС логический диск. Контроллер хранит RAID-метаданные, принимает решения при отказе участника и выполняет Rebuild. ОС обычно работает с готовым томом, а сведения о каждом физическом диске получает через драйвер, утилиту управления или не получает в полном объёме.

Способ представления	Что обычно получает ОС	Что нужно установить по документации
Полноценный HBA	Каждый диск отдельно	Поддержку нужных накопителей, драйвера, телеметрии и команд.
IT mode	Отдельные SAS/SATA-диски без аппаратных RAID-томов	Что именно этот режим поддерживает у данного семейства, OEM-модели и версии firmware.
HBA mode RAID-контроллера	Зависит от модели: отдельные устройства либо режим с ограничениями	Передачу идентификаторов, S.M.A.R.T., TRIM/UNMAP, поведение при замене и загрузку ОС.
JBOD или passthrough	Обычно каждый диск отдельно	Является ли режим настоящим поштучным представлением, а не логическим объектом контроллера.
Один RAID 0 на диск	По одному логическому диску на каждый накопитель	Метаданные RAID, стабильность идентификаторов, доступные команды и процедуру замены.
Аппаратный RAID-массив	Один или несколько логических дисков	RAID-функции, состояние кэша, совместимость драйвера и средства мониторинга.

Одинарный RAID 0 не равен HBA по определению

Создание RAID 0 из одного накопителя на каждый диск иногда используется как обход отсутствия JBOD. Но контроллер может записывать собственные RAID-метаданные, менять видимые ОС идентификаторы, фильтровать команды или требовать удаления и повторного создания виртуального диска при замене. Использовать такую схему для ZFS, Ceph или mdadm можно только после проверки документированных свойств конкретной модели, firmware, драйвера и типа накопителя.

Почему ZFS обычно нужен доступ к отдельным дискам

ZFS сама управляет составом пула, избыточностью, заменой накопителей и проверкой целостности. Поэтому типовая схема — отдельные устройства за HBA или напрямую подключённые диски. Так ZFS может сопоставлять устройство с конкретным накопителем по доступным идентификаторам и использовать доступные сведения о его состоянии.

Если создать ZFS поверх аппаратного RAID-тома, ZFS видит главным образом один логический диск, а не его участников. Часть сведений о серийных номерах, состоянии, температуре и ошибках физических накопителей может быть доступна только средствами контроллера или быть недоступной. Добавляется второй слой, который отдельно обрабатывает отказы, замену дисков и Rebuild. Такая конфигурация не обязательно неработоспособна, но её допустимость, настройки кэширования записи и ограничения нужно сверять с документацией конкретной реализации и версии ZFS.

Почему Ceph обычно размещает OSD на отдельных устройствах

В Ceph OSD обычно работают с отдельными устройствами, а реплики или erasure coding распределяются между доменами отказа по правилам пула. Это позволяет кластеру учитывать отказ узла, диска, стойки или другого настроенного домена, а администратору — заменять конкретный накопитель. Для BlueStore также отдельно проектируют устройства для данных, базы метаданных (DB) и журнала упреждающей записи (WAL), если это требуется профилем нагрузки и архитектурой кластера.

Аппаратный RAID под OSD добавляет контроллеру собственный Rebuild и может скрыть деградацию или отказ отдельного диска от Ceph. Замена накопителя становится операцией на уровне RAID-контроллера, а не только OSD; отказоустойчивость и производительность начинают зависеть от двух независимых слоёв. Исключения возможны, но их следует обосновать архитектурой кластера и рекомендациями используемой версии Ceph, а не тем, что контроллер умеет создавать RAID.

Можно ли использовать mdadm за RAID-контроллером

Да. mdadm может собирать программный RAID из дисков за HBA, напрямую подключённых накопителей, а также устройств, поштучно представленных RAID-контроллером в JBOD, passthrough или подтверждённом HBA mode. Для mdadm важны не маркетинговое название режима, а доступность и предсказуемость отдельных устройств.

ОС получает отдельные и стабильные идентификаторы: серийный номер, WWN или иной документированный идентификатор; нельзя полагаться только на меняющиеся имена /dev/sdX.
Доступны нужные данные S.M.A.R.T., температура и счётчики ошибок либо понятен другой способ мониторинга через контроллер.
Контроллер корректно сообщает об отказе, извлечении и установке диска; после замены не требуется неожиданное пересоздание RAID-объекта.
Для SSD проверена передача нужных команд обслуживания, включая TRIM/UNMAP, именно для сочетания контроллера, firmware, драйвера и SAS/SATA-накопителя.
Установщик и загруженная ОС видят устройства в выбранном режиме; для загрузочного массива проверены драйвер и поддержка boot-пути.
Средства мониторинга умеют сопоставить устройство ОС со слотом в корзине. Настройка mdadm описана в отдельном материале, а восстановление после сбоя — в статье о действиях после отказа.

Когда аппаратный RAID рациональнее HBA

Аппаратный RAID предпочтителен, когда ОС или гипервизору нужен готовый логический том, а управление массивом — создание, мониторинг, замена дисков и Rebuild — планируется на уровне контроллера. Это типичный вариант для ОС, хранилища виртуальных машин (datastore) или приложения, которому не требуется самостоятельно управлять отдельными физическими дисками.

В ряде нагрузок полезен Write-Back кэш: контроллер подтверждает запись после помещения данных в кэш и позже переносит их на накопители. Снижение задержки не гарантировано: результат зависит от профиля ввода-вывода, модели контроллера, политики кэша, накопителей и состояния массива.

Write-Back требует работающей защиты кэша

Включать Write-Back следует только при подтверждённой исправности предусмотренной моделью защиты: BBU, CacheVault, flash-backed cache или суперконденсатора. При ошибке защиты многие контроллеры переключаются на сквозную запись или отключают Write-Back; принудительное включение без понимания причины создаёт риск. Проверка и замена таких компонентов описаны в статье «BBU, CacheVault и суперконденсатор RAID-контроллера».

Для виртуализации выбор зависит от профиля datastore, нагрузки записи и плана обслуживания, а не только от типа контроллера: см. «RAID для VMware ESXi и Hyper-V: проектирование хранилища ВМ». RAID-уровень, полезная ёмкость и допустимые отказы — отдельная тема: сравнение RAID-уровней.

NVMe: HBA или RAID не заменяет проверку PCIe-тракта

Выбор HBA либо RAID-контроллера сам по себе не определяет поддержку NVMe. Обычный SAS/SATA HBA не становится NVMe-контроллером. Для NVMe отдельно проверяют PCIe-топологию сервера, дисковую корзину, кабели, backplane, разбиение линий PCIe и поддержку конкретной платформой.

Трёхрежимный контроллер может поддерживать SAS, SATA и PCIe/NVMe, но слово tri-mode в его описании не подтверждает совместимость всего тракта. Нужно сверить поддержку портов, корзины и конфигурации конкретного сервера. Особенности RAID для SSD, M.2 и NVMe разобраны в статье «RAID на SSD, M.2 и NVMe».

Стоп-критерии до покупки и настройки

Проверка контроллера до выбора схемы

Если на любой шаг нет документированного ответа для сочетания модели, firmware, драйвера и платформы, схему лучше не считать подтверждённой.

1
Зафиксируйте владельца избыточности
Для ZFS, Ceph и mdadm планируйте отдельно представленные диски. Для обычного аппаратного массива — логический диск, создаваемый контроллером.
2
Проверьте фактический режим представления дисков
Установите по документации, поддерживает ли конкретная модель полноценный HBA, IT firmware, HBA mode, JBOD или passthrough. Не заменяйте эту проверку названием режима в интерфейсе.
3
Проверьте телеметрию и команды
Сверьте, видит ли ОС для нужного типа диска идентификаторы, S.M.A.R.T., температуру и ошибки; передаются ли команды обслуживания SSD, включая TRIM/UNMAP.
4
Проверьте отказ и замену
Выясните, как ОС и утилита контроллера показывают извлечение, отказ и установку диска, сохраняются ли идентификаторы и требуется ли создавать либо удалять объект на контроллере.
5
Проверьте загрузку и драйвер
Подтвердите поддержку выбранного режима прошивкой, BIOS/UEFI, установщиком ОС и драйвером. Отдельно проверьте, может ли сервер загружаться с нужного устройства.
6
Сверьте интерфейс и топологию
Для SAS и SATA проверьте контроллер, корзину и кабели. Для NVMe дополнительно подтвердите PCIe-линии, backplane либо tri-mode-путь. Полный подбор совместимых компонентов приведён в статье «Как выбрать RAID-контроллер: совместимость, кэш, SAS, SSD и NVMe».
7
Для аппаратного RAID подтвердите защиту кэша
Проверьте наличие, тип и текущий статус BBU, CacheVault, flash-backed cache или суперконденсатора, а также фактическую политику Write-Back/Write-Through для логического диска.

Термины в статье

Аппаратный RAID: Реализация RAID, в которой специализированный контроллер формирует логические диски и выполняет операции массива. Наличие и защита кэша зависят от модели.
Виртуализация: Технология абстрагирования физических вычислительных ресурсов, позволяющая создавать виртуальные серверы, хранилища, сети и другие логические ресурсы.
Виртуальная машина: Изолированная вычислительная среда с виртуальными процессорами, памятью, дисками и сетевыми адаптерами, в которой под управлением гипервизора работает гостевая ОС.
Гипервизор: Программный слой, который абстрагирует ресурсы физического хоста, выполняет виртуальные машины и управляет ими.
Дисковая корзина: Дисковая корзина — узел шасси с отсеками для установки нескольких накопителей и организации их подключения к питанию и контроллеру либо HBA.
Кэш со сквозной записью: Кэш со сквозной записью — режим, в котором кэш не подтверждает запись раньше нижележащего хранилища и не оставляет подтверждённые данные только в своей энергозависимой памяти.
Кэширование записи: Кэширование записи — временное размещение записываемых данных в быстрой памяти перед их передачей в нижестоящее хранилище для снижения задержки и оптимизации ввода-вывода. Момент подтверждения записи и гарантия её сохранности зависят от политики кэша и всех уровней стека хранения.
Логический диск: Логический диск — блочное устройство, которое RAID-контроллер или программная RAID-подсистема предоставляет хосту как отдельный накопитель.
Метаданные RAID: Метаданные RAID — служебные записи на дисках или контроллере, описывающие состав, уровень, состояние и параметры RAID-массива для его распознавания и сборки.
Программный RAID: RAID, реализованный ОС или другим программным стеком хоста без отдельного аппаратного RAID-контроллера. Использует вычислительные ресурсы сервера.
Суперконденсатор: Накопитель энергии высокой мощности, применяемый для кратковременного питания кэша RAID-контроллера. При сбое питания он сохраняет данные до записи во флеш-память.
Трёхрежимный RAID-контроллер: Аппаратный RAID-контроллер, интерфейсы которого поддерживают SAS-, SATA- и PCIe/NVMe-накопители; схема подключения зависит от контроллера и платформы.
Физический диск: Физический диск — отдельный HDD, SSD или иной накопитель, распознанный RAID-контроллером как член массива либо как независимое устройство.
BBU: Аккумуляторный модуль, поддерживающий питание энергозависимого кэша RAID-контроллера при сбое питания до восстановления питания и записи данных на диски.
CacheVault: CacheVault — технология защиты кэша записи RAID-контроллера, сохраняющая во флеш-память подтверждённые хосту, но ещё не записанные на диски данные при потере питания.
Ceph: Ceph — распределённая программно-определяемая система хранения, объединяющая диски серверов в масштабируемое объектное, блочное и файловое хранилище.
Datastore: Логический контейнер хранилища в VMware для размещения файлов виртуальных машин (диски, конфигурации, логи)
HBA: HBA — адаптер ввода-вывода, соединяющий сервер с накопителями или SAN и не формирующий аппаратные RAID-массивы.
IT mode: IT mode — прошивочный режим прежде всего SAS HBA Broadcom/LSI и их OEM-вариантов, в котором ОС видит отдельные SAS/SATA-накопители без аппаратных RAID-томов.
JBOD: Способ подключения дисков без аппаратного RAID: обычно ОС видит каждый накопитель отдельно. Сам JBOD не обеспечивает избыточность; при необходимости её создаёт программный уровень.
M.2: M.2 — спецификация компактного разъёма и модулей расширения, определяющая размеры и ключи; накопители M.2 могут использовать интерфейс SATA или PCIe.
mdadm: Утилита командной строки Linux для создания, сборки, мониторинга и изменения программных RAID-массивов подсистемы MD.
NVMe: NVMe — протокол обмена командами с энергонезависимыми накопителями, оптимизированный для параллельного ввода-вывода; локальные NVMe-SSD обычно подключаются по PCIe.
Passthrough: Passthrough — режим контроллера, в котором отдельный накопитель предоставляется ОС как самостоятельное блочное устройство без включения в аппаратный RAID-массив.
RAID 0: RAID 0 — массив минимум из двух дисков с чередованием данных без избыточности. Отказ любого участника делает весь логический том недоступным.
RAID-контроллер: Устройство или модуль, который формирует RAID-массивы из накопителей и предоставляет ОС логические диски, управляя размещением данных, отказами и восстановлением избыточности.
RAID-уровень: RAID-уровень — схема размещения данных и избыточности по накопителям массива, определяющая полезную ёмкость, отказоустойчивость и характеристики ввода-вывода.
Rebuild: Процесс восстановления избыточности массива после замены отказавшего диска: контроллер вычисляет и записывает на новый диск недостающие данные из остальных дисков.
S.M.A.R.T.: S.M.A.R.T. — технология самодиагностики накопителей, собирающая показатели состояния и ошибок. Она помогает выявлять признаки деградации диска до отказа.
SAS: SAS — последовательный интерфейс и набор протоколов SCSI для подключения накопителей, поддерживающий адресацию устройств, экспандеры и обычно двухпортовое подключение дисков.
SATA: SATA — последовательный интерфейс подключения HDD, SSD и оптических приводов; в обычной прямой схеме один порт контроллера соединён с одним накопителем.
TRIM: TRIM — операция ATA, которой ОС сообщает SATA SSD, что указанные логические блоки больше не используются; немедленное стирание данных при этом не гарантируется.
Write-Back кэш: Политика кэша RAID-контроллера: запись подтверждается после помещения данных в кэш, а на накопители переносится позже. Кэш требует защиты от потери питания.
ZFS: ZFS — файловая система и менеджер томов с пулами хранения, контрольными суммами и копированием при записи, объединяющий управление дисками и данными.