Linux.raid

Aus OrgaMon Wiki
Zur Navigation springen Zur Suche springen

"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 im Hauptspeicher 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!)

... oder Journal

November 2020: das einrichten eines Journals ist mir noch nicht gelungen

--bitmap=none --consistency-policy=journal --write-journal
  • Das Journal ist 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

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

N/A

  • Super - Aber nicht verfügbar
  • Folgende Marvell Spec sind interessant, wird aber nicht produziert
  • 88SE9345 PCIe 2.0 x4 -> 4x SATA 6 Gbps
  • 88SE1475 PCIe 3.0 x8 -> 16x SATA 6 Gbps
  • 88SE1337 PCIe 3.0 x4 -> 8x SATA 6 Gbps
  • Doch verfügbar? Bitte eMail an mich: -> andreas(.)filsinger(@)orgamon(.)org

StarTech PEXSAT32

DC-624e RAID

MegaRAID® SAS 9271-4i

MegaRAID® SAS 9270-8i

MegaRAID® SAS 9271-8i

HighPoint RocketRaid 640L

  • (RR640L, 88SE9230 laut Prospekt, in Wirklichkeit 88SE9235)
  • (RR640L, Marvell 88SE9235)
    • identisches Board-Layout im Vergleich zu R640L, jedoch mehr Bestückung:
    • onboard Buzzer
    • Nuvoton Microcontroller
    • I2C Bus Jumper
    • diverse Probleme:
      • Bootet nicht mehr bei 2 Boards, musste auf einem alten Board teste
      • weder im nonRAID noch in RAID Modus wird es von Linux erkannt
      • openSUSE Treiber greifen fix auf eine bestimmte Kernel-Version zu, setup misslingt
    • Fazit: Unbrauchbar


syba SI-PEX40062

  • (Marvell 88SE9235, NonRAID)

88SE9230

https://www.aliexpress.com/item/33013809220.html?spm=a2g0o.productlist.0.0.799340a7JCEMxZ&algo_pvid=0d1fa1bf-ea0c-4db0-ba12-1c3b0583135e&algo_expid=0d1fa1bf-ea0c-4db0-ba12-1c3b0583135e-0&btsid=5b08ed0d-515a-4809-affd-f6f78911c19b&ws_ab_test=searchweb0_0,searchweb201602_3,searchweb201603_55

SY-PEX40096

  • 4x SATA

IO Crest SI-PEX40062

  • (Marvell 88SE9235, NonRAID)

IO Crest SI-PEX40057

IO-PCE9235-4I

  • (Marvell 88SE9235, NonRAID, 2x Lane)

IO-PCE9215-4I

  • (Marvell 88SE9215, NonRAID, 1x Lane)

Exsys EX-3508

  • PCIe - 1x Slot - 1 Lane -> 8x SATA (Silicon Image SIL3132)
  • Läuft direkt unter Linux ohne Problem
  • Er hat 2 "echte" SATA-Ports a 3 Gb/s, diese werden auf 4 Ports per "Port Multiplier" gemultiplext also nominal 1.5 GB/s, effektiv weniger
  • Testergebnis: Funktioniert - jedoch die einzelnen Platten können nur langsam angesprochen werden

Exsys EX-3516

  • PCIe - 2.0 2x -> 4x SATA (Marvell 88SE9230)
  • Läuft direkt unter Linux ohne Problem
  • Erkennt alle Platten mit 6 Gbps
  • Ein Jumper deaktiviert das BIOS (was ja in meinem Fall sinvoll wäre), wenn man aber beim Linux Betrieb auf das BIOS verzichtet wird die Karte überhaupt nicht mehr erkannt
  • In Ruhe ist per LED und per Geräusch aktivität an den Platten zu bemerken, keine Ahnung was der hier macht (hat nix mit md zu tun!!!)
  • (Fazit: Durchgefallen)

Exsys EX-3517

HighPoint Rocket 640L

  • (Marvell 88SE9230)
  • komisch, auf dem Marvell Chip steht 88SE9230 es sollte aber laut Marvell ein 88SE9235 sein?! Es ist scheinbar so, dass Marvel hier die Politik geändert hat (nonRAID=88SE9230, RAID=88SE9235)
  • Tatsache ist dass das Board-Layout zwischen RR640L und RR640L völlig identisch ist.
  • Läuft direkt unter Linux ohne Problem
  • Erkennt alle Platten mit 6 Gbps
  • Nicht mehr BIOS als notwendig, keine LEDs, keine Jumper
  • ca. 90 Euro
  • Fazit: Testsieger (2. Platz)
  • 29.10.2016: Ausfall des Controllers, ev. auch verursacht durch Update auf openSuSE 42.2
    • die 4 (der 8) angeschlossenen Disks wurden aus dem Array rausgeworfen
    • das Array wurde auf "inactive" gesetzt
    • nach "--run" kamen i/o Errors!

Adaptec HBA 1000-8i

  • 3. Gen PCIe 8x
  • 2 Ports á 4x SATA á 3 Gbp/s
  • 2 Ports á 12 Gbp/s
  • Muss aktiv angeblassen / gekühlt werden sonst wird sie zu heiss
  • Funktioniert nativ unter Linux openSUSE 41.2
  • Fazit: solide
  • Im Testlauf: Einfach mal eine Festplatte verloren und rausgeschmissen, Es ist noch nicht klar, ob ein Defekt der Platte vorliegt.

Startech PEXSAT34RH

Starline ARC-1330-8i

  • 2x SFF-8643 -> 8x SATA
  • PCIe 3.0 x8 lanes
  • geringe Wärmeentwicklung
  • ca. 220 Euro
  • würde ich gerne mal testen, ev. ist unter Linux eine Treiberinstallation notwendig?!
  • Chipsatz 88SE1485

Supermicro AOC-SAS2LP-MV8

ASUS PIKE ll 3008-8i

Fujitsu PRAID CP400i

LSI Logic SAS 9217-8i

  • Anbieter: Dell, HP,

LSI Logic SAS 9211-8i

  • 2. Gen PCI-Express 8x
  • Anbieter: 10Gtek

LSI Logic SAS 9200-8i

  • 2. Gen PCI-Express 8x
  • Anbieter: 10Gtek

Hybrid

Hersteller unbekannt

  • im Test seit 20.12.2019
  • Sporadische Hänger eines Supermicro Boards beim Cold/Warm Boot, bleibt hängen bei "15"

Hersteller unbekannt

  • im Test seit 20.12.2019
  • Sporadische Hänger eines Supermicro Boards beim Cold/Warm Boot, bleibt hängen bei "15"

Ziyituod

  • im Test seit 24.04.2020

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

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

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

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
#!/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.


  • Umzug von Kernel 3.0.101-95 nach 3.4.63-2.44 ist ohne Probleme gelungen
  • Umzug von Kernel 3.4.63-2.44 nach Kernel 4.1.10-1 ist ohne Probleme gelungen

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

Benchmarks

Also hier die Messergebnisse mit einem per 1GBit-LAN angebundenen Windows 7 Client. Das Netzwerk ist hier wohl das Limitierende Element.

reale Umsetzungen

Ideen

emde

Links

Abgerufen von „https://wiki.orgamon.org/index.php?title=Linux.raid&oldid=29887“