Притча о том, как я RAID воскрешал (почти)


ДИСКЛЕЙМЕР

ВНИМАНИЕ!

Все события, хосты, UUID, md-устройства, hypervisor’ы, логи и особенно “тот самый sda7” в этом топике являются полностью вымышленными.


Любые совпадения с реально существующими продакшн-хостами, vSphere-кластерами, datastore’ами, корпоративными продуктами и особенно рабочими миграциями - абсолютно случайны.


Настоящий кейс произошёл в параллельной вселенной, где:

  • хосты не падают в Not Responding

  • миграции всегда проходят успешно

  • а RAID1 из одного диска - это нормальная идея


Все UUID, номера md-устройств, размеры разделов и временные метки были:

  • искажены

  • подделаны

  • переименованы

  • замаскированы

  • подвергнуты процедуре “мы вообще не знаем о чём вы говорите”


Никакие реальные логи не пострадали.
Никакие реальные storage-файлы не были побиты.
Никакие реальные админы не нервничали.


Если вы думаете, что узнали свою инфраструктуру - это не она.
Это другая инфраструктура.
Очень похожая. Но не ваша.


Спасибо за понимание.
И помните: это всё было сделано “на тестовом стенде”. Всегда.

Кейс

Одним вечером на нашем vSphere во время миграции ВМ хост решил уйти в статус not responding, как результат… побитые storage файлы на ВМ.

Получаю трассу при попытке стартануть ВМ:

Timed out waiting for device /dev/disk/by-uuid/0c2ab381-4122-4a60-8894-f1bafc0d9491
Dependency failed for /mnt/logs
Dependency failed for /var/log
Dependency failed for Local File Systems
...
You are in emergency mode
...

В целом… это классический кейс падения в emergency mode из-за отсутствующего/недоступного диска, прописанного в /etc/fstab… подумал я, но оказалось все немного сложнее.


Что происходит технически

  • В /etc/fstab есть запись с UUID:

    0c2ab381-4122-4a60-8894-f1bafc0d9491

  • При старте systemd:

    • пытается смонтировать этот UUID

    • ждёт появления устройства в /dev/disk/by-uuid/

  • Устройство не появляется → происходит timeout.

  • Падают зависимости:

    • /mnt/logs

    • /var/log

    • local-fs.target

  • Базовые файловые системы не собираются → система уходит в emergency mode.

Первичный анализ

Для этого нам потребуется буквально 2 командочки:

  • cat /etc/fstab - проверяем fstab, хотим убедится, что строка с UUID существует

    fstab содержит UUID - тут всё ожидаемо.

  • blkid - проверить, существует ли UUID

    И вот тут начинается самое интересное, при выполнении команды мы получаем:

     [ 388.113146 ] Buffer I/O error on dev md124

Это уже не похоже на проблему fstab…

Смотрим, что такое md124

Хм… окей, давайте глянем к какому RAID мемберу он может относится:

lsblk -f

И видим там такое:

sda7  linux_raid_member
 └─ md124

Какой вывод мы можем сделать…

  • sda7 - RAID member

  • он собирается в md124

  • ext4 UUID отсутствует

  • присутствуют I/O ошибки

    Выходит… это уже уровень блока, а не конфигурации.

Проверяем состояние RAID

Окей… мы в целом поняли, что дело не в fstabе, теперь надо провести анализ mdшки и убедится, что она живая:

cat /proc/mdstat

md124 : active (auto-read-only) raid1 sda7[0]
State : clean
Working Devices : 1
Failed Devices : 0

Это значит:

  • RAID собран

  • состояние clean

  • диск не failed

  • массив single-disk RAID1 (по факту просто зеркало из 1 диска)

Окей круть, выходит RAID metadata читается.

Но это не значит, что читаются данные.

Попытки восстановления

Дальше идет очень и очень долгий путь… проб различными способами восстановить /dev/md124, в ход шло:

fsck.ext4 -f /dev/md124 # тут мы вообще зависали
...
blkid /dev/md124
file -s /dev/md124
mount /dev/md124 /mnt/test
...
...
# А ТУТ ВЕЗДЕ Я ПОЛУЧАЛ
Buffer I/O error on dev md124, logical block 0

Как итог… ядро не может прочитать блоки с md124 по сути это ошибка I/O диска


Что это означает в контексте VM

md124 - это RAID1 из /dev/sda7.

RAID1 из одного диска - фактически просто прокси к sda7.

Если есть:

Buffer I/O error on md124

То это эквивалент:

Buffer I/O error on sda7

Возможные причины:

  • повреждение виртуального диска

  • сбой storage backend

  • corruption VMDK / datastore

  • некорректная миграция

  • зависший hypervisor

Физическая деградация диска - исключаем, это виртуалка.

Итог: раздел logs физически не читается.

Быстрое решение (временное)

В целом… мы можем запустить нашу систему, для этого достаточно закомментировать записи в /etc/fstab:

#UUID=0c2ab381-4122-4a60-8894-f1bafc0d9491 /mnt/logs ...
#/mnt/logs/system ...
#/mnt/logs/core ...
#/mnt/logs/coredump ...

После:

mount -a # тут важно убедится, что нет ошибок
reboot

Система загрузится.

Но… теряем весь раздел логов

Финальное решение: чистое пересоздание массива logs

Принимаю волевое решение - пересоздать md-массив.


А почему нет, погнали!

p.s. всяко бекапов нет… а все что там было уже давно превратилось в тыкву.

После ребута массив сменил номер (md124 → md126).
Номер не важен - важно устройство и размер (~200G).

И для этого нам нужно пройти 8 шагов:

  1. Найти logs-массив

  2. Убрать старые записи из fstab

  3. Остановить массив

  4. Очистить superblock

  5. Пересоздать массив

  6. Создать файловую систему

  7. Получить новый UUID

  8. Ребут


Найти logs-массив

cat /proc/mdstat
lsblk -f

Ищем md-устройство ~200G без mountpoint.
В моём случае - /dev/md126.

Убрать старые записи из fstab

Закомментировать UUID и bind-mount строки (если вдруг мы раскомментили, вообще тут уже можно убирать старый UUID, он нам не нужен):

#UUID= /mnt/logs ...
#/mnt/logs/system ...
#/mnt/logs/core ...
#/mnt/logs/coredump ...

Проверить:

mount -a

Если нет ошибок → идем дальше

Остановить массив

umount /dev/md126 2>/dev/null
mdadm --stop /dev/md126

Важно так же убедиться, что он исчез из /proc/mdstat.

Очистить superblock

mdadm --zero-superblock /dev/sda7
mdadm --examine /dev/sda7

RAID metadata больше не должно быть

Пересоздать массив

mdadm --create /dev/md126 \
  --level=1 \
  --raid-devices=1 \
  /dev/sda7 \
  --metadata=1.2 \
  --force

Проверяем что массив создался:

cat /proc/mdstat

Создать файловую систему

mkfs.ext4 -F /dev/md126

Если здесь снова появится I/O error - проблема в виртуальном диске и чинить нужно storage на гипервизоре.

Но благо… в моём случае ошибок не было.

Получить новый UUID

blkid /dev/md126

И теперь его надо добавить в /etc/fstab и раскомментировать строчки:

UUID=<новый UUID> /mnt/logs ...
/mnt/logs/system /var/log ...
/mnt/logs/core ...
/mnt/logs/coredump ...

Перезагрузка

reboot

Если система стартует - проверяем:

df -h mount | grep logs

И убеждаемся, что:

  • /mnt/logs смонтирован

  • /var/log - bind с него

  • логи создаются корректно

Итоги

В моем случае все успешно завелось

Пхпхпп… буквально на протяжении всего анализа… я ощущал себя примерно так:


Хватался буквально за все… и был железно уверен, что виноват ОН, а он оказался НИ ПРИ ЧЕМ…

Проблема выглядела как классический fstab issue.

На деле - это был I/O error уровня виртуального диска после некорректной миграции… хоть где-то знания полученные с сертификации RHCSA по RAID массивам… пригодились на практике, как я долго этого ждал.