Как стать автором
Обновить

Программный RAID-6 под Linux: опыт восстановления массива 16Тб

Время на прочтение5 мин
Количество просмотров14K
Несколько дней назад вышел из строя один из жестких дисков на бюджетном массиве из 16х1ТБ дисков. Уровень массива: RAID 6. Ситуация осложнилась тем, что (как оказалось) ранее также встал кулер на видеокарте этого же сервера, что не было заранее подмечено, и после замены HDD, в результате изменения режима охлаждения корпуса — это стало проявляться в виде зависаний во время синхронизации, что само по себе очень неприятно. Вылилось это в то, что массив перестал автособираться, и были помечены как сбойные еще несколько дисков, и пришлось уже разбираться с ним по-серьёзному, курить вики, мануалы и форумы (форумы — самое полезное, поскольку описывают опыт конкретных людей в конкретных ситуациях).

Структура моего массива:

16х1Тб HDD

разделы:
md0 — /root 8х1 Гб, RAID 6
md1 — /data: 16х999Гб, RAID 6

Сначала все эксперименты по сборке ставились на md0, т. е. на рутовой партиции, которая сама по себе большой ценностью не обладает, разве что тот факт что это настроенная система.

Итак я загрузился с 1-го диска Дебиан в режиме «Resque mode»

Попытка автосборки массива через

mdadm --assemble --scan

привела к выводу ошибки «недостаточно дисков для сборки массива».

Продолжаем по науке:

1. Необходимо сохранить информацию описания для массивов, которые содержат иформацию, какой конкретно диск является каким номером в массиве. На случай если придется собирать «опасными методами»:

mdadm --examine /dev/sd[abcdefghijklmnop]1 > /mnt/raid_layout1
mdadm --examine /dev/sd[abcdefghijklmnop]2 > /mnt/raid_layout2

Данные файлы содержат что-то похожее на приведенное ниже для всех HDD, у которых на партиции sdX1 есть суперблок (в моем случае только 8 из 16 для md0 имеют суперблок на sdX1)

Ниже пример вывода одного из разделов:

/dev/sdp1:
        Version : 0.90.00
     Raid Level : raid6
  Used Dev Size : 975360 (952.66 MiB 998.77 MB)
   Raid Devices : 8
  Total Devices : 8

      Number   Major   Minor   RaidDevice State
this     4       8      177        4      active sync   /dev/sdl1

   0     0       8       97        0      active sync   /dev/sdg1
   1     1       8      113        1      active sync   /dev/sdh1
   2     2       8      129        2      active sync   /dev/sdi1
   3     3       8      145        3      active sync   /dev/sdj1
   4     4       8      177        4      active sync   /dev/sdl1
   5     5       8      193        5      active sync   /dev/sdm1
   6     6       8      209        6      active sync   /dev/sdn1
   7     7       8      225        7      active sync   /dev/sdo1

Кратко о том, что это означает:

sdf2 — текущая анализируемая партиция
Version 0.90.00 — Версия суперблока
Также вы увидите кучу полезной информации — размер массива, UUID, Level, Размер массива, Кол-во устройств и т. д.

Но самое важное для нас сейчас — это таблица внизу списка, первая строчка в ней, указывает, каким по счету HDD в массиве является наш экзаменуемый:

this     4       8      177        4      active sync   /dev/sdl1

Также обратите пристальное внимание на версию суперблока! В моем случае это 0.90.00.

Тут мы видим его номер в массиве, т. е. 4 — такие же номера вы найдете в выводе для всех других устройств из списка. Обратите внимание, что буковка диска в строчке статуса другая — sdl1 — это означает, что диск был проинициализирован на другом SATA порту, затем перемещен. Это некритичная информация, но может быть полезной.

Критичным является название устройства и его номер в массиве (они поменяются при переносе устройств с порта на порт).

Сохраняем созданный файл raid_layout (например на флешке), чтобы не потерялся, и приступаем к следующему шагу:

2. Пытаемся собрать массив

Собрать массив можно 2мя способами: автоматический и ручной.

Автоматический:

mdadm --assemble --scan -v

Если автоматически он собрался, считайте вам повезло, надо просто проверить все ли HDD в массиве, и если нет, добавить недостающие, и дальше можно не читать. Но, в моем случае, автоматическая сборка не проходит с ошибкой, что недостаточно работающих устройств:

mdadm: /dev/md2 assembled from 4 drives - not enough to start the array.

и массив был создан на 4 из 8 дисков. Работать конечно не будет, поскольку Raid6 позволяет отсутствовать только 2-м дискам.

Проверяем статус массива

cat /proc/mdstat

md2 : inactive sdn1[3](S) sdk1[7](S) sdj1[6](S) sdp1[4](S)
      3907264 blocks

Тут есть тонкость — если в списке HDD встречается не проинициализированный или помеченный как сбойный, то сборка немедленно прекращается, поэтому полезен флаг «-v» — чтобы увидеть на каком из HDD сборка встала.

Ручная сборка:

mdadm --assemble /dev/sd[abcdefgh]1 -v

Тоже самое, но мы указали конкретно, какие HDD использовать для сборки.

Скорее всего массив не соберется также, как и в случае с автоматической сборкой. Но, собирая вручную, вы начинаете лучше понимать саму суть происходящего.

Массив также не соберется, если в метаданных раздела, диск помечен как «faulty».

Тут я перескакивая на то, как я запустил массив с данными, поскольку /root массив я потерял, почему и как — рассказано ниже. Собрать массив игнорируя статус «faulty» — можно добавив флаг «-f» (force) — в моем случае это решило проблему сборки основного раздела с данными т. е. раздел был успешно пересобран следующей командой:

mdadm --assemble /dev/md3 /dev/sd[abcdefghijklmnop]2 -f

наверняка, простой способ собрать его был бы следующим:

mdadm —assemble —scan -f -v

Но, поскольку я добрался до флага "-f" через тернии, это сейчас понятно.
Т. е. разделы, помеченные как сбойные, или устаревшие были добавлены в массив, а не проигнорированы. С большой вероятностью, сбойным или устаревшим раздел может быть помечен при плохо, или не плотно сидящем SATA кабеле, что является не редкостью.

Тем не менее, у меня получился массив в режиме degraded, на 14 дисков из 16.

Теперь, чтобы восстановить нормальную работоспособность массива и не бояться за него, нужно добавить в него 2 недостающих диска:

mdadm --add /dev/md3 /dev/sdX2

где Х буковка раздела нового HDD

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

Я использовал рекомендации WIKI — Linux RAID Recovery ( raid.wiki.kernel.org/index.php/RAID_Recovery ) по работе с массивом с Linux RAID WIKI — Советую быть с ними осторожными, поскольку страничка очень кратко описывает процесс, и благодаря этим рекомендациям, я разрушил /root (md0) моего массива.

До данной строчки в самом низу статьи WIKI, все очень полезно:

mdadm --create --assume-clean --level=6 --raid-devices=10 /dev/md0 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1 missing missing /dev/sdl1 /dev/sdk1 /dev/sdj1

Данная строчка демонстрирует как пересоздать массив, зная какие устройства в каком порядке в него входят. Тут очень важно учесть версию своего суперблока, поскольку новые mdadm создают суперблок 1.2 и он располагается в начале раздела, 0.90 же располагается в конце. Поэтому нужно добавить флаг "--metadata=0.90".
После того, как я собрал массив используя «--create», файловая система оказалась разрушенной, и ни основной суперблок ext4, ни резервные не нашлись. Сначала я обнаружил, что новый суперблок не 0.90 а 1.2, что могло являться причиной уничтожения раздела, но, похоже, не являлось, поскольку изменение версии RAID суперблока на 0.90 и поиск backup суперблока ext4 — был неудачен.
Поскольку /root партиция — это не самая важная часть, тут я решил поэкспериментировать — массив был переформатирован и после этого остановлен:
mdadm —stop /dev/md2
и тотчас создан ещё раз через «--create»: результат — файловая система разрушена опять, хотя этого случиться не должно было, я уверен, что не перепутал порядок устройств и первый раз, и тем более 2-й.
Возможно кто-то успешно восстанавливал разделы, через "--create", буду рад добавить в данную статью, что конкретно мною было сделано неправильно, и почему разрушалась FS. Возможно, она была собрана еще и с другими параметрами размера блока (chunk size).

Очевидно что какими либо рекомендациями из данной статьи следует пользоваться на свой страх и риск, никто не гарантирует что в Вашем случае все сработает именно так как в моём.
Теги:
Хабы:
Всего голосов 60: ↑57 и ↓3+54
Комментарии66

Публикации

Истории

Работа

Ближайшие события

3 – 18 октября
Kokoc Hackathon 2024
Онлайн
10 – 11 октября
HR IT & Team Lead конференция «Битва за IT-таланты»
МоскваОнлайн
25 октября
Конференция по росту продуктов EGC’24
МоскваОнлайн
7 – 8 ноября
Конференция byteoilgas_conf 2024
МоскваОнлайн
7 – 8 ноября
Конференция «Матемаркетинг»
МоскваОнлайн