Программные RAID-массивы на Linux и когда аппаратный контроллер действительно нужен

Спор между программным и аппаратным RAID существует столько же, сколько существует сам Linux. Один лагерь уверен: настоящая надёжность требует выделенного железа с батарейным кэшем. Другой возражает: современный процессор справляется с пересчётом чётности за доли процента загрузки, а vendor-lock на проприетарный контроллер опаснее любого software overhead. Обе позиции имеют право на жизнь, но при одном условии - понимании того, что именно происходит внутри каждого подхода.

mdadm появился в 2001 году как замена устаревшему raidtools и с тех пор стал стандартным инструментом управления программными RAID-массивами в Linux. Сегодня, по данным 2024-2025 годов, программный RAID через mdadm обслуживает около 60% всех RAID-конфигураций на Linux в корпоративной среде. Облачные платформы практически полностью перешли на программно-определяемое хранилище: доля software RAID в виртуальных средах превышает 80-90%. Цифры говорят сами за себя - но не означают, что аппаратные контроллеры устарели.

Как mdadm управляет массивами и где хранит метаданные

Ядро Linux содержит модуль md (Multiple Devices), который реализует всю логику RAID прямо в kernel space. Утилита mdadm - это лишь userspace-инструмент для управления этим модулем. Когда дисковые операции происходят, их обрабатывает ядро без участия демонов пространства пользователя. Именно поэтому overhead mdadm на современных многоядерных процессорах пренебрежимо мал - пересчёт чётности для RAID 5 и RAID 6 занимает менее 1% процессорного времени даже при интенсивной нагрузке.

Каждый диск массива хранит суперблок - небольшую область метаданных, описывающую состав и параметры массива. Формат суперблока определяет, где именно на диске он расположен, и это принципиально важно при загрузке системы с RAID:

• Формат 0.90 - суперблок в конце диска, безопасен для загрузки с RAID 1
• Формат 1.0 - суперблок в конце раздела, совместим с большинством загрузчиков
• Формат 1.1 - суперблок в начале раздела
• Формат 1.2 - суперблок по смещению 4 КБ от начала, рекомендован для новых массивов

# Создать RAID 1 из двух дисков с форматом суперблока 1.2
mdadm --create /dev/md0 --level=1 --raid-devices=2 \
  --metadata=1.2 /dev/sdb /dev/sdc

# Создать RAID 6 из шести дисков с горячей заменой
mdadm --create /dev/md0 --level=6 --raid-devices=6 \
  --spare-devices=1 /dev/sd{b,c,d,e,f,g,h}

# Сохранить конфигурацию в mdadm.conf
mdadm --detail --scan >> /etc/mdadm/mdadm.conf

После создания массива его состояние видно через /proc/mdstat - один из наиболее читаемых файлов в /proc:

cat /proc/mdstat

Вывод покажет активные массивы, их состояние, прогресс синхронизации и список устройств. При деградированном массиве (один или несколько дисков отсутствуют) статус сменится с [UU] на [U_], что сразу сигнализирует о проблеме.

Управление массивом в работе и процедура замены диска

Повседневное обслуживание массива - это мониторинг, проверка целостности и реагирование на отказы. mdadm умеет отправлять email-уведомления при проблемах, но для этого нужно настроить режим мониторинга.

# Подробная информация о массиве
mdadm --detail /dev/md0

# Информация о конкретном диске в массиве
mdadm --examine /dev/sdb

# Запустить фоновую проверку целостности
echo check > /sys/block/md0/md/sync_action

# Посмотреть прогресс проверки
cat /sys/block/md0/md/sync_completed

# Настроить мониторинг с отправкой email
mdadm --monitor --mail=Адрес электронной почты защищен от спам-ботов. Для просмотра адреса в браузере должен быть включен Javascript. --delay=300 /dev/md0

Процедура замены отказавшего диска в mdadm прозрачна и предсказуема. Это одно из ключевых преимуществ перед аппаратными контроллерами: каждый шаг виден и контролируем:

# Пометить диск как отказавший вручную (если не произошло автоматически)
mdadm /dev/md0 --fail /dev/sdc

# Удалить диск из массива
mdadm /dev/md0 --remove /dev/sdc

# Добавить новый диск - перестройка начнётся автоматически
mdadm /dev/md0 --add /dev/sdd

# Следить за прогрессом перестройки
watch cat /proc/mdstat

Скорость перестройки влияет на производительность системы в период восстановления. mdadm позволяет управлять этим балансом:

# Ограничить скорость перестройки (в КБ/с)
echo 50000 > /proc/sys/dev/raid/speed_limit_max

# Повысить приоритет перестройки для быстрого восстановления
echo 200000 > /proc/sys/dev/raid/speed_limit_min

Выбор уровня RAID и реальные компромиссы между надёжностью и ёмкостью

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

RAID 1 - зеркало. Максимальная надёжность на паре дисков, 100% overhead по ёмкости. Каждый диск содержит полную копию данных. Идеален для системного раздела, где важна простота и гарантированная восстанавливаемость. Чтение может обслуживаться с любого диска, что даёт прирост скорости чтения при параллельных запросах.

RAID 5 требует минимум три диска, один из которых эффективно уходит под хранение чётности. Умеренная ёмкость при хорошей производительности чтения. Слабое место - write penalty: каждая запись требует чтения, пересчёта и записи чётности. На массивах из дисков объёмом 16 ТБ и больше время перестройки после отказа может достигать нескольких суток, и вероятность второго отказа за это время уже не пренебрежимо мала. Именно поэтому RAID 5 теряет популярность в пользу RAID 6.

RAID 6 добавляет второй блок чётности и выживает после одновременного отказа двух дисков. Write penalty выше, чем у RAID 5, но на больших массивах это единственный разумный уровень с чётностью. Доля RAID 6 в корпоративных развёртываниях выросла до 22% в 2025 году именно за счёт миграции с RAID 5 на больших массивах.

RAID 10 - это RAID 0 поверх RAID 1: зеркала, объединённые в страйп. Половина ёмкости уходит на зеркалирование, зато производительность записи максимальна среди всех надёжных уровней. Нет write penalty чётности, нет длительных перестроек с промежуточным риском. RAID 10 занимает 35% корпоративных развёртываний на Linux в базах данных и высоконагруженных хранилищах.

Аппаратные контроллеры и то что они действительно дают

Настоящий аппаратный RAID-контроллер - не "RAID-режим" в BIOS материнской платы, который на самом деле является псевдоаппаратным (fakeraid) и реализован программно через драйвер. Настоящий контроллер - это отдельная карта расширения с собственным процессором (RAID-on-Chip), собственной памятью кэша и, что критически важно, защитой кэша при потере питания через BBU (Battery Backup Unit) или flash-backed cache.

Главное преимущество аппаратного контроллера с BBU - это write-back cache. Контроллер подтверждает запись хосту сразу, как только данные попали в кэш, не дожидаясь фактической записи на диски. Для приложений с интенсивной записью это даёт значительное ускорение. BBU гарантирует, что при внезапном отключении питания данные из кэша будут записаны при восстановлении. Программный RAID такого не предоставляет - он работает в write-through режиме по умолчанию, и данные считаются записанными только после реальной записи на диск.

Второй сценарий, где аппаратный контроллер имеет смысл - это legacy-окружения с устоявшейся операционной практикой и поддержкой вендора. Серверы с пятилетней историей, где всё обслуживание ведётся через интерфейс контроллера, где команда умеет работать именно с этим железом - здесь менять подход ради mdadm нет смысла.

Однако аппаратный контроллер несёт риск, о котором нередко забывают: vendor lock-in на уровне данных. Если контроллер Adaptec или LSI выходит из строя, а точно такой же модели нет в наличии, данные на массиве становятся недоступны до замены на идентичное железо. Метаданные проприетарного формата не читаются другими контроллерами. mdadm же использует открытый формат суперблока, и массив собирается на любой машине с Linux.

Псевдоаппаратный RAID и почему его стоит обходить стороной

Отдельная тема, которая требует честного разговора - это так называемый fakeraid, или RAID-режим в BIOS материнских плат Intel и AMD. Маркетинг называет его "аппаратным", но это не так. Логика RAID реализована в драйвере операционной системы, а BIOS лишь создаёт метаданные о составе массива. По сути, это программный RAID, но с дополнительным слоем проприетарных метаданных, который усложняет управление и восстановление.

На Linux fakeraid поддерживается через dmraid и mdadm с форматом imsm (Intel Matrix Storage Manager):

# Посмотреть обнаруженные fakeraid-контейнеры
mdadm --examine --scan --config=partitions

# Собрать Intel fakeraid массив
mdadm --assemble --scan --run

На практике большинство специалистов рекомендуют отключить RAID-режим в BIOS и перейти на чистый mdadm. Тесты показывают, что производительность сопоставима или выше, управляемость несравнимо лучше, а зависимость от проприетарного формата исчезает.

Мониторинг, автосборка и интеграция с systemd

Надёжная работа RAID-массива требует не только правильного создания, но и постоянного мониторинга. mdadm предоставляет для этого несколько механизмов. На системах с systemd мониторинг реализуется через mdmonitor.service:

# Включить службу мониторинга mdadm
systemctl enable mdmonitor
systemctl start mdmonitor

# Проверить статус всех массивов
mdadm --detail --scan

# Принудительно собрать все массивы из конфигурации
mdadm --assemble --scan

# Остановить массив корректно перед обслуживанием
mdadm --stop /dev/md0

После редактирования /etc/mdadm/mdadm.conf необходимо обновить initramfs, чтобы система могла собрать корневой массив при загрузке:

update-initramfs -u      # Debian/Ubuntu
dracut --force           # RHEL/Fedora

Пропуск этого шага - классическая причина, по которой система после изменений в конфигурации RAID перестаёт загружаться.

Выбор между mdadm и аппаратным контроллером сегодня всё меньше определяется производительностью - современные CPU давно закрыли этот вопрос - и всё больше определяется требованиями к операционной практике. Прозрачность, переносимость данных, стоимость, зависимость от вендора и наличие BBU для write-back кэша: именно эти факторы делают выбор осознанным, а не основанным на мифах о "настоящем железном RAID".