JBOD-массив: что это и чем отличается от RAID

JBOD (Just a Bunch of Disks) — режим работы дисковой подсистемы, когда каждый физический накопитель виден операционной системе как отдельный диск. Контроллер не объединяет диски в единый массив и не обеспечивает избыточность данных. JBOD используют, когда нужна максимальная гибкость в управлении дисками, а отказоустойчивость обеспечивают другими средствами — например, репликацией на уровне приложения или резервным копированием.

Режим JBOD встречается в двух основных сценариях: когда нужно передать диски напрямую гипервизору или приложению для создания программных массивов, и когда требуется изолировать данные по разным дискам без объединения в общее пространство. В первом случае JBOD работает как passthrough-режим, во втором — как альтернатива аппаратному RAID для задач с особыми требованиями к управлению данными.

Как работает JBOD

В режиме JBOD контроллер передаёт диски операционной системе без какой-либо обработки. Каждый накопитель получает собственную букву или точку монтирования. Нет ни чередования данных (striping), ни зеркалирования (mirroring), ни вычисления контрольных сумм четности (parity).

Это означает:

• Операционная система видит N физических дисков
• Каждый диск работает независимо от остальных
• Скорость чтения и записи — как у одиночного диска
• Отказ одного диска не влияет на данные на других дисках
• Общая ёмкость равна сумме ёмкостей всех дисков, но без объединения в единое пространство

JBOD mode реализуется через настройки контроллера RAID или HBA (Host Bus Adapter). В серверах Dell, HP, Supermicro эта опция называется по-разному: Non-RAID, Pass-Through, IT Mode, HBA Mode. Суть одна — диски становятся доступны напрямую без абстракции массива.

Отличие JBOD от RAID

RAID (Redundant Array of Independent Disks) объединяет несколько дисков в единый логический том с избыточностью данных. JBOD не создаёт единого тома и не обеспечивает избыточности. Это фундаментальная разница.

Параметр	JBOD	RAID
Объединение дисков	Нет, каждый диск отдельно	Да, единый логический том
Избыточность данных	Нет	Есть (кроме RAID 0)
Производительность	Как у одиночного диска	Зависит от уровня RAID
Управление	На уровне ОС или приложения	На уровне контроллера
Восстановление после сбоя	Только из резервных копий	Автоматическое (RAID 1/5/6/10)
Гибкость конфигурации	Максимальная	Ограничена уровнем RAID

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

JBOD vs RAID 0

RAID 0 часто путают с JBOD, но это разные технологии. RAID 0 объединяет диски в единый том с чередованием данных (striping) — блоки записываются последовательно на разные диски, что повышает скорость чтения и записи в 2-3 раза. JBOD не делает striping, каждый диск работает на своей скорости.

Оба режима не обеспечивают отказоустойчивости: потеря одного диска в RAID 0 ведёт к потере всех данных массива, в JBOD — только данных с этого диска. Для критичных приложений нужны серверы с RAID 1, 5, 6 или 10, либо программные решения вроде Ceph или GlusterFS поверх JBOD.

Когда использовать JBOD

JBOD применяют в нескольких сценариях, где аппаратный RAID избыточен или ограничивает возможности.

Программные СХД и распределённые системы

Системы хранения данных вроде Ceph, GlusterFS, MinIO, ZFS требуют прямого доступа к дискам. Они самостоятельно управляют избыточностью через репликацию и контрольные суммы. Аппаратный RAID в таких конфигурациях создаёт дополнительный уровень абстракции, который снижает производительность и усложняет диагностику.

Пример: кластер Ceph на трёх узлах с 12 дисками на каждом. Контроллер переведён в JBOD mode, Ceph видит 36 OSD (Object Storage Daemon — по одному на диск). Данные реплицируются в три копии на разные узлы. Отказ одного диска приводит к перебалансировке, но не к потере данных.

Виртуализация с passthrough

Гипервизоры ESXi, Proxmox, Hyper-V позволяют пробрасывать физические диски напрямую в виртуальные машины. Это нужно для баз данных или приложений, которые управляют дисками самостоятельно — например, Oracle RAC с ASM (Automatic Storage Management).

В режиме JBOD виртуальная машина получает полный контроль над диском: видит SMART-данные, управляет кэшем, настраивает выравнивание блоков. Аппаратный RAID скрывает физический диск за логическим томом, что блокирует эти возможности.

Разделение данных по дискам

Когда нужно изолировать данные разных проектов или клиентов, JBOD позволяет назначить каждому отдельный диск. Операционная система монтирует диски в разные каталоги, квоты и права доступа настраиваются отдельно.

Пример: сервер резервного копирования с 8 HDD-накопителями в JBOD. Каждый диск хранит бэкапы одного клиента. Отказ диска затрагивает только одного клиента, остальные данные остаются доступны.

Тестирование и разработка

В тестовых средах JBOD упрощает эксперименты с разными файловыми системами, уровнями RAID, конфигурациями кэширования. Диски легко переключать между режимами, добавлять и удалять без перестройки массива.

Настройка JBOD на серверах

Процедура зависит от контроллера и производителя сервера. Общий алгоритм одинаков: заходим в BIOS/UEFI контроллера, переключаем режим с RAID на Non-RAID или HBA.

Dell PowerEdge с PERC

Контроллеры PERC H330, H730, H740P поддерживают режим Non-RAID. В настройках контроллера (доступны через BIOS или iDRAC) каждый диск конфигурируется как Non-RAID Disk. После этого диск виден операционной системе напрямую.

Пример конфигурации для серверной платформы Dell R740 под Proxmox с Ceph: 2 SSD M.2 в RAID 1 для системы (управляются через PERC), 12 SSD 2.5″ в Non-RAID для OSD Ceph. Proxmox видит 12 отдельных SSD, на каждом создаётся OSD.

HP/HPE с Smart Array

Контроллеры Smart Array (P408i, P816i) работают в режиме RAID по умолчанию. Для включения HBA Mode нужно либо перепрошить контроллер в IT-режим (необратимая операция, теряется поддержка RAID), либо создать массивы RAID 0 из одного диска — псевдо-JBOD, который выглядит как JBOD с точки зрения ОС, но управляется контроллером.

Supermicro с LSI/Broadcom

Серверы Supermicro комплектуются контроллерами LSI (теперь Broadcom) — например, 3108, 3516. В утилите WebBIOS или MegaRAID Storage Manager выбираем JBOD Mode или создаём диски в режиме JBOD. Каждый диск становится отдельным устройством без создания виртуального тома.

HBA вместо RAID-контроллера

Альтернатива — использовать HBA (например, LSI 9300-8i, Broadcom 9500-16i) вместо RAID-контроллера. HBA работает только в режиме passthrough, без функций RAID. Это оптимальный выбор для Ceph, ZFS, FreeNAS, где аппаратный RAID не нужен.

HBA дешевле RAID-контроллера, потребляет меньше энергии, не требует батареи для кэша. Но если планируется использовать RAID, нужен именно контроллер с поддержкой JBOD — так можно гибко переключаться между режимами.

Производительность JBOD

В режиме JBOD скорость работы диска определяется характеристиками самого накопителя и интерфейса подключения. Нет ни ускорения, ни замедления от контроллера.

• HDD 7200 RPM SATA: 120-180 МБ/с последовательное чтение/запись, 80-120 IOPS случайное чтение
• SSD SATA: 500-550 МБ/с последовательное, 80 000-100 000 IOPS случайное
• NVMe SSD: 3000-7000 МБ/с последовательное, 300 000-1 000 000 IOPS случайное

Если приложение одновременно работает с несколькими дисками в JBOD, суммарная пропускная способность растёт линейно. Например, 6 SSD SATA в JBOD дают до 3000 МБ/с при параллельной записи — это сравнимо с RAID 0 из того же количества дисков, но без риска потери всех данных при отказе одного диска.

Распределённые системы вроде Ceph используют эту особенность: данные пишутся параллельно на несколько OSD, суммарная скорость зависит от количества дисков и сетевой подсистемы. В такой конфигурации JBOD эффективнее RAID, поскольку Ceph управляет распределением данных самостоятельно.

Отказоустойчивость и резервное копирование

JBOD массив что это такое с точки зрения надёжности — набор независимых дисков без избыточности. Отказ диска ведёт к потере данных на нём. Защита данных — обязанность администратора или приложения.

Стратегии защиты данных в JBOD

Репликация на уровне приложения. Базы данных (PostgreSQL, MySQL, MongoDB) умеют реплицировать данные на несколько узлов. Отказ одного диска или узла не влияет на доступность данных.

Распределённые файловые системы. Ceph, GlusterFS, MooseFS автоматически создают копии данных на разных дисках или узлах. Количество копий настраивается (обычно 3).

Программный RAID поверх JBOD. Операционная система создаёт RAID-массив из дисков в JBOD. Linux поддерживает mdadm (Software RAID), Windows — Storage Spaces, FreeBSD/TrueNAS — ZFS. Гибкость выше, чем у аппаратного RAID, но производительность зависит от процессора.

Резервное копирование. Регулярные бэкапы на внешнее хранилище или в облако. Для критичных данных настраивают автоматические копии по расписанию — например, через Veeam, Bacula, restic.

Мониторинг дисков

В JBOD важно отслеживать состояние дисков через SMART (Self-Monitoring, Analysis and Reporting Technology). Утилиты smartmontools (Linux), CrystalDiskInfo (Windows) показывают счётчики ошибок, температуру, время работы, количество переназначенных секторов.

Настройте уведомления при превышении пороговых значений: рост Reallocated Sectors, высокая температура (>50°C для HDD, >70°C для SSD), ошибки интерфейса. Это позволяет заменить диск до отказа.

Примеры конфигураций с JBOD

Файловый сервер на базе TrueNAS

• 8 HDD 4 ТБ в JBOD
• ZFS pool в режиме RAIDZ2 (аналог RAID 6)
• Доступная ёмкость: 24 ТБ (2 диска под чётность)
• Отказоустойчивость: до 2 дисков одновременно
• Производительность: 600-800 МБ/с чтение, 400-500 МБ/с запись

ZFS управляет дисками в JBOD эффективнее аппаратного RAID: контрольные суммы данных, сжатие, дедупликация, снимки состояния. Для такой конфигурации подходят серверы с 16-32 ГБ оперативной памяти (ZFS активно использует RAM для кэша).

Кластер виртуализации Proxmox с Ceph

• 3 узла по 12 SSD 1 ТБ в JBOD на каждом
• 36 OSD в кластере Ceph
• Реплика = 3 (каждый объект хранится на 3 дисках на разных узлах)
• Доступная ёмкость: 12 ТБ
• Производительность: масштабируется с количеством узлов и дисков

Сетевая подсистема — критичный компонент. Нужны сетевые адаптеры 10GbE или выше (25GbE, 40GbE) для коммуникации между узлами. Без быстрой сети Ceph работает медленнее локальных дисков.

Сервер баз данных с изоляцией данных

• 2 SSD 500 ГБ в RAID 1 для ОС (управляются контроллером)
• 4 NVMe 2 ТБ в JBOD для разных СУБД
• Диск 1: PostgreSQL (основная база)
• Диск 2: PostgreSQL реплика
• Диск 3: MongoDB
• Диск 4: Redis (кэш)

Каждая СУБД работает на выделенном диске. Производительность не зависит от других приложений. Администратор настраивает I/O-приоритеты, квоты, мониторинг отдельно для каждого сервиса.

Распространённые ошибки при работе с JBOD

Отсутствие резервного копирования

Администраторы иногда считают, что JBOD безопаснее RAID 0, поскольку отказ одного диска не затрагивает остальные. Это верно, но без бэкапов потеря одного диска всё равно означает потерю данных. Настройте автоматическое копирование на внешнее хранилище или второй сервер.

Использование JBOD для критичных приложений без репликации

Если приложение не умеет реплицировать данные, JBOD — плохой выбор. База данных без репликации на JBOD потеряет данные при отказе диска. Используйте RAID 1/10 на аппаратном контроллере или программный RAID.

Игнорирование мониторинга SMART

Диски в JBOD управляются ОС, но это не освобождает от мониторинга. Утилиты вроде smartd (Linux) или Windows Storage Spaces отправляют уведомления о проблемах. Настройте их при первом запуске сервера.

Неправильный выбор контроллера

Не все RAID-контроллеры поддерживают JBOD mode. Перед покупкой проверьте спецификацию. Альтернатива — HBA, но если планируется использовать RAID для системных дисков, нужен именно контроллер с JBOD.

Недооценка требований к сети в Ceph

Ceph по JBOD с медленной сетью (1GbE) работает хуже локального RAID. Минимум — 10GbE, рекомендуется выделенная сеть для Ceph (Public и Cluster Network). Без этого кластер будет узким местом.

Часто задаваемые вопросы