Schlagwort-Archive: Dateisystem

Homeserver 18: Das RAID erweitern

Mein RAID läuft ja als RAID 5. Ich habe das RAID mit der Mindestanzahl von drei Festplatten erstellt. Somit war ich in der Lage, den Server bereits zu nutzen, da ich ja schon Daten auf ihm lagern kann. Mein Time Machine Backup läuft darauf, Daten werden Stück für Stück kopiert und später kommen noch Webserver-Daten dazu.

Der Server war aber von Anfang an für ein wesentlich größeres RAID ausgelegt. Denn nicht nur für mich, sondern auch für den Rest meiner Familie, dient der Server als Datenablage. Und da kommt bei HD-Camcordern und hochauflösenden Digitalkameras so einiges an Daten zusammen. Das RAID wird jetzt also, je nach Bedarf, erweitert.

Vorher

Schauen wir uns doch mal an, wie viel Speicherplatz wir auf dem RAID gerade haben. Dazu benutze ich den Befehl „df“, kann man sich gut mit „Disk Free“ als Eselsbrücke merken. 🙂

df -h /raid1

Das vorangestellte sudo ist hier nicht nötig. Der Parameter -h sorgt dafür, dass die Ausgabe für Menschen lesbar wird. Sonst bekommen wir monströse Zahlen, die nur die Dateisystemblöcke angeben. Rechnen dürfen wir dann selber… Und zum Schluss das Verzeichnis /raid1, an dem ja unser RAID angedockt ist. Die Ausgabe sieht dann so aus:

Filesystem      Size  Used Avail Use% Mounted on
/dev/md0        7.3T  4.4T  2.9T  62% /raid1

Sagt doch eigentlich alles, oder? Um die 62 % sind schon belegt, weil ich schon mit dem Kopieren der Daten angefangen habe. Ich werde aber nicht fertig, weil mir der Speicherplatz nicht ausreichen wird, das weiß ich jetzt schon. Die Zahl, die für uns jetzt interessant ist, ist die Zahl unter Size, also 7,3T (Terrabyte). Nur, damit wir später den Unterschied sehen.

RAID Erweitern

Jetzt werde ich dem RAID also zwei Festplatten hinzufügen. Wieso gerade zwei? Nun, eine, damit ich alle Daten von meinem QNAP NAS kopieren kann. Danach wird das QNAP NAS nicht mehr benötigt. Dort steckt aber schon eine ST4000VN000 drin, weil ich ursprünglich dessen RAID neu anlegen wollte. Später habe ich mich dann aber für den Bau dieses Servers entschieden. Diese Festplatte nehme ich dann natürlich aus dem NAS raus und baue sie in meinen Server ein. Hier wird nix verschwendet… 🙂

Festplatten vorbereiten

Genau so, wie ich im Teil 12 beschrieben habe, müssen nun die neuen Festplatten partitioniert werden. Das sind dann die Laufwerke /dev/sde und /dev/sdf. Insbesondere bei der Festplatte, die ich aus dem QNAP NAS rausgenommen habe muss ich darauf achten, dessen Partitionstabelle mit O zu löschen und mit einer leeren zu überschreiben. Danach läuft alles wie bisher ab, Partition erstellen, Typ auf FD00 stellen und Daten mit W auf die Platten schreiben.

Festplatten in den RAID-Verbund aufnehmen

Dies passiert in mehreren Schritten. Laut einer Webseite im Internet ist es möglich, den Prozess auch mit mehreren Festplatten gleichzeitig durchzuführen. Das ist mir auch lieber, weil ich sonst für jede Festplatte erst warten müsste, bis der Synchronisationsvorgang abgeschlossen ist. Das kann Tage dauern. Die Wartezeit halbiert sich quasi, wenn man das nur ein mal tun muss… Ich Probiere es mal, falls es nicht klappt, dann halt einzeln.

Um die nun partitionierten Festplatten in den RAID-Verbund aufzunehmen, nutze ich diesen Befehl:

sudo mdadm --add /dev/md0 /dev/sde1 /dev/sdf1

Mit dem Parameter --add wird MDADM mitgeteilt, dass nun neue Festplatten hinzugefügt werden, nämlich dem RAID-Verbund /dev/md0. Und die Platten sind /dev/sde1 und /dev/sdf1.

Wir können uns auch gleich angucken, ob das zumindest schon mal geklappt hat, indem wir uns mal die mdstat angucken. Die sieht nach dieser Aktion nämlich so aus:

Personalities : [raid6] [raid5] [raid4] 
md0 : active raid5 sdf1[6](S) sde1[5](S) sdb1[0] sdd1[3] sdc1[4]
      7813772544 blocks super 1.2 level 5, 128k chunk, algorithm 2 [3/3] [UUU]

unused devices: <none>

Wie ihr jetzt sehen könnt, sind die Platten sde1 und sdf1 als Spares, also als Ersatzplatten hinzugefügt worden. Daher steht neben diesen Platten ein S in Klammern. Würde jetzt eine der ursprünglichen aktiven Platten ausfallen, würde MDADM sofort eine der Ersatzplatten nehmen, um das RAID wiederherzustellen. Das will ich ja nicht, also muss ich jetzt das RAID auf die beiden zusätzlichen platten erweitern.

RAID vergrößern

Der Grow-Modus von MDADM kann ziemlich viel. Man kann viele Parameter des RAIDs ändern. Wenn man z. B. merkt, die Chunk-Size von 128K ist zu klein, könnte man sie auf 512K erweitern oder sogar auf 64K verkleinern. Auch ein Wechsel des RAID-Level wäre möglich. Das will ich jetzt gar nicht machen, ich will die Anzahl der an dem RAID beteiligten Platten erhöhen.

sudo mdadm --grow /dev/md0 --raid-devices=5

Zuvor waren es ja 3, nun habe ich es auf 5 Platten erweitert. Die Platten sind bereits im Verbund, also erweitert MDADM das RAID auf die Spares, die schon hinzugefügt wurden.

MDADM fängt sofort damit an, das RAID auf die zusätzlichen Platten auszuweiten. Das kann man an der mdstat-Datei gut sehen, die jetzt so aussieht:

Personalities : [raid6] [raid5] [raid4] 
md0 : active raid5 sdf1[6] sde1[5] sdb1[0] sdd1[3] sdc1[4]
      7813772544 blocks super 1.2 level 5, 128k chunk, algorithm 2 [5/5] [UUUUU]
      [>....................]  reshape =  0.0% (927744/3906886272) finish=2565.2min speed=25377K/sec

unused devices: <none>

Das kann jetzt eine gehörige Zeit dauern. MDADM verteilt die Daten und ihre Wiederherstellungsinformationen jetzt auf die 5 Platten. Hierbei müssen eine ganze Menge Daten bewegt werden.

Die ersten paar Sekunden sind kritisch. Fällt jetzt der Strom aus, oder sonst irgendwas passiert, ist das RAID futsch. Das sind, wie gesagt, nur die ersten paar Sekunden, so um die 5 bis 10. Danach ist das RAID wieder ausfallsicher. Man könnte jetzt den Rechner sogar herunterfahren, und MDADM würde nach dem Einschalten dort weitermachen. Ich lasse ihn aber mal durchlaufen, der Prozess dauert so schon lange genug.

Auch auf die Daten kann man zugreifen. Aber auch hier, jeder Zugriff verlangsamt die Rekonstruktion des RAIDs. Und fertig sind wir ja noch nicht, es müssen noch ein paar Dinge erledigt werden. Dies können wir aber erst machen, wenn das RAID fertig ist mit Daten Umverteilen.

Man kann sich den Fortschritt des Reshape auch ganz bequem anschauen, ohne dass man ständig die mdstat-Datei aufrufen muss. Hierfür gibt es den Watch-Befehl. Der Aufruf sähe so aus:

watch cat /proc/mdstat

Das Terminal-Fenster wird jetzt komplett geleert und die mdstat-Datei angezeigt. Alle zwei Sekunden wird die Anzeige aktualisiert. Die Anzeige der Datei unterbricht man mit STRG+C, somit steht man wieder im Terminal-Fenster und kann weitere Befehle eingeben.

Natürlich macht es keinen Sinn, sich den Fortschritt die ganze Zeit anzugucken, aber wenn man mal über eine Minute sich anschauen will, was da passiert, ist das eine bequemere Lösung, als die Datei ständig immer wieder aufzurufen.

Dateisystem anpassen

Na, das hat ja mal richtig lange gedauert! Anfänglich sah es so aus, als bräuchte er ganze 2 Tage, aber so ab 50 % hat er mal so richtig Gas gegeben und war schon in 1,5 Tagen fertig.

Wir sind aber noch lange nicht fertig damit, das RAID zu erweitern. Bis eben noch sah die 3. Zeile von mdstat so aus:

      7813772544 blocks super 1.2 level 5, 128k chunk, algorithm 2 [5/5] [UUUUU]

Erst, seit der Prozess ganz fertig ist, steht die volle Größe zur Verfügung. Jetzt sieht die Zeile so aus:

      15627545088 blocks super 1.2 level 5, 128k chunk, algorithm 2 [5/5] [UUUUU]

Noch steht uns die volle Kapazität aber nicht zur Verfügung, da müssen wir noch einiges tun.

Dateisystem erweitern

Zwar hat das RAID jetzt eine höhere Kapazität, das Dateisystem ist weiterhin auf 7,3T. Wir haben quasi das bestehende Dateisystem von 3 auf 5 Platten verteilt. Also muss es auf die volle Kapazität erweitert werden.

Um die folgenden Schritte gefahrlos für Daten ausführen zu können, werde ich das Dateisystem aushängen. Dies geht mit folgendem Befehl:

sudo umount /dev/md0

Es könnte sein, dass umount den Dienst verweigert, weil das Dateisystem angeblich noch in Benutzung ist. Dies passiert vor allem dann, wenn man mit seinem Windows-Rechner verbunden war. Um das Problem zu lösen, kann man einfach vorübergehend den Samba-Service stoppen:

sudo service samba stop

Dann sollte auch das Aushängen klappen.

Um Problemen vorzubeugen, werde ich zunächst das Dateisystem auf Fehler prüfen. Klar, es ist noch neu und viel passiert ist ja darauf nicht, aber sicher ist sicher. Also starte ich die Prüfung mit folgendem Befehl:

sudo e2fsck -f -C 0 /dev/md0

Dieser Befehl erzwingt die Fehlerprüfung, auch wenn das Dateisystem als sauber markiert ist, zeigt einen Prozentbalken an und führt die Prüfung auf dem RAID /dev/md0 aus. Mit dem Prozentbalken sehe ich wenigstens, ob das Programm noch arbeitet, oder ob etwas hängt.

Die Dateisystemprüfung war jetzt bei mir problemlos durchgelaufen und keine Fehler gefunden. Also kann ich jetzt das Dateisystem erweitern. Hierzu nehme ich den Befehl:

sudo resize2fs -p /dev/md0

Der Parameter -p zeigt mir wieder einen Fortschritt an, so dass ich sehe, ob das Programm noch was tut. Die Änderung soll auf /dev/md0 ausgeführt werden. Ich habe hier jetzt hinter /dev/md0 keine Größe angegeben. Dann wird das Dateisystem auf die maximal mögliche Größe erweitert. Ich könnte aber natürlich auch eine feste Größe hier eingeben. Das möchte ich aber nicht, sondern ich will die ganze Kapazität für mich alleine! 🙂 Dieser Vorgang kann eine ganze Weile dauern.

Zur Sicherheit mache ich noch mal eine Dateisystemprüfung, vielleicht ist beim Vergrößern ja was schiefgelaufen? Dafür nehme ich wieder den gleichen Befehl wie oben.

Stride und Stripe-Width

Ihr erinnert euch? Der Stride-Wert ist die Chunk-Größe dividiert durch Dateisystem-Blockgröße. Diese Werte haben sich nicht geändert, also ist es immer noch 128 / 4 = 32. Aber der Stripe-Width-Wert ist der Stride-Wert mal Nutzplatten. Zuerst waren es 2 Nutzplatten, jetzt sind es 4, also 5 Platten minus eine Paritätsplatte, gleich 4. Also hat sich der Stripe-Width-Wert geändert, 32 * 4 = 128. Dies müssen wir dem Dateisystem natürlich auch klar machen.

Diese Werte lassen sich ganz einfach nachträglich anpassen. Hierzu nimmt man das Programm tune2fs. Der Befehl würde hier also so lauten:

sudo tune2fs -E stride=32,stripe-width=128 /dev/md0

Dateisystem mounten

Nun muss das Dateisystem nur noch wieder in den Verzeichnisbaum eingehängt werden. Da das RAID bereits in der fstab-Datei eingetragen ist, ist die Prozedur ziemlich einfach. Der Befehl lautet:

sudo mount /raid1

Und das war es auch schon. Schauen wir doch mal, wie viel Platz wir jetzt haben. Vorher waren es ja 7.3T. Zwischenzeitlich habe ich weiter Daten auf das RAID kopiert, aber mich interessiert ja nur der Wert unter Size. Ich verwende wieder den gleichen df-Befehl wie oben. Jetzt ist der Wert unter Size bei 15T. Ja, das sollte für die nächste Zeit reichen. 🙂

Fazit

Wenn man Platz im Server hat, könnte man das RAID noch um wer weiß wie viele Platten erweitern. Ich weiß ehrlich gesagt gar nicht, wo da die Grenze ist. Aber für den Hausgebrauch reicht es alle mal.

Und jetzt noch ganz schnell die Daten vom QNAP kopieren! Weil ich eine der Platten, nämlich die 4-TB-Platte, aus dem RAID-Verbund gepflückt habe, läuft dieses jetzt im degraded mode, also im herabgesetzten Modus. Ich kann drauf schreiben, ich kann davon lesen, aber die Ausfallsicherheit ist dahin! Gut, die platten sind noch nicht alt und ein Ausfall daher nicht zu erwarten, aber sicher ist sicher, je eher ich damit fertig bin, desto besser.

Super, das hat auch geklappt. Nun ist mein Server vollständig einsatzbereit. Das war’s! Nein, natürlich nicht für das Projekt Homeserver im Eigenbau. Aber der erste große Meilenstein, das QNAP NAS zu ersetzen, ist erreicht. Alles, was jetzt kommt, ist Bonus!

Ich habe noch einige Dinge mit dem Server vor. Was sich aber wie bewerkstelligen lässt, wird sich nach und nach ergeben. Daher mache ich jetzt auch erst mal keinen Ausblick darauf, was wohl als nächstes kommt. Das weiß ich selbst noch nicht so genau. Eines der Ziele, die in nächster Zeit angegangen werden, wird wohl ein Webserver sein, der auf dem Server läuft. Nicht, weil ich Webseiten im Internet damit anbieten will, sondern weil ich z. B. von außen auf meine eigenen Daten zugreifen können will, oder vielleicht auch einen CalDAV und CardDAV Dienst für die Synchronisation meiner Handydaten betreiben will. Aber wie gesagt, ob und wie, das muss ich selbst erst noch rausfinden.

Also, auch wenn es jetzt etwas länger dauert, bis wieder ein Beitrag kommt, es kommt sicher noch mehr.

Homeserver 17: Optionen der fstab optimieren

Mein Server ist gerade dabei, das RAID zu erweitern. Das kann noch eine ganze Weile dauern, daher kümmere ich mich mal um ein Thema, dass ich etwas vernachlässigt habe. Ich will die Dateisysteme des Servers etwas optimieren, genauer gesagt, die Optionen in der fstab-Datei.

Optimierungen für die SSD

Wenn man auf der SSD etwas löscht, so wird der Block nicht sofort freigegeben. Das Dateisystem markiert den Block lediglich als „Frei“. Der Controler der SSD selbst, der auch die Speicherverwaltung und die zu beschreibenden Blöcke verwaltet, erfährt davon nichts. Dieser Block, obwohl nicht mehr benötigt, wird ständig weiter mitgeführt und bei Schreiboperationen evtl. weiter mitgeschrieben. Das kann, in gewissem Maße, die Lebensdauer der SSD beeinflussen.

Dafür gibt es den TRIM-Befehl, der solch eine Löschung auch an die Hardware der SSD meldet, so dass der Block wirklich als nicht mehr genutzt markiert wird. Linux unterstützt diesen Befehl, aber nicht standardmäßig.

Für weitere Informationen könnt ihr euch ja den Wikipedia-Artikel zu TRIM durchlesen.

Um die TRIM-Funktion zu aktivieren, fügen wir der fstab die Mount-Option „discard“ hinzu.

Eine weitere Optimierung ist, die letzte Zugriffszeit auf eine Datei nicht mitzuprotokollieren. Dies ist zum einen nicht unbedingt nötig, und macht die SSD auch unnötig langsamer. Um dies zu erreichen, fügen wir die Option „noatime“ hinzu.

Die fstab-Datei öffnen wir so:

sudo nano /etc/fstab

Ganz unten stehen die Zeilen mit den Dateisystemen, die zum Systemstart automatisch eingehängt werden. Die Zeile für mein Root-Verzeichnis sieht also so aus:

UUID=1d7a581e-f7da-4325-9600-438f4fabb75d /               ext4    errors=remount-ro 0       1

Wenn ich jetzt die oben angegebenen Änderungen durchführe, sieht die Zeile anschließend so aus:

UUID=1d7a581e-f7da-4325-9600-438f4fabb75d /               ext4    errors=remount-ro,discard,noatime 0       1

Beide Parameter, „discard“ und „noatime“, zumindest aber „discard“, sollten wir auch in die Swap-Zeile darunter einfügen.

RAID-Optimierung

Hier gibt es nicht so viel zu optimieren. Lediglich die letzte Zugriffszeit auf eine Datei möchte ich nicht automatisch protokollieren, weil dies das RAID zum Einen langsamer macht, und zum Anderen meinen Netzwerkpapierkorb stört.

Wenn ich eine Datei in den Papierkorb lege, also lösche, setzt Linux automatisch den Löschzeitpunkt als letzten Zugriffszeitpunkt. Diese Zugriffszeit nutze ich, um die automatische Leerung des Papierkorbs zu erledigen. Öffne ich die Datei, um zu gucken, ob die wirklich weg kann, aktualisiert sich die Zugriffszeit, und das Löschen dieser Datei aus dem Papierkorb verzögert sich nach hinten.

Insgesamt wird das RAID aber langsamer, weil bei jedem Dateizugriff dieser Wert angepasst wird. Das können durchaus viele Dateizugriffe sein, wenn z. B. ein Batch-Backup läuft. Also empfiehlt es sich hier auch, die Option „noatime“ zu setzen. Die Zeile sieht nach der Änderung also so aus:

/dev/md0    /raid1      ext4    noatime,defaults    0   2

Dieser Parameter beeinflusst aber nicht das gewollte Setzen der Zugriffszeit als Löschzeitpunkt. Das funktioniert weiterhin.

Fazit

Nun noch die fstab speichern, fertig. Im Falle des RAID reicht es, es mit umount auszuhängen und wieder mit mount zu mounten. Aber im Falle des Root- und Swap-Dateisystems wird man um ein Reboot nicht herumkommen. Daher sollte man vielleicht gleich einen Reboot machen.

Die Optimierungen fallen vielleicht nicht auf den ersten Blick auf, langfristig wird sich das aber schon bemerkbar machen. Windows ist, zumindest bei meinem Windows 7, standardmäßig so eingestellt, dass es die letzte Zugriffszeit nicht mitschreibt.

So, dann warte ich mal, bis mein Server mit RAID Erweitern fertig ist, dann kommt der Beitrag dazu.

Homeserver 13: RAID und Dateisystem erstellen und in Betrieb nehmen

Das RAID aufzubauen ist eigentlich auch kein Hexenwerk. Jetzt muss nur noch das RAID Array definiert werden, ein Dateisystem muss drauf angelegt werden und das Dateisystem muss dann in den Verzeichnisbaum eingehängt werden. Fangen wir also mal ganz von Anfang an an.

Erstellen des RAIDs

Wir wissen, wir wollen ein RAID5, wir haben die Laufwerke /dev/sdb, /dev/sdc und /dev/sdd zur Verfügung. Außerdem wollen wir die Chunk-Size ändern.

Chunk-Size?

Ein RAID5 schreibt ja eine Datei auf alle ihm zur Verfügung stehende Platten. In unserem Falle sind das 3. Die Chunk-Size legt fest, wie groß der Teil der Datei ist, welche auf eine Platte geschrieben wird. Der Standardwert ist 512k. Das bedeutet für eine Datei, die 1 MB groß ist, dass die ersten 512 KB auf Platte 1, und die zweiten 512 KB auf Platte 2 geschrieben werden. die Paritätsinformationen, die zur Rekonstruktion nötig wären, wenn eine Platte ausfällt, werden auf die jeweils andere Platte geschrieben.

Jedes Chunk, also jeder Teil, der auf die Platten verteilt wird, ist also 512 KB groß. Das ist prima für viele große Dateien, das erhöht tatsächlich die Performance. Hätte man viele kleine Dateien, hätte man ein Problem. Nehmen wir an, wir schreiben viele kleine Dateien, die kleiner als 64 KB sind, dann müssen dennoch Schreiboperationen für 512 KB pro Block und Platte durchgeführt werden. Das würde die Performance wirklich niederdrücken. Da wäre es besser, man hat eine kleinere Chunk-Größe, so 64k wären OK. Ich habe ein Gemisch aus vielen kleinen, einigen mittelgroßen und einigen sehr großen Dateien. Also mache ich einen Kompromiss und entscheide mich für eine Chunk-Size von 128k. Das sollte die Performance nicht zu sehr drücken und stellt eigentlich ein gutes Mittelmaß dar. Im übrigen habe ich gesehen, dass mein QNAP sein RAID mit einer Chunk-Size von 64k angelegt hat.

RAID erstellen

Um unser RAID nun zu erstellen, geben wir folgenden Befehl ein:

sudo mdadm --create --verbose /dev/md0 --level=5 --chunk=128 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1

Was genau wollte ich jetzt also von MDADM?

  • --create: Erstelle mir ein RAID,
  • --verbose: sag mir genau, was du da tust,
  • /dev/md0: nenne das RAID-Gerät dann /dev/md0,
  • --level=5 erzeuge es als RAID5,
  • --chunk=128: stelle die Chunk-Größe auf 128k ein,
  • --raid-devices=3: die Zahl der beteiligten Festplatten oder Partitionen und
  • /dev/sdb1 /dev/sdc1 /dev/sdd1: das sind die einzelnen beteiligten Partitionen.

Nachdem wir diesen Befehl eingegeben haben, fängt das RAID an sich zu synchronisieren. Wir können dennoch schon damit arbeiten, z. B. ein Dateisystem drauf erstellen.

Um zu sehen, was das RAID gerade tut oder in welchem Zustand es gerade ist, kann man sich die Datei mdstat anzeigen lassen:

cat /proc/mdstat

Und so sieht meine gerade aus:

Personalities : [raid6] [raid5] [raid4] 
md0 : active raid5 sdd1[3] sdc1[1] sdb1[0]
      7813772544 blocks super 1.2 level 5, 128k chunk, algorithm 2 [3/2] [UU_]
      [>....................]  recovery =  0.1% (4061324/3906886272) finish=480.4min speed=135377K/sec

unused devices: <none>

Diese Ausgabe zeigt, das ich beim Erstellen ein kleines Problem hatte, welches normalerweise nicht auftritt. Das lag einfach daran, dass ich den Befehl zum Erstellen des RAIDs gegeben hatte, wo die Festplatten im Standby waren und eine davon nicht rechtzeitig aufgewacht ist… 🙂 Da dies aber sonst nicht vorkommt, habe ich mal darauf verzichtet, das Problem darzustellen. Zur Problemlösung kommen wir noch früh genug.

Nun will ich aber mal darstellen, was diese Ausgabe eigentlich bedeutet:

  • Personalities : [raid6] [raid5] [raid4]
    Diese Zeile zeigt die vom Kernel unterstützten RAID-Modi an.
  • md0 : active raid5 sdd1[3] sdc1[1] sdb1[0]
    Dies ist das RAID-Gerät. Das Wort nach „md0 : “ Zeigt an, ob es aktiv, „Active“, Nur-Lese-Modus „Read-Only“ oder herabgesetzt „Degraded“ ist.
    Anschließend werden das RAID-Level und die beteiligten Geräte aufgelistet.
  • 7813772544 blocks super 1.2 level 5, 128k chunk, algorithm 2 [3/2] [UU_]
    Das sind die Anzahl der Blöcke, RAID-Level, Superblock-Version, Chunk-Größe, genutzter Algorithmus und Laufwerksstatus. Das [UU_] bedeutet, dass die ersten beiden Laufwerke OK sind, aber das 3. nicht.
  • [>………………..] recovery = 0.1% (4061324/3906886272) finish=480.4min speed=135377K/sec
    Das ist der aktuelle Status, und wie lange es noch dauert, bis er fertig ist. In diesem Falle sind es 480 Minuten.
  • unused devices:
    Dies zeigt an, ob noch Laufwerke im RAID angegeben wurden, die aber gerade nicht genutzt werden. Dies ist von Bedeutung, wenn wir ein Hot-Spare, also ein bereits eingebautes Ersatzlaufwerk im System hätten. Haben wir hier aber nicht.

Dateisystem erstellen

Obwohl das RAID gerade dabei ist, sich zu synchronisieren, können wir dennoch damit weiterarbeiten. Zwar ist die Ausfallsicherheit gerade nicht gegeben, aber das ist in diesem Stadium auch nicht so wichtig.

Nun muss ein Dateisystem auf das RAID aufgesetzt werden. Hierzu nehme ich ein EXT4-Dateisystem. Aber, wie sollte es auch anders sein, wird es nicht ganz unkompliziert. Zwar würde es mit einem einfach draufgeklatschten Dateisystem auch prima funktionieren, aber ich will es doch noch etwas optimieren. Vor allem die Chunk-Size kommt hier zum Tragen. Ich erstelle also mein Dateisystem als EXT 4 so:

sudo mkfs.ext4 -v -m .1 -E stride=32,stripe-width=64 /dev/md0

Und was tun diese Optionen nun?

  • -v: Ausführliche Ausgabe.
  • -m .1: Reserviere nur 0,1 % des Dateisystems für Betriebssystem. Standard sind 5 %, aber da wir ein monströs großes Dateisystem anlegen, wäre das reine Platzverschwendung.
  • -E stride=32,stripe-width=64: Das hat mit der Chunk-Size zu tun. Der Stride-Wert errechnet sich durch Chunk-Size dividiert durch Dateisystemblockgröße. Meine Chunk-Size ist 128, die Dateisystemblöcke sind alle 4 K groß. Also 128 / 4 = 32. Der Stripe-Width-Wert errechnet sich durch Stride multipliziert mit der Anzahl Nutzplatten. In meinem RAID 5 habe ich 3 Platten, das sind 2 Nutzplatten und eine Paritätsplatte, also 2. Dies sind dann 32 * 2 = 64. Dies optimiert den Dateisystemdurchsatz.
  • /dev/md0: Das RAID-Gerät, auf dem das Dateisystem erstellt werden soll.

Das dauert nur ein paar Sekunden bis zu einer Minute, dann ist das Dateisystem bereit.

RAID Konfiguration in Datei speichern

Damit das RAID beim Start des Servers auch immer mitgestartet wird, muss dessen Konfiguration in die Konfigurationsdatei mdadm.conf eingetragen werden. MDADM kann mittels eines Befehls die entsprechende Zeile ausgeben. Was mir nicht gelungen ist, ist die Zeile auch automatisch an die Konfiguration anzuhängen. Daher müssen wir dies mit Markieren und Einfügen erledigen. Zunächst einmal zeigen wir die Zeile an, die in die Konfiguration eingefügt werden soll.

sudo mdadm --detail --scan

Nun markiere ich die Zeile indem ich den Jaws-Cursor verwende. Hier muss man leider die Maus verwenden, ob nun mittels des Jaws-Cursors, einer anderen Methode eines anderen Screenreaders, die die Maus an die entsprechende Stelle zieht oder mittels Sehrest.

Da diese Markierungsmethode ziemlich ungenau ist, füge ich die Zeile in einen leeren Editor ein, um sie von Zeilenumbrüchen zu bereinigen. Anschließend markiere ich die ganze Zeile wieder und kopiere sie in die Zwischenablage.

Ich weiß, es klingt kompliziert, ich weiß ehrlich gesagt auch nicht, warum es nicht funktioniert hat, die Ausgabe direkt in die Konfigurationsdatei umzuleiten. Die Datei hat „Permission denied“ gemeldet, obwohl ich es als Super User gemacht habe. Na, egal.

Jedenfalls öffne ich nun die MDADM-Konfigurationsdatei und gehe mit dem Cursor ganz nach unten.

sudo nano /etc/mdadm/mdadm.conf

Übrigens sieht die bereinigte Zeile, die ich ganz unten in die Konfigurationsdatei einfüge, so aus:

ARRAY /dev/md0 metadata=1.2 name=server01:0 UUID=3282449e:63a42eea:ec51f565:89790348

So, die Datei nur noch mit Ctrl+X speichern, fertig.

Dateisystem automatisch einhängen

Damit beim Start des Servers das Dateisystem auch gleich mitstartet, muss es in die Datei fstab eingetragen werden. Hier trägt man alle Dateisysteme ein, die automatisch gemounted werden sollen.

sudo nano /etc/fstab

In dieser Datei stehen schon einige Einträge, die wir aber in Ruhe lassen, weil diese das eigentliche Server-Dateisystem und dessen Auslagerungsdateisystem laden. Ganz unten fügen wir eine Zeile hinzu.

/dev/md0    /raid1  ext4    defaults    0   2
  • /dev/md0: Das RAID-Gerät.
  • /raid1: Der Ort, also der Mountpunkt, an dem das RAID ins Dateisystem eingehängt wird.
  • ext4: Der Typ des Dateisystems.
  • defaults: Verwendet die normalen Dateisystemparameter.

Die 0 hinter dem „default“, nun, was die tut, weiß ich auch nicht wirklich. Aber die 2 am Ende ist wichtig. Das eigentliche Dateisystem der SSD hat am Ende eine 1. Das legt die Priorität fest, wie die Dateisysteme beim Start auf Fehler überprüft werden. Das eigentliche Root-Dateisystem hat hierbei natürlich die höchste Priorität. Danach erst wird das Dateisystem auf dem RAID überprüft.

Wenn wir nun den Server neu starten, und ins Verzeichnis /raid1 wechseln, befinden wir uns also nicht mehr auf der SSD, sondern im Hauptverzeichnis des RAIDs. Hier können wir natürlich Verzeichnisse anlegen und dergleichen.

Und nun?

Im nächsten Teil werden wir mit dem RAID experimentieren. Wir werden es kaputt machen, herausfinden, welche Platte kaputt ist, es wieder reparieren und dergleichen. Es ist wichtig dies mal gemacht zu haben, jetzt, wo noch keine Daten drauf sind, die verloren gehen könnten. Später, wenn man mal in eine Notlage gerät, weiß man wenigstens, wie man sich da wieder herauswindet… 🙂

Server hat Aua!

Und wenn es dem Server, hier dem RAID, in irgendeiner Art an etwas fehlt, schickt es auch gleich eine Mail. So eine habe ich bekommen, als ich vorhin beim Erstellen auf ein Problem gestoßen bin. Und so eine Mail kann so aussehen:

DegradedArray event on /dev/md0:server01
This is an automatically generated mail message from mdadm
running on server01

A DegradedArray event had been detected on md device /dev/md0.

Faithfully yours, etc.

P.S. The /proc/mdstat file currently contains the following:

Personalities : [raid6] [raid5] [raid4] 
md0 : active (auto-read-only) raid5 sdd1[3](S) sdc1[1] sdb1[0]
      7813772544 blocks super 1.2 level 5, 128k chunk, algorithm 2 [3/2] [UU_]

unused devices: <none>

Wie gesagt, wie man mit solchen Fehlern umgeht, probieren wir im nächsten Teil aus.