Linux.raid: Unterschied zwischen den Versionen
(129 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt) | |||
Zeile 16: | Zeile 16: | ||
** Ihre Kapazität ist "n" Sektoren, somit kann die Platte n * ~SectorSize~ Bytes speichern | ** Ihre Kapazität ist "n" Sektoren, somit kann die Platte n * ~SectorSize~ Bytes speichern | ||
** Früher hatten Festplatten 512 Bytes Sektorgrösse, heute sind es oft 4096 Byte (=4K) | ** Früher hatten Festplatten 512 Bytes Sektorgrösse, heute sind es oft 4096 Byte (=4K) | ||
** Ein "Sektor" ist | ** Ein "Sektor" ist die kleinste physikalische Datengruppe die adressiert danach im gesammten gelesen oder geschrieben werden muss | ||
** Will man ein Byte lesen, so wird man physikalisch immer den ganzen Sektor lesen müssen. | ** Will man ein Byte lesen, so wird man physikalisch immer den ganzen Sektor lesen müssen. | ||
** Daraus ergibt sich ein Hintergrundwissen: Habe ich ein Byte gelesen, sind die restlichen 4095 Bytes im Cache | ** Daraus ergibt sich ein Hintergrundwissen: Habe ich ein Byte gelesen, sind die restlichen 4095 Bytes im Cache | ||
Zeile 23: | Zeile 23: | ||
* Beim Übergang auf RAID wird diese Datengruppierung noch massiver | |||
* Ein RAID - Chunk (=ein Datenblock D) hat z.B. die Größe von 512K also 128 Sektoren zu 4096 Byte (128*4K=512K) | |||
* Die Änderung eines einzelnen Bits in einem Datenblock D muss auf 3 Festplatten geschrieben werden (D+P+Q), das ist unabhängig von der Anzahl der Festplatten | |||
** Ein Stripe hat bei 4 RAID-Devices 4 Chunks, D0+D1+P(0,1)+Q(0,1) = 4 MByte brutto = 2 MByte netto | * Ein Stripe hat bei 4 RAID-Devices 4 Chunks, D0+D1+P(0,1)+Q(0,1) = 4 MByte brutto = 2 MByte netto | ||
* Jeder Block hat natürlich eine "Adresse", die sind einfach durchnummeriert von "0" bis "n-1" | |||
* Dem Filesystem Gegenüber wird eine Sektorgrösse von ??? vorgespielt | |||
=== Rolle des Dateisystem === | === Rolle des Dateisystem === | ||
Zeile 46: | Zeile 47: | ||
* Ein Stripe (ein Streifen) ist also immer 1 MByte gross (Nutzdaten D0 + D1). Das ist die Minimale atomare Grösse die ein RAID Array schreiben kann. Wird also nur 1 Byte einer Datei geändert muss md 1 Mbyte neu schreiben. Es kann also sein dass das Byte in D0 liegt -> D0 muss neu geschrieben werden, D1 kann bleiben, P und Q Muss neu geschrieben werden. 3 Chunks werden geschrieben: D0, P und Q -> 1,5 MByte. | * Ein Stripe (ein Streifen) ist also immer 1 MByte gross (Nutzdaten D0 + D1). Das ist die Minimale atomare Grösse die ein RAID Array schreiben kann. Wird also nur 1 Byte einer Datei geändert muss md 1 Mbyte neu schreiben. Es kann also sein dass das Byte in D0 liegt -> D0 muss neu geschrieben werden, D1 kann bleiben, P und Q Muss neu geschrieben werden. 3 Chunks werden geschrieben: D0, P und Q -> 1,5 MByte. | ||
* P und Q sind zwei Funktionen, die keine kurze Prüfsumme bilden, sondern wiederum eine Bitfolge mit genau der Länge eines ganzen Blockes. Die mathematischen Routinen sind dabei so geschickt gewählt dass die Ergebniswerte von P und Q eindeutig mit dem Inhalt von "0" und "1" zusammenhängen. Ändert sich also nur ein Bit in "0" oder "1", so ändert sich auch entsprechend der Wert von "P" und "Q". | * P und Q sind zwei Funktionen, die keine kurze Prüfsumme bilden, sondern wiederum eine Bitfolge mit genau der Länge eines ganzen Blockes. Die mathematischen Routinen sind dabei so geschickt gewählt dass die Ergebniswerte von P und Q eindeutig mit dem Inhalt von "0" und "1" zusammenhängen. Ändert sich also nur ein Bit in "0" oder "1", so ändert sich auch entsprechend der Wert von "P" und "Q". | ||
* P und Q werden rotierend angeordnet damit keine reinen Paritätsplatten entstehen | * P und Q sich auch so geschickt gewählt, dass P(0,...,0)=0 und Q(0,...,0)=0, das heisst also fabrikneue Platten erfüllen die Parity-Anforderung uns es muss nix geschrieben werden. | ||
* P und Q werden rotierend angeordnet damit keine reinen Paritätsplatten entstehen, es gibt keine explizite Parity Disk | |||
=== wie werden "P" und "Q" berechnet === | |||
* P und Q verwenden unterschiedliche Algorithmen. Aber beide Routinen brauchen die Blöcke "0" und "1" als Eingangsparameter. | * P und Q verwenden unterschiedliche Algorithmen. Aber beide Routinen brauchen die Blöcke "0" und "1" als Eingangsparameter. | ||
* P ist ein einfaches XOR aller Daten Chunks<br> | * P ist ein einfaches XOR aller Daten Chunks<br> | ||
# | # | ||
# das Original ist in den Kernel Sourcen unter " | # das Original ist in den Kernel Sourcen unter "lib\raid6\int.uc" | ||
# | # | ||
# Copyright 2002-2004 H. Peter Anvin - All Rights Reserved | # Copyright 2002-2004 H. Peter Anvin - All Rights Reserved | ||
Zeile 105: | Zeile 110: | ||
end; | end; | ||
end; | end; | ||
** P und Q werden in Wirklichkeit auf einen Rutsch in einer Funktion names "gen_syndrome". Diese liegt mehrfach implementiert vor: Verschieden optimiert für spezielle CPU Technologien z.B. für NANO (ARM), oder MMX, MMX2, AVX2 (AMD/Intel). | |||
* P/Q Berechnung | |||
* P und Q werden in Wirklichkeit auf einen Rutsch in einer Funktion names "gen_syndrome". Diese liegt mehrfach implementiert vor: Verschieden optimiert für spezielle CPU Technologien z.B. für NANO (ARM), oder MMX, MMX2, AVX2 (AMD/Intel). | |||
* der darüberliegende Code ruft nur raid6_call.gen_syndrome(disks, bytes, ptrs) | |||
* disks = Anzahl der chunks (im Quelltext auch "Buffers" geannt) (Datenchunks+Paritätschunks) | |||
* bytes = Chunk-Größe | |||
* ptrs = Array[0..disks-1] of Ptr^[0..bytes-1] | |||
* Chunk Recovery | |||
** Ein oder Zwei Chunks eines Stripes können "berechnet" werden | |||
** Für die beiden Fälle gibt es spezialisierte Funktionen | |||
** "data2" und "datap": raid6_2data_recov, raid6_datap_recov | |||
** Dazu wird der/die als falsch erkannte(n) Chunk(s) als Byte-Folge mit lauter Nullen aufgefüllt | |||
** dann wird wie immer "syndrome" aufgerufen, es gibt dann bei "Q" Methoden das zurückzurechnen | |||
** bei "P" ist es trivial, dann ist P der korrigierte Chunk, P muss dann abermals berechnet werden | |||
=== Lese/Schreib Überlegungen === | |||
Number Major Minor RaidDevice State | |||
0 8 81 0 active sync /dev/sdf1 | |||
1 8 17 1 active sync /dev/sdb1 | |||
9 8 113 2 active sync /dev/sdh1 | |||
3 8 97 3 active sync /dev/sdg1 | |||
4 8 129 4 active sync /dev/sdi1 | |||
5 8 33 5 active sync /dev/sdc1 | |||
6 8 49 6 active sync /dev/sdd1 | |||
7 8 145 7 active sync /dev/sdj1 | |||
8 8 161 8 active sync /dev/sdk1 | |||
10 8 65 - spare /dev/sde1 | |||
# blockdev --getiomin /dev/md0 | |||
524288 | |||
# blockdev --getioopt /dev/md0 | |||
3670016 | |||
* Man sieht hier schön, dass minimal (getiomin) ein "Chunk" gelesen werden kann | |||
* Da eh immer ein Stripe gelesen/geschrieben werden muss ist die optimale grösse ein 9-2=7*Chunk = 3670016 Bytes, also die Nutzdatengrösse eines Stripes | |||
=== entweder Bitmap ... === | |||
* Die folgende Information könnte falsch sein, das hab ich noch nicht überprüft: | |||
** Das Bitmap eines RAID-Verbundes ist eine Datenstruktur in den Metadaten jedes einzelnen drive des RAID wobei jedes Bit einem Stripe entspricht | |||
** Im laufenden Betrieb kann ein "clone" eines gesamten drives notwendig werden (ein spare wird produktiv) | |||
** Schreibende Zugriffe sind in dieser sync Zeit möglich | |||
** Das bitmap verzeichnet diese ungeplanten Zugriffe, damit der lineare sync-Prozess diese Stripes überspringen kann (da bereits synchron!) | |||
* ein Bitmap kann einen kompletten resync verhindern da es verzeichnet welche Stripe neu geschrieben werden müssen | |||
=== ... oder Journal === | |||
* Das Journal ist eine alternative zum einem Bitmap, und ein optionales Element eines RAID Verbundes | |||
* Es speichert Daten und Paritäten bevor diese dem Verbund zum Speichern übergeben werden | |||
* Unsicher: Es hält schreibende Zugriffe auf den Verbund zurück, obwohl die darüberliegende Schicht ein sync gefordert hat | |||
* Es wird ein eigenes Volume benötigt, es sollte schnell und zuverlässig sein (SSD) | |||
* die Grösse bei einem 20 TB Verbund habe ich mit 99 GByte vorgesehen (wahrscheinlich viel zu groß!) | |||
* Nachträgliches Einrichten eines journals | |||
* Ich hatte Schwierigkeiten es schon beim Erstellen des Verbundes mit anzulegen, da scheiterte einfach jeder Befehl: | |||
* "so" habe ich es geschafft: | |||
# | |||
# warte, bis der initiale resync fertig ist! | |||
# | |||
# | |||
# stelle sicher dass das Array nicht gemountet ist | |||
# (gerade der ext4lazyinit des Dateisystems schreibt gerne mal länger auf ein frisches Dateisystem) | |||
# | |||
umount /srv/smb/ra6 | |||
# | |||
# entferne das Bitmap | |||
# | |||
mdadm --grow /dev/md127 --bitmap=none | |||
# | |||
# nehme keine weiteren Schreibzugriffe mehr an | |||
# | |||
mdadm --readonly /dev/md127 | |||
# | |||
# füge die Journal- Partition dazu | |||
# | |||
mdadm /dev/md127 --add-journal /dev/sda4 | |||
# das Array ist nun wieder automatisch im read-write | |||
# man kann jetzt wieder mounten | |||
* "write-back" ist mein Favorit beim Journal, Unterschiede sind hier dokumentiert | |||
** https://www.kernel.org/doc/Documentation/md/raid5-cache.txt | |||
# | |||
# | |||
# | |||
cat /sys/class/block/md127/md/journal_mode | |||
# | |||
# | |||
# | |||
echo "write-back" >/sys/block/md127/md/journal_mode | |||
=== Ausfallüberlegungen === | === Ausfallüberlegungen === | ||
Zeile 131: | Zeile 233: | ||
* Benutze Level 5 (ab 3 Partitionen) für Grössen bis 5GB oder Level 6 (ab 4 Partitionen) ab 5 GB | * Benutze Level 5 (ab 3 Partitionen) für Grössen bis 5GB oder Level 6 (ab 4 Partitionen) ab 5 GB | ||
* Benutze ein Bitmap (das ist default!), aber kein externes (dadurch schwächst Du die Datensicherheit, Stichwort Mobilität des RAID) | * Benutze ein Bitmap (das ist default!), aber kein externes (dadurch schwächst Du die Datensicherheit, Stichwort Mobilität des RAID) | ||
** Bitmap Begriff allgemein: https://github.com/qemu/qemu/blob/master/docs/interop/bitmaps.rst | |||
* Benutze Platten mit nahezu gleicher Grösse und Datenrate | * Benutze Platten mit nahezu gleicher Grösse und Datenrate | ||
* Wenn eine Platte leicht oder sehr viel grösser ist als die anderen im Verbund | * Benutze Platten ohne SMR (Shingled Magnetic Recording) Technik. Da dies dazu führen kann dass ein Resync-Vorgang (Full Write) nur 1/4 der Plattengeschwindigkeit nutzen kann. | ||
** Benutze lieber Platten mit CMR. | |||
* Wenn eine (neue) Platte leicht oder sehr viel grösser ist als die anderen im Verbund: Erstelle dennoch eine maximal grosse Partition. Wenn die kleinen Platten in Zukunft alle ausgefallen / ausgetauscht sind kannst Du mit --grow die RAID- Partition auch vergrössern und so den zunächst ungenutzen Platz dennoch nutzen. | |||
* Benutze/Beschaffe Platten ... | * Benutze/Beschaffe Platten ... | ||
** verschiedener Hersteller, | ** verschiedener Hersteller, | ||
Zeile 144: | Zeile 249: | ||
* Im Notfall | * Im Notfall | ||
** stelle sicher, dass deine Ersatz-Platte nicht bootfähig ist (keine Drama wenn ja, aber willst Du dass ev. dein BIOS durchdreht und das System von dieser Platte startet?) | ** stelle sicher, dass deine Ersatz-Platte nicht bootfähig ist (keine Drama wenn ja, aber willst Du dass ev. dein BIOS durchdreht und das System von dieser Platte startet?) | ||
** stelle sicher, dass deine Ersatz-Platte nicht zuvor Teilnehmer eines anderen RAID Verbundes war (keine | ** stelle sicher, dass deine Ersatz-Platte nicht zuvor Teilnehmer eines anderen RAID Verbundes war (keine Drama wenn ja, aber willst Du dass Linux ein "md126" erstellt mir nur eben diesem Waisenkind?) | ||
** stelle sicher, dass deine Ersatz-Platte keine Partitionstabelle hat (kein Drama wenn ja, aber willst Du dass dies keine maximale Partition ist, oder 2, oder?) | ** stelle sicher, dass deine Ersatz-Platte keine Partitionstabelle hat (kein Drama wenn ja, aber willst Du dass dies keine maximale Partition ist, oder 2, oder?) | ||
* Mache Dir eine Lageplan-Skizze der Platten mit folgenden Angaben: | * Mache Dir eine Lageplan-Skizze der Platten mit folgenden Angaben: | ||
Zeile 152: | Zeile 257: | ||
** "Serien-Nummer" der Platte (z.B. "GDCCBSGGS", ermitteln durch smartctl -a /dev/sdb) | ** "Serien-Nummer" der Platte (z.B. "GDCCBSGGS", ermitteln durch smartctl -a /dev/sdb) | ||
** Nummer der Platte innerhalb des RAID-Verbundes (z.B. "3", ermitteln mdadm --detail /dev/md0) | ** Nummer der Platte innerhalb des RAID-Verbundes (z.B. "3", ermitteln mdadm --detail /dev/md0) | ||
* Auflisten der verfügbaren ata Schnittstellen | |||
** <code>dmesg -T | grep ahci</code> | |||
=== Mitarbeit === | |||
==== False Positiv Error Msg ==== | |||
* sync, umount, reboot -> | |||
* <code>[Fri Nov 6 10:27:22 2020] md/raid:md127: recovering 0 data-only stripes and <b>1</b> data-parity stripes</code> | |||
https://github.com/torvalds/linux/blob/master/drivers/md/raid5-cache.c | |||
Line 2496 | |||
https://github.com/torvalds/linux/commit/b4c625c67362b3940f619c1a836b4e8329106658#diff-be24a83d195fa53b3da9c7257a0352e92dbe2318c725e0492986d425317d4e3d | |||
* data_parity_stripes wird incrementiert, auch wenn er nichts arbeitet ist der Wert zumindest 1 | |||
==== was tut sich? ==== | |||
* https://git.kernel.org/pub/scm/linux/kernel/git/song/md.git/log/?h=md-next | |||
== Inbetriebnahme eines neuen RAID Verbundes == | == Inbetriebnahme eines neuen RAID Verbundes == | ||
Zeile 161: | Zeile 284: | ||
* Um eine zusätzliche Adapter-Karte PCIe <-> SATA kommt man in der Regel nicht herum | * Um eine zusätzliche Adapter-Karte PCIe <-> SATA kommt man in der Regel nicht herum | ||
* Ich schwöre auf Software-RAID somit tun es Adapter ohne RAID Logik völlig | * Ich schwöre auf Software-RAID somit tun es Adapter ohne RAID Logik völlig | ||
* Ist mal eine RAID Logik auf dem Controller schadet das in der Regel nicht da | * Ist mal eine RAID-Logik auf dem Controller schadet das in der Regel nicht da ... | ||
** ... die angeschlossenen Platten auch einzeln ansprechbar sind | ** ... die angeschlossenen Platten auch einzeln ansprechbar sind | ||
** ... sich die RAID Logik abschalten lässt | ** ... sich die RAID-Logik abschalten lässt | ||
** ... der RAID | ** ... der RAID-Controller auch den Modus JBOD anbietet | ||
* Mich interessieren nur Controller mit internen SATA | * Mich interessieren nur Controller mit internen SATA Anschlüssen | ||
hier [[Linux.host-adapter]] Infos über Host-Adapter | |||
=== HDD-Bunch: loser Versuchsaufbau === | === HDD-Bunch: loser Versuchsaufbau === | ||
Zeile 337: | Zeile 320: | ||
[[Datei:NAS-0001-0001-fpd.png|150px]] | [[Datei:NAS-0001-0001-fpd.png|150px]] | ||
* Download der Frontplatte : | * Download der Frontplatte : https://cargobay.orgamon.org/NAS-0001-0001.fpd (fräst die Schaeffer AG Berlin)<br> | ||
* Man braucht noch 3x 2 Winkel: http://www.caselabs-store.com/flex-bay-5-25-device-mount-hd/ | * Man braucht noch 3x 2 Winkel: http://www.caselabs-store.com/flex-bay-5-25-device-mount-hd/ | ||
Zeile 344: | Zeile 327: | ||
==== Partition erstellen ==== | ==== Partition erstellen ==== | ||
* Es gibt Diskussionen dem raid einfach eine Platte zur Verfügung zu stellen, technisch geht das, RAID benötigt keine Partitionstabelle | |||
* Ich empfehle eine Partition anzulegen, im Recovery-Fall hat das meiner Meinung nach Vorteile | |||
** übliche Partitionsgrössen bei typische Laufwerksgrößen | |||
** 1TB HDD, 1000203820544 Bytes Partition | |||
** 2TB HDD, 2000397868544 Bytes Partition | |||
** 4TB HDD, | |||
** 8TB HDD, 8001562156544 Bytes Partition | |||
* Die Partionskennung "Linux RAID" ist auch eine saubere Sache | |||
* Pro Platte des Verbundes: eine maximal grosse Partition | * Pro Platte des Verbundes: eine maximal grosse Partition | ||
* Auf allen RAID Platten des Verbundes: Erstelle eine Primäre sowie Maximal grosse Partition Typ xFD00 (=Linux RAID autodetect)<br> | * Auf allen RAID Platten des Verbundes: Erstelle eine Primäre sowie Maximal grosse Partition Typ xFD00 (=Linux RAID autodetect)<br> | ||
Zeile 364: | Zeile 355: | ||
** Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING PARTITIONS!! Do you want to proceed? (Y/N): <code><span style="background-color:#000000;color:#FFFFFF"> y <ENTER> </span></code> | ** Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING PARTITIONS!! Do you want to proceed? (Y/N): <code><span style="background-color:#000000;color:#FFFFFF"> y <ENTER> </span></code> | ||
==== | ==== RAID Verbund erstellen ==== | ||
* | * wir erstellen nun die "virtuelle" RAID-Partition /dev/md0 aus 5 Partitionen | ||
**<code>mdadm --create --verbose /dev/md0 --level=6 --raid-devices=5 /dev/sd[bcdef]1</code> | **<code>mdadm --create --verbose /dev/md0 --level=6 --raid-devices=5 /dev/sd[bcdef]1</code> | ||
* /dev/md0 ist nun sofort nutzbar | |||
* Im Hintergrund läuft ein initialer resync des Array ab, da P(s)=0 und Q(s)=0 bei s1..sn=0 ist es ein nur lesender Vorgang | |||
md0 : active raid6 sdf1[4](S) sde1[3] sdd1[2] sdc1[1] sdb1[0] | |||
23437503488 blocks super 1.2 level 6, 512k chunk, algorithm 2 [4/4] [UUUU] | |||
[============>........] resync = 64.0% (7504388632/11718751744) finish=578.6min speed=121383K/sec | |||
bitmap: 35/88 pages [140KB], 65536KB chunk | |||
[[Datei:Initial.png]] | |||
==== etx4 Dateisysten erstellen ==== | ==== etx4 Dateisysten erstellen ==== | ||
* Erstelle ein Filesystem auf der raid-Partition<br><code>mkfs.ext4 -m 0 -O 64bit /dev/md0</code> | * Erstelle ein Filesystem auf der raid-Partition<br><code>mkfs.ext4 -m 0 -O 64bit -E lazy_itable_init=0,lazy_journal_init=0 /dev/md0</code> | ||
** "-m 0": da die Platte NICHT unsere Systemplatte ist soll für root nichts reserviert werden | ** "-m 0": da die Platte NICHT unsere Systemplatte ist soll für root nichts reserviert werden | ||
** "-O 64bit": sollte die aktuelle Partition < 16 TB sein, würde kein Dateisystem erstellt, das auf über 16 TB erweiterbar ist. Um diese Situation nach möglicher Erweiterung des Arrays zu vermeinden, wird mkfs gezwungen den >16TB Support von Anfang an zu aktivieren. Zu beachten sind dabei 2 Dinge: | ** "-O 64bit": sollte die aktuelle Partition < 16 TB sein, würde kein Dateisystem erstellt, das auf über 16 TB erweiterbar ist. Um diese Situation nach möglicher Erweiterung des Arrays zu vermeinden, wird mkfs gezwungen den >16TB Support von Anfang an zu aktivieren. Zu beachten sind dabei 2 Dinge: | ||
Zeile 380: | Zeile 377: | ||
*** ES GIBT KEINEN Migrationsweg von "ext4 OHNE 64bit-Support" auf "ext4 auf eine Partition >16 TB" (Stand 1.42.13, also 03.2016) (Das kann man nicht glauben oder?!) | *** ES GIBT KEINEN Migrationsweg von "ext4 OHNE 64bit-Support" auf "ext4 auf eine Partition >16 TB" (Stand 1.42.13, also 03.2016) (Das kann man nicht glauben oder?!) | ||
*** ES GIBT EINEN WEG? eMail an andreas.filsinger at orgamon.org | *** ES GIBT EINEN WEG? eMail an andreas.filsinger at orgamon.org | ||
** Im Internet gibt es Infos, dass ext4 auf den RAID Betrieb hin optimiert werden kann. Das passiert aber im Rahmen der Erzeugung des Systems von alleine. | ** Im Internet gibt es Infos, dass ext4 auf den RAID Betrieb hin optimiert werden kann. Das passiert aber im Rahmen der Erzeugung des Systems von alleine, mke2fs kommuniziert über I/O Ctl Funktionen mit der Partition. Es gibt im Netz Hinweise für die manuelle Berechnung. Es war bei mir aber immer so dass die automatischen Werte passten! Hier: http://busybox.net/~aldot/mkfs_stride.html aber der Link für die Berechnung der Werte. | ||
** Ich habe ein ext4 Dateisystem, also vielmehr das darunter liegende md-Device von RAID5 auf RAID6 migriert, dabei habe ich die Plattenanzahl von 4 auf 5 erhöht, dennoch passten die Werte am Ende wieder zusammen. | ** Ich habe ein ext4 Dateisystem, also vielmehr das darunter liegende md-Device von RAID5 auf RAID6 migriert, dabei habe ich die Plattenanzahl von 4 auf 5 erhöht, dennoch passten die Werte am Ende wieder zusammen. | ||
Zeile 427: | Zeile 424: | ||
** [[Linux.systemd#eines_RAID_Arrays]] | ** [[Linux.systemd#eines_RAID_Arrays]] | ||
=== | === Monitoring === | ||
==== Zugriffe beobachten ==== | |||
nmon | |||
==== USV ==== | |||
apcaccess status | |||
==== Read Ahead ==== | |||
* Fraglich ist, ob das Setzen des Read Ahead Buffers was bringt | |||
* Tatsache ist dass md immer Stripe-Weise die Platten ausliesst und schreibt | |||
* Somit bringt es für die Platte nichts "weniger als eine Chunk Grösse" zu lesen | |||
* Aber ich hoffe, dass schon über SATA die Anforderung zu Lesen/Schreiben eines Chunks als EIN Befehl kommt | |||
* Get block device read ahead buffer size | |||
# blockdev --getra /dev/sda | |||
1024 | |||
==== Stripe Cache ==== | |||
cat /sys/block/md127/md/stripe_cache_size | |||
cat /sys/block/md127/queue/physical_block_size | |||
cat /sys/block/md127/md/raid_disks | |||
* der Hauptspeicher Bedarf ist stripe_cache_size*physical_block_size*raid_disks | |||
==== SCT ==== | ==== SCT ==== | ||
* Bestimme und setze einen definierten Zeitrahmen für Lese- und Schreib- Operationen | |||
* Hier geht es darum unnötiges Aushängen einer ganzen Platte zu verhindern, die Probleme mit einzelnen Sektoren hat | |||
* Bei Lese- oder Schreib- Problemen sollte eine Platte nicht endlos weiterversuchen irgendwas zu Lesen oder zu Schreiben | |||
* Für die RAID- Software ist es viel besser nach einer Definierten Zeit ein Read-Timeout oder Write-Timeout zurückzugeben | |||
* Sonst droht der Timeout für das ganze Blockdevice (default 30 Sekunden) | |||
* die MD Software kommt mit Sektor-Fehlern klar und beginnt hier Sektorweise Massnahmen zu ergreifen indem es den Sektor korrigiert schreibt | |||
* Nicht klar kommt sie mit einer endlos langen Nicht-Rückkehr der Festplatte nach einen read- oder write- Befehl | |||
** dies führt zum Aushängen <u>der ganzen Platte</u> aus dem Verbund obwohl 99% eigentlich noch OK sind | |||
* read/write Timeout der Platte muss also kleiner sein als der Timeout des Block-Device | |||
* Anzeigen | |||
smartctl -l scterc /dev/disk/by-id/ata-WDC_WD120EDAZ-11F3RA0_5PH5124D | |||
* Setzen auf Read=7 Sekunden, Write=7 Sekunden Timeout | |||
smartctl -l scterc,70,70 /dev/disk/by-id/ata-WDC_WD120EDAZ-11F3RA0_5PH5124D | |||
* https://raid.wiki.kernel.org/index.php/Timeout_Mismatch | * https://raid.wiki.kernel.org/index.php/Timeout_Mismatch | ||
#!/bin/bash | |||
for i in /dev/sd? ; do | |||
if smartctl -l scterc,70,70 $i > /dev/null ; then | |||
echo -n $i " is good " | |||
else | |||
echo 180 > /sys/block/${i/\/dev\/}/device/timeout | |||
echo -n $i " is bad " | |||
fi; | |||
smartctl -i $i | egrep "(Device Model|Product:)" | |||
done | |||
==== Sync, Reshape ==== | ==== Sync, Reshape ==== | ||
Zeile 493: | Zeile 545: | ||
dumpe2fs /dev/md0 | dumpe2fs /dev/md0 | ||
=== | === Korrekturlauf === | ||
* Data Scrubbing, vollständiger Lesecheck | |||
* | * Beim RAID6 kann sein, dass ein Stripe unstimmig ist. Das bedeutet, die Infos "D", "P" und "Q" passen nicht zusammen. Für jeden Datenblock in D lassen sich 3 Varianten berechnen: raw(D), D² zurückgerechnet aus P(), D³ zurückgerechnet aus Q(). Nun werden diese 3 Varianten verglichen. Bei einer 2:1 Situation ist die Sache klar, dann ist eine Korrektur von D oder P oder Q möglich. Ergeben sich 3 unterschiedliche Werte ist eine Korrektur nicht mehr möglich. Im Idealfall sind alle 3 Werte gleich. | ||
* Es gibt die Möglichkeit einen "check" zu machen, die Laufzeiten sind natürlich immens, da alle devices zu 100% gelesen werden müssen. Es gibt kein Trim bei md-Partitionen. Ich hatte mal den Fall, dass 267 "mismatch" gefunden wurden. Die Laufzeit dafür war 10 Stunden. Seither mache ich immer einen "repair", gebe also dem "check" die Erlaubnis mit, wenn was nicht stimmt dann auch gleich korrigieren zu können, nichts anderes ist bei einem RAID6 sinnvoll. | |||
* Vor der Prüfung, lass dir anzeigen wie der Stand der Anzahl der Lesefehler ist | * Vor der Prüfung, lass dir anzeigen wie der Stand der Anzahl der Lesefehler ist | ||
Zeile 504: | Zeile 557: | ||
* Starte die Prüfung | * Starte die Prüfung | ||
mdadm --action=repair /dev/md<b>~ArrayNummer~</b> | |||
* Wie immer wird der Fortschritt des "check" in <code>/proc/mdstat</code> angezeigt | * Wie immer wird der Fortschritt des "check" in <code>/proc/mdstat</code> angezeigt | ||
watch -n2 'cat /proc/mdstat && cat /sys/block/md<b>~ArrayNummer~</b>/md/mismatch_cnt' | |||
* Werden Platten zu warm, oder es ist zu viel los kann man den check unterberechen | * Werden Platten zu warm, oder es ist zu viel los kann man den check unterberechen | ||
echo idle > /sys/block/md<b>~ArrayNummer~</b>/md/sync_action | echo idle > /sys/block/md<b>~ArrayNummer~</b>/md/sync_action | ||
* Will man die Prüfung stoppen muss man (wir nach einem reboot fortgesetzt) | |||
echo frozen > /sys/block/md<b>~ArrayNummer~</b>/md/sync_action | |||
* Ist die Prüfung beendet lass Dir anzeigen ob es Lesefehler gab | * Ist die Prüfung beendet lass Dir anzeigen ob es Lesefehler gab | ||
cat /sys/block/md<b>~ArrayNummer~</b>/md/mismatch_cnt | cat /sys/block/md<b>~ArrayNummer~</b>/md/mismatch_cnt | ||
==== scrub.sh ==== | |||
#!/bin/sh | |||
# | |||
# Andreas Filsinger, scrub | |||
# | |||
DEV=md127 | |||
LOG=/root/scrub.log.txt | |||
# | |||
# Optional: Stop a Backup-Service | |||
# | |||
systemctl stop bak | |||
echo -n "md/mismatch_cnt=" >$LOG | |||
cat /sys/block/$DEV/md/mismatch_cnt >>$LOG | |||
mdadm --action=repair /dev/$DEV | |||
mdadm -W /dev/$DEV | |||
dmesg -T >>$LOG | |||
echo -n "md/mismatch_cnt=" >>$LOG | |||
cat /sys/block/$DEV/md/mismatch_cnt >>$LOG | |||
# | |||
# Optional: Start Backup Service | |||
# | |||
systemctl start bak | |||
# | |||
=== Identifikation === | === Identifikation === | ||
Zeile 528: | Zeile 619: | ||
# die neue md-Partition mit dem richtigen Filesystem mounten. | # die neue md-Partition mit dem richtigen Filesystem mounten. | ||
==== ohne Journal ==== | |||
* sollte das RAID-Array über ein Journal abgesichert sein ist es nach einem Umzug nicht mehr direkt funktions-fähig | |||
* Es gibt ein inaktives Array, stoppe dieses mit | |||
* | mdadm --stop /dev/md127 | ||
* | |||
* Kopiere dir den uuid des Arrays, wähle dazu ein beliebiges drive des Arrays | |||
mdadm --examine /dev/sde1 | |||
* Zwinge Ihn das ARRAY zu aktivieren, obwohl das Journal fehlt | |||
mdadm --assemble --force --uui 47:11:nnnnnnnnnnnnnnnnnnnnn:019 /dev/md0 | |||
* das Array steht Dir jetzt Read-Only zur Verfügung | |||
* Du kannst nun das Array wieder schreibfhähig machen indem Du ein Bitmap oder ein Journal hinzufügst | |||
ungetestet: mdadm --grow /dev/md0 (--bitmap=internal |--add-journal /dev/sda5 ) | |||
==== mit Journal ==== | |||
* das array war nicht aktiv, sda4 ist das bisherige journal / es wird im lsblk nicht mit md127 markiert | |||
mdadm --run /dev/md127 | |||
mdadm /dev/md127 --add-journal /dev/sda4 | |||
=== Hot Plug === | === Hot Plug === | ||
Zeile 538: | Zeile 654: | ||
** Beim Anschluss einer neuen Platte: Zuerst Strom, dann Datenkabel dranstecken. | ** Beim Anschluss einer neuen Platte: Zuerst Strom, dann Datenkabel dranstecken. | ||
** Beim Ausbau einer alten Platte: Zuerst Datenkabel, dann Stromkabel abziehen. | ** Beim Ausbau einer alten Platte: Zuerst Datenkabel, dann Stromkabel abziehen. | ||
=== Disk Fitness === | |||
* Besonders nach einem Rauswurf aus einem RAID Verbund stellt sich die Frage nach dem "wirklichen" Fitnesszustand einer Platte | |||
* Ursächlich für den Rauswurf können auch mal reine Timing Probleme auf dem Datenweg von Platte zu md sein und dieser Weg ist lang | |||
* Hier bräuchte man einen 48h Stress Test, aber mit nicht ausserordentlichem Stress sondern einer typischen MD Belastung | |||
* Ev. könnte man auch einen "Full"-Write simulieren und danach 30% Write 70 % Read und mal sehen was passiert | |||
* Das Datenmuster sollte sich auch der Schreib-Position ergeben, ein reproduzierbares Rauschen, da leicht überprüfbar ist | |||
* Dabei könnte man ein Bitmap verwenden, so dass Write mal Pattern A und Pattern B schreibt damit der Schreib-Test nicht identische Daten schreiben muss | |||
* Dabei würde auch das Bitmap Bit kippen wenn mal wieder in "diesen" Bereich geschrieben wird | |||
* Ein Bit soll dabei für einen so minimalen Datenbereich stehen wie auch später md einen Block sieht | |||
# | |||
# lass die Platte sich selbst testen | |||
# (meiner Erfahrung nach wenig Aussagekräftig) | |||
# | |||
smartctl --test long /dev/sda | |||
# | |||
# ready only test zum lesen aller Blocks | |||
# | |||
badblocks -sv /dev/sda1 | |||
=== Probleme und deren Lösung === | === Probleme und deren Lösung === | ||
Zeile 591: | Zeile 729: | ||
* Erster Versuche (ohne Erfolg) | * Erster Versuche (ohne Erfolg) | ||
# mdadm /dev/md127 --grow --raid-devices=8 | |||
mdadm: Failed to initiate reshape! | mdadm: Failed to initiate reshape! | ||
unfreeze | unfreeze | ||
Zeile 597: | Zeile 735: | ||
* Zweiter Versuch (mit dem Erfolg) | * Zweiter Versuch (mit dem Erfolg) | ||
# mdadm /dev/md127 --grow --raid-devices=8 --backup-file=/root/mdadm_backup-file | |||
mdadm: Need to backup 15360K of critical section.. | mdadm: Need to backup 15360K of critical section.. | ||
Zeile 607: | Zeile 745: | ||
* nun erst gings los ... | * nun erst gings los ... | ||
==== resize2fs 100% CPU Usage ==== | |||
* bei einem System lief resize2fs über 24 Stunden bei 100% CPU auslastung ohne Fortschritt | |||
* ich habe es abgebrochen, es ist eine fehlerhafte Version, zuvor natürlich backup | |||
* LÖSUNG: ich habe das System per USB mit knoppix gebootet und die 3 folgenden Schritte durchgeführt | |||
* In der Knoppix Leiste unten links Symbol "rotes 4er Terminal" (Terminator) starten | |||
** Prüfe ob das RAID-Array erkannte wurde, schau nach "clean": <code>sudo mdadm --detail /dev/md0</code> | |||
** Bringe das Dateisystem in einen einwandfreien Zustand: <code>e2fsck -f /dev/md0</code> | |||
** Korrigiere die Grösse: <code>sudo resize2fs -f /dev/md0</code> | |||
[[Datei:Knoppix-resize2fs.png|100px]] | |||
* Menü->Abmelden->Neu Starten->Bootreihenfolge wieder wie früher | |||
* Knoppix USB entnehmen | |||
==== die 64bit - Falle des Ext4 ==== | ==== die 64bit - Falle des Ext4 ==== | ||
Zeile 859: | Zeile 1.012: | ||
=== Vorsorglicher Austausch einer Platte === | === Vorsorglicher Austausch einer Platte === | ||
==== Vorarbeiten ==== | |||
* Es ist von Vorteil, wenn man eine weitere SATA- Schnittstelle im System frei hat (Oder man will ein existierendes Spare zum neuen Array-Mitglied machen). An diesen neuen Port hängt man die neue Platte. In <code>dmesg -T</code> steht drin wie der device-Name ist (Bei- Hotswap Einbau). Nach dem Neustart schaut man mit hwinfo --disk wie der Devicename von Linux für die neue Platte vergeben wurde (Oder bei Hotswap mit dmesg). | |||
* Man muss wissen dass bei einem planmäßigen Ersatz die Ausbau- Platte komplett gelesen wird, die Zielplatte mit deren Inhalt beschrieben. Der Vorgang wird nicht durch Lesen des ganzen Stripes abgesichert. Das entlastet zwar den laufenden Betrieb ist aber auch etwas unsicher, da negative Veränderungen mitkopiert werden. Zuvor sollte ein Scrub durchgeführt werden (oder direkt danach), da wir der ausgemusterten Platte 100% vertrauen müssen. | |||
* Idee: Teamup: Dies wäre ein Vorgang bei dem die neue Platte schleichend die Rolle der ausgemusterten Platte übernimmt, aber immer abgesichert durch P/Q. Alle Ws gehen auf beide Platten, R- Zugriffe werden ev. bereits aufgeteilt, ein Bitmap wie weit er ist wird geführt. | |||
* Die neue Platte: Eine maximal grosse Linux-RAID Partition erstellen [[Linux.raid#Partition_erstellen]] | * Die neue Platte: Eine maximal grosse Linux-RAID Partition erstellen [[Linux.raid#Partition_erstellen]] | ||
* Die neue Partition der neuen Platte muss man bekannt machen | * Die neue Partition der neuen Platte muss man bekannt machen | ||
** <code><span style="background-color:#000000;color:#FFFFFF"> mdadm /dev/md0 | ** <code><span style="background-color:#000000;color:#FFFFFF"> mdadm /dev/md0 --add-spare /dev/sdd1 </span></code> | ||
==== Kopie auf neue Platte ==== | |||
* Die alte Partition muss ausgetauscht werden | * Die alte Partition muss ausgetauscht werden | ||
** <code><span style="background-color:#000000;color:#FFFFFF"> mdadm /dev/md0 --replace /dev/sde1 </span></code> | ** <code><span style="background-color:#000000;color:#FFFFFF"> mdadm /dev/md0 --replace /dev/sde1 --with /dev/sdd1 </span></code> | ||
* Nun erfolgt die resync-Phase | * Nun erfolgt die resync-Phase | ||
Zeile 880: | Zeile 1.039: | ||
unused devices: <none> | unused devices: <none> | ||
[[Datei:RAID6-replace.jpg|190px]] | |||
* Er macht vom "replace"-Drive (sdb1-RRR) eine Kopie nach "spare"-Drive (sdd-WWW) | |||
* Man erkennt dass RAID-Device "2" (rot) durch "2" (grün) ersetzt wird | * Man erkennt dass RAID-Device "2" (rot) durch "2" (grün) ersetzt wird | ||
Zeile 957: | Zeile 1.119: | ||
* Vermindere die Sync-Leistung massiv ggf. so lange bis die Platten wieder unter 45 Grad sind, durch | * Vermindere die Sync-Leistung massiv ggf. so lange bis die Platten wieder unter 45 Grad sind, durch | ||
# | |||
# ermittle zunächst die aktuelle sync Leistung | |||
# | |||
cat /sys/block/md0/md/sync_speed | |||
# | |||
# schreibe deinen wesentlich kleineren Wert in die speed Obergrenze | |||
# | |||
echo 5000 > /sys/block/md0/md/sync_speed_max | echo 5000 > /sys/block/md0/md/sync_speed_max | ||
Zeile 1.019: | Zeile 1.189: | ||
<span style="background-color:#C00000">2 8 65 - faulty /dev/sde1</span> | <span style="background-color:#C00000">2 8 65 - faulty /dev/sde1</span> | ||
==== Abschluss ==== | |||
* Nun muss man dieses "faulty" device noch aus dem Array entfernen | |||
* Nun muss man dieses noch aus dem Array entfernen | |||
** <code><span style="background-color:#000000;color:#FFFFFF"> mdadm /dev/md0 --remove /dev/sde1 </span></code> | ** <code><span style="background-color:#000000;color:#FFFFFF"> mdadm /dev/md0 --remove /dev/sde1 </span></code> | ||
* Die Platte selbst trägt noch die Signatur für dieses RAID-Array, um Verwirrung auszuschliessen sollte der Superblock gelöscht werden | * Die Platte selbst trägt noch die Signatur für dieses RAID-Array, um Verwirrung auszuschliessen sollte der Superblock gelöscht werden | ||
Zeile 1.027: | Zeile 1.197: | ||
* Wer will kann die Platte vor dem Entsorgen noch komplett nullen, andernfalls sollte die Platte mechanisch zerstört werden | * Wer will kann die Platte vor dem Entsorgen noch komplett nullen, andernfalls sollte die Platte mechanisch zerstört werden | ||
** <code><span style="background-color:#000000;color:#FFFFFF"> shred -v -z --iterations=0 /dev/sde </span></code> | ** <code><span style="background-color:#000000;color:#FFFFFF"> shred -v -z --iterations=0 /dev/sde </span></code> | ||
* Nun sollte man wenn möglich wieder für ein spare sorgen | |||
* Nun sollte man ein scrub machen um Sicherzustellen dass das neue drive die Daten auch wirklich speichern konnte! | |||
* Erst jetzt ist das vorsorgliche austauschen eines Drives abgeschlossen | |||
=== RAID insgesamt vergrößern === | === RAID insgesamt vergrößern === | ||
Zeile 1.035: | Zeile 1.209: | ||
* mdadm --grow ausführen, um das Array wachsen zu lassen | * mdadm --grow ausführen, um das Array wachsen zu lassen | ||
** mdadm --grow /dev/md0 --size=max | ** <code><span style="background-color:#000000;color:#FFFFFF"> mdadm --grow /dev/md0 --size=max </span></code> | ||
* SOFORT kann man das Dateisystem vergrössern | * SOFORT kann man das Dateisystem vergrössern | ||
** resize2fs /dev/md0 | ** <code><span style="background-color:#000000;color:#FFFFFF"> resize2fs /dev/md0 </span></code> | ||
* Nun noch beobachten was der "grow" verursacht. ext4 merkt davon nix. | * Nun noch beobachten was der "grow" verursacht. ext4 merkt davon nix. | ||
** <code><span style="background-color:#000000;color:#FFFFFF"> watch -n.4 'cat /proc/mdstat' </span></code> | ** <code><span style="background-color:#000000;color:#FFFFFF"> watch -n.4 'cat /proc/mdstat' </span></code> | ||
Zeile 1.181: | Zeile 1.355: | ||
* die Automatisierung via systemd erfolgt "so": [[Linux.systemd#einzelne_Festplatten_in_den_Standby]] | * die Automatisierung via systemd erfolgt "so": [[Linux.systemd#einzelne_Festplatten_in_den_Standby]] | ||
=== Spares entfernen === | |||
* Hier sind keine Vorarbeiten nötig, einfach "remove" | |||
mdadm /dev/md127 --remove /dev/sdd1 | |||
== Begriffe == | |||
* Block | |||
** Blocksize | |||
** Superblock | |||
* Stripe | |||
* Stride | |||
* Chunk | |||
* Bitmap | |||
* Journal | |||
* Device | |||
== Benchmarks == | == Benchmarks == | ||
Zeile 1.192: | Zeile 1.384: | ||
* Produktiv Server "raib42" [[RAID6-2015]] | * Produktiv Server "raib42" [[RAID6-2015]] | ||
* Backup Server "raib2" [[RAID6-2016]] | * Backup Server "raib2" [[RAID6-2016]] | ||
* Produktiv Server " | * Produktiv Server "raib23" [[RAID6-2017]] (death 2021) | ||
* Produktiv Server "tokio" [[RAID6-2018]] | * Produktiv Server "tokio" [[RAID6-2018]] | ||
* Backup Server "backup" [[RAID6-2020]] | |||
* Spare Server "raib80" [[RAID6-2021]] | |||
* Spare Mainboard+OS [[RAID6-ratingen]] | |||
* Grey Server [[RAID6-osgiliath]] | |||
* Ideensammlung [[RAID6-20p]] | |||
== Ideen == | |||
[[emde]] | |||
== Links == | == Links == | ||
* https://raid.wiki.kernel.org/index.php/Linux_Raid | * https://raid.wiki.kernel.org/index.php/Linux_Raid | ||
* https://raid.wiki.kernel.org/index.php/Timeout_Mismatch | |||
* http://www.linuxfromscratch.org/blfs/view/svn/postlfs/mdadm.html | |||
* http://www.thomas-krenn.com/de/wiki/Mdadm_checkarray |
Aktuelle Version vom 16. August 2023, 12:10 Uhr
"md" ist ein Kernel Bestandteil von Linux mit dem man per Software ein RAID-System aufbauen kann. md stellt dem Linux System eine virtuelle Partition zur Verfügung (in der Regel "/dev/md0") die es "so" gar nicht real auf der/den Festplatte(n) gibt. Je nach RAID Level werden Schreib- Lesezugriff auf /dev/md0 durch die md-Software auf die realen Partitionen weitergegeben. RAID kann für mehr Datensicherheit sorgen (der Preis dafür ist geringe Geschwindigkeit sowie geringere Nettonutzinhalt der Partition), oder für höhere Zugriffsgeschwindigkeit (der Preis dafür die eine höhere Ausfallwahrscheinlichkeit), das alles jedoch unterhalb der Dateisystem-Ebene. Ich finde Software-RAID optimal, da das ganze Array von einem Mainboard auf ein anderes umgezogen werden kann. Auch von einem Kernel zu einem neueren. Es ist kein spezieller Controller nötig, der 2fach vorgehalten werden muss. Hier einige ausgesuchte Details - Infos ...
- Es gibt verschiedene RAID-Level: (Am besten finde ich dazu die Dokumentation im Wiki: https://de.wikipedia.org/wiki/RAID)
- Mein Lieblingslevel ist eindeutig RAID6, hier eine Erklärung wie RAID6 bei 4 Platten organisiert ist:
wie funktioniert RAID6 mit 4 Platten genau?
Evolution von einer "realen Partition" zur "simulierten"
- Festplatten sind "Block"-Devices:
- Erst mal betrachten wir Festplatten als "Block" Devices
- Ihre Kapazität ist "n" Sektoren, somit kann die Platte n * ~SectorSize~ Bytes speichern
- Früher hatten Festplatten 512 Bytes Sektorgrösse, heute sind es oft 4096 Byte (=4K)
- Ein "Sektor" ist die kleinste physikalische Datengruppe die adressiert danach im gesammten gelesen oder geschrieben werden muss
- Will man ein Byte lesen, so wird man physikalisch immer den ganzen Sektor lesen müssen.
- Daraus ergibt sich ein Hintergrundwissen: Habe ich ein Byte gelesen, sind die restlichen 4095 Bytes im Cache
- Beim Übergang auf RAID wird diese Datengruppierung noch massiver
- Ein RAID - Chunk (=ein Datenblock D) hat z.B. die Größe von 512K also 128 Sektoren zu 4096 Byte (128*4K=512K)
- Die Änderung eines einzelnen Bits in einem Datenblock D muss auf 3 Festplatten geschrieben werden (D+P+Q), das ist unabhängig von der Anzahl der Festplatten
- Ein Stripe hat bei 4 RAID-Devices 4 Chunks, D0+D1+P(0,1)+Q(0,1) = 4 MByte brutto = 2 MByte netto
- Jeder Block hat natürlich eine "Adresse", die sind einfach durchnummeriert von "0" bis "n-1"
- Dem Filesystem Gegenüber wird eine Sektorgrösse von ??? vorgespielt
Rolle des Dateisystem
- Ein Dateisystem braucht einfach nur eine Block-Device, darauf bildet es Dateien und Ordner und Zugriffsrechte ab.
- Das Dateisystemsystem sieht einfach nur die Partition "/dev/md0", hier ist die Welt in Ordnung: einfach eine Kette blauer Nutzdatenblöcke, hier nur von "0" bis "5" dargestellt, das geht natürlich in Wirklichkeit viel weiter. Eine 1 TB Platte hätte z.B. Blöcke von "0" bis "488280".
"md" schneidet die linear angeordnete Partion in Streifen
- 4 Platten im RAID6-Verbund, ein Block=Chunk sei 512K lang.
- md bezeichnet Block auch auch als "Chunk" oder "Strip"
- Also 2 Blöcke mit Nutzdaten "D" (die beiden Datenblöcke mit den Adressen "0" und "1") verteilt md auf alle 4 Platten. Oben sieht man die "0". darunter die "1". dann die Parität "P(0,1)". dann die Parität "Q(0,1)". Dies ist ein Stripe, also ein Streifen (vertikal betrachten!).
- Platte "0": bekommt direkt den Block "0"
- Platte "1": bekommt direkt den Block "1"
- Platte "2": md berechnet aus "0" und "1" einen neuen Blockinhalt mithilfe der magischen Funktion "P"
- Platte "3": md berechnet aus "0" und "1" einen neuen Blockinhalt mithilfe der magischen Funktion "Q"
- Ein Stripe (ein Streifen) ist also immer 1 MByte gross (Nutzdaten D0 + D1). Das ist die Minimale atomare Grösse die ein RAID Array schreiben kann. Wird also nur 1 Byte einer Datei geändert muss md 1 Mbyte neu schreiben. Es kann also sein dass das Byte in D0 liegt -> D0 muss neu geschrieben werden, D1 kann bleiben, P und Q Muss neu geschrieben werden. 3 Chunks werden geschrieben: D0, P und Q -> 1,5 MByte.
- P und Q sind zwei Funktionen, die keine kurze Prüfsumme bilden, sondern wiederum eine Bitfolge mit genau der Länge eines ganzen Blockes. Die mathematischen Routinen sind dabei so geschickt gewählt dass die Ergebniswerte von P und Q eindeutig mit dem Inhalt von "0" und "1" zusammenhängen. Ändert sich also nur ein Bit in "0" oder "1", so ändert sich auch entsprechend der Wert von "P" und "Q".
- P und Q sich auch so geschickt gewählt, dass P(0,...,0)=0 und Q(0,...,0)=0, das heisst also fabrikneue Platten erfüllen die Parity-Anforderung uns es muss nix geschrieben werden.
- P und Q werden rotierend angeordnet damit keine reinen Paritätsplatten entstehen, es gibt keine explizite Parity Disk
wie werden "P" und "Q" berechnet
- P und Q verwenden unterschiedliche Algorithmen. Aber beide Routinen brauchen die Blöcke "0" und "1" als Eingangsparameter.
- P ist ein einfaches XOR aller Daten Chunks
# # das Original ist in den Kernel Sourcen unter "lib\raid6\int.uc" # # Copyright 2002-2004 H. Peter Anvin - All Rights Reserved # // // Pascalversion (c) Andreas Filsinger // function P(D : Array of TStrip) : TStrip; var n : Byte; begin P := D[High(D)]; for n := High(D)-1 downto 0 do P := P xor D[n]; end;
- Q ist komplizierter Reed-Solomon-Code, bzw ein Galois Field, GF(2 hoch 8), (dadurch begründet sich übrigens die RAID6 Limitierung auf 253 Disks):
# # das Original findet man in den Kernel Sourcen unter "md\lib\raid6\int.uc" # # Copyright 2002-2004 H. Peter Anvin - All Rights Reserved # // // Pascalversion (c) Andreas Filsinger // function Q(D : Array of TStrip): TStrip; var n : Byte; T1, T2 : TStrip; begin Q := D[High(D)]; for n := High(D)-1 downto 0 do begin // // The MASK() operation returns $FF in any byte for which the high // bit is 1, $00 for any byte for which the high bit is 0. // T2 := MASK(Q); // // The SHLBYTE() operation shifts each byte left by 1, *not* // rolling over into the next byte // T1 := SHLBYTE(Q); // // The NBYTES() operation returns a TStrip filled with the given // byte // T2 := T2 and NBYTES($1D); T1 := T1 xor T2; Q := T1 xor D[n]; end; end;
- P/Q Berechnung
- P und Q werden in Wirklichkeit auf einen Rutsch in einer Funktion names "gen_syndrome". Diese liegt mehrfach implementiert vor: Verschieden optimiert für spezielle CPU Technologien z.B. für NANO (ARM), oder MMX, MMX2, AVX2 (AMD/Intel).
- der darüberliegende Code ruft nur raid6_call.gen_syndrome(disks, bytes, ptrs)
- disks = Anzahl der chunks (im Quelltext auch "Buffers" geannt) (Datenchunks+Paritätschunks)
- bytes = Chunk-Größe
- ptrs = Array[0..disks-1] of Ptr^[0..bytes-1]
- Chunk Recovery
- Ein oder Zwei Chunks eines Stripes können "berechnet" werden
- Für die beiden Fälle gibt es spezialisierte Funktionen
- "data2" und "datap": raid6_2data_recov, raid6_datap_recov
- Dazu wird der/die als falsch erkannte(n) Chunk(s) als Byte-Folge mit lauter Nullen aufgefüllt
- dann wird wie immer "syndrome" aufgerufen, es gibt dann bei "Q" Methoden das zurückzurechnen
- bei "P" ist es trivial, dann ist P der korrigierte Chunk, P muss dann abermals berechnet werden
Lese/Schreib Überlegungen
Number Major Minor RaidDevice State 0 8 81 0 active sync /dev/sdf1 1 8 17 1 active sync /dev/sdb1 9 8 113 2 active sync /dev/sdh1 3 8 97 3 active sync /dev/sdg1 4 8 129 4 active sync /dev/sdi1 5 8 33 5 active sync /dev/sdc1 6 8 49 6 active sync /dev/sdd1 7 8 145 7 active sync /dev/sdj1 8 8 161 8 active sync /dev/sdk1 10 8 65 - spare /dev/sde1 # blockdev --getiomin /dev/md0 524288 # blockdev --getioopt /dev/md0 3670016
- Man sieht hier schön, dass minimal (getiomin) ein "Chunk" gelesen werden kann
- Da eh immer ein Stripe gelesen/geschrieben werden muss ist die optimale grösse ein 9-2=7*Chunk = 3670016 Bytes, also die Nutzdatengrösse eines Stripes
entweder Bitmap ...
- Die folgende Information könnte falsch sein, das hab ich noch nicht überprüft:
- Das Bitmap eines RAID-Verbundes ist eine Datenstruktur in den Metadaten jedes einzelnen drive des RAID wobei jedes Bit einem Stripe entspricht
- Im laufenden Betrieb kann ein "clone" eines gesamten drives notwendig werden (ein spare wird produktiv)
- Schreibende Zugriffe sind in dieser sync Zeit möglich
- Das bitmap verzeichnet diese ungeplanten Zugriffe, damit der lineare sync-Prozess diese Stripes überspringen kann (da bereits synchron!)
- ein Bitmap kann einen kompletten resync verhindern da es verzeichnet welche Stripe neu geschrieben werden müssen
... oder Journal
- Das Journal ist eine alternative zum einem Bitmap, und ein optionales Element eines RAID Verbundes
- Es speichert Daten und Paritäten bevor diese dem Verbund zum Speichern übergeben werden
- Unsicher: Es hält schreibende Zugriffe auf den Verbund zurück, obwohl die darüberliegende Schicht ein sync gefordert hat
- Es wird ein eigenes Volume benötigt, es sollte schnell und zuverlässig sein (SSD)
- die Grösse bei einem 20 TB Verbund habe ich mit 99 GByte vorgesehen (wahrscheinlich viel zu groß!)
- Nachträgliches Einrichten eines journals
- Ich hatte Schwierigkeiten es schon beim Erstellen des Verbundes mit anzulegen, da scheiterte einfach jeder Befehl:
- "so" habe ich es geschafft:
# # warte, bis der initiale resync fertig ist! # # # stelle sicher dass das Array nicht gemountet ist # (gerade der ext4lazyinit des Dateisystems schreibt gerne mal länger auf ein frisches Dateisystem) # umount /srv/smb/ra6 # # entferne das Bitmap # mdadm --grow /dev/md127 --bitmap=none # # nehme keine weiteren Schreibzugriffe mehr an # mdadm --readonly /dev/md127 # # füge die Journal- Partition dazu # mdadm /dev/md127 --add-journal /dev/sda4 # das Array ist nun wieder automatisch im read-write # man kann jetzt wieder mounten
- "write-back" ist mein Favorit beim Journal, Unterschiede sind hier dokumentiert
# # # cat /sys/class/block/md127/md/journal_mode # # # echo "write-back" >/sys/block/md127/md/journal_mode
Ausfallüberlegungen
- der Ausfall einer einzelnen Platte ist uns zu einfach (der Wert P wird benutzt!): wir nehmen immer 2 gleichzeitige Ausfälle an:
- ich betrachte jetzt einen einzelnen Chunk als Problem, es gilt aber auch alles für alle Chunks
- Die 4 Platten nenne ich jetzt einfach mal 0 und 1 und P und Q
- Es ist bei dem 4er Verbund so, dass uns immer eine Platte eigentlich nichts bringt, weil da KEINE Infos zu dem ausgefallenen Chunk drauf sind
- Jetzt müssen wird ganz stark sein: Wenn wir nichts mehr haben (also die beiden Platten die "0" und "1" beherbergen), also nur noch "P" und "Q" können wir daraus "0" und "1" rekonstruieren.
- die Partitionen "2" und "3" fallen aus: Ähm, null-Problem: Wir haben kein Datenverlust Block #0 und #1 sind doch noch da! Und P und Q neu zu berechnen? Das machen wir jeden Tag millionenfach! Also ist die Rekonstruktion einfach!
- die Partitionen "0" und "1" fallen aus: da "P" und "Q" zur Verfügung stehen lässt sich "0" und "1" zurückrechnen.
- die Partition "0" und "P" fallen aus. Aus Q und "1" lässt sich "0" berechnen, danach können wir wieder "P" rekonstruieren
- die Partition "0" und "Q" fallen aus. Aus P und "1" lässt sich "0" berechnen, danach können wir wieder "Q" rekonstruieren
- Das Tool unter Linux heisst mdadm, und es ist überall gut dokumentiert
http://www.ducea.com/2009/03/08/mdadm-cheat-sheet/
Tipps
- Benutze eine eigene Platte (SSD) für Boot und Betriebssystem. Es gibt natürlich auch die Möglichkeit vom RAID Array zu booten, oder Swap oder Systempartitionen darauf zu haben, aber das ist NICHT zu empfehlen weil es auch mit Risiken verbunden ist (Wenn das vermischt wird schwächst Du die Datensicherheit, Gefahr bei Updates, Mobilität). Betrachte dein RAID Array als Verbund, den man auch mal komplett an neue Hardware anschliessen können muss.
- Benutze Level 5 (ab 3 Partitionen) für Grössen bis 5GB oder Level 6 (ab 4 Partitionen) ab 5 GB
- Benutze ein Bitmap (das ist default!), aber kein externes (dadurch schwächst Du die Datensicherheit, Stichwort Mobilität des RAID)
- Bitmap Begriff allgemein: https://github.com/qemu/qemu/blob/master/docs/interop/bitmaps.rst
- Benutze Platten mit nahezu gleicher Grösse und Datenrate
- Benutze Platten ohne SMR (Shingled Magnetic Recording) Technik. Da dies dazu führen kann dass ein Resync-Vorgang (Full Write) nur 1/4 der Plattengeschwindigkeit nutzen kann.
- Benutze lieber Platten mit CMR.
- Wenn eine (neue) Platte leicht oder sehr viel grösser ist als die anderen im Verbund: Erstelle dennoch eine maximal grosse Partition. Wenn die kleinen Platten in Zukunft alle ausgefallen / ausgetauscht sind kannst Du mit --grow die RAID- Partition auch vergrössern und so den zunächst ungenutzen Platz dennoch nutzen.
- Benutze/Beschaffe Platten ...
- verschiedener Hersteller,
- oder verschiedene Modelle
- oder unterschiedlichen bisherigen Betriebsstunden
- oder Verschiedene Einkaufsquellen, oder Serien, oder verschiedene Chargen
- ... Dies erhöht die Diversität des Ausfallmomentes, und das ist das Wichtige. Es muss vermieden werden dass 2 oder 3 Platten nahezu gleichzeitig ausfallen!!!
- Mache Firmware-Updates aller Platten auf einem Windows PC vor dem Einbau
- Bei einer Wartung kann die SATA Verkabelung völlig vertauscht werden, kein Problem!
- Versuche zumindest einen SATA Port freizulassen, hier kann bei einem Plattentausch die "Neue" angeschlossen werden, ohne dass man eine bestehende Platte abziehen muss (Ja, man kann und sollte im reibungslos laufenden Betrieb mal eine (alte) Platte tauschen!!). Optimal sind z.B. 6x SATA Ports: 1x System 4x RAID6 1x frei
- Im Notfall
- stelle sicher, dass deine Ersatz-Platte nicht bootfähig ist (keine Drama wenn ja, aber willst Du dass ev. dein BIOS durchdreht und das System von dieser Platte startet?)
- stelle sicher, dass deine Ersatz-Platte nicht zuvor Teilnehmer eines anderen RAID Verbundes war (keine Drama wenn ja, aber willst Du dass Linux ein "md126" erstellt mir nur eben diesem Waisenkind?)
- stelle sicher, dass deine Ersatz-Platte keine Partitionstabelle hat (kein Drama wenn ja, aber willst Du dass dies keine maximale Partition ist, oder 2, oder?)
- Mache Dir eine Lageplan-Skizze der Platten mit folgenden Angaben:
- Lage der Platte (aus der Skizze ersichtlich)
- SATA Port Bezeichnung (z.B. "Rot"-"0", ermitteln durch Aufdruck auf dem Mainboard)
- Plattenbezeichnung (z.B. "/dev/sdb", ermitteln durch hwinfo --hdd)
- "Serien-Nummer" der Platte (z.B. "GDCCBSGGS", ermitteln durch smartctl -a /dev/sdb)
- Nummer der Platte innerhalb des RAID-Verbundes (z.B. "3", ermitteln mdadm --detail /dev/md0)
- Auflisten der verfügbaren ata Schnittstellen
dmesg -T | grep ahci
Mitarbeit
False Positiv Error Msg
- sync, umount, reboot ->
[Fri Nov 6 10:27:22 2020] md/raid:md127: recovering 0 data-only stripes and 1 data-parity stripes
https://github.com/torvalds/linux/blob/master/drivers/md/raid5-cache.c Line 2496 https://github.com/torvalds/linux/commit/b4c625c67362b3940f619c1a836b4e8329106658#diff-be24a83d195fa53b3da9c7257a0352e92dbe2318c725e0492986d425317d4e3d
- data_parity_stripes wird incrementiert, auch wenn er nichts arbeitet ist der Wert zumindest 1
was tut sich?
Inbetriebnahme eines neuen RAID Verbundes
Hardware
- Vorrangig nutze ich erst (fast) alle OnBoard SATA 6 Gb/s Schnittstellen
- eine der Schnittstelle sollte man freilassen für Recovery-Szenarien
- Um eine zusätzliche Adapter-Karte PCIe <-> SATA kommt man in der Regel nicht herum
- Ich schwöre auf Software-RAID somit tun es Adapter ohne RAID Logik völlig
- Ist mal eine RAID-Logik auf dem Controller schadet das in der Regel nicht da ...
- ... die angeschlossenen Platten auch einzeln ansprechbar sind
- ... sich die RAID-Logik abschalten lässt
- ... der RAID-Controller auch den Modus JBOD anbietet
- Mich interessieren nur Controller mit internen SATA Anschlüssen
hier Linux.host-adapter Infos über Host-Adapter
HDD-Bunch: loser Versuchsaufbau
- Hier 4x 1 Terrabyte Festplatten von 2 unterschiedlichen Herstellern (2x ST1000NM0011, 2x WD1003FBYX) im Software RAID 5 Verbund
- Zum Booten und für das openSuSe 11.4 System verwende ich eine Intel SSD
- Man sieht im Versuchsaufbau die 4 Festplatten auf übergrosse Kühlkörper geschraubt
HDD-Bunch: 19" Eigenkonstruktion für Produktivbetrieb
- 6x HotSwap Wechselrahmen auf einem 19" Träger
- Die Wechselrahmen sind ohne Temperaturkühlung passiv (Bin nicht so 100% zufrieden, werden durch ICY DOCK ersetzt)
- Mit den 6x ICY DOCK MB171SP-B (http://www.icydock.de/goods.php?id=142) ist das wesentlich besser
- aktive Kühlung der Platte durch einen Lüfter -> Temperaturen < 42 °C
- Front LED blau, erleichtert die Identifikation der Platte
- Download der Frontplatte : https://cargobay.orgamon.org/NAS-0001-0001.fpd (fräst die Schaeffer AG Berlin)
- Man braucht noch 3x 2 Winkel: http://www.caselabs-store.com/flex-bay-5-25-device-mount-hd/
Software
Partition erstellen
- Es gibt Diskussionen dem raid einfach eine Platte zur Verfügung zu stellen, technisch geht das, RAID benötigt keine Partitionstabelle
- Ich empfehle eine Partition anzulegen, im Recovery-Fall hat das meiner Meinung nach Vorteile
- übliche Partitionsgrössen bei typische Laufwerksgrößen
- 1TB HDD, 1000203820544 Bytes Partition
- 2TB HDD, 2000397868544 Bytes Partition
- 4TB HDD,
- 8TB HDD, 8001562156544 Bytes Partition
- Die Partionskennung "Linux RAID" ist auch eine saubere Sache
- Pro Platte des Verbundes: eine maximal grosse Partition
- Auf allen RAID Platten des Verbundes: Erstelle eine Primäre sowie Maximal grosse Partition Typ xFD00 (=Linux RAID autodetect)
- Es spielt keine Rolle ob eine DOS-Partitionstabelle (fdisk) oder eine GPT-Partitionstabelle (gdisk) erstellt wird, gdisk ist Stand der Technik (2016)
- Bei OpenSuse verwende ich gerne
- mit gdisk eine maximale "Linux RAID" - Partition erstellen
gdisk /dev/sd~DeinBuchstabe~
- sicherstellen das es keine Partitionen bisher gibt:
i
- "No paritions" (Gut!)
n
- Partition number (1-128, default 1):
<ENTER>
- First sector (34-5860533134, default = 2048) or {+-}size{KMGTP}:
<ENTER>
- Last sector (2048-5860533134, default = 5860533134) or {+-}size{KMGTP}:
<ENTER>
- Current type is 'Linux filesystem'
- Hex code or GUID (L to show codes, Enter = 8300):
fd00
- Changed type of partition to 'Linux RAID'
- Command (? for help):
w
- Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING PARTITIONS!! Do you want to proceed? (Y/N):
y <ENTER>
RAID Verbund erstellen
- wir erstellen nun die "virtuelle" RAID-Partition /dev/md0 aus 5 Partitionen
mdadm --create --verbose /dev/md0 --level=6 --raid-devices=5 /dev/sd[bcdef]1
- /dev/md0 ist nun sofort nutzbar
- Im Hintergrund läuft ein initialer resync des Array ab, da P(s)=0 und Q(s)=0 bei s1..sn=0 ist es ein nur lesender Vorgang
md0 : active raid6 sdf1[4](S) sde1[3] sdd1[2] sdc1[1] sdb1[0] 23437503488 blocks super 1.2 level 6, 512k chunk, algorithm 2 [4/4] [UUUU] [============>........] resync = 64.0% (7504388632/11718751744) finish=578.6min speed=121383K/sec bitmap: 35/88 pages [140KB], 65536KB chunk
etx4 Dateisysten erstellen
- Erstelle ein Filesystem auf der raid-Partition
mkfs.ext4 -m 0 -O 64bit -E lazy_itable_init=0,lazy_journal_init=0 /dev/md0
- "-m 0": da die Platte NICHT unsere Systemplatte ist soll für root nichts reserviert werden
- "-O 64bit": sollte die aktuelle Partition < 16 TB sein, würde kein Dateisystem erstellt, das auf über 16 TB erweiterbar ist. Um diese Situation nach möglicher Erweiterung des Arrays zu vermeinden, wird mkfs gezwungen den >16TB Support von Anfang an zu aktivieren. Zu beachten sind dabei 2 Dinge:
- die Defaults aus /etc/mke2fs.conf gelten dennoch, wir schalten also nur die 64bit noch dazu
- ES GIBT KEINEN Migrationsweg von "ext4 OHNE 64bit-Support" auf "ext4 auf eine Partition >16 TB" (Stand 1.42.13, also 03.2016) (Das kann man nicht glauben oder?!)
- ES GIBT EINEN WEG? eMail an andreas.filsinger at orgamon.org
- Im Internet gibt es Infos, dass ext4 auf den RAID Betrieb hin optimiert werden kann. Das passiert aber im Rahmen der Erzeugung des Systems von alleine, mke2fs kommuniziert über I/O Ctl Funktionen mit der Partition. Es gibt im Netz Hinweise für die manuelle Berechnung. Es war bei mir aber immer so dass die automatischen Werte passten! Hier: http://busybox.net/~aldot/mkfs_stride.html aber der Link für die Berechnung der Werte.
- Ich habe ein ext4 Dateisystem, also vielmehr das darunter liegende md-Device von RAID5 auf RAID6 migriert, dabei habe ich die Plattenanzahl von 4 auf 5 erhöht, dennoch passten die Werte am Ende wieder zusammen.
Einhängen in ein Verzeichnis
- Damit wir das rießige ext4 Dateisystem nutzen können müssen wir es an beliebiger Stelle in unser Verzeichnis-System einhängen
- Erstelle dazu ein Verzeichnis (in meinem Fall /srv/smb/ra6)
- Unser Array hat Namen "~Hostname~:0", danach ist es als "/dev/md0" sichtbar, das bedeutet die erste (=0) LOKALE md-Partition
- Ändert sich jedoch der Name dieses Hosts (durch DHCP), oder wird das Array auf einen anderen Host umgezogen so ist es nicht mehr "lokal" und es erhält einen Namen wie z.B. "/dev/md127"
- Also Vorsicht vor diesen Alias-Namen beim Mounten: Ich verwende lieber den "uuid" des Arrays selbst, und nicht "lokale" oder "remote" Namen. Diese Bezeichnung ist viel langlebiger (also eigentlich für immer), und stimmt auf jedem System.
- l /dev/disk/by-id | grep md
- ... liefert Dir den passenden Namen
- schau ev. mit mdadm nach, ob die UUID auch richtig/identisch ist:
- mdadm --detail /dev/md127
- joe /etc/systemd/system/srv-smb-ra6.mount
[Unit] Description=srv-smb-ra6 [Mount] What=/dev/disk/by-id/md-uuid-2ca7d214:9c6bfab4:b2ecf28b:72df44ca Where=/srv/smb/ra6 [Install] WantedBy=local-fs.target
- Sicherstellen, dass das Array beim Hochfahren gemounted wird:
systemctl enable srv-smb-ra6.mount
- Jetzt endlich einhängen und nutzen:
systemctl start srv-smb-ra6.mount
Fertig
- Nun endlich kann das RAID voll genutzt werden, beschreibe es unter Volllast - egal
- Bedenke aber dass im Hintergrund die Redundanz des RAID aufgebaut wird, ich denke mal in dieser Phase darf nix schiefgehen
- Ein Restore aus einem Backup kann schon mal gestartet werden, so richtig in Betrieb nehmen würde ich es erst wenn es den Status "clean" hat
Im laufenden Betrieb
Mounten des Dateisystemes
- natürlich automatisch beim Systemstart mit einer systemd-Datei:
Monitoring
Zugriffe beobachten
nmon
USV
apcaccess status
Read Ahead
- Fraglich ist, ob das Setzen des Read Ahead Buffers was bringt
- Tatsache ist dass md immer Stripe-Weise die Platten ausliesst und schreibt
- Somit bringt es für die Platte nichts "weniger als eine Chunk Grösse" zu lesen
- Aber ich hoffe, dass schon über SATA die Anforderung zu Lesen/Schreiben eines Chunks als EIN Befehl kommt
- Get block device read ahead buffer size
# blockdev --getra /dev/sda 1024
Stripe Cache
cat /sys/block/md127/md/stripe_cache_size cat /sys/block/md127/queue/physical_block_size cat /sys/block/md127/md/raid_disks
- der Hauptspeicher Bedarf ist stripe_cache_size*physical_block_size*raid_disks
SCT
- Bestimme und setze einen definierten Zeitrahmen für Lese- und Schreib- Operationen
- Hier geht es darum unnötiges Aushängen einer ganzen Platte zu verhindern, die Probleme mit einzelnen Sektoren hat
- Bei Lese- oder Schreib- Problemen sollte eine Platte nicht endlos weiterversuchen irgendwas zu Lesen oder zu Schreiben
- Für die RAID- Software ist es viel besser nach einer Definierten Zeit ein Read-Timeout oder Write-Timeout zurückzugeben
- Sonst droht der Timeout für das ganze Blockdevice (default 30 Sekunden)
- die MD Software kommt mit Sektor-Fehlern klar und beginnt hier Sektorweise Massnahmen zu ergreifen indem es den Sektor korrigiert schreibt
- Nicht klar kommt sie mit einer endlos langen Nicht-Rückkehr der Festplatte nach einen read- oder write- Befehl
- dies führt zum Aushängen der ganzen Platte aus dem Verbund obwohl 99% eigentlich noch OK sind
- read/write Timeout der Platte muss also kleiner sein als der Timeout des Block-Device
- Anzeigen
smartctl -l scterc /dev/disk/by-id/ata-WDC_WD120EDAZ-11F3RA0_5PH5124D
- Setzen auf Read=7 Sekunden, Write=7 Sekunden Timeout
smartctl -l scterc,70,70 /dev/disk/by-id/ata-WDC_WD120EDAZ-11F3RA0_5PH5124D
#!/bin/bash for i in /dev/sd? ; do if smartctl -l scterc,70,70 $i > /dev/null ; then echo -n $i " is good " else echo 180 > /sys/block/${i/\/dev\/}/device/timeout echo -n $i " is bad " fi; smartctl -i $i | egrep "(Device Model|Product:)" done
Sync, Reshape
watch -n.4 'cat /proc/mdstat'
Fittness des Array
mdadm --detail /dev/md0
Temperatur einzelner Platten
smartctl -l scttemp /dev/sdX | grep Current
Lesegeschwindigkeit des Array
dd if=/dev/md127 iflag=direct of=/dev/null bs=1M count=4096
Lesegeschwindigkeit einer einzelnen Platte
dd if=/dev/sdc1 iflag=direct of=/dev/null bs=1M count=4096
automatisiert von Windows aus mit Putty
plink -batch -pw *** -P 2222 root@host "mdadm --detail /dev/md127"
Infos über RAID und ext4
# # Welche Platte hängt an welchem SATA-Controller? # hwinfo --disk | grep ata # # Aktueller Status des RAID Verbundes # cat /proc/mdstat # # Alle Parameter meines RAID 6 # mdadm --detail /dev/md0 # # Alle Infos über den Superblock auf jeder Disk # mdadm --examine /dev/sdb1 mdadm --examine /dev/sdc1 mdadm --examine /dev/sdd1 mdadm --examine /dev/sde1 mdadm --examine /dev/sdf1 # # Alle Parameter meines ext4 Dateisystems # tune2fs -l /dev/md0
# # Alternativer Befehl # dumpe2fs /dev/md0
Korrekturlauf
- Data Scrubbing, vollständiger Lesecheck
- Beim RAID6 kann sein, dass ein Stripe unstimmig ist. Das bedeutet, die Infos "D", "P" und "Q" passen nicht zusammen. Für jeden Datenblock in D lassen sich 3 Varianten berechnen: raw(D), D² zurückgerechnet aus P(), D³ zurückgerechnet aus Q(). Nun werden diese 3 Varianten verglichen. Bei einer 2:1 Situation ist die Sache klar, dann ist eine Korrektur von D oder P oder Q möglich. Ergeben sich 3 unterschiedliche Werte ist eine Korrektur nicht mehr möglich. Im Idealfall sind alle 3 Werte gleich.
- Es gibt die Möglichkeit einen "check" zu machen, die Laufzeiten sind natürlich immens, da alle devices zu 100% gelesen werden müssen. Es gibt kein Trim bei md-Partitionen. Ich hatte mal den Fall, dass 267 "mismatch" gefunden wurden. Die Laufzeit dafür war 10 Stunden. Seither mache ich immer einen "repair", gebe also dem "check" die Erlaubnis mit, wenn was nicht stimmt dann auch gleich korrigieren zu können, nichts anderes ist bei einem RAID6 sinnvoll.
- Vor der Prüfung, lass dir anzeigen wie der Stand der Anzahl der Lesefehler ist
cat /sys/block/md~ArrayNummer~/md/mismatch_cnt
- Starte die Prüfung
mdadm --action=repair /dev/md~ArrayNummer~
- Wie immer wird der Fortschritt des "check" in
/proc/mdstat
angezeigt
watch -n2 'cat /proc/mdstat && cat /sys/block/md~ArrayNummer~/md/mismatch_cnt'
- Werden Platten zu warm, oder es ist zu viel los kann man den check unterberechen
echo idle > /sys/block/md~ArrayNummer~/md/sync_action
- Will man die Prüfung stoppen muss man (wir nach einem reboot fortgesetzt)
echo frozen > /sys/block/md~ArrayNummer~/md/sync_action
- Ist die Prüfung beendet lass Dir anzeigen ob es Lesefehler gab
cat /sys/block/md~ArrayNummer~/md/mismatch_cnt
scrub.sh
#!/bin/sh # # Andreas Filsinger, scrub # DEV=md127 LOG=/root/scrub.log.txt # # Optional: Stop a Backup-Service # systemctl stop bak echo -n "md/mismatch_cnt=" >$LOG cat /sys/block/$DEV/md/mismatch_cnt >>$LOG mdadm --action=repair /dev/$DEV mdadm -W /dev/$DEV dmesg -T >>$LOG echo -n "md/mismatch_cnt=" >>$LOG cat /sys/block/$DEV/md/mismatch_cnt >>$LOG # # Optional: Start Backup Service # systemctl start bak #
Identifikation
- Machmal kann es schwierig sein die Platte zu identifizieren. Vorausgesetzt der Wechselrahmen hat eine Aktivitäts-LED kann mit folgendem Befehl für maximale (Lese-) Aktivität gesorgt werden. Ev. lässt sich so die Platte erkennen:
dd if=/dev/sdX of=/dev/null
Umzug
- Wenn möglich unmounten, um das Array definiert runterzufahren. Stromlos schalten.
- Das ganze Array einfach abklemmen, über die SATA-Host-Kanal-Kabel-Reihenfolge keine Gedanken machen.
- An den neuen Server anschliessen. Neu starten, im dmesg müsste über die Bildung eines neuen md-devices berichtet sein.
- die neue md-Partition mit dem richtigen Filesystem mounten.
ohne Journal
- sollte das RAID-Array über ein Journal abgesichert sein ist es nach einem Umzug nicht mehr direkt funktions-fähig
- Es gibt ein inaktives Array, stoppe dieses mit
mdadm --stop /dev/md127
- Kopiere dir den uuid des Arrays, wähle dazu ein beliebiges drive des Arrays
mdadm --examine /dev/sde1
- Zwinge Ihn das ARRAY zu aktivieren, obwohl das Journal fehlt
mdadm --assemble --force --uui 47:11:nnnnnnnnnnnnnnnnnnnnn:019 /dev/md0
- das Array steht Dir jetzt Read-Only zur Verfügung
- Du kannst nun das Array wieder schreibfhähig machen indem Du ein Bitmap oder ein Journal hinzufügst
ungetestet: mdadm --grow /dev/md0 (--bitmap=internal |--add-journal /dev/sda5 )
mit Journal
- das array war nicht aktiv, sda4 ist das bisherige journal / es wird im lsblk nicht mit md127 markiert
mdadm --run /dev/md127 mdadm /dev/md127 --add-journal /dev/sda4
Hot Plug
- Bei SATA ist Hotplug kein Feature irgendeiner extra Elektronik, sondern die Fähigkeit der Platten & Stecker selbst!
- Physikalisch sind die Kontaktzungen verschieden lang ausgeprägt, also elektrisch werden einige Kontakte später als andere erreicht, das ermöglicht ein stufenweises Hochfahren der Elektronik oder der Signalisierung. Also nicht die Kabel rein und raus wie ein wilder Stier, sondern schön langsam mit Gefühl. Dabei die Stecker immer plan aufstecken, nicht schief, an einer Ecke zuerst und dann reinwuchten. Du bist jetzt der Caddy, der sauber und plan einlochen sollte.
- Beim Anschluss einer neuen Platte: Zuerst Strom, dann Datenkabel dranstecken.
- Beim Ausbau einer alten Platte: Zuerst Datenkabel, dann Stromkabel abziehen.
Disk Fitness
- Besonders nach einem Rauswurf aus einem RAID Verbund stellt sich die Frage nach dem "wirklichen" Fitnesszustand einer Platte
- Ursächlich für den Rauswurf können auch mal reine Timing Probleme auf dem Datenweg von Platte zu md sein und dieser Weg ist lang
- Hier bräuchte man einen 48h Stress Test, aber mit nicht ausserordentlichem Stress sondern einer typischen MD Belastung
- Ev. könnte man auch einen "Full"-Write simulieren und danach 30% Write 70 % Read und mal sehen was passiert
- Das Datenmuster sollte sich auch der Schreib-Position ergeben, ein reproduzierbares Rauschen, da leicht überprüfbar ist
- Dabei könnte man ein Bitmap verwenden, so dass Write mal Pattern A und Pattern B schreibt damit der Schreib-Test nicht identische Daten schreiben muss
- Dabei würde auch das Bitmap Bit kippen wenn mal wieder in "diesen" Bereich geschrieben wird
- Ein Bit soll dabei für einen so minimalen Datenbereich stehen wie auch später md einen Block sieht
# # lass die Platte sich selbst testen # (meiner Erfahrung nach wenig Aussagekräftig) # smartctl --test long /dev/sda # # ready only test zum lesen aller Blocks # badblocks -sv /dev/sda1
Probleme und deren Lösung
- Im folgenden Fallbeispiele was alles in der Praxis schiefgehen kann
Ausfall eines Strom-Stranges
- Ich hatte einen Ausfall folgender Art: An einer Stromversorgung hingen 3 Platten: 2 eines RAID 6 Verbundes (zum Glück RAID 6!), und eine SSD. Die 2 magnetischen Platten waren plötzlich weg, die SSD jedoch noch da! Ich dachte erste an ein Problem an den beiden SATA Kabeln, aber es war ein Ausfall (Wackler) des 12 Stranges. Der SSD war das egal, da sie scheinbar nur den 5 Volt Part des Kabels benutzt (der 3.3 Volt Part war gar nicht angeschlossen! Früher war das mal Teil der Norm - heutzutage werden die 3.3 V nicht mehr benutzt). OK in der Panik habe ich eine der 2 Platten getauscht , mit dem Ergebnis dass diese nicht in dmesg sichtbar war. Ich kan nun auf die Idee mit den 12 Volt und konnte den Wackler beheben. Eigentlich sofort war die eine (alte) Platte nach einem --add wieder im Verbund, die neue Platte musse ich erst passend partionieren, dann mit --add, dann machte er einen resync.
(Folgendes Dokumentation bezieht sich auf "einfach mal eine Platte rausgezogen! Natürlich im laufenden Betrieb.")
- Das Dateisystem hat davon gar nix gemerkt, eigentlich ohne sichtbaren Performanche-Verlust weitergeschrieben
- Die mdadm --detail sah schon traurig aus:
Number Major Minor RaidDevice State 0 8 49 0 active sync /dev/sdd1 2 0 0 2 removed 2 8 81 2 active sync /dev/sdf1 4 8 17 3 active sync /dev/sdb1 5 8 33 4 active sync /dev/sdc1
- OK, einfach neue Platte rein.
- Im "dmesg" erkannt dass es als "/dev/sde" eingetragen wurde
- Das war so eine "recycelte Platte" mit 5 Partitionen, erst mal im Yast alle gelöscht und EINE grosse RAID Partition erstellt
- Ein einziger Befehl reichte, um das Array wieder komplett zu machen:
mdadm --manage /dev/md127 --add /dev/sde1
- Im mdadm --detail sah es nun besser aus:
Number Major Minor RaidDevice State 0 8 49 0 active sync /dev/sdd1 6 8 65 1 spare rebuilding /dev/sde1 2 8 81 2 active sync /dev/sdf1 4 8 17 3 active sync /dev/sdb1 5 8 33 4 active sync /dev/sdc1
- Nach 180 Minuten war wieder alles gut!
Ausfall eines Controllers
- Noch nicht abschliessend geklärt ist, ob ein Controller nicht mehr vom Kernel unterstützt wurde
- oder ob der Controller hardwaremäßig ausgefallen ist
- oder ob der PCIe Bus plötzlich defekt wurde
- 4 von 8 Platten eines RAID6 Arrays waren weg, das Array inaktiv
- Da das Array nicht wichtig war habe ich es neu erstellt
- "--run" brachte eher Probleme
- "--re-add" brachte letztendlich auch wieder ein inaktives Array
Grow wird verweigert
- Erster Versuche (ohne Erfolg)
# mdadm /dev/md127 --grow --raid-devices=8 mdadm: Failed to initiate reshape! unfreeze
- Zweiter Versuch (mit dem Erfolg)
# mdadm /dev/md127 --grow --raid-devices=8 --backup-file=/root/mdadm_backup-file mdadm: Need to backup 15360K of critical section..
Reshape hängt bei 0.0%
- reshape hängt bei 0.0% : Erst ein "Nachtreten" half
echo max > /sys/block/md127/md/sync_max
- nun erst gings los ...
resize2fs 100% CPU Usage
- bei einem System lief resize2fs über 24 Stunden bei 100% CPU auslastung ohne Fortschritt
- ich habe es abgebrochen, es ist eine fehlerhafte Version, zuvor natürlich backup
- LÖSUNG: ich habe das System per USB mit knoppix gebootet und die 3 folgenden Schritte durchgeführt
- In der Knoppix Leiste unten links Symbol "rotes 4er Terminal" (Terminator) starten
- Prüfe ob das RAID-Array erkannte wurde, schau nach "clean":
sudo mdadm --detail /dev/md0
- Bringe das Dateisystem in einen einwandfreien Zustand:
e2fsck -f /dev/md0
- Korrigiere die Grösse:
sudo resize2fs -f /dev/md0
- Prüfe ob das RAID-Array erkannte wurde, schau nach "clean":
- Menü->Abmelden->Neu Starten->Bootreihenfolge wieder wie früher
- Knoppix USB entnehmen
die 64bit - Falle des Ext4
- Ein ohne besondere Parameter frisch angelegtes ext4 Dateisystem hat einen grössen Beschränkubg von 16 TB. Erst das 64bit Flag, das beim Anlegen des Dateisystems gesetzt werden muss ermöglicht mehr als 16 TB. Es gibt keinen Weg ein befülltes 16 TB Dateisystem auf 64Bit zu migrieren.
- Partition Size
Number Start (sector) End (sector) Size Code Name 1 2048 7814035455 3.6 TiB FD00 primary
nach dem reshape kam
[72254.324630] md: md127: reshape done. [72256.830962] RAID conf printout: [72256.830966] --- level:6 rd:7 wd:7 [72256.830969] disk 0, o:1, dev:sde1 [72256.830970] disk 1, o:1, dev:sdd1 [72256.830972] disk 2, o:1, dev:sdc1 [72256.830973] disk 3, o:1, dev:sdb1 [72256.830975] disk 4, o:1, dev:sdg1 [72256.830976] disk 5, o:1, dev:sdf1 [72256.830977] disk 6, o:1, dev:sda1 [72256.830982] md127: detected capacity change from 8001301774336 to 20003254435840 [72259.591900] VFS: busy inodes on changed media or resized disk md127
also hatte ich anstelle der 8 TB nun 20 TB, dann kam der grosse Schock
1)
resize2fs /dev/md127 resize2fs 1.42.11 (09-Jul-2014) resize2fs: New size too large to be expressed in 32 bits
- Also der Resize ist NICHT möglich da bei der Erstellung des Filesystems die 64bit Option nicht gesetzt wurde.
2)
tune2fs -l /dev/md127 tune2fs 1.42.11 (09-Jul-2014) Filesystem volume name: <none> Last mounted on: /srv/smb/ra6 Filesystem UUID: 2fb00d07-5394-4bc5-8f7d-cdaf5ea90d17 Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize Filesystem flags: signed_directory_hash Default mount options: user_xattr acl Filesystem state: clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 244183040 Block count: 1953442816 Reserved block count: 0 Free blocks: 227623471 Free inodes: 236320173 First block: 0 Block size: 4096 Fragment size: 4096 Reserved GDT blocks: 558 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 4096 Inode blocks per group: 256 RAID stride: 128 RAID stripe width: 256 Flex block group size: 16 Filesystem created: Sun Nov 8 00:32:48 2015 Last mount time: Mon Mar 7 16:30:20 2016 Last write time: Mon Mar 7 16:30:20 2016 Mount count: 21 Maximum mount count: -1 Last checked: Sun Nov 8 00:32:48 2015 Check interval: 0 (<none>) Lifetime writes: 12 TB Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 256 Required extra isize: 28 Desired extra isize: 28 Journal inode: 8 Default directory hash: half_md4 Directory Hash Seed: 95862d26-1883-4880-b221-ee78f166846f Journal backup: inode blocks
- meine Lösung war: Daten sichern, mkfs neu machen mit der 64bit Option, Daten rücksichern
- Dokumentation entsprechend geändert!: IMMER DAS 64bit FEATURE SCHON VON ANFANG AN EINSCHALTEN AUCH BEI KLEINEN PARTITION BEI DENEN EIN WACHSEN ZU ERWARTEN IST
tune2fs 1.42.11 (09-Jul-2014) Filesystem volume name: <none> Last mounted on: /srv/smb/ra6 Filesystem UUID: f0362f20-bf7a-4e6b-9be3-9e3626488036 Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: has_journal ext_attr dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize Filesystem flags: signed_directory_hash Default mount options: user_xattr acl Filesystem state: clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 305225728 Block count: 4883607040 Reserved block count: 0 Free blocks: 4864141337 Free inodes: 305225717 First block: 0 Block size: 4096 Fragment size: 4096 Group descriptor size: 64 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 2048 Inode blocks per group: 128 RAID stride: 128 RAID stripe width: 640 Flex block group size: 16 Filesystem created: Tue Mar 8 15:31:09 2016 Last mount time: Tue Mar 8 15:41:14 2016 Last write time: Tue Mar 8 15:41:14 2016 Mount count: 1 Maximum mount count: -1 Last checked: Tue Mar 8 15:31:09 2016 Check interval: 0 (<none>) Lifetime writes: 165 MB Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 256 Required extra isize: 28 Desired extra isize: 28 Journal inode: 8 Default directory hash: half_md4 Directory Hash Seed: 7d24e40b-9935-4dec-8d4d-7dfa965f5942 Journal backup: inode blocks
/dev/md127 19T 1.3T 17T 8% /srv/smb/ra6
smartctl -all killt Platte
- Ich hatte mal einen Lesefehler in dmesg bei einer Platte gesehen
[7942108.409331] ata6.00: exception Emask 0x0 SAct 0x783f523f SErr 0x0 action 0x0 [7942108.409395] ata6.00: irq_stat 0x40000008 [7942108.409430] ata6.00: failed command: READ FPDMA QUEUED [7942108.409474] ata6.00: cmd 60/08:20:50:49:f4/00:00:6e:00:00/40 tag 4 ncq 4096 in res 41/40:08:51:49:f4/00:00:6e:00:00/00 Emask 0x409 (media error) <F> [7942108.409587] ata6.00: status: { DRDY ERR } [7942108.409619] ata6.00: error: { UNC } [7942108.437177] ata6.00: configured for UDMA/133 [7942108.437229] sd 5:0:0:0: [sdd] tag#4 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [7942108.437235] sd 5:0:0:0: [sdd] tag#4 Sense Key : Medium Error [current] [descriptor] [7942108.437239] sd 5:0:0:0: [sdd] tag#4 Add. Sense: Unrecovered read error - auto reallocate failed [7942108.437244] sd 5:0:0:0: [sdd] tag#4 CDB: Read(10) 28 00 6e f4 49 50 00 00 08 00 [7942108.437247] blk_update_request: I/O error, dev sdd, sector 1861503313 [7942108.437347] ata6: EH complete [7942110.787097] ata6.00: exception Emask 0x0 SAct 0x107ffc00 SErr 0x0 action 0x0 [7942110.787153] ata6.00: irq_stat 0x40000008 [7942110.787185] ata6.00: failed command: READ FPDMA QUEUED [7942110.787227] ata6.00: cmd 60/08:e0:50:49:f4/00:00:6e:00:00/40 tag 28 ncq 4096 in res 41/40:08:51:49:f4/00:00:6e:00:00/00 Emask 0x409 (media error) <F> [7942110.787332] ata6.00: status: { DRDY ERR } [7942110.787362] ata6.00: error: { UNC } [7942110.788892] ata6.00: configured for UDMA/133 [7942110.788965] sd 5:0:0:0: [sdd] tag#28 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [7942110.788970] sd 5:0:0:0: [sdd] tag#28 Sense Key : Medium Error [current] [descriptor] [7942110.788975] sd 5:0:0:0: [sdd] tag#28 Add. Sense: Unrecovered read error - auto reallocate failed [7942110.788979] sd 5:0:0:0: [sdd] tag#28 CDB: Read(10) 28 00 6e f4 49 50 00 00 08 00 [7942110.788983] blk_update_request: I/O error, dev sdd, sector 1861503313 [7942110.789050] ata6: EH complete [7942111.154860] md/raid:md127: read error corrected (8 sectors at 1861501264 on sdd1)
- Es hatte keinen negativen Einfluss auf den Betrieb (im Moment, also Ruhe bewahren) und ich schaute mir jedoch die Ausgabe von smartctl an. Es dauerte ein bissl bis zur Ausgabe (das wunderte mich schon, später wusste ich warum) ...
5 Reallocated_Sector_Ct 0x0033 095 095 036 Pre-fail Always - 221 ... Error 6 occurred at disk power-on lifetime: 35382 hours (1474 days + 6 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 00 ff ff ff 0f Error: UNC at LBA = 0x0fffffff = 268435455 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- 60 00 28 ff ff ff 4f 00 42d+03:24:48.491 READ FPDMA QUEUED 61 00 05 10 08 00 40 00 42d+03:24:48.491 WRITE FPDMA QUEUED ea 00 00 00 00 00 a0 00 42d+03:24:48.491 FLUSH CACHE EXT 60 00 08 ff ff ff 4f 00 42d+03:24:48.462 READ FPDMA QUEUED 60 00 28 ff ff ff 4f 00 42d+03:24:48.461 READ FPDMA QUEUED [mehrfach solche Fehler]
- Also der Platte gingen scheinbar die freien Sektoren zur Reallozierung aus, hui, höchste Zeit sie auf das Altenteil zu schicken!
- Deshalb habe ich eine Spare eingefügt und den "--replace" gestartet, damit sie frei wird zur Entnahme, der resync lief einwandfrei an!
- Ich wollte mit "smartctl --all /dev/sd~fail~" mal eben die Temperatur dieser schwächelnden Platte auslesen, Bumm, Absturz!
[ 5420.589752] ata6.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen [ 5420.594868] ata6.00: failed command: SMART [ 5420.599490] ata6.00: cmd b0/d0:01:00:4f:c2/00:00:00:00:00/00 tag 16 pio 512 in res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) [ 5420.608670] ata6.00: status: { DRDY } [ 5420.612996] ata6: hard resetting link [ 5424.853461] ata6: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [ 5425.020906] ata6.00: configured for UDMA/133 [ 5425.020925] ata6: EH complete
- Das führte dazu, dass die Platte aus dem RAID-Verbund als "fail" nun rausflog, der resync ging aber einfach weiter. (Super md-Software!!)
- Also einfach warten bis fertig, dann ist die Platte frei und bereit für den Schredder
Hinzufügen einer Platte zur Kapazitätserhöhung
- Im RAID6 dient die Kapazität von 2 Platten allein der Paritätsspeicherung (Die Parität ist dabei über alle Platten verstreut, die Aussage bezieht sich nur auf die Kapazitätsanforderungen der Parität).
- Ist diese feststehende Anforderung des RAID6 erfüllt, dient jede weitere Platte der echten Kapazitätserhöhung. Also ist ein Ausbau von 4 Platten auf 5 Platten besonders lukrativ.
- Alle folgenden Aktionen wurden im laufenden Betrieb durchgeführt (RAID6, bisher 4 Platten, ext4 ist die ganze Zeit gemounted).
- neue Platte, die eine Kapazität von >="device Size" haben muss hinzustecken
- im kernel log sehen ob die Platte sauber hinzugefügt wurde
dmesg
- Link Speed wie erwartet? In meinem Fall "6 Gbps"
- in meinem Fall war der neue Device /dev/sdf
Linux.raid#Partition erstellen
- Platte dem md bekanntmachen und dann dem Verbund einverleiben
mdadm --manage /dev/md0 --add /dev/sdf1
- Optional: Cache Size erhöhen (war bei mir nur 513 groß)
echo 32768 > /sys/block/md0/md/stripe_cache_size
mdadm /dev/md0 --grow --raid-devices=5 --backup-file=/root/mdadm_backup_4_devices
- das nun folgende und technisch notwendige "reshape" geht sehr lange (bei mir 18 Stunden) und man muss warten, bis die neue Kapazität zur Verfügung steht
- bleibt das reshape bei 0.0% stehen siehe Kapitel "Ausfall"
- Man erfährt es, dass er fertig ist z.B. über
dmesg
[159744.821671] md: md0: reshape done. [159746.036346] RAID conf printout: [159746.036349] --- level:6 rd:5 wd:5 [159746.036351] disk 0, o:1, dev:sdb1 [159746.036352] disk 1, o:1, dev:sdd1 [159746.036352] disk 2, o:1, dev:sde1 [159746.036353] disk 3, o:1, dev:sdc1 [159746.036354] disk 4, o:1, dev:sdf1 [159746.036357] md0: detected capacity change from 4000527155200 to 6000790732800
- erst danach das Dateisystem (kann gerne gemounted bleiben!) erweitern
resize2fs /dev/md0
Vorsorglicher Austausch einer Platte
Vorarbeiten
- Es ist von Vorteil, wenn man eine weitere SATA- Schnittstelle im System frei hat (Oder man will ein existierendes Spare zum neuen Array-Mitglied machen). An diesen neuen Port hängt man die neue Platte. In
dmesg -T
steht drin wie der device-Name ist (Bei- Hotswap Einbau). Nach dem Neustart schaut man mit hwinfo --disk wie der Devicename von Linux für die neue Platte vergeben wurde (Oder bei Hotswap mit dmesg). - Man muss wissen dass bei einem planmäßigen Ersatz die Ausbau- Platte komplett gelesen wird, die Zielplatte mit deren Inhalt beschrieben. Der Vorgang wird nicht durch Lesen des ganzen Stripes abgesichert. Das entlastet zwar den laufenden Betrieb ist aber auch etwas unsicher, da negative Veränderungen mitkopiert werden. Zuvor sollte ein Scrub durchgeführt werden (oder direkt danach), da wir der ausgemusterten Platte 100% vertrauen müssen.
- Idee: Teamup: Dies wäre ein Vorgang bei dem die neue Platte schleichend die Rolle der ausgemusterten Platte übernimmt, aber immer abgesichert durch P/Q. Alle Ws gehen auf beide Platten, R- Zugriffe werden ev. bereits aufgeteilt, ein Bitmap wie weit er ist wird geführt.
- Die neue Platte: Eine maximal grosse Linux-RAID Partition erstellen Linux.raid#Partition_erstellen
- Die neue Partition der neuen Platte muss man bekannt machen
mdadm /dev/md0 --add-spare /dev/sdd1
Kopie auf neue Platte
- Die alte Partition muss ausgetauscht werden
mdadm /dev/md0 --replace /dev/sde1 --with /dev/sdd1
- Nun erfolgt die resync-Phase
watch -n.4 'cat /proc/mdstat'
Personalities : [raid6] [raid5] [raid4] md0 : active raid6 sdd1[4](R) sdc1[1] sde1[2] sdb1[0] sdf1[3] 976504832 blocks super 1.2 level 6, 512k chunk, algorithm 2 [4/4] [UUUU] [==========>..........] recovery = 53.3% (260476332/488252416) finish=59.5min speed=63787K/sec bitmap: 0/4 pages [0KB], 65536KB chunk unused devices: <none>
- Er macht vom "replace"-Drive (sdb1-RRR) eine Kopie nach "spare"-Drive (sdd-WWW)
- Man erkennt dass RAID-Device "2" (rot) durch "2" (grün) ersetzt wird
mdadm --detail /dev/md0
/dev/md0: Version : 1.2 Creation Time : Wed Jan 28 22:47:57 2015 Raid Level : raid6 Array Size : 976504832 (931.27 GiB 999.94 GB) Used Dev Size : 488252416 (465.63 GiB 499.97 GB) Raid Devices : 4 Total Devices : 5 Persistence : Superblock is persistent Intent Bitmap : Internal Update Time : Mon Mar 30 17:49:32 2015 State : active, recovering Active Devices : 4 Working Devices : 5 Failed Devices : 0 Spare Devices : 1 Layout : left-symmetric Chunk Size : 512K Rebuild Status : 55% complete Name : raib23:0 (local to host raib23) UUID : a9b9721a:7da8602e:313975c3:10fa337e Events : 5132 Number Major Minor RaidDevice State 0 8 17 0 active sync /dev/sdb1 1 8 33 1 active sync /dev/sdc1 2 8 65 2 active sync /dev/sde1 4 8 49 2 spare rebuilding /dev/sdd1 3 8 81 3 active sync /dev/sdf1
- Beobachte während des Resync die Temperatur aller Platten.
- Dies mache ich durch folgendes Script:
#!/bin/bash echo "b:" smartctl -A /dev/sdb | grep "Temperature_Celsius " smartctl -A /dev/sdb | grep "Power_On_Hours " echo "c:" smartctl -A /dev/sdc | grep "Temperature_Celsius " smartctl -A /dev/sdc | grep "Power_On_Hours " echo "d:" smartctl -A /dev/sdd | grep "Temperature_Celsius " smartctl -A /dev/sdd | grep "Power_On_Hours " echo "e:" smartctl -A /dev/sde | grep "Temperature_Celsius " smartctl -A /dev/sde | grep "Power_On_Hours " echo "f:" smartctl -A /dev/sdf | grep "Temperature_Celsius " smartctl -A /dev/sdf | grep "Power_On_Hours " echo "g:" smartctl -A /dev/sdg | grep "Temperature_Celsius " smartctl -A /dev/sdg | grep "Power_On_Hours " echo "h:" smartctl -A /dev/sdh | grep "Temperature_Celsius " smartctl -A /dev/sdh | grep "Power_On_Hours "
- Kommt es zu Temperaturen>=50°C sollte man einschreiten
190 Temperature_Celsius 0x0032 071 056 000 Old_age Always - 29
190 Temperature_Celsius 0x0022 072 072 045 Old_age Always - 28 (Min/Max 26/28)
190 Temperature_Celsius 0x0022 071 069 045 Old_age Always - 29 (Min/Max 28/29)
190 Temperature_Celsius 0x0022 055 048 045 Old_age Always - 50 (Min/Max 45/51)
190 Temperature_Celsius 0x0022 062 059 045 Old_age Always - 38 (Min/Max 38/41)
- Vermindere die Sync-Leistung massiv ggf. so lange bis die Platten wieder unter 45 Grad sind, durch
# # ermittle zunächst die aktuelle sync Leistung # cat /sys/block/md0/md/sync_speed # # schreibe deinen wesentlich kleineren Wert in die speed Obergrenze # echo 5000 > /sys/block/md0/md/sync_speed_max # alternativ # # sysctl -w dev.raid.speed_limit_max=5000
es wird wohl schwer sein ein gutes Mittelmass zu finden, bei mir war es
echo 60000 > /sys/block/md0/md/sync_speed_max
Full speed ist ja
echo 200000 > /sys/block/md0/md/sync_speed_max
- Erst nachdem der Resync durch ist, steht die auszubauende Platte auf (F)
# cat /proc/mdstat Personalities : [raid6] [raid5] [raid4] md0 : active raid6 sdd1[4] sdc1[1] sde1[2](F) sdb1[0] sdf1[3] 976504832 blocks super 1.2 level 6, 512k chunk, algorithm 2 [4/4] [UUUU] bitmap: 0/4 pages [0KB], 65536KB chunk unused devices: <none>
# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Wed Jan 28 22:47:57 2015
Raid Level : raid6
Array Size : 976504832 (931.27 GiB 999.94 GB)
Used Dev Size : 488252416 (465.63 GiB 499.97 GB)
Raid Devices : 4
Total Devices : 5
Persistence : Superblock is persistent
Intent Bitmap : Internal
Update Time : Mon Mar 30 18:59:42 2015
State : active
Active Devices : 4
Working Devices : 4
Failed Devices : 1
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 512K
Name : raib23:0 (local to host raib23)
UUID : a9b9721a:7da8602e:313975c3:10fa337e
Events : 5136
Number Major Minor RaidDevice State
0 8 17 0 active sync /dev/sdb1
1 8 33 1 active sync /dev/sdc1
4 8 49 2 active sync /dev/sdd1
3 8 81 3 active sync /dev/sdf1
2 8 65 - faulty /dev/sde1
Abschluss
- Nun muss man dieses "faulty" device noch aus dem Array entfernen
mdadm /dev/md0 --remove /dev/sde1
- Die Platte selbst trägt noch die Signatur für dieses RAID-Array, um Verwirrung auszuschliessen sollte der Superblock gelöscht werden
mdadm --zero-superblock /dev/sde1
- Wer will kann die Platte vor dem Entsorgen noch komplett nullen, andernfalls sollte die Platte mechanisch zerstört werden
shred -v -z --iterations=0 /dev/sde
- Nun sollte man wenn möglich wieder für ein spare sorgen
- Nun sollte man ein scrub machen um Sicherzustellen dass das neue drive die Daten auch wirklich speichern konnte!
- Erst jetzt ist das vorsorgliche austauschen eines Drives abgeschlossen
RAID insgesamt vergrößern
- Im obigen Schritt habe ich EINE Platte ausgetauscht. Es ist somit möglich ALLE 512 GB Platten Schritt für Schritt durch 2 TB Platten zu ersetzen. Es gab immer ein "reboot" weil ich Platten entfernen und neue anklemmen musste - aber niemals war ein unmount des Dateisystems nötig.
- NAchdem alle Platten neu sind, und auch alle neuen Platten ein "maximale" Partition ausweisen kann man die Kapazität erhöhen
- Auch für die folgenden Schritte war kein unmount nötig - alles erfolgte "online" mit ext4 gemountet!
- mdadm --grow ausführen, um das Array wachsen zu lassen
mdadm --grow /dev/md0 --size=max
- SOFORT kann man das Dateisystem vergrössern
resize2fs /dev/md0
- Nun noch beobachten was der "grow" verursacht. ext4 merkt davon nix.
watch -n.4 'cat /proc/mdstat'
Every 0.4s: cat /proc/mdstat Wed Apr 1 00:15:16 2015 Personalities : [raid6] [raid5] [raid4] md0 : active raid6 sdd1[7] sdc1[4] sdb1[5] sdf1[6] 3906764800 blocks super 1.2 level 6, 512k chunk, algorithm 2 [4/4] [UUUU] [=====>...............] resync = 29.3% (573007872/1953382400) finish=327.4min speed=70255K/sec bitmap: 3/4 pages [12KB], 262144KB chunk unused devices: <none>
RAID5 nach RAID6 Migration
- Ich hatte 4x 1 TB Festplatten im RAID5 Verbund
Personalities : [raid6] [raid5] [raid4]
md127 : active (auto-read-only) raid5 sdd1[0] sdf1[1] sdb1[4] sde1[2]
2930277888 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]
unused devices: <none>
- Hole dir eine weitere passende Platte (auch wenn es schon 4 Platten sind, was ja die Mindestanforderung ist bei RAID6, braucht RAID6 die neue Platten zwingend für die zusätzliche Parität "Q", die neben der Parität "P" erstellt wird).
- mit yast eine maximale Partition erstellen
- mdadm /dev/md127 --manage --add /dev/sdc1
Personalities : [raid6] [raid5] [raid4]
md127 : active raid5 sdc1[5](S) sdd1[0] sdf1[1] sdb1[4] sde1[2]
2930277888 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]
unused devices: <none>
- mdadm /dev/md127 --grow --level=6 --raid-devices=5
Personalities : [raid6] [raid5] [raid4]
md127 : active raid6 sdc1[5] sdd1[0] sdf1[1] sdb1[4] sde1[2]
2930277888 blocks super 1.2 level 6, 512k chunk, algorithm 18 [5/4] [UUUU_]
[=>...................] reshape = 5.7% (55685504/976759296) finish=248.1min speed=61864K/sec
unused devices: <none>
- Resize des Dateisystems?
- resize2fs /dev/md127
- Ich Dussel! Ich habe durch die Migration doch gar keinen neuen Platz gewonnen, das war mehr so ein Reflex, da ich ja eine neue Platte hinzugefügt habe. Auf meinen Resize-Versuch sagt Linux richtigerweise:
resize2fs 1.42.11 (09-Jul-2014)
The filesystem is already 732569472 blocks long. Nothing to do!
- Wir haben jetzt laut Händlerangabe 5 Terra-Byte. Doch wieviel davon ist im ext4-Dateisystem nun verfügbar? Durch den RAID 6 Level sind das reale 2,7 Terra-Byte.
- Das Bild zeigt den ganzen Vorgang wie ihn dmesg gesehen hat. Es beginnt also mit der neuen Partition sdc1, die aber zunächst als "Spare" in dem Array vorhanden ist.
- Bei der Migration merkt er, ok ich muss einen reshape durchführen
RAID abwickeln
- Ich hatte eine "alte" Platte in einen Linux Server eingehängt (sde), schwups hatte der einen RAID Verbund (hihi mit nur einer Platte!) erkannt (Name war "md126", md127 hatte seine Berechtigung in diesem System!). OK, er hatte es als inaktiv erkannt, aber ...
- Ich wollte die RAID markierung entfernen:
mdadm --stop /dev/md126 mdadm --zero-superblock /dev/sde1
Spares hinzufügen
- Spare erhöhen nicht die Kapazität sondern werden automatisch aktiv wenn eine Platte einen Aussetzer hat und ausgehängt werden muss, oder nicht startet
- Man erhöht durch Spares die Zeit bis man dringend eingereifen muss, ein RAID Verbund kann so länger wartungsfrei laufen
- Ich habe das noch nie erlebt, Daumen drücken das dies mir mal passiert (ohne Probleme!)
- Ich habe einem RAID6 Verbund aus diesem Grund mal 2 Spares spendiert
mdadm /dev/md127 --add-spare /dev/sde1 mdadm /dev/md127 --add-spare /dev/sdg1
- das sieht danach so aus:
/dev/md127: Version : 1.2 Creation Time : Wed Jan 28 22:47:57 2015 Raid Level : raid6 Array Size : 5860147200 (5588.67 GiB 6000.79 GB) Used Dev Size : 1953382400 (1862.89 GiB 2000.26 GB) Raid Devices : 5 Total Devices : 7 Persistence : Superblock is persistent Intent Bitmap : Internal Update Time : Fri Feb 9 17:26:45 2018 State : clean Active Devices : 5 Working Devices : 7 Failed Devices : 0 Spare Devices : 2 Layout : left-symmetric Chunk Size : 512K Name : raib23:0 UUID : a9b9721a:7da8602e:313975c3:10fa337e Events : 13326 Number Major Minor RaidDevice State 5 8 49 0 active sync /dev/sdd1 6 8 81 1 active sync /dev/sdf1 4 8 17 2 active sync /dev/sdb1 7 8 1 3 active sync /dev/sda1 8 8 33 4 active sync /dev/sdc1 9 8 65 - spare /dev/sde1 10 8 97 - spare /dev/sdg1
md127 : active raid6 sdg1[10](S) sde1[9](S) sdf1[6] sdd1[5] sdb1[4] sdc1[8] sda1[7] 5860147200 blocks super 1.2 level 6, 512k chunk, algorithm 2 [5/5] [UUUUU] bitmap: 0/4 pages [0KB], 262144KB chunk unused devices: <none>
Strom sparen mit den Spares
- Status abfragen:
smartctl -i -n standby /dev/sdg
hdparm -C /dev/sdg
- Schlafen legen:
hdparm -y /dev/sdg
hdparm -S 10 -y /dev/sdg
- die Automatisierung via systemd erfolgt "so": Linux.systemd#einzelne_Festplatten_in_den_Standby
Spares entfernen
- Hier sind keine Vorarbeiten nötig, einfach "remove"
mdadm /dev/md127 --remove /dev/sdd1
Begriffe
- Block
- Blocksize
- Superblock
- Stripe
- Stride
- Chunk
- Bitmap
- Journal
- Device
Benchmarks
Also hier die Messergebnisse mit einem per 1GBit-LAN angebundenen Windows 7 Client. Das Netzwerk ist hier wohl das Limitierende Element.
reale Umsetzungen
- Produktiv Server "raib42" RAID6-2015
- Backup Server "raib2" RAID6-2016
- Produktiv Server "raib23" RAID6-2017 (death 2021)
- Produktiv Server "tokio" RAID6-2018
- Backup Server "backup" RAID6-2020
- Spare Server "raib80" RAID6-2021
- Spare Mainboard+OS RAID6-ratingen
- Grey Server RAID6-osgiliath
- Ideensammlung RAID6-20p