http://lists.debian.org/debian-russian/2008/04/msg00102.html Содержание

• Обнаружение ошибки
• Уточнение происшедшего по логам
• Отключение томов от raid
• Отключение отказавшего диска от системы
• Определение, где находится отказавший диск
• Переподключение диска
• Отключение вновь обнаруженного диска от multipathd
• Возврат томов в raid

Обнаружение ошибки

В случае ошибки промлемный физический том перестаёт использоваться raid-ом, и демон mdadm уведомляет администраторов о происшедшем по почте:

This is an automatically generated mail message from mdadm
running on buki

A Fail event had been detected on md device /dev/md2.

It could be related to component device /dev/sdj2.

Faithfully yours, etc.

P.S. The /proc/mdstat file currently contains the following:

Personalities : [raid1] [raid6] [raid5] [raid4] 
md2 : active raid5 sdi2[0] sdl2[3] sdk2[2] sdj2[4](F)
      1463681856 blocks level 5, 64k chunk, algorithm 2 [4/3] [U_UU]

md1 : active raid1 sdk1[0] sdl1[1]
      489856 blocks [2/2] [UU]

md0 : active raid1 sdi1[0] sdj1[1]
      489856 blocks [2/2] [UU]

unused devices: 

В данном случае ошибка была обнаружена на устройстве /dev/sdj2, входящем в raid /dev/md2.

Уточнение происшедшего по логам

Первое, что следует сделать, это посмотреть в логи - файл /var/log/syslog. Там должен остаться какой-то след происшедшего события. Примерное время события можно определить по времени отправки письма от демона mdadm. Если событие произошло достаточно давно, то информация может быть уже в файле /var/log/syslog.0 или в следующих файлах, оставленных службой logrotate.

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

Dec 15 07:45:30 buki kernel: ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
Dec 15 07:45:32 buki kernel: ata2.00: tag 0 cmd 0xea Emask 0x4 stat 0x40 err 0x0 (timeout)
Dec 15 07:45:38 buki kernel: ata2: port is slow to respond, please be patient
Dec 15 07:46:01 buki kernel: ata2: port failed to respond (30 secs)
Dec 15 07:46:47 buki kernel: ata2: soft resetting port
Dec 15 07:46:47 buki kernel: ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
Dec 15 07:46:47 buki kernel: ATA: abnormal status 0xD0 on port 0xD9044CC7
Dec 15 07:46:47 buki last message repeated 4 times
Dec 15 07:46:47 buki kernel: ata2.00: qc timeout (cmd 0xec)
Dec 15 07:46:47 buki kernel: ata2.00: failed to IDENTIFY (I/O error, err_mask=0x4)
Dec 15 07:46:47 buki kernel: ata2.00: revalidation failed (errno=-5)
Dec 15 07:46:47 buki kernel: ata2: failed to recover some devices, retrying in 5 secs
Dec 15 07:46:47 buki kernel: ata2: hard resetting port
Dec 15 07:46:47 buki kernel: ata2: COMRESET failed (device not ready)
Dec 15 07:46:47 buki kernel: ata2: hardreset failed, retrying in 5 secs
Dec 15 07:46:47 buki kernel: ata2: hard resetting port
Dec 15 07:46:47 buki kernel: ata2: COMRESET failed (device not ready)
Dec 15 07:46:47 buki kernel: ata2: hardreset failed, retrying in 5 secs
Dec 15 07:46:47 buki kernel: ata2: hard resetting port
Dec 15 07:46:47 buki kernel: ata2: COMRESET failed (device not ready)
Dec 15 07:46:47 buki kernel: ata2: reset failed, giving up
Dec 15 07:46:47 buki kernel: ata2.00: disabled
Dec 15 07:46:47 buki kernel: ata2: EH complete
Dec 15 07:46:47 buki kernel: sd 3:0:0:0: SCSI error: return code = 0x00040000
Dec 15 07:46:47 buki kernel: end_request: I/O error, dev sdj, sector 976767869
Dec 15 07:46:47 buki kernel: raid5: Disk failure on sdj2, disabling device. Operation continuing on 3 devices
Dec 15 07:46:47 buki kernel: RAID5 conf printout:
Dec 15 07:46:47 buki kernel:  --- rd:4 wd:3 fd:1
Dec 15 07:46:47 buki kernel:  disk 0, o:1, dev:sdi2
Dec 15 07:46:47 buki kernel:  disk 1, o:0, dev:sdj2
Dec 15 07:46:47 buki kernel:  disk 2, o:1, dev:sdk2
Dec 15 07:46:47 buki kernel:  disk 3, o:1, dev:sdl2
Dec 15 07:46:47 buki kernel: RAID5 conf printout:
Dec 15 07:46:47 buki kernel:  --- rd:4 wd:3 fd:1
Dec 15 07:46:47 buki kernel:  disk 0, o:1, dev:sdi2
Dec 15 07:46:47 buki kernel:  disk 2, o:1, dev:sdk2
Dec 15 07:46:47 buki kernel:  disk 3, o:1, dev:sdl2

Видно, что проблема на интерфейсе ata2.

Отключение томов от raid

Первым действием нужно исключить sdj2 из состава raid. Важно сделать это до физического отключения диска, пока устройство /dev/sdj2 есть в файловой системе.

root@buki:/> mdadm /dev/md2 --remove /dev/sdj2
mdadm: hot removed /dev/sdj2

Раз была проблема на sdj2, скорее всего не будут работать и другие разделы на том же физическом диске. Если они входят в другие raid, то возможно для тех разделов тоже пришло письмо от mdadm. Но могло и не прийти - возможно другие raid до текущего момента ещё не пробовали осуществить обмен с отказавшим физическим томом.

Убедиться в наличие проблемы и на sdj1 можно например так:

root@buki:/> dd if=/dev/sdj1 of=/dev/null bs=1k count=128
dd: чтение `/dev/sdj1': Input/output error
0+0 записей считано
0+0 записей написано
 скопировано 0 байт (0 B), 0,018232 секунд, 0,0 kB/s

Как и ожидалось, проблема есть. Поэтому sdj1 также нужно отключить от raid. Предварительно его нужно пометить как отказавший (иначе mdadm откажется его отключить).

root@buki:/> mdadm /dev/md0 --fail /dev/sdj1
mdadm: set /dev/sdj1 faulty in /dev/md0
root@buki:/> mdadm /dev/md0 --remove /dev/sdj1
mdadm: hot removed /dev/sdj1

В момент, когда sdj1 будет помечен как отказавший, демон mdadm это обнаружит и отправит уведомление системному администратору.

Отключение отказавшего диска от системы

Перед извлечением отказавшего диска желательно отключить его от системы.

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

root@buki:/> cd /sys/class/scsi_host
root@buki:/sys/class/scsi_host> ls -l */device/target*/*/block:sdj
lrwxrwxrwx 1 root root 0 2007-12-15 11:14 host3/device/target3:0:0/3:0:0:0/block:sdj ->../../../../../../../block/sdj

Из этой выдачи однозначно следует, что контроллеру соответствует объект /sys/class/scsi_host/host3/, а диску - объект /sys/class/scsi_host/host3/device/target3:0:0/3:0:0:0/.

Программное отключение диска осуществляется записью в поле delete объекта sysfs, соответствующего диску:

root@buki:/sys/class/scsi_host> echo 1 > host3/device/target3:0:0/3:0:0:0/delete

В результате этой команды устройство /dev/sdj должно исчезнуть из системы.

Определение, где находится отказавший диск

Из-за динамической нумерации дисков, сходу нельзя точно сказать, в какой именно корзине находится отказавший диск.

Проще всего определить это визуально, по индикаторам активности дисков. Если сервер активно работает с локальными дисками, то индикаторы активностей всех дисков, кроме отключённого, будут мигать, а индикатор активности отключённого - просто гореть.

Если сервер не работает активно с локальными дисками, то таковую работу можно вызвать искусственно. Для этого надо определить, каким именно устройствам sd* соответствуют локальные диски, и запустить команду обмена на каждом из них.

В случае наших серверов, когда все локальные диски используются как чисти raid, определить их полный список можно по /proc/mdstat. В данном примере там упоминаются sdi, sdj, sdk и sdl, один из них отключён, соответственно три других остались.

Заставить три оставшихся диска активно работать можно например так:

root@buki:/> dd if=/dev/sdi2 of=/dev/null &
[1] 12833
root@buki:/> dd if=/dev/sdk2 of=/dev/null &
[2] 12834
root@buki:/> dd if=/dev/sdl2 of=/dev/null &
[3] 12835

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

Переподключение диска

В случае, если диск действительно вышел из строя, он должен быть заменён на новый.

Однако практика показывает, что диск может «ожить» после холодной инициализации. Поэтому можно по крайней мере попробовать его вытащить и вставить обратно. После чего попросить систему пересканировать шину (записав строку из трёх дефисов в атрибут scan объекта sysfs, соответствующего контроллеру):

echo "- - -" > /sys/class/scsi_host/host3/scan

Если диск успешно запустился, в логах появится примерно следующее:

Dec 15 10:04:35 buki kernel: ata2: exception Emask 0x10 SAct 0x0 SErr 0x50000 action 0x2 frozen
Dec 15 10:04:35 buki kernel: ata2: hard resetting port
Dec 15 10:04:36 buki kernel: ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
Dec 15 10:04:36 buki kernel: ata2.00: ATA-7, max UDMA/133, 976773168 sectors: LBA48 NCQ (depth 0/32)
Dec 15 10:04:36 buki kernel: ata2.00: ata2: dev 0 multi count 0
Dec 15 10:04:36 buki kernel: ata2.00: configured for UDMA/100
Dec 15 10:04:36 buki kernel: ata2: EH complete
Dec 15 10:04:37 buki kernel:   Vendor: ATA       Model: WDC WD5000YS-01M  Rev: 07.0
Dec 15 10:04:37 buki kernel:   Type:   Direct-Access                      ANSI SCSI revision: 05
Dec 15 10:04:37 buki kernel: SCSI device sdj: 976773168 512-byte hdwr sectors (500108 MB)
Dec 15 10:04:37 buki kernel: sdj: Write Protect is off
Dec 15 10:04:37 buki kernel: sdj: Mode Sense: 00 3a 00 00
Dec 15 10:04:37 buki kernel: SCSI device sdj: drive cache: write back
Dec 15 10:04:37 buki kernel: SCSI device sdj: 976773168 512-byte hdwr sectors (500108 MB)
Dec 15 10:04:37 buki kernel: sdj: Write Protect is off
Dec 15 10:04:37 buki kernel: sdj: Mode Sense: 00 3a 00 00
Dec 15 10:04:37 buki kernel: SCSI device sdj: drive cache: write back
Dec 15 10:04:37 buki kernel:  sdj: sdj1 sdj2
Dec 15 10:04:37 buki kernel: sd 3:0:0:0: Attached scsi disk sdj

Отключение вновь обнаруженного диска от multipathd

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

Dec 15 10:04:37 buki multipathd: sdj: add path (uevent)
Dec 15 10:04:37 buki multipathd: SATA_WDC_WD5000YS-01_WD-WMANU1680649: load table 
[0 976773168 multipath 0 0 1 1 round-robin 0 1 1 8:144 1000]
Dec 15 10:04:37 buki multipathd: SATA_WDC_WD5000YS-01_WD-WMANU1680649: event checker started
Dec 15 10:04:37 buki multipathd: dm-28: add map (uevent)
Dec 15 10:04:37 buki multipathd: dm-28: devmap already registered
Dec 15 10:04:37 buki multipathd: dm-29: add map (uevent)
Dec 15 10:04:37 buki multipathd: dm-30: add map (uevent)

После чего разделы диска sdj оказываются занятыми, и вернуть их в raid оказывается невозможно.

Чтобы «освободить» разделы, необходимо удалить dm-устройства, которые создал на их основе multipathd. Для этого нужно выяснить имена dm-устройств при помощи команды dmsetup ls, после чего удалить их:

root@buki:/> dmsetup remove SATA_WDC_WD5000YS-01_WD-WMANU1680649p2
root@buki:/> dmsetup remove SATA_WDC_WD5000YS-01_WD-WMANU1680649p1
root@buki:/> dmsetup remove SATA_WDC_WD5000YS-01_WD-WMANU1680649

Возврат томов в raid

Наконец, можно вернуть тома в raid. В данном примере это делается следующими командами:

root@buki:/> mdadm /dev/md0 --add /dev/sdj1
mdadm: re-added /dev/sdj1
root@buki:/> mdadm /dev/md2 --add /dev/sdj2
mdadm: re-added /dev/sdj2

На этом процедуру можно считать законченной. Пересинхронизация raid будет выполнена автоматически.

Snks: Никита Ющенко