mdadm на практике: сборка, деградация, замена диска

MAATRIX

Документация mdadm — это десятки страниц man-страницы, где нужную команду приходится выискивать между опциями, которые вы никогда не используете. На практике же весь жизненный цикл программного RAID укладывается в четыре сценария: собрать массив, посмотреть его текущее состояние, понять, что один диск отвалился, и заменить его так, чтобы не потерять данные. Разберём каждый по шагам, с реальными командами и выводом, который вы увидите на экране.

Создание нового массива

Допустим, в сервере четыре чистых диска /dev/sdb, /dev/sdc, /dev/sdd, /dev/sde, и вы хотите собрать из них RAID 5 — три диска под данные, один эквивалент под избыточность (реально данные и чётность размазаны по всем дискам, но полезный объём считается именно так). Команда:

mdadm --create /dev/md0 --level=5 --raid-devices=4 /dev/sdb /dev/sdc /dev/sdd /dev/sde

Здесь /dev/md0 — имя нового массива, --level=5 — уровень RAID, --raid-devices=4 — сколько устройств входит в массив. mdadm переспросит, всё ли верно, если на дисках нашлись остатки старой файловой системы или суперблока — не игнорируйте это предупреждение, а убедитесь, что взяли действительно чистые диски, а не тот, где ещё вчера жили нужные данные.

Сразу после создания массив уже доступен как блочное устройство, но фактически он начинает первичную синхронизацию — пересчитывает и записывает чётность по всем дискам с нуля. Это тяжёлая операция, похожая по нагрузке на дальнейший ребилд, и на больших дисках может занять много часов. Работать с массивом (создавать файловую систему, монтировать) можно и во время синхронизации, но лучше дождаться её завершения, если сроки позволяют — меньше конкуренции за дисковый ввод-вывод.

Дальше сохраните конфигурацию массива, иначе после перезагрузки mdadm может собрать его не под тем именем или не собрать автоматически:

mdadm --detail --scan >> /etc/mdadm/mdadm.conf
update-initramfs -u

Последняя команда актуальна для Debian/Ubuntu — initramfs должен знать о массиве, если на нём находится корневой раздел. На RHEL/CentOS аналогичная операция — dracut -f.

Для RAID 1 (зеркало из двух дисков) команда та же, только уровень и число устройств другие:

mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sdb /dev/sdc

Выбор уровня — тема отдельного разговора: если ещё не определились между зеркалом, RAID 5, RAID 6 и RAID 10, у нас есть отдельный разбор уровней RAID и того, как выбрать подходящий.

Проверка текущего статуса массива

Два инструмента покрывают почти все вопросы о состоянии массива. Первый — файл /proc/mdstat, который читается мгновенно и не требует прав root:

cat /proc/mdstat

Типичный вывод здорового массива:

Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 sde[3] sdd[2] sdc[1] sdb[0]
      8790402048 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]
unused devices: <none>

Ключевая строка — [4/4] [UUUU]. Первое число — сколько дисков должно быть в массиве, второе — сколько реально работает сейчас. Буквы U (up) в квадратных скобках — по одной на каждый диск массива, все на месте и живы. Если в этой строке видите [4/3] и [UUU_] или [UU_U] — один диск выпал, символ подчёркивания стоит на месте отказавшего устройства.

Если массив в процессе синхронизации или ребилда, /proc/mdstat покажет прогресс отдельной строкой:

      [==========>..........]  recovery = 52.3% (2301045248/4395201024) finish=118.4min speed=42315K/sec

Это самая полезная строка при замене диска — по ней видно и процент готовности, и приблизительное время до конца.

Второй инструмент даёт больше деталей по каждому диску отдельно:

mdadm --detail /dev/md0

Вывод включает общее состояние массива (State:), число активных и отказавших устройств, UUID массива и таблицу с ролью каждого диска:

    Number   Major   Minor   RaidDevice State
       0       8       16        0      active sync   /dev/sdb
       1       8       32        1      active sync   /dev/sdc
       2       8       48        2      active sync   /dev/sdd
       3       8       64        3      active sync   /dev/sde

Именно эта таблица понадобится, когда нужно точно узнать, какое системное имя диска (/dev/sdX) соответствует отказавшему слоту — на сервере с десятком дисков угадывать по памяти не стоит.

Как распознать деградированное состояние

Деградация — это когда массив продолжает отвечать на запросы, но работает без одного (или, для RAID 6, без двух) дисков из штатного набора. Она видна сразу в обеих командах.

В /proc/mdstat признак — строка State: (или отсутствие полного набора U в [UUUU]), а также явное слово рядом с именем устройства:

md0 : active raid5 sde[3] sdd[2] sdc[1](F) sdb[0]
      8790402048 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/3] [U_UU]

Буква (F) рядом с именем диска — это failed, диск помечен как отказавший и исключён из работы массива. В mdadm --detail /dev/md0 то же самое видно по строке общего состояния:

        State : clean, degraded

Вместо clean (здоровый массив) появляется clean, degraded. В таблице устройств отказавший диск получает пометку faulty вместо active sync, либо вовсе пропадает из списка активных и попадает в отдельную секцию с пометкой removed, если он уже был удалён из массива:

       -       0        0        2      removed

Отдельный сценарий — диск физически ещё присутствует и отвечает, но копит ошибки чтения/записи в SMART, при этом mdadm его ещё не исключил. Такое состояние /proc/mdstat не покажет как деградацию — с точки зрения массива диск ещё в строю. Поэтому проверка одного mdadm недостаточна: нужен отдельный мониторинг SMART-атрибутов диска, который ловит проблему до того, как её увидит массив. Как настроить такой мониторинг и на какие атрибуты смотреть, разобрано в статье про мониторинг диска на сервере.

Замена отказавшего диска: пошагово

Порядок действий один и тот же вне зависимости от того, mdadm сам пометил диск как failed или вы обнаружили проблему по SMART раньше и хотите заменить диск превентивно.

Шаг 1. Если mdadm ещё не пометил диск как отказавший (например, вы видите повторяющиеся ошибки в dmesg, но массив формально clean), сделайте это явно:

mdadm --manage /dev/md0 --fail /dev/sdc

Шаг 2. Удалите диск из массива логически:

mdadm --manage /dev/md0 --remove /dev/sdc

Без этого шага массив не отпустит устройство, и его нельзя будет корректно извлечь или переиспользовать под другой массив.

Шаг 3. Физическая замена. На серверах с hot-swap корзинами диск можно менять без выключения питания — но перед этим обязательно сверьтесь с таблицей из mdadm --detail /dev/md0 (или, что надёжнее, со светодиодом на самой корзине, если контроллер корзины его поддерживает), какой физический слот соответствует /dev/sdc. Перепутать слот и вытащить рабочий диск вместо отказавшего — самая частая причина превратить деградированный, но живой массив в полностью развалившийся; разбор именно такого инцидента есть в статье про то, как заменили диск и потеряли массив.

Шаг 4. После установки нового диска система обычно присваивает ему то же самое системное имя /dev/sdc (если не менялась разметка контроллера), но это стоит проверить командой lsblk — новый диск должен появиться в списке без разделов и без файловой системы.

Шаг 5. Добавьте новый диск в массив:

mdadm --manage /dev/md0 --add /dev/sdc

Эта команда автоматически запускает ребилд — mdadm начинает восстанавливать данные отказавшего диска на новом, читая оставшиеся диски массива и пересчитывая чётность (для RAID 5/6) либо копируя данные с зеркальной пары (для RAID 1/10). Прогресс, как уже сказано выше, виден в /proc/mdstat строкой recovery = ...%.

Почему ребилд — самый рискованный этап

Ребилд для дисков массива — это максимальная возможная нагрузка: полное последовательное чтение всех оставшихся дисков от начала до конца, растянутое на часы, а на больших массивах — на сутки и больше. Именно в этот момент чаще всего проявляются проблемы, которые до этого молчали: скрытые бэд-блоки на «здоровых» дисках, которые почти не задействовались при обычной нагрузке, вдруг оказываются на пути чтения.

Для RAID 5 это критично: если во время ребилда встречается ошибка чтения на любом из оставшихся дисков, массиву не из чего восстановить недостающий блок — избыточность уже исчерпана отказом первого диска. Результат — потеря данных на затронутых участках, иногда полный разваливающийся массив. Это ровно то, что происходит, когда диск в массиве деградирует не резко, а постепенно — есть отдельный разбор с реальным выводом mdadm --detail, как второй диск в RAID отказывает вскоре после первого, пока никто не смотрел глубже статуса «OK».

Практический вывод из этого: если у вас RAID 5 и объём дисков от нескольких терабайт, стоит всерьёз рассмотреть RAID 6 (переживает отказ двух дисков одновременно) — запас избыточности как раз на случай, когда ребилд после замены одного диска выявляет проблему на втором. И в любом случае — свежий бэкап перед плановой заменой диска, а не только после того, как что-то пошло не так: RAID защищает от простоя из-за отказа диска, но не от случайного rm -rf, повреждения файловой системы или отказа сразу нескольких дисков — то есть не заменяет резервное копирование, о чём подробнее в статье про миф о RAID как о резервной копии.

Email-уведомления от mdadm

Обнаружить отказавший диск через cat /proc/mdstat, который вы случайно запустили спустя месяц — плохой способ мониторинга. У mdadm есть встроенный демон мониторинга, который следит за состоянием всех массивов и отправляет письмо при любом изменении статуса.

На Debian/Ubuntu он обычно уже настроен как systemd-сервис mdadm-monitor (иногда называется mdmonitor на других дистрибутивах), нужно только указать адрес получателя в конфиге /etc/mdadm/mdadm.conf:

MAILADDR admin@example.com

Проверьте, что сервис действительно запущен:

systemctl status mdadm
systemctl enable --now mdmonitor

(имя юнита отличается между дистрибутивами — если mdadm не находится, ищите mdmonitor или mdadm-monitor; при сомнении systemctl list-units | grep mdadm покажет актуальное имя в вашей системе).

Демон опрашивает состояние массивов с интервалом (по умолчанию раз в минуту) и отправляет письмо при событиях вроде Fail, DegradedArray, RebuildFinished. Отправка почты на практике требует настроенного локального MTA (postfix, exim или хотя бы msmtp с релеем через внешний SMTP) — сам mdadm не умеет отправлять письма напрямую, он просто вызывает системную команду mail или sendmail. Если на сервере не настроена отправка почты в принципе, письма о деградации массива будут просто теряться, а не «не отправляться с ошибкой» — это стоит проверить заранее, отправив тестовое письмо, а не полагаться на то, что при реальном отказе оно точно дойдёт.

Проверить конфигурацию мониторинга без ожидания реального отказа диска можно тестовым запуском:

mdadm --monitor --scan --test --oneshot

Эта команда должна прислать тестовое письмо на адрес из MAILADDR, даже если с массивами всё в порядке — если письмо не пришло, проблема в цепочке отправки почты, а не в mdadm.

Если письма по каким-то причинам ненадёжны (спам-фильтры, отсутствие почтового сервера), продублируйте оповещение внешним мониторингом — например, скриптом, который раз в несколько минут проверяет /proc/mdstat на наличие _ или (F) в статусе и шлёт алерт через Telegram или систему мониторинга, а не полагается только на почту.

Частые вопросы