Ich habe eine Frage zumdadm-Ersatzfestplattendas beantwortet meine Frage fast, aber mir ist nicht klar, was passiert.
Wir haben ein RAID5 mit 4 Festplatten eingerichtet – und alle sind im Normalbetrieb wie folgt gekennzeichnet active/sync:
Update Time : Sun Sep 29 03:44:01 2013
State : clean
Active Devices : 4
Working Devices : 4
Failed Devices : 0
Spare Devices : 0
...
Number Major Minor RaidDevice State
0 202 32 0 active sync /dev/sdc
1 202 48 1 active sync /dev/sdd
2 202 64 2 active sync /dev/sde
4 202 80 3 active sync /dev/sdf
Doch als eine der Festplatten ausfiel, funktionierte das RAID nicht mehr:
Update Time : Sun Sep 29 01:00:01 2013
State : clean, FAILED
Active Devices : 2
Working Devices : 3
Failed Devices : 1
Spare Devices : 1
...
Number Major Minor RaidDevice State
0 202 32 0 active sync /dev/sdc
1 202 48 1 active sync /dev/sdd
2 0 0 2 removed
3 0 0 3 removed
2 202 64 - faulty spare /dev/sde
4 202 80 - spare /dev/sdf
Was ist hier wirklich los??
Die Lösung bestand darin, das RAID neu zu installieren – zum Glück kann ich das. Beim nächsten Mal werden wahrscheinlich einige wichtige Daten darauf sein. Ich muss das verstehen, damit ich ein RAID haben kann, das nicht wegen eines einzelnen Festplattenfehlers ausfällt.
Mir ist aufgefallen, dass ich nicht aufgelistet habe, was ich erwartet habe und was passiert ist.
Ich gehe davon aus, dass ein RAID5 mit 3 guten und 1 fehlerhaften Festplatte im eingeschränkten Modus betrieben wird – 3 aktiv/synchronisiert und 1 fehlerhaft.
Was passierte, war, dass ein Ersatzteil aus dem Nichts hergestellt und für fehlerhaft erklärt wurde - dann wurde ein neues ErsatzteilAuchaus dem Nichts erstellt und für funktionsfähig erklärt - wonach das RAID für funktionsunfähig erklärt wurde.
Dies ist die Ausgabe von blkid:
$ blkid
/dev/xvda1: LABEL="/" UUID="4797c72d-85bd-421a-9c01-52243aa28f6c" TYPE="ext4"
/dev/xvdc: UUID="feb2c515-6003-478b-beb0-089fed71b33f" TYPE="ext3"
/dev/xvdd: UUID="feb2c515-6003-478b-beb0-089fed71b33f" SEC_TYPE="ext2" TYPE="ext3"
/dev/xvde: UUID="feb2c515-6003-478b-beb0-089fed71b33f" SEC_TYPE="ext2" TYPE="ext3"
/dev/xvdf: UUID="feb2c515-6003-478b-beb0-089fed71b33f" SEC_TYPE="ext2" TYPE="ext3"
Der TYP und der SEC_TYPE sind interessant, da das RAID XFS und nicht ext3 hat....
Die Protokolle für einen Mount-Versuch auf dieser Festplatte, der wie jeder andere Mount zum oben aufgeführten Endergebnis führte, enthalten die folgenden Protokolleinträge:
Oct 2 15:08:51 it kernel: [1686185.573233] md/raid:md0: device xvdc operational as raid disk 0
Oct 2 15:08:51 it kernel: [1686185.580020] md/raid:md0: device xvde operational as raid disk 2
Oct 2 15:08:51 it kernel: [1686185.588307] md/raid:md0: device xvdd operational as raid disk 1
Oct 2 15:08:51 it kernel: [1686185.595745] md/raid:md0: allocated 4312kB
Oct 2 15:08:51 it kernel: [1686185.600729] md/raid:md0: raid level 5 active with 3 out of 4 devices, algorithm 2
Oct 2 15:08:51 it kernel: [1686185.608928] md0: detected capacity change from 0 to 2705221484544
Oct 2 15:08:51 it kernel: [1686185.615772] md: recovery of RAID array md0
Oct 2 15:08:51 it kernel: [1686185.621150] md: minimum _guaranteed_ speed: 1000 KB/sec/disk.
Oct 2 15:08:51 it kernel: [1686185.627626] md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for recovery.
Oct 2 15:08:51 it kernel: [1686185.634024] md0: unknown partition table
Oct 2 15:08:51 it kernel: [1686185.645882] md: using 128k window, over a total of 880605952k.
Oct 2 15:22:25 it kernel: [1686999.697076] XFS (md0): Mounting Filesystem
Oct 2 15:22:26 it kernel: [1686999.889961] XFS (md0): Ending clean mount
Oct 2 15:24:19 it kernel: [1687112.817845] end_request: I/O error, dev xvde, sector 881423360
Oct 2 15:24:19 it kernel: [1687112.820517] raid5_end_read_request: 1 callbacks suppressed
Oct 2 15:24:19 it kernel: [1687112.821837] md/raid:md0: read error not correctable (sector 881423360 on xvde).
Oct 2 15:24:19 it kernel: [1687112.821837] md/raid:md0: Disk failure on xvde, disabling device.
Oct 2 15:24:19 it kernel: [1687112.821837] md/raid:md0: Operation continuing on 2 devices.
Oct 2 15:24:19 it kernel: [1687112.821837] md/raid:md0: read error not correctable (sector 881423368 on xvde).
Oct 2 15:24:19 it kernel: [1687112.821837] md/raid:md0: read error not correctable (sector 881423376 on xvde).
Oct 2 15:24:19 it kernel: [1687112.821837] md/raid:md0: read error not correctable (sector 881423384 on xvde).
Oct 2 15:24:19 it kernel: [1687112.821837] md/raid:md0: read error not correctable (sector 881423392 on xvde).
Oct 2 15:24:19 it kernel: [1687112.821837] md/raid:md0: read error not correctable (sector 881423400 on xvde).
Oct 2 15:24:19 it kernel: [1687112.821837] md/raid:md0: read error not correctable (sector 881423408 on xvde).
Oct 2 15:24:19 it kernel: [1687112.821837] md/raid:md0: read error not correctable (sector 881423416 on xvde).
Oct 2 15:24:19 it kernel: [1687112.821837] md/raid:md0: read error not correctable (sector 881423424 on xvde).
Oct 2 15:24:19 it kernel: [1687112.821837] md/raid:md0: read error not correctable (sector 881423432 on xvde).
Oct 2 15:24:19 it kernel: [1687113.432129] md: md0: recovery done.
Oct 2 15:24:19 it kernel: [1687113.685151] Buffer I/O error on device md0, logical block 96
Oct 2 15:24:19 it kernel: [1687113.691386] Buffer I/O error on device md0, logical block 96
Oct 2 15:24:19 it kernel: [1687113.697529] Buffer I/O error on device md0, logical block 64
Oct 2 15:24:20 it kernel: [1687113.703589] Buffer I/O error on device md0, logical block 64
Oct 2 15:25:51 it kernel: [1687205.682022] Buffer I/O error on device md0, logical block 96
Oct 2 15:25:51 it kernel: [1687205.688477] Buffer I/O error on device md0, logical block 96
Oct 2 15:25:51 it kernel: [1687205.694591] Buffer I/O error on device md0, logical block 64
Oct 2 15:25:52 it kernel: [1687205.700728] Buffer I/O error on device md0, logical block 64
Oct 2 15:25:52 it kernel: [1687205.748751] XFS (md0): last sector read failed
Ich sehe xvdf dort nicht aufgeführt ...
Antwort1
Dies ist ein grundsätzliches Problem bei RAID5 – fehlerhafte Blöcke beim Neuaufbau können tödlich sein.
Oct 2 15:08:51 it kernel: [1686185.573233] md/raid:md0: device xvdc operational as raid disk 0
Oct 2 15:08:51 it kernel: [1686185.580020] md/raid:md0: device xvde operational as raid disk 2
Oct 2 15:08:51 it kernel: [1686185.588307] md/raid:md0: device xvdd operational as raid disk 1
Oct 2 15:08:51 it kernel: [1686185.595745] md/raid:md0: allocated 4312kB
Oct 2 15:08:51 it kernel: [1686185.600729] md/raid:md0: raid level 5 active with 3 out of 4 devices, algorithm 2
Oct 2 15:08:51 it kernel: [1686185.608928] md0: detected capacity change from 0 to 2705221484544
⋮
Das Array wurde zusammengebaut und degradiert. Es wurde mit xvdc, xvde und xvdd zusammengebaut. Anscheinend gibt es ein Hotspare:
Oct 2 15:08:51 it kernel: [1686185.615772] md: recovery of RAID array md0
Oct 2 15:08:51 it kernel: [1686185.621150] md: minimum _guaranteed_ speed: 1000 KB/sec/disk.
Oct 2 15:08:51 it kernel: [1686185.627626] md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for recovery.
Oct 2 15:08:51 it kernel: [1686185.634024] md0: unknown partition table
Oct 2 15:08:51 it kernel: [1686185.645882] md: using 128k window, over a total of 880605952k.
Die Meldung „Partitionstabelle“ hat damit nichts zu tun. Die anderen Meldungen sagen Ihnen, dass md versucht, eine Wiederherstellung durchzuführen, wahrscheinlich auf einem Hotspare (das könnte das Gerät sein, das zuvor ausgefallen ist, wenn Sie versucht haben, es zu entfernen/erneut hinzuzufügen).
⋮
Oct 2 15:24:19 it kernel: [1687112.817845] end_request: I/O error, dev xvde, sector 881423360
Oct 2 15:24:19 it kernel: [1687112.820517] raid5_end_read_request: 1 callbacks suppressed
Oct 2 15:24:19 it kernel: [1687112.821837] md/raid:md0: read error not correctable (sector 881423360 on xvde).
Oct 2 15:24:19 it kernel: [1687112.821837] md/raid:md0: Disk failure on xvde, disabling device.
Oct 2 15:24:19 it kernel: [1687112.821837] md/raid:md0: Operation continuing on 2 devices.
Und hier versucht md, einen Sektor von xvde (einem der verbleibenden drei Geräte) zu lesen. Das schlägt fehl (wahrscheinlich fehlerhafter Sektor), und md kann (da das Array degradiert ist) nicht wiederherstellen. Daher wirft es die Platte aus dem Array, und bei einem Doppelplattenfehler ist Ihr RAID5 tot.
Ich bin mir nicht sicher, warum es als Ersatz gekennzeichnet ist – das ist komisch (obwohl ich normalerweise denke, dass ich mir anschaue /proc/mdstat, also ist es vielleicht einfach die Bezeichnung von mdadm). Außerdem dachte ich, dass neuere Kernel viel zögerlicher sind, fehlerhafte Blöcke rauszuwerfen – aber vielleicht verwenden Sie etwas Älteres?
Was können Sie dagegen tun?
Gute Backups. Das ist immer ein wichtiger Teil jeder Strategie, um Daten am Leben zu erhalten.
Stellen Sie sicher, dass das Array regelmäßig nach fehlerhaften Blöcken durchsucht wird. Ihr Betriebssystem enthält hierfür möglicherweise bereits einen Cron-Job. Geben Sie hierzu entweder repairoder checkan /sys/block/md0/md/sync_actionaus. „Reparieren“ behebt auch alle erkannten Paritätsfehler (z. B. wenn das Paritätsbit nicht mit den Daten auf den Festplatten übereinstimmt).
# echo repair > /sys/block/md0/md/sync_action
#
Der Fortschritt kann mit oder den verschiedenen Dateien in diesem Sysfs-Verzeichnis verfolgt werden cat /proc/mdstat. (Eine einigermaßen aktuelle Dokumentation finden Sie unterLinux Raid Wiki mdstat-Artikel.
HINWEIS: Bei älteren Kerneln (die genaue Version ist nicht bekannt) behebt die Überprüfung möglicherweise fehlerhafte Blöcke nicht.
Eine letzte Möglichkeit ist die Umstellung auf RAID6. Dies erfordert eine weitere Festplatte (SiedürfenWenn Sie ein RAID6 mit vier oder sogar drei Festplatten ausführen möchten, möchten Sie das wahrscheinlich nicht. Bei ausreichend neuen Kerneln werden fehlerhafte Blöcke nach Möglichkeit sofort repariert. RAID6 kann zwei Festplattenausfälle überstehen. Wenn also eine Festplatte ausgefallen ist, kann es immer noch einen fehlerhaften Block überstehen. Somit wird der fehlerhafte Block zugeordnet und der Neuaufbau fortgesetzt.
Antwort2
Ich stelle mir vor, dass Sie Ihr RAID5-Array folgendermaßen erstellen:
$ mdadm --create /dev/md0 --level=5 --raid-devices=4 \
/dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1
Das ist nicht ganz das, was Sie wollen. Vielmehr müssen Sie die Datenträger folgendermaßen hinzufügen:
$ mdadm --create /dev/md0 --level=5 --raid-devices=4 \
/dev/sda1 /dev/sdb1 /dev/sdc1
$ mdadm --add /dev/md0 /dev/sdd1
Oder Sie können mdadmdie Option von verwenden, um Ersatzteile wie folgt hinzuzufügen:
$ mdadm --create /dev/md0 --level=5 --raid-devices=3 --spare-devices=1 \
/dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1
Das letzte Laufwerk in der Liste ist das Ersatzlaufwerk.
Auszug aus demmdadm-Manpage
-n, --raid-devices=
Specify the number of active devices in the array. This, plus the
number of spare devices (see below) must equal the number of
component-devices (including "missing" devices) that are listed on
the command line for --create. Setting a value of 1 is probably a
mistake and so requires that --force be specified first. A value
of 1 will then be allowed for linear, multipath, RAID0 and RAID1.
It is never allowed for RAID4, RAID5 or RAID6. This number can only
be changed using --grow for RAID1, RAID4, RAID5 and RAID6 arrays, and
only on kernels which provide the necessary support.
-x, --spare-devices=
Specify the number of spare (eXtra) devices in the initial array.
Spares can also be added and removed later. The number of component
devices listed on the command line must equal the number of RAID devices
plus the number of spare devices.