Ребилд RAID — самый опасный момент в жизни массива

MAATRIX

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

Деградированный массив: избыточность есть только на бумаге

Пока массив в норме, он переживает отказ одного диска (а в RAID 6 — и двух) спокойно: данные либо продублированы на зеркале, либо восстановимы по контрольным суммам с оставшихся дисков. Это и есть смысл избыточности — она даёт запас прочности на случай проблемы.

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

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

Что физически происходит во время ребилда

Ребилд — это процесс восстановления избыточности: контроллер (программный mdadm, ZFS, аппаратный RAID-контроллер) берёт новый диск и последовательно, блок за блоком, воссоздаёт на нём данные, которые были на отказавшем накопителе.

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

Посмотреть на процесс в Linux можно так:

cat /proc/mdstat

Типичный вывод во время ребилда:

md0 : active raid5 sdd1[4] sda1[0] sdb1[1] sdc1[2]
      11720658432 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/3] [UUU_]
      [=====>...............]  recovery = 27.3% (1067234816/3906886144) finish=189.4min speed=93214K/sec

Строка [UUU_] показывает состояние дисков массива (U — up, работает; символ пропуска — восстанавливается), а recovery — прогресс и текущую скорость. Обратите внимание на скорость: контроллер читает и пишет с максимальной доступной пропускной способностью, ограниченной только настройками системы и физикой дисков.

Почему именно ребилд — момент максимального риска

Здесь сходятся два независимых фактора, и оба работают против вас именно в этот период.

Первый — пиковая нагрузка на все оставшиеся диски одновременно. Обычная повседневная работа массива — это чтение и запись отдельных файлов, случайные обращения вперемешку с последовательными, с паузами между операциями. Ребилд — это полное последовательное чтение всего объёма данных со всех оставшихся дисков сразу, без пауз, часами подряд. Такая нагрузка кардинально отличается от привычного профиля работы диска и статистически повышает шанс обнаружить проблему, которая на обычной нагрузке могла бы оставаться скрытой ещё месяцами: неисправимую ошибку чтения на давно не читавшемся секторе, деградацию головок, растущее число переназначенных секторов, которое ещё не пробило порог тревоги в SMART. Диск, который годами спокойно жил на лёгкой нагрузке, на многочасовом сплошном чтении показывает себя таким, какой он есть на самом деле — и не всегда это хорошая новость.

Второй — диски одного возраста склонны отказывать примерно в одно время. Массив почти всегда собирают из дисков одной партии: их покупают вместе, ставят вместе, они работают в одинаковых условиях — температура, нагрузка, вибрация — с первого дня. Кривая отказов у HDD и SSD не равномерна во времени: есть всплеск ранних дефектов, длинный участок относительного спокойствия и рост отказов ближе к выработке ресурса. Если один диск из партии дошёл до отказа, то остальные диски той же партии, прожившие тот же срок в тех же условиях, статистически находятся куда ближе к своему собственному отказу, чем случайно выбранный диск того же возраста откуда-то ещё. Это не значит, что второй диск обязательно откажет — но шанс заметно выше базового, и именно в этот уязвимый период он реализуется больнее всего.

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

Насколько уязвим конкретный уровень RAID

Степень риска отличается по уровням, но логика одна и та же — везде это отсутствие запаса избыточности на время ребилда:

RAID 5 здесь исторически на особом счету — с ростом ёмкости дисков вероятность словить нечитаемый сектор именно во время полного чтения всего объёма для ребилда выросла настолько, что для больших современных дисков многие администраторы вовсе избегают RAID 5. Это отдельная и важная тема, которую стоит разобрать специально для больших дисков. Но сама логика — уязвимость именно в фазе ребилда — универсальна для любого избыточного уровня: с RAID 6 и RAID 10 картина мягче по вероятности, но принцип «во время ребилда запаса на дополнительный сбой нет» работает точно так же.

Минимизируйте время в деградированном состоянии

Раз риск концентрируется именно в промежутке между отказом и завершением ребилда, первая и самая очевидная мера — сократить этот промежуток до минимума.

• Не откладывайте замену отказавшего диска. Массив в деградированном режиме обычно продолжает нормально обслуживать нагрузку, и это создаёт ложное ощущение, что можно не спешить. На практике каждый лишний день в этом состоянии — лишний день без запаса прочности.
• Держите под рукой запасной диск того же типа и объёма (или на складе у провайдера, если сервер арендован) — чтобы не ждать доставки в момент, когда счёт уже идёт на часы. Сам порядок безопасной замены диска на живом массиве разобран отдельно: замена диска без простоя на RAID.
• Настройте мониторинг и алерты на состояние массива, а не полагайтесь на то, что заметите проблему сами. Простейший вариант — mdadm --monitor с отправкой почты, или проверка /proc/mdstat по крону:

mdadm --monitor --scan --mail=admin@example.com --delay=300

• Проверяйте SMART оставшихся дисков сразу после отказа одного из них, ещё до начала ребилда:

smartctl -a /dev/sdb | grep -E "Reallocated|Pending|Uncorrectable"

Если у соседнего диска уже растут Reallocated_Sector_Ct или Current_Pending_Sector — это тревожный сигнал ровно того рода риска, о котором речь выше: диск того же возраста и условий может быть на пороге собственного отказа.

Свежий бэкап до старта ребилда — обязательное условие, а не перестраховка

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

Поэтому прежде чем нажимать mdadm --add или аналог на аппаратном контроллере, убедитесь, что у вас есть бэкап не месячной давности, а действительно свежий — снятый до появления проблемы или сразу после обнаружения отказа диска, пока массив ещё в деградированном, но рабочем состоянии. Это тот самый момент, когда бэкап стоит проверить на целостность, а не просто на факт существования файла архива.

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

Снижайте нагрузку на массив во время самого ребилда

Пока ребилд идёт, диски и так работают на пределе — читая весь объём данных подряд. Любая дополнительная нагрузка со стороны приложений конкурирует с ребилдом за те же самые головки и ту же самую пропускную способность, продлевая и время восстановления, и время нахождения массива в уязвимом состоянии.

Практические шаги на этот период:

• Отложите фоновые тяжёлые задачи — полное резервное копирование большого объёма, массовую переиндексацию базы данных, batch-обработку файлов, дефрагментацию, перенос больших наборов данных. Всё, что можно сдвинуть на день-два, стоит сдвинуть.
• Ограничьте скорость самого ребилда при необходимости, если приоритет — сохранить отзывчивость сервиса для пользователей, помня, что это удлиняет уязвимое окно:

cat /proc/sys/dev/raid/speed_limit_min
cat /proc/sys/dev/raid/speed_limit_max
# при необходимости поднять минимальную скорость ребилда:
echo 50000 > /proc/sys/dev/raid/speed_limit_min

Здесь всегда компромисс: выше скорость ребилда — короче уязвимое окно, но больше конкуренция за ресурс диска с текущей нагрузкой; ниже скорость — комфортнее для приложений, но дольше массив остаётся без запаса избыточности. Если задача — минимизировать риск потери данных, а не удобство пользователей прямо сейчас, разумный выбор чаще в сторону более быстрого ребилда.

• На аппаратных RAID-контроллерах (LSI/Broadcom MegaRAID, Adaptec) есть аналогичная настройка приоритета ребилда — как правило, в BIOS-утилите контроллера или через storcli/perccli:

storcli /c0/v0 set rebuild_rate=80

Более высокий процент приоритета отдаёт ребилду больше ресурсов дисковой подсистемы за счёт текущих операций ввода-вывода.

• Не запускайте параллельно проверку целостности других массивов или томов на том же сервере, если это можно отложить — каждая дополнительная фоновая операция ввода-вывода — это дополнительная случайная нагрузка поверх и так предельной последовательной нагрузки ребилда.

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