Как работает RAID-контроллер при отказе диска: минуты после сбоя

MAATRIX

Диск в массиве умирает не с предупреждением, а внезапно — и в этот момент решается, заметите вы проблему за минуту или узнаете о ней постфактум, когда откажет второй диск. Разберём, что именно делает RAID-контроллер в первые секунды после отказа, как понять, что массив в degraded-режиме, где искать уведомление и почему восстановление после замены диска — самый опасный этап во всей истории.

Что происходит в первые секунды после отказа

Диск не «выключается» аккуратно — обычно он либо перестаёт отвечать на команды ввода-вывода, либо начинает возвращать ошибки чтения/записи одну за другой. Контроллер (аппаратный чип или программный слой вроде mdadm) видит это по таймаутам и кодам ошибок и после нескольких неудачных попыток помечает диск как failed. Дальше он больше не пытается с ним работать — исключает его из массива логически, даже если физически диск ещё вставлен в корзину.

Что происходит с данными зависит от уровня RAID. Если избыточности нет (RAID 0) — массив просто разваливается, доступа к данным больше нет. Если избыточность есть (RAID 1, 10, 5, 6), контроллер переходит в деградированный режим: массив продолжает отвечать на запросы, но недостающие данные пересчитывает на лету — либо берёт копию с зеркального диска (RAID 1/10), либо восстанавливает блок из контрольных сумм чётности по оставшимся дискам (RAID 5/6). Для приложения сверху это прозрачно: тот же путь к файлу, тот же том — просто каждое чтение теперь стоит дороже.

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

Аппаратный RAID: что делает контроллер и как это увидеть

На аппаратном RAID (LSI/Avago MegaRAID, Dell PERC, HPE Smart Array и подобные) вся логика отказа живёт в прошивке контроллера, независимо от операционной системы. Диск помечается как Failed на уровне контроллера, часто с одновременной физической индикацией — на многих серверных корзинах при этом загорается янтарный/красный светодиод на конкретном слоте, чтобы инженер дата-центра сразу видел, какой физический диск менять.

Состояние массива и дисков смотрят консольной утилитой производителя. Для LSI/Avago это storcli (или устаревающий megacli), для Dell — perccli:

# общий статус контроллера и виртуальных дисков
storcli64 /c0 show
# состояние физических дисков (ищем Fail, Rbld, Dgrd)
storcli64 /c0/eall/sall show
# то же для Dell PERC
perccli64 /c0/vall show

В выводе интересуют два поля: состояние виртуального диска (Optl — норма, Dgrd — degraded, Offln — массив недоступен) и состояние физического диска (Onln — жив, Fail/UBad — отказал, Rbld — идёт восстановление на нём). Ключевое отличие аппаратного RAID от программного — контроллер обычно ведёт собственный энергонезависимый лог событий (event log), который переживает перезагрузку и хранит точное время отказа, что удобно для разбора инцидента:

# история событий контроллера — время отказа, старт ребилда и т.д.
storcli64 /c0 show events

Программный RAID: mdadm и /proc/mdstat

На программном RAID (mdadm в Linux) логика проще и полностью прозрачна, потому что весь код открыт и работает в самой ОС. При ошибках ввода-вывода ядро сообщает драйверу mdadm, тот помечает диск как faulty и переводит массив в degraded state. Быстрее всего состояние смотрят так:

# статус всех программных массивов — здесь сразу видно [_U] вместо [UU]
cat /proc/mdstat
# подробности по конкретному массиву: State, отказавшие диски
mdadm --detail /dev/md0

В /proc/mdstat деградацию видно буквально по символам: [UU] — оба диска зеркала в строю, [_U] или [U_] — один выпал. В mdadm --detail при отказе появляется строка State : clean, degraded, а отказавший диск помечается faulty. То же самое пишется в системный журнал:

journalctl -k | grep -i md0
# или в классическом syslog
grep -i 'md/raid\|md0' /var/log/syslog

Программный RAID ничего не знает о физических слотах — он видит только блочные устройства (/dev/sda, /dev/sdb). Сопоставление отказавшего /dev/sdX с физическим местом в корзине делают по серийному номеру через smartctl -i /dev/sdX, это отдельный и важный шаг перед любой физической заменой.

Как узнать об отказе, не проверяя массив вручную

Полагаться на то, что кто-то вспомнит проверить /proc/mdstat — плохая стратегия: диск может простоять в degraded-режиме неделями незамеченным. Массив должен сам сообщать о проблеме.

Для mdadm это штатный демон mdadm --monitor, который следит за состоянием массивов и шлёт письмо при событии Fail, DegradedArray и подобных:

# /etc/mdadm/mdadm.conf
MAILADDR admin@example.com

# демон мониторинга (обычно уже запущен как systemd-сервис)
systemctl status mdmonitor
# ручная проверка конфигурации почты
mdadm --monitor --scan --test

Флаг --test полезен сам по себе — он один раз отправляет тестовое письмо, чтобы убедиться, что почта на сервере вообще уходит, а не что настройка «выглядит правильно». Проверьте это сразу после установки массива, а не когда диск уже откажет.

У аппаратных контроллеров свой механизм: их утилиты (storcli, perccli, hpssacli) можно поставить в cron для периодической проверки состояния и отправки алерта, либо использовать штатный агент мониторинга производителя (например, MegaRAID Storage Manager), который слушает события контроллера и сам шлёт email или SNMP-трап. Многие производители также кладут события в лог IPMI/BMC сервера — их видно через ipmitool sel list независимо от состояния ОС, что удобно, если сама система из-за деградации уже подтормаживает или недоступна.

Отдельно стоит smartd — он следит за здоровьем самих дисков (не массива) и умеет заранее предупреждать о растущих переназначенных секторах, то есть ловить проблему до того, как контроллер вообще пометит диск как failed. Подробно о его настройке — в статье про мониторинг диска на сервере. Три источника вместе — mdadm/контроллер, smartd, лог BMC — закрывают почти все сценарии, при которых отказ можно было бы пропустить.

Что практически значит «массив в degraded-режиме»

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

Практические следствия:

• Следующий отказ диска может означать потерю данных. Для RAID 1/5/10 (по парам) это отказ ещё одного конкретного диска в той же паре/группе чётности; для RAID 6 — отказ ещё двух дисков одновременно, поэтому он переживает degraded-состояние заметно спокойнее.
• Производительность снижена, иногда существенно — из-за постоянного пересчёта на лету. Насколько именно, зависит от паттерна нагрузки (случайное чтение просаживается сильнее последовательного) и от того, сколько дисков осталось в группе.
• Часы простоя без реакции стоят дорого. Чем дольше массив живёт в degraded-режиме, тем дольше окно, в котором любой второй отказ фатален. Это не статистика на бумаге — старые диски одной партии часто вырабатывают ресурс синхронно, и second failure в первые дни после первого — не редкость.
• Массив не «чинится сам». Пока не вставлен новый диск и не запущен rebuild, деградация не пройдёт — контроллер будет так и работать без резерва сколь угодно долго.

Из этого практический вывод один: увидев уведомление о degraded, реагируют в тот же день, а не «когда будет время». Подробный порядок замены диска на горячую, без остановки сервиса, разобран в статье про замену диска без простоя на RAID — здесь сосредоточимся на том, почему сам rebuild после замены — самый рискованный шаг.

Rebuild: почему это самый опасный момент

После установки нового диска контроллер запускает восстановление (rebuild) — переписывает или пересчитывает данные на замену. Для зеркала (RAID 1/10) это простое копирование с живого диска; для RAID 5/6 — куда более тяжёлая операция: контроллер должен прочитать соответствующие блоки со всех оставшихся дисков массива и пересчитать по ним недостающие данные чётности для каждого блока нового диска.

Именно это и делает rebuild самым рискованным этапом. Во-первых, это интенсивное последовательное чтение всего объёма с каждого из оставшихся дисков — нагрузка, которой в обычной работе не бывает. Во-вторых, происходит это как раз с дисками, которые уже наработали тот же ресурс, что и уже умерший, часто из одной партии поставки. Совпадение повышенной нагрузки с уже подношенным железом — ровно та комбинация, при которой отказывает второй диск, и для RAID 5 это означает полную потерю массива, для RAID 6 — переход в ещё более уязвимое двойное degraded-состояние.

Прогресс и статус rebuild смотрят теми же командами, что и общее состояние массива:

# программный RAID — процент восстановления и оставшееся время
cat /proc/mdstat
# аппаратный RAID — статус Rbld и процент по конкретному физическому диску
storcli64 /c0/eall/sall show

Пока rebuild не завершён и статус не вернулся к Optl/clean (без слова degraded), считайте массив всё ещё уязвимым — вплоть до последнего процента. Отсюда несколько практических правил:

• Не откладывайте замену диска после уведомления о degraded — каждый лишний час в этом состоянии увеличивает окно риска.
• Перед rebuild убедитесь, что бэкап свежий и восстановим — если второй диск не переживёт нагрузку, единственный путь назад — это бэкап, а не сам массив.
• На больших дисках (несколько терабайт и выше) rebuild RAID 5/6 может идти многие часы — точная скорость зависит от объёма, модели дисков и уровня RAID, ориентируйтесь на показания конкретного контроллера, а не на общие цифры из интернета.
• Если контроллер это позволяет, можно временно снизить приоритет rebuild ради текущей нагрузки или, наоборот, поднять его в окно низкой активности — оба варианта лучше, чем оставить процесс без внимания.
• После завершения rebuild обязательно проверьте итоговый статус массива, а не просто факт, что «диск добавился» — контроллер может завершить восстановление с пометкой о проблемах на отдельных блоках.

Более общий обзор уровней RAID и того, какой из них выбрать под конкретную нагрузку, — в статье RAID на сервере: уровни и как выбрать. Если же диск уже отказал и данные под вопросом ещё до всякого rebuild, порядок действий по спасению данных описан в статье восстановление после сбоя диска.

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