Linux.raid: Unterschied zwischen den Versionen

Version vom 10. November 2020, 13:30 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 werden rotierend angeordnet damit keine reinen Paritätsplatten entstehen

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.
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)

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 : http://cargobay.orgamon.de/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
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

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 )

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 ...

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

Dazu ist es von Vorteil, wenn man eine weitere SATA Schnittstelle im System frei hat. An diesen neuen Port hängt man die neue Platte. 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).

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

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

Nun muss man dieses 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 --action=repair 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

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
Produktiv Server "tokio" RAID6-2018
Backup Server "backup" RAID6-2020

Ideen

emde

@@ Zeile 596: / Zeile 596: @@
 ==== ohne Journal ====
-* sollte das RAID-Array über ein Journal abgesichert sein ist es nach einem Umzug nicht direkt funktions-fähig
+* 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