Отказ одного диска в зеркалированном массиве - событие запланированное: архитектура с самого начала проектировалась переживать именно его. На практике паника всё же случается, потому что процедура замены в стеке LVM и RAID имеет свои тонкости, и ошибки на этом пути стоят дороже самой поломки. В этой статье - полный маршрут от признаков отказа до подтверждённого восстановления: устройство слоёв, порядок действий для mdadm, специфика LVM-зеркал, мониторинг восстановления и меры профилактики, превращающие отказ из события в рутину.
Как слои LVM и RAID устроены вместе
Стек хранения читается снизу вверх: физические диски, поверх них software RAID через mdadm, поверх массивов - физические тома LVM, из которых собираются группы томов, а из групп вырезаются логические тома под файловые системы. Каждая авария и каждое восстановление проходят через все слои по очереди, и потому первый навык - уметь определить, какой слой сигнализирует о проблеме: /proc/mdstat отражает состояние массивов, pvs и lvs - состояние LVM, а журнал ядра связывает слои между собой.
Вторая конфигурация - LVM-зеркала без mdadm, где избыточность живёт в самом LVM через зеркалирование сегментов. И третья - самая болезненная в эксплуатации - LVM без зеркалирования поверх одиночного RAID или вовсе без него. Для каждой конфигурации процедура замены своя, и определение своей - первый вопрос, который стоит задать системе до аварии, а не в её разгар.
Признаки отказа и подтверждение диагноза
Отказ заявляет о себе из нескольких мест одновременно: мониторинг приносит алерт SMART или событий md; /proc/mdstat показывает массив с пометкой degraded и именем выпавшего устройства; журнал ядра содержит строки о таймаутах и ошибках чтения конкретного диска. Подтверждение диагноза - smartctl -a на подозреваемом носителе: счётчики реаллокаций и ожидающих секторов складываются с журналом в непротиворечивую картину.
Отдельная дисциплина - определить, какой физический диск соответствует выпавшему устройству: по серийному номеру из smartctl и по индикатору локации, если сервер поддерживает подсветку. В многодисковых корпусах перепутать диски проще, чем кажется, и именно на этом этапе случается большинство настоящих катастроф в истории замены.
Замена диска в mdadm
Классическая процедура для software RAID проходит по строгому порядку. Первый шаг - маркировка и вывод отказавшего: mdadm --fail /dev/md0 /dev/sdb1 и сразу mdadm --remove /dev/md0 /dev/sdb1, переводя носитель в состояние, из которого его можно извлекать. Второй шаг - физическая замена на идентичный или больший диск; при большем новом диске лишнее место останется неиспользованным до расширения, но само восстановление от этого не зависит.
Третий шаг - разметка нового диска по образцу старого: таблица разделов копируется с соседнего члена массива через sgdisk -R или создаётся вручную того же размера. Четвёртый - добавление в массив: mdadm --add /dev/md0 /dev/sdb1, и с этого момента запускается восстановление - rebuild, ход которого виден в /proc/mdstat процентами и оценкой времени.
Пятый шаг - обновление конфигурации: mdadm --detail --scan проверяется на соответствие /etc/mdadm.conf или /etc/mdadm/mdadm.conf, чтобы после перезагрузки массив собрался правильно и с новым членом.
Мониторинг rebuild
Восстановление массива идёт от минут на быстрых SSD до часов на больших механических дисках, и всё это время массив уязвим вдвойне: второй отказ до завершения rebuild означает потерю данных в RAID10 и RAID1 с двумя копиями. Поэтому окно восстановления переживается с минимальной нагрузкой: тяжёлые операции записи замедляют rebuild и растят риск, и рассудительная пауза до полного восстановления - не перестраховка, а расчёт.
Ход отслеживается cat /proc/mdstat в цикле или через notify-скрипты, а по завершении контрольный осмотр: статус active (U), отсутствие degraded-пометок и чистый журнал. Для mdadm с bitmap восстановление после прерывания продолжается с места остановки - полезная мелочь при нестабильной подаче питания в домашней лаборатории.
Замена диска в LVM-зеркале
В LVM с зеркалированием сегментов отказ обрабатывается своими командами: lvs показывает состояние зеркал с пометками о выпавшей копии, а pvs - статус физических томов. Процедура: pvremove не выполняется на живом зеркале - вместо этого vgreduce --removemissing выводит сбойный физический том из группы, затем на новом диске создаётся pv через pvcreate, vgextend возвращает его в группу, и lvconvert --repair восстанавливает зеркалирование на новом носителе.
Порядок команд LVM менее очевиден, чем в mdadm, и потому зрелая практика - прогнать полный цикл замены на тестовом стенде один раз, записав команды в runbook. Вторая практика - проверка lvs -a+ после каждого шага, чтобы видеть состояние зеркал явно, а не предполагать его.
Когда зеркала нет - pvmove как ручное спасение
Особая конфигурация - LVM без избыточности поверх одиночного RAID-0 или JBOD. Здесь отказ диска означает потерю данных на нём, и до события вопрос решается только бэкапом. Если же отказ замечен на деградирующем, но ещё читающемся диске, метод спасения - pvmove: команда переносит экстенты с проблемного физического тома на другие члены группы, и после успешного переноса носитель выводится через vgreduce и заменяется. Успех pvmove зависит от читаемости источника, и потому он выполняется при первых признаках деградации, а не после полного отказа.
Профилактика и hot-spare
Дисциплина зрелой эксплуатации сводится к трём линиям обороны. Первая - мониторинг SMART по всему парку с алертами на рост счётчиков: заменять диск до отказа всегда дешевле, чем во время. Вторая - hot-spare в конфигурации mdadm: простаивающий запасной диск подхватывает восстановление автоматически, срезая окно уязвимости до минут. Третья - регламентная тренировка замены на списанном железе раз в год, потому что руки, прошедшие процедуру на стенде, не дрожат на проде.
История из практики
Типовая ночь: алерт о выпадении sdb из зеркала md0 на файловом сервере. Диагноз по /proc/mdstat подтвердил degraded, SMART показал всплеск реалокаций. Порядок: fail и remove, физическая замена на диске из запаса, копирование таблицы разделов через sgdisk, add в массив, и четырёхчасовое окно восстановления под присмотром. Утром - active, чистый журнал, запись в runbook о серийных номерах и времени. Вся операция - полчаса активной работы плюс ожидание, и именно так выглядит замена диска, когда подготовка есть, а когда её нет - та же ночь выглядит как потеря терабайт и недели работы.
Памятка
Свод всей темы: диагноз по /proc/mdstat и SMART; серийный номер и локатор для точного адреса; fail и remove до физического извлечения; копия таблицы разделов на новый носитель; add и мониторинг rebuild; окно восстановления - с минимальной нагрузкой; для LVM - свой порядок с pvcreate, vgextend и lvconvert; тренировка на стенде и hot-spare как страховка. От алерта до полного восстановления проходит полдня, из которых активных действий - меньше часа, и это плата за архитектуру, которая прощает отказ отдельного диска.
Проверка после rebuild и чистка конфигурации
Завершение восстановления - короткий контрольный круг по всем слоям. Массив: cat /proc/mdstat без degraded и с полным числом устройств. LVM: pvs и vgs показывают все физические тома и группы активными, lvs - все тома с согласованным состоянием. Файловые системы: монтирование и запись работают. Журнал: journalctl -k за новый период без ошибок I/O от заменённого носителя. И конфигурация: mdadm.conf отражает актуальный состав, потому что именно рассинхронизация конфигурации с реальностью порождает загадочные выпадения массивов после перезагрузки.
Тонкие ошибки при замене
Первая и главная - вывод из массива не того диска: по серийному номеру и локатору подозреваемый определяется до единой команды, и это правило без исключений. Вторая - замена на диск меньшего размера: массив откажется принимать члена, не вмещающего объём, и это узнаётся в самый неподходящий момент. Третья - забытое копирование таблицы разделов: новый диск добавлен целиком без разметки, и mdadm формально принимает его, но геометрия расходится с остальными членами. Четвёртая - жёсткое имя устройства в fstab и загрузчике: /dev/sdb после замены может указывать уже на другой носитель, и потому UUID - единственный правильный якорь в конфигурации.
Все ошибки объединяет одно - они совершаются в спешке ночью, и все они предотвращаются главной привычкой: процедура замены читается целиком до первой команды, а не по ходу действия.
Замена на диск большего размера
Частный случай, заслуживающий отдельного абзаца: замена на больший носитель в RAID10 или зеркале. Добавление проходит штатно, но массив использует только объём, равный остальным членам; лишнее место остаётся неиспользованным до роста. Путь к использованию - последовательная замена всех членов на большие, затем grow массива: mdadm --grow с новым размером, затем resize2fs или xfs_growfs на файловой системе. Процедура требует терпения - каждая замена ждёт полного rebuild - но позволяет расширять ёмкость без даунтайма, и потому любима в местах, где остановка обслуживания дороже времени инженера.
Финальный принцип темы
Зеркалированный стек хранения проектируется так, чтобы отказ одного диска был вопросом процедуры, а не героизма. Инженер, знающий свой стек, порядок команд и серийные номера носителей, проходит замену за час активной работы; инженер без этой подготовки рискует превратить штатную защиту в потерю данных. И именно поэтому тренировка на стенде стоит в списке профилактических мер наравне с hot-spare: руки, прошедшие процедуру, не дрожат на проде.
Итоговая строка темы
Замена диска в зеркалированном стеке - процедура из дюжины команд и одного часа внимания, и вся её сложность держится не в синтаксисе, а в порядке и осторожности. Тот, кто единожды прошёл её на стенде, навсегда перестаёт бояться алертов о degraded-массиве: за каждым таким алертом стоит не катастрофа, а штатная работа по памятке из этой статьи - со свежим диском в запасе и спокойствием в руках.
SMART нового диска как часть процедуры
Завершающая деталь, которую часто пропускают: новый диск перед вводом в массив проходит собственную проверку. smartctl -a показывает заводское состояние, короткий тест -t short убеждает в работоспособности механики, а сверка модели и прошивки с остальными членами массива предотвращает тихие несовместимости. Десять минут на этих шагах - и в массив встаёт проверенный носитель, а не кот в мешке с ярлыком нового. На парк серверов это правило особенно важно: диски одной партии иногда разделяют заводские дефекты, и правило разнообразия моделей при закупке - дешёвая страховка от их одновременного отказа.
Свод для runbook
Итоговая строка темы звучит так: диагноз по журналу и mdstat, точный адрес по серийнику, fail и remove, замена, копия разметки, add, rebuild под присмотром, проверка слоёв, обновление конфигурации, запись в историю. Дюжина строк - и отказ отдельного диска перестаёт быть аварией, оставаясь плановым обслуживанием с предсказуемым концом.
Мысль на выходе
Массивы RAID и зеркала LVM проектируются именно для того, чтобы отказ отдельного носителя стал вопросом дисциплины, а не судьбы. Каждая команда из этой статьи старая как сама технология, каждый шаг выверен поколениями инженеров, и единственное, что невозможно скачать вместе с инструментами - это привычка к порядку: серийный номер до команды, пауза между шагами, запись в runbook после. С этим набором замена диска занимает спокойный час вместо бурной ночи, и разница между этими двумя сценариями целиком создаётся подготовкой.
Берегите свои массивы, держите запасные диски под рукой и пусть каждый rebuild завершается к утру.