> Собственно имитирую, что один диск в массиве сдох ...вытаскиваю... все > ок, вставляю обратно, но он определяется уже не как sdb, а как sdd. Это связано с тем, что логически sdb из системы не исчезло. Да и не могло - оно же открыто (хотя бы тем же raid). Поэтому процедура должна быть чуть сложнее. См. текст в аттачменте.Title: admin: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: <none>
В данном случае ошибка была обнаружена на устройстве /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.
Первым действием нужно исключить 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, запущенный на наших серверах, обнаруживает вновь подключённое устройство 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 1 000] 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. В данном примере это делается следующими командами:
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 будет выполнена автоматически.