Linux.raid

"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
  • 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

• 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?

• https://git.kernel.org/pub/scm/linux/kernel/git/song/md.git/log/?h=md-next

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:
  • 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

• 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

• 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

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

1. Wenn möglich unmounten, um das Array definiert runterzufahren. Stromlos schalten.
2. Das ganze Array einfach abklemmen, über die SATA-Host-Kanal-Kabel-Reihenfolge keine Gedanken machen.
3. An den neuen Server anschliessen. Neu starten, im dmesg müsste über die Bildung eines neuen md-devices berichtet sein.
4. 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

• 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

Ideen

emde

Links

• 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