Программный RAID в Linux. Тестирование и мониторинг






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




Чтобы получить подробную информацию, а также узнать, в каком состоянии находится массив, можно воспользоваться опцией --detail из режима misc утилиты mdadm. Ниже предоставлен пример вывода для массива RAID-1, состоящего из трёх дисков, который мы создавали в предыдущей заметке:

Как видим, все три устройства являются активными и синхронизированными, иными словами всё хорошо. Теперь давайте представим (к сожалению, у меня нет возможности физически сломать одно из устройств, входящих в рассматриваемый массив), что один из дисков вышел из строя (вспомним, что для RAID-1/5/6 это допустимо). В случае «железных» проблем драйвер md автоматически пометит диск как сбойный и исключит его дальнейшее использование в массиве; в нашем же тестовом случае мы сделаем это программно. Итак, сделаем устройство /dev/sdc сбойным:

И посмотрим, что изменилось:

Первое, что видим: массив стал неполным (degraded). хотя и продолжает функционировать (clean) :

Сразу же оцениваем ситуацию. Вместо трёх активных устройств у нас осталось всего два:

и один диск сбойный:

В самом конце mdadm любезно предоставляет подробную информацию об устройствах, входящих массив, отметив что второй по счёту диск был удалён:

а после — информацию об удалённом диске:

Из всего становится понятно, что наш RAID-1 работает на двух дисках и что надо-что-то решать с вышедшим из строя устройством. Прежде всего, его необходимо отключить от массива:

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

Если всё в порядке, драйвер md тут же приступит к операции восстановления массива до «полного» состояния путём синхронизации данных на вернувшийся диск:

И, в случае успешного восстановления, массив вернётся к своему нормальному состоянию, которое было приведено в начале заметки.

Если же устройство, которое вышло из строя, к жизни вернуть не представляется возможным, то после замены его новым, вместо опции --re-add следует использовать опцию --add:

Мониторинг

Вопрос, который возникает в первую очередь: а как, собственно, администратору узнать о том, что с массивом что-то неладно? Не заглядывать же постоянно в логи системы! Для целей мониторинга и оповещения о событиях, среди режимов работы утилиты mdadm предусмотрен режим monitor, позволяющий в качестве средств оповещения использовать как традиционный syslog, так и отправку уведомлений почтой. В этом режиме утилита, как правило, работает в режиме демона и запускается init-сценария во время старта системы.

В частности в Ubuntu/Debian запускающий сценарий называется mdadm и по-умолчанию включён. Если вы хотите получать уведомления не только в syslog, но и электронной почтой, добавьте исправьте строку в /etc/default/mdadm:

на

и перезапустите демон:

Тем, кому необходимо запускать mdadm в режиме монитора из собственных сценариев или же в целях тестирования, можно воспользоваться командой:

Если же нужно, чтобы mdadm запустилась в режиме демона и не занимала консоль, просто добавьте опцию --daemonize:




Программный RAID в Linux. Тестирование и мониторинг: 1 комментарий

Комментарии запрещены.