Ich hatte ein funktionierendes RAID5-Array, das aus 6 4TB-Festplatten bestand. Smartd meldete, dass eine der Festplatten zu versagen begann. Ich beschloss, mehrere Dinge in einem Vorgang zu erledigen: 1) die ausgefallene Festplatte entfernen 2) eine neue hinzufügen, um sie zu ersetzen 3) dem Array ein paar weitere Festplatten hinzufügen und es erweitern
Da ich für (3) nur kleinere Festplatten hatte, habe ich LVM verwendet, um kleinere Festplatten in Volumes zu integrieren, die größer als 4 TB waren.
Hier ist die Reihenfolge dessen, was ich ausgeführt habe:
1) vgcreate vg_sdi_sdj /dev/sdi1 /dev/sdj1
2) vgcreate vg_sdj_sdl /dev/sdk1 /dev/sdl1
3) lvcreate -l 100%FREE -n all vg_sdi_sdj
4) lvcreate -l 100%FREE -n all vg_sdk_sdl
5) mdadm --manage /dev/md1 --add /dev/sdg1
6) mdadm --manage /dev/md1 --add /dev/vg_sdi_sdj/all
7) mdadm --manage /dev/md1 --add /dev/vg_sdk_sdl/all
8) mdadm --manage /dev/md1 --fail /dev/sdc1
9) mdadm --grow --raid-devices=8 --backup-file=/home/andrei/grow_md1.bak /dev/md1
Zunächst lief alles fast reibungslos. Array wurde neu aufgebaut. Das einzige Merkwürdige war, dass keine Backup-Datei erstellt wurde. Ich lief
watch -n 1 mdadm --detail /dev/md1
nmon
im Hintergrund, um alles im Auge zu behalten. Während der Neuaufbau lief, konnte ich auf das Array zugreifen.
Nach 9 % des Vorgangs stoppten jedoch alle I/Os auf dem Array, mit Ausnahme von 100 % Lesevorgängen auf /dev/sdb und /dev/sdb1. Nachdem ich watch -n 1 mdadm beendet hatte, stoppte auch das.
Hier die aktuelle Ausgabe von mdadm --detail:
/dev/md1: Version : 1.2 Creation Time : Sun Jan 8 22:16:01 2017 Raid Level : raid5 Array Size : 19534430720 (18629.49 GiB 20003.26 GB) Used Dev Size : 3906886144 (3725.90 GiB 4000.65 GB) Raid Devices : 8 Total Devices : 8 Persistence : Superblock is persistent Intent Bitmap : Internal Update Time : Sun Jan 15 21:38:17 2017 State : clean, degraded, reshaping Active Devices : 7 Working Devices : 8 Failed Devices : 0 Spare Devices : 1 Layout : left-symmetric Chunk Size : 512K Reshape Status : 9% complete Delta Devices : 2, (6->8) Name : server:1 (local to host server) UUID : bec66f95:2975e7ae:8f8ba15c:8eb3a33f Events : 79504 Number Major Minor RaidDevice State 0 8 17 0 active sync /dev/sdb1 9 252 0 1 spare rebuilding /dev/dm-0 2 8 49 2 active sync /dev/sdd1 3 8 145 3 active sync /dev/sdj1 4 8 161 4 active sync /dev/sdk1 6 8 177 5 active sync /dev/sdl1 8 252 1 6 active sync /dev/dm-1 7 8 129 7 active sync /dev/sdi1
Ich konnte keine E/A auf dem Array durchführen. Beim Ausführen von htop wurde angezeigt, dass ein CPU-Kern zu 100 % mit E/A-Operationen ausgelastet war.
Ich habe die Maschine neugestartet. Das Array wurde nicht neu zusammengesetzt. Ich habe es manuell neu zusammengesetzt, indem ich Folgendes ausgeführt habe:
mdadm --assemble /dev/md1 --force /dev/sdb1 /dev/sdd1 /dev/sdi1 /dev/sdj1 /dev/sdk1 /dev/sdl1 /dev/vg_sdi_sdj/all /dev/vg_sdk_sdl/all
(Nach dem Neustart wurden die Datenträgernamen geändert). LVM hat Volumes und Gruppen jedoch korrekt gefunden und angezeigt.
Ohne Zwang würde es nicht mitspielen. Es hat sich versammelt und den oben zitierten Detailbericht angezeigt.
Es ließ jedoch weiterhin keinen I/O zu, sodass der Mount-Befehl einfror (ich habe dort ein LVM mit einer einzelnen Festplatte und ein ext4-Dateisystem darin). htop zeigte auch einen CPU-Kern an, der mit I/O belegt war.
Allerdings leuchtet keine der Festplattenaktivitäts-LEDs.
Im Moment hänge ich mit einem nicht funktionsfähigen Array fest, das eine große Menge an Daten enthält. Am liebsten würde ich die Daten abrufen.
Vielleicht war es ein Fehler, logische LVM-Volumes als mdadm-„Festplatten“ zu verwenden. Allerdings habe ich keine Informationen gefunden, die darauf hinweisen, dass es nicht funktionieren würde.
Ich wäre für jeden Rat und Hinweis zur Wiederherstellung meines Arrays sehr dankbar.
Ein genauerer Blick auf journalctl -xe ergab Folgendes:
Jan 15 22:41:15 server sudo[1612]: andrei : TTY=tty1 ; PWD=/home/andrei ; USER=root ; COMMAND=/sbin/mdadm --assemble /dev/md1 --force /dev/sdb1 /dev/sdd1 /dev/sde1 /dev/sdf1 /dev/sdg1 /dev/sdh1 /dev/vg_sdi_sdj/all /dev/vg_sdk_sdl/all
Jan 15 22:41:15 server sudo[1612]: pam_unix(sudo:session): session opened for user root by andrei(uid=0)
Jan 15 22:41:15 server kernel: md: md1 stopped.
Jan 15 22:41:15 server kernel: md: bind<dm-1>
Jan 15 22:41:15 server kernel: md: bind<sdd1>
Jan 15 22:41:15 server kernel: md: bind<sdg1>
Jan 15 22:41:15 server kernel: md: bind<sdh1>
Jan 15 22:41:15 server kernel: md: bind<sdf1>
Jan 15 22:41:15 server kernel: md: bind<dm-0>
Jan 15 22:41:15 server kernel: md: bind<sde1>
Jan 15 22:41:15 server kernel: md: bind<sdb1>
Jan 15 22:41:15 server mdadm[879]: NewArray event detected on md device /dev/md1
Jan 15 22:41:15 server mdadm[879]: DegradedArray event detected on md device /dev/md1
Jan 15 22:41:15 server kernel: md/raid:md1: reshape will continue
Jan 15 22:41:15 server kernel: md/raid:md1: device sdb1 operational as raid disk 0
Jan 15 22:41:15 server kernel: md/raid:md1: device sde1 operational as raid disk 7
Jan 15 22:41:15 server kernel: md/raid:md1: device dm-0 operational as raid disk 6
Jan 15 22:41:15 server kernel: md/raid:md1: device sdf1 operational as raid disk 5
Jan 15 22:41:15 server kernel: md/raid:md1: device sdh1 operational as raid disk 4
Jan 15 22:41:15 server kernel: md/raid:md1: device sdg1 operational as raid disk 3
Jan 15 22:41:15 server kernel: md/raid:md1: device sdd1 operational as raid disk 2
Jan 15 22:41:15 server kernel: md/raid:md1: allocated 8606kB
Jan 15 22:41:15 server kernel: md/raid:md1: raid level 5 active with 7 out of 8 devices, algorithm 2
Jan 15 22:41:15 server kernel: RAID conf printout:
Jan 15 22:41:15 server kernel: --- level:5 rd:8 wd:7
Jan 15 22:41:15 server kernel: disk 0, o:1, dev:sdb1
Jan 15 22:41:15 server kernel: disk 1, o:1, dev:dm-1
Jan 15 22:41:15 server kernel: disk 2, o:1, dev:sdd1
Jan 15 22:41:15 server kernel: disk 3, o:1, dev:sdg1
Jan 15 22:41:15 server kernel: disk 4, o:1, dev:sdh1
Jan 15 22:41:15 server kernel: disk 5, o:1, dev:sdf1
Jan 15 22:41:15 server kernel: disk 6, o:1, dev:dm-0
Jan 15 22:41:15 server kernel: disk 7, o:1, dev:sde1
Jan 15 22:41:15 server kernel: created bitmap (30 pages) for device md1
Jan 15 22:41:15 server kernel: md1: bitmap initialized from disk: read 2 pages, set 7 of 59615 bits
Jan 15 22:41:16 server kernel: md1: detected capacity change from 0 to 20003257057280
Jan 15 22:41:16 server kernel: md: reshape of RAID array md1
Jan 15 22:41:16 server kernel: md: minimum _guaranteed_ speed: 1000 KB/sec/disk.
Jan 15 22:41:16 server kernel: md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for reshape.
Jan 15 22:41:16 server kernel: md: using 128k window, over a total of 3906886144k.
Jan 15 22:41:16 server mdadm[879]: RebuildStarted event detected on md device /dev/md1
Jan 15 22:41:16 server sudo[1612]: pam_unix(sudo:session): session closed for user root
Jan 15 22:41:23 server kernel: md/raid:md1: read error corrected (8 sectors at 759589312 on sdf1)
Jan 15 22:41:23 server kernel: md/raid:md1: read error corrected (8 sectors at 759589320 on sdf1)
Jan 15 22:41:23 server kernel: md/raid:md1: read error corrected (8 sectors at 759589328 on sdf1)
Jan 15 22:41:23 server kernel: md/raid:md1: read error corrected (8 sectors at 759589336 on sdf1)
Jan 15 22:41:23 server kernel: md/raid:md1: read error corrected (8 sectors at 759589344 on sdf1)
Jan 15 22:41:23 server kernel: md/raid:md1: read error corrected (8 sectors at 759589352 on sdf1)
Jan 15 22:41:23 server kernel: md/raid:md1: read error corrected (8 sectors at 759589360 on sdf1)
Jan 15 22:41:23 server kernel: md/raid:md1: read error corrected (8 sectors at 759589368 on sdf1)
Jan 15 22:41:23 server kernel: md/raid:md1: read error corrected (8 sectors at 759589376 on sdf1)
Jan 15 22:41:23 server kernel: md/raid:md1: read error corrected (8 sectors at 759582288 on sdf1)
...
Jan 15 22:43:36 server kernel: INFO: task md1_reshape:1637 blocked for more than 120 seconds.
Jan 15 22:43:36 server kernel: Not tainted 4.4.0-59-generic #80-Ubuntu
Jan 15 22:43:36 server kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Jan 15 22:43:36 server kernel: md1_reshape D ffff88021028bb68 0 1637 2 0x00000000
Jan 15 22:43:36 server kernel: ffff88021028bb68 ffff88021028bb80 ffffffff81e11500 ffff88020f5e8e00
Jan 15 22:43:36 server kernel: ffff88021028c000 ffff8800c6993288 ffff88021028bbe8 ffff88021028bd14
Jan 15 22:43:36 server kernel: ffff8800c6993000 ffff88021028bb80 ffffffff818343f5 ffff8802144c7000
Jan 15 22:43:36 server kernel: Call Trace:
Jan 15 22:43:36 server kernel: [<ffffffff818343f5>] schedule+0x35/0x80
Jan 15 22:43:36 server kernel: [<ffffffffc01d2fec>] reshape_request+0x7fc/0x950 [raid456]
Jan 15 22:43:36 server kernel: [<ffffffff810c4240>] ? wake_atomic_t_function+0x60/0x60
Jan 15 22:43:36 server kernel: [<ffffffffc01d346b>] sync_request+0x32b/0x3b0 [raid456]
Jan 15 22:43:36 server kernel: [<ffffffff81833d46>] ? __schedule+0x3b6/0xa30
Jan 15 22:43:36 server kernel: [<ffffffff8140c305>] ? find_next_bit+0x15/0x20
Jan 15 22:43:36 server kernel: [<ffffffff81704c5c>] ? is_mddev_idle+0x9c/0xfa
Jan 15 22:43:36 server kernel: [<ffffffff816a20fc>] md_do_sync+0x89c/0xe60
Jan 15 22:43:36 server kernel: [<ffffffff810c4240>] ? wake_atomic_t_function+0x60/0x60
Jan 15 22:43:36 server kernel: [<ffffffff8169e689>] md_thread+0x139/0x150
Jan 15 22:43:36 server kernel: [<ffffffff810c4240>] ? wake_atomic_t_function+0x60/0x60
Jan 15 22:43:36 server kernel: [<ffffffff8169e550>] ? find_pers+0x70/0x70
Jan 15 22:43:36 server kernel: [<ffffffff810a0c08>] kthread+0xd8/0xf0
Jan 15 22:43:36 server kernel: [<ffffffff810a0b30>] ? kthread_create_on_node+0x1e0/0x1e0
Jan 15 22:43:36 server kernel: [<ffffffff8183888f>] ret_from_fork+0x3f/0x70
Jan 15 22:43:36 server kernel: [<ffffffff810a0b30>] ? kthread_create_on_node+0x1e0/0x1e0
Antwort1
Die Verwendung von LVM hierfür war tatsächlich ein Fehler. Es entsteht nicht nur ein unnötig komplizierter Speicherstapel für alle außer seinem Ersteller, sondern MD-Arrays werden auch vor LVM-Arrays erstellt, sodass Sie MD-Scans manuell auf Ihren LVs aufrufen müssen, die als MD-Mitglieder fungieren.
Vermeiden Sie außerdem die Verwendung von Kernel-Gerätenamen in persistenten Konfigurationen (wie sda, sdb usw.). Dies ist insbesondere beim Benennen einer Datenträgergruppe relevant, da VGs den zugrunde liegenden Speicher abstrahieren und frei zwischen PVs verschoben werden können. Kernel-Gerätenamen gelten ebenfalls nicht als dauerhaft und können sich aus verschiedenen Gründen jederzeit ändern. Dies ist kein Problem für LVM-PVs (da sie Teil eines umfassenden Festplattenscans sind und praktisch alles erfassen), aber Ihr VG-Name wird in der von Ihnen geschaffenen Situation schnell nicht mehr die Realität widerspiegeln.
Ich würde Ihnen empfehlen, den LV auf anständige Weise aus Ihrem MD-Array zu entfernen und ihn wieder in einen herabgestuften (aber vernünftigen) Zustand zu versetzen. Bedenken Sie, dass MD auf LVM nichts ist, worauf die Leute beim Beheben von Fehlern achten. Sie befinden sich auf unbekanntem Terrain, und Dinge, von denen Sie erwarten, dass sie funktionieren, können ohne ersichtlichen Grund fehlschlagen.
Wenn diese Daten kritisch sind und nicht gesichert werden, sollten Sie sich an jemanden vor Ort wenden, der sich wirklich gut mit LVM und MD auskennt. Ich gehe davon aus, dass Sie das nicht haben, da Sie hier fragen, also lassen Sie uns darüber sprechen, wenn Sie es brauchen. Ich werde dies mit allen interessanten Details aktualisieren, wenn Sie diesen Weg gehen müssen. Versuchen Sie vorerst einfach, einen Rückzieher zu machen, indem Sie das LVM-Chaos durch eine einfache alte Festplatte für ein Mitglied ersetzen.