Schlagwort-Archive: MDADM

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 14: Festplattenausfall im RAID

Im Grunde könnten wir jetzt einfach mal mit dem RAID arbeiten und Daten kopieren. Ich denke aber, bevor wir das tun, sollten wir die Gelegenheit nutzen. Noch ist nichts drauf, was wichtig ist, also können wir auch bedenkenlos experimentieren. Denn was nutzt eine Ausfallsicherheit, wenn man nicht weiß, was passiert, wenn was passiert?

Ergänzungen zum vorherigen Artikel

Zuvor aber will ich noch mal auf ein paar Punkte eingehen, die ich im vorherigen Artikel entweder vergessen habe, oder nur viel zu oberflächlich angesprochen habe.

Superblock

Ihr erinnert euch? Wenn man die Datei mdstat anzeigt, bekommt man in der dritten Zeile die Angabe „super 1.2“. Ich bin nicht weiter darauf eingegangen, dabei ist der Superblock sehr wichtig.

Der Superblock ist ein Datensatz, der auf jede am RAID beteiligte Platte geschrieben wird. Viele Angaben stehen hier drin, wie der Typ des RAID, welcher Algorithmus verwendet wird und dergleichen. Wenn ein RAID gestartet wird, wird dieser Superblock gelesen und dessen Informationen ausgewertet. So können die einzelnen Laufwerke im RAID korrekt zusammengestellt werden.

Die Angabe „super 1.2“ sagt eigentlich nichts weiter aus, als dass die Definition der Version 1.2 des Superblocks verwendet wird.

Was passiert bei Neuinstallation?

Niemals wieder darf auf diesen Laufwerken der Befehl mdadm --create verwendet werden! Es gibt widersprüchliche Texte, wobei manche sagen, es würde nur der Superblock neu erstellt, manche sagen aber, die Daten gingen verloren.

Wenn ihr, aus welchen Gründen auch immer, mal euer Linux neu installieren müsst, ist das RAID erst mal nicht vorhanden. Aber ihr braucht es nicht neu zu erstellen, sondern könnt es ganz einfach wieder zusammenstellen. Hier helfen euch die Superblöcke, die auf den Laufwerken gespeichert sind und die nötigen Informationen des RAIDs beinhalten. Und so stellt ihr euer bisheriges RAID einfach wieder zusammen:

sudo mdadm --assemble /dev/md0 /dev/sdb1 /dev/sdc1 /dev/sdd1

Fertig! Das RAID ist wieder da und funktioniert auch. Weil aber die Superblocks auf den Festplatten gespeichert sind, würde auch folgender Befehl funktionieren:

sudo mdadm --assemble --scan

Das RAID mit all euren Daten wäre wieder da. Nun müsstet ihr nur noch das Dateisystem einhängen und die fstab editieren. Neu anlegen braucht, und dürft, ihr das Dateisystem nicht, es ist ja schon vorhanden.

Und wie im vorherigen Artikel müsst ihr das RAID nur noch in die Konfigurationsdatei mdadm.conf eintragen. Das ist alles.

Festplatte ausgefallen, was nun?

Ein RAID ersetzt niemals ein Backup! Sichert eure Daten irgendwo auf externen Platten oder auf einem anderen Server. Ein RAID kann euch helfen, beim Ausfall einer Platte weiterarbeiten zu können oder die Daten noch eben schnell sichern zu können. Aber ein RAID schützt euch nicht vor versehentlichem Löschen, Virusbefall oder einer Alien-Invasion. OK, ein Backup schützt euch vor der Alien-Invasion jetzt auch nicht wirklich … 🙂 Gerade ein RAID 5 schützt euch, zumindest für eine gewisse Zeit, vor dem Ausfall einer Platte. Wenn aber zwei Platten ausfallen, was zwar ziemlich unwahrscheinlich ist aber dennoch passieren kann, sind alle Daten weg. Macht also immer ein Backup!

Wenn im RAID 5 also eine Festplatte ausfällt, so kann man dennoch weiter arbeiten. Man sollte die ausgefallene Festplatte aber so schnell wie möglich auswechseln. Denn wenn nun noch eine ausfällt, sind die Daten weg. Man hat zwar ein Backup, aber das wiederherzustellen dauert seine Zeit.

Bei fertigen NAS-Systemen, wie z. B. meinem QNAP NAS, weiß ich, welche Platte defekt ist. Zum Einen sind die Platten durchnummeriert, zum Anderen leuchtet an der defekten Platte ein rotes Lämpchen. Mein Selbstbauserver hat weder feste Laufwerksnummern noch kleine rote Lämpchen, die mir dabei helfen. Wie kriege ich also heraus, welche Platte ausgefallen ist?

Festplattenausfall simulieren

Ich könnte jetzt natürlich einfach zum Server rennen und eines der Festplattenkabel rausziehen. Das ist aber witzlos, weil ich dann ja weiß, welche Platte als kaputt simuliert werden soll. Es geht ja eben gerade darum, dass man das in der Praxis ja nicht weiß. Also werde ich MDADM einfach anweisen, eine der Platten als kaputt zu markieren.

sudo mdadm -f /dev/md0 /dev/sdc1

Somit habe ich MDADM angewiesen, die Platte /dev/sdc1 als kaputt zu markieren. Und Prompt bekomme ich auch schon eine Mail vom Server!

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

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

It could be related to component device /dev/sdc1.

Faithfully yours, etc.

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

Personalities : [raid6] [raid5] [raid4] 
md0 : active raid5 sdb1[0] sdd1[3] sdc1[1](F)
      7813772544 blocks super 1.2 level 5, 128k chunk, algorithm 2 [3/2] [U_U]

unused devices: <none>

Wie ihr sehen könnt, sagt er mir auch schon, welche Platte evtl. kaputt ist. Die Datei mdstat zeigt dies in der zweiten Zeile an:

md0 : active raid5 sdb1[0] sdd1[3] sdc1[1](F)

Neben sdc1 ist ein F in Klammern, (F). Damit ist die Platte als kaputt markiert, auch in der dritten Zeile, [U_U], wird angezeigt, dass die mittlere Platte kaputt ist.

Übrigens, in der zweiten Zeile, wo sdc1[1] (F) steht, weiß ich nicht, was die Zahl in eckigen Klammern bedeutet. Es ist jedenfalls nicht die Position im RAID. Aber das soll erst mal nicht von Bedeutung sein.

Festplatte aus dem RAID-Verbund entfernen

Bevor wir die Festplatte nun ausbauen können, müssen wir sie erst aus dem RAID-Verbund entfernen.

sudo mdadm -r /dev/md0 /dev/sdc1

Nun ist die Festplatte aus dem RAID entfernt und kann ausgebaut werden.

Finden der Festplatte

Aber welche der 3 ist es denn nun? Wir wollen ja nicht die falsche Platte ausbauen. Das würde dem RAID nicht besonders gut tun.

Das Tool lshw, welches wir früher schon installiert haben, wird uns dabei helfen, die Festplatte zu identifizieren. Sie kann uns sagen, an welchem Port sie angeschlossen ist. Ich habe ja das Layout meiner SATA-Ports beschrieben, und dass die Platte an Port 1 ganz unten, und Port 5 ganz oben im Gehäuse eingebaut ist. Also schauen wir doch mal nach, wo welche Platte angeschlossen ist.

sudo lshw -c disk

Damit werden mir nur die Festplatten angezeigt. Würde ich lshw ohne Parameter ausführen, würde mir alles über jede verbaute Hardware angezeigt werden. Das ist aber jetzt zu viel Information, daher interessiere ich mich zur Zeit nur für die Festplatten.

Auch hier, die Ausgabe ist so umfangreich, dass ich mal nur die Ausgabe der betreffenden Festplatte hier einfüge:

  *-disk:2
       description: ATA Disk
       product: ST4000VN000-1H41
       vendor: Seagate
       physical id: 2
       bus info: scsi@2:0.0.0
       logical name: /dev/sdc
       version: SC46
       serial: S300ZDWJ
       size: 3726GiB (4TB)
       capabilities: gpt-1.00 partitioned partitioned:gpt
       configuration: ansiversion=5 guid=36d24ddd-4bcb-44bf-9de2-97e057ee3e79 sectorsize=4096

Wenn ihr also eine Ausgabe mit mehreren Festplatten bekommt, sucht nach der Zeile „logical name: /dev/sdc“. Ich habe jetzt nur mal diese Festplatte hier eingefügt.

All diese Informationen sind für euch zwar interessant, aber nicht wirklich wichtig. Die einzige Zeile, die uns eigentlich interessiert ist diese hier:

bus info: scsi@2:0.0.0

Aus dieser Zeile interessiert uns auch nur die Zahl direkt hinter dem @-Zeichen, alles andere ist irrelevant. Nun weiß ich, dass die kaputte Platte an Port 2 hängt, somit weiß ich, es ist die zweite Platte von unten. Also schalte ich den Server mal aus und ziehe nun das Kabel ab. Wenn ich den Server wieder hochfahre, müsste das RAID, wenn auch im herabgesetzten Modus, weiter arbeiten.

Das tut es sogar, der Server ist gerade ohne /dev/sdc1 normal hochgefahren, und das RAID funktioniert noch. Allerdings ist jetzt die Ausfallsicherheit nicht mehr da. Fällt jetzt noch eine Platte aus, war es das.

Noch eine Besonderheit am Rande: Die Bezeichnungen /dev/sdc usw. werden dynamisch vergeben. Somit ist /dev/sdd gerade zu /dev/sdc geworden. Das könnte hinterher wichtig sein, wenn ihr eine neue Platte einbaut und partitionieren wollt.

Neue Festplatte einbauen und ins RAID integrieren

Nun baut ihr dort, wo die kaputte Platte war, eine neue, gleichgroße Festplatte ein. Diese muss selbstverständlich noch partitioniert werden. Dies tut ihr, wie ich es im Teil 12 beschrieben habe.

Ich habe jetzt die Festplatte wieder angeschlossen und den Server wieder hochgefahren. Die Laufwerksbezeichnungen haben sich wieder verschoben, /dev/sdc wurde wieder zu /dev/sdd, wie es sich gehört, und die eigentliche Festplatte /dev/sdc ist wieder da, wo sie hingehört.

Partitioniert ist die Festplatte jetzt auch. Nun muss die Platte aber wieder in den RAID-Verbund integriert werden.

sudo mdadm -add /dev/md0 /dev/sdc1

Die Wiederherstellung des RAID-Arrays beginnt sofort von selbst. Dies kann, je nach Anzahl der Platten und der Größe aber schon mal mehrere Stunden dauern. Die Datei mdstat sagt, es könne so um die 470 Minuten dauern. OK, warte ich halt… 🙁

Weiterarbeiten möglich?

Natürlich. Genau wie beim Erstellen des RAIDs, ist das Arbeiten ohne Einschränkungen möglich. Nur die Ausfallsicherheit ist halt nicht gegeben, bis das Array sich wieder komplett synchronisiert hat.

Fazit

Es können eine Vielzahl von Problemen mit einem RAID entstehen. Mit den meisten Sonderfällen hat man in der Regel aber nie zu tun. Daher gehe ich jetzt da auch nicht weiter drauf ein. Der häufigste Fall, also ein Festplattenausfall, kann jeden treffen, daher habe ich diesen auch ausführlich beschrieben. Der wohl wichtigste Aspekt ist, die richtige Platte zu finden, wenn ein Array sich im herabgesetzten Modus befindet. Die falsche Platte auszubauen wäre nicht von Vorteil.

Wenn man aber damit umgehen kann, also die richtige Festplatte herausfinden kann, die ausgetauscht werden muss, und wenn man dann noch ein aktuelles Backup seiner Daten hat, kann einem eigentlich nichts wirklich schlimmes passieren. Dann habt ihr im schlimmsten Fall eine Menge Arbeit und eine Menge Zeit verloren. Aber eure Daten sind weiterhin sicher.

Ausblick

Das Grundgerüst des Servers steht ja und funktioniert auch. Nun müssen wir es noch mit Leben füllen. Als nächstes werden daher auf dem RAID Ordner angelegt und Netzwerkfreigaben erstellt. Dann können wir auch endlich Daten auf das RAID kopieren.

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.

Homeserver 12: RAID-Grundlagen und Festplatten partitionieren

Kommen wir nun also zu einem der Kernaufgaben des Servers, das Speichern von Daten. Dazu ist es nötig, in den Server mehrere Platten einzubauen und diese als ein Software-RAID anzusprechen. Es gibt auch Hardware RAID-Kontroller, aber die sind zum einen Teuer, und falls man mal das System umbauen muss, evtl. inkompatibel. Muss also mal der RAID-Kontroller ausgetauscht werden, sind die Daten evtl. weg. Daher werde ich mit den Mitteln des Linux-Systems ein Software-RAID aufbauen. Wenn hier z. B. die Hardware ausgetauscht werden muss und Linux neu installiert wird, kann man das RAID recht einfach wieder zusammenstellen und wieder in Betrieb nehmen.

Da dieses Thema doch recht umfangreich ist, werde ich es in mehrere Teile aufteilen.

Vorüberlegungen

Ich möchte gerne ein RAID mit sehr viel Speicherplatz, schnellem Zugriff und einer gewissen Ausfallsicherheit. Also bietet sich für mich ein RAID Level 5, kurz RAID5, an.

Für eine Erklärung, was RAID ist und was die einzelnen RAID Levels sind und wofür sie gedacht sind, könnt ihr euch ja mal den Wikipedia-Artikel zu RAID durchlesen. Und im Linux RAID Wiki gibt es eine sehr ausführliche Anleitung zum Thema Software-RAID unter Linux. Das Linux RAID Wiki ist aber in Englisch.

Für ein RAID5 benötige ich ein Minimum von 3 Festplatten, vorzugsweise gleicher Größe und gleicher Geschwindigkeit. Es ist nicht so tragisch, wenn es Platten unterschiedlicher Hersteller sind, aber die Gesamtleistung und Größe des RAIDs richtet sich nach der kleinsten und/oder langsamsten Platte. Es ist also vorzuziehen, Festplatten des gleichen Herstellers und Modells zu nehmen.

Außerdem will ich das RAID hinterher im Linux-Verzeichnisbaum unter /raid1 einhängen. Das ist nummeriert für den Fall, dass ich statt einem großen RAID lieber mehrere kleine RAIDs anlegen möchte. Zunächst will ich aber ein großes RAID anlegen.

Vorbereitung

Um unser RAID also anlegen zu können, müssen mehrere Dinge getan werden. Zunächst mal muss der Mountpunkt, also der Ordner, wo das RAID später eingehängt wird, erstellt werden:

sudo mkdir /raid1

Dies legt im Hauptverzeichnis den Ordner „raid1“ an, in den wir später das RAID einhängen werden.

Nun muss noch die RAID-Verwaltung installiert werden. Dies ist unter Linux MDADM. Damit werden alle Werkzeuge und Module installiert, die für das Einrichten des RAIDs und dessen Betrieb notwendig sind.

sudo apt-get install mdadm

Hierauf öffnet sich ein Fenster, in dem mehrere Fragen zur Konfiguration von MDADM gestellt werden. Im ersten Fenster wird uns erklärt, was wir eingeben müssen, wenn unser System auf dem RAID installiert ist. Es geht darum, welches RAID schon beim Bootvorgang gestartet werden soll. Die einzige Schaltfläche hier ist OK, die wir auch drücken. Hier kommt nun das Eingabefeld, in das wir entweder „all“ für alle RAIDs starten beim Bootvorgang, „none“ für keines oder ein bestimmtes Array angeben können. Zum Boottzeitpunkt muss noch kein Array gestartet werden, da unser Array kein Systemdatenträger, sondern nur für Nutzerdaten gedacht ist. Also trage ich hier „none“ ein.

Im nächsten Fenster werden wir gefragt, ob wir alle in der Konfiguration eingetragenen RAIDs nach dem Systemstart automatisch starten wollen. Das möchten wir natürlich, daher gebe ich hier „Ja“ an. Wie wir das RAID in die Konfigurationsdatei eintragen, kommt später noch dran.

Eine Kleinigkeit wollen wir dann aber doch noch in der Konfigurationsdatei von MDADM ändern. Ich möchte, dass mir MDADM eine Mail schickt, wenn es zu Problemen mit dem RAID kommt. Es gibt in der Datei bereits eine Zeile „MAILADDR“, die wir modifizieren, und eine Zeile hinzufügen. Die Konfigurationsdatei für MDADM öffnen wir mit:

sudo nano /etc/mdadm/mdadm.conf

Und die Zeilen sehen nach unserer Änderung dann so aus:

MAILADDR eure_mailadresse@gmx.de
MAILFROM mdadm

Die MAILFROM-Zeile sorgt dafür, dass die Mail auch erkennbar von MDADM kommt. Dann noch alles mit STRG+X speichern, fertig.

Festplatten vorbereiten

Achtet beim Anschließen der Platten darauf, an welchen Anschluss ihr sie angeschlossen habt. Das wird sehr wichtig, wenn es darum geht, eine defekte Platte auszubauen. Bei mir sind die 6 SATA-Anschlüsse am Board so aufgebaut: Senkrecht sind 3 Blöcke mit je 2 Anschlüssen. Oben rechts Port 0, links Port 1, darunter rechts Port 2, links Port 3, darunter rechts Port 4, links Port 5. Die Festplatten werden bei mir im Gehäuse von unten nach oben eingebaut. Festplatte an Port 1 ist also ganz unten, Festplatte an Port 5 ganz oben im Rahmen des Gehäuses.

Wenn eine Festplatte defekt ist, so können wir mit lshw abfragen, an welchem Port sie angeschlossen ist. Das werden wir später auch noch ausprobieren, und damit ihr nicht die falsche Platte ausbaut, solltet ihr euch, falls nicht anders möglich, von einem Sehenden erklären lassen, welcher SATA-Anschluss welche Nummer hat.

An meinem Port 0 ist die SSD angeschlossen, von der wir booten. An Port 1 bis 5 kommen die platten dran.

Ich habe jetzt also 3 Seagate ST4000VN000 Festplatten mit je 4 TB eingebaut und von Port 1 bis 3 angeschlossen. Nun müssen diese Platten noch partitioniert werden.

Ausrichtung der Partitionen

Das Problem der Ausrichtung der Partition, auch Alignment genannt, ist gar nicht so zu unterschätzen. Vor allem bei SSDs kommt das sehr zum Tragen.

SSDs lesen und schreiben immer ganze Blöcke, die zwischen 4 KB und 8 KB groß sein können. Ein Sektor hat aber nur 512 Bytes, daher sind erst 8 Sektoren 4 KB. Nun beginnt eine Partition aber nicht bei 4 KB, weil davor noch Platz für diverse technische Daten bleiben muss. Oft beginnt bei so großen Platten die eigentliche Partition bei einem Sektor weit über 1024. Das Tool parted kann die Ausrichtung der Partition automatisch vornehmen, bei fdisk müssen wir Start- und Endsektor angeben. Und wenn wir eine Partition so anlegen, dass sie in der Mitte eines Blocks beginnt, passiert folgendes: Da die Daten, die nun gelesen und geschrieben werden sollen jetzt auf 2 physische Blöcke verteilt sind, werden 2 Blöcke gelesen und auch 2 Blöcke geschrieben. Das macht die SSD nicht nur langsamer, sondern halbiert ihre Lebensdauer. Denn wo nur 1 Block zu belasten war, werden jetzt 2 Blöcke belastet.

Bei magnetischen Festplatten ist das nicht ganz so tragisch, verlangsamt ihre Leistung aber doch merklich. Gerade dann, wenn viel gelesen und geschrieben wird, fällt das auf. Daher sollte man die Partitionen auch hier korrekt ausrichten.

Die meisten Tools, die ich unter Windows gesehen habe, machen das auch schon automatisch, fdisk geht aber davon aus, dass man weiß, was man tut. Mit viel lesen könnte ich mir evtl. das Wissen aneignen, ich habe aber ehrlich gesagt keine Lust dazu. 🙂 Daher nutze ich parted, das kümmert sich schon um das richtige Alignment.

Wir können das mit der SSD übrigens mal testen. Startet mal partedt:

sudo parted /dev/sda

Hier werden Kommandos zum Steuern von parted eingegeben. Um zu überprüfen, ob /dev/sda1 also korrekt ausgerichtet ist, geben wir folgendes ein:

align-check optimal 1

Wenn die Ausgabe „1 aligned“ ist, dann ist die Partition korrekt ausgerichtet.

Mit dem Befehl „quit“ verlassen wir parted wieder.

Festplatte partitionieren

Was ihr hier macht, macht bitte mit der größten Vorsicht. Überprüft alles doppelt und dreifach, wenn es sein muss. Wenn ihr z. B. die Partitionstabelle der falschen Disk löscht, sind alle Daten futsch! Geht also mit besonderer Sorgfalt beim partitionieren vor. Überprüft mit dem Befehl „print“ innerhalb von parted lieber mehrmals, ob ihr wirklich die richtige Platte manipuliert. Und bedenkt, ihr handelt auf eigene Gefahr. So, nachdem das gesagt ist, kann’s los gehen.

Am Beispiel von /dev/sdb, also der ersten Platte des zukünftigen RAIDs, zeige ich euch nun, wie die Platte partitioniert werden muss.

Nach mehreren Experimenten habe ich mich dazu entschlossen, weder fdisk noch parted zum Partitionieren der Platten zu nutzen. fdisk kann nicht mit GPT-Partitionstabellen umgehen, und parted ist teils wegen seiner Befehle umständlich. Stattdessen habe ich gdisk entdeckt, was im Grunde eine Weiterentwicklung von fdisk ist, wodurch auch GPT-Partitionstabellen unterstützt werden. Allerdings muss gdisk erst installiert werden:

sudo apt-get install gdisk

Noch ein Wort zu GPT-Partitionstabellen: Bisher waren die Partitionstabellen im Format MBR, Master Boot Record, angelegt. Diese haben aber gewisse Begrenzungen, die sie für größere Platten eher ungeeignet macht. Daher wird oft für Platten, die größer als 2 TB sind , die GPT-Partitionstabelle verwendet. Näheres zu GPT-Partitionstabellen könnt ihr im entsprechenden Wikipedia-Artikel nachlesen.

Also rufen wir zum Partitionieren der ersten platte des zukünftigen RAIDs das Programm so auf:

sudo gdisk /dev/sdb

Nun könnt ihr mit einzelnen Buchstaben die Befehle ausführen. Um euch alle verfügbaren Befehle anzeigen zu lassen, gebt ihr ein „?“ ein.

Da ich diese Platte schon mal für was anderes genutzt hatte, und auch, wenn man sich nicht darüber sicher ist, legt man einfach eine neue Partitionstabelle an. Dazu drückt ihr einfach die Taste „o“ und Enter. Anschließend werdet ihr gefragt, ob ihr das wirklich wollt, weil dann die Partitionstabelle überschrieben wird. Dies bestätigt ihr mit „y“. wie gesagt, bei mir ist ja alles noch englisch.

Bevor ihr das macht, schaut mit dem Befehl „p“ nach, ob ihr wirklich die richtige Platte gewählt habt. Nicht, dass ihr eine wichtige Datenplatte kaputt macht.

Mit der Taste „n“ legt ihr eine neue Partition an. Anschließend kommen noch einige Fragen:

  • Partitionsnummer?: Hier gebt ihr eine 1 ein.
  • Erster Sektor: Der Standardwert ist bei meiner Platte 2048, und den übernehme ich, ohne etwas einzugeben. Dadurch ist das Alignment der Partition OK.
  • Letzter Sektor: Der Standard ist der letzte verfügbare Sektor auf der Platte. Ihr könntet aber auch eine Größe angeben, oder z. B. -100m, so dass am Ende etwa 100 MB frei bleiben. Ich übernehme den Standardwert mit Enter.
  • Partitionstyp: Hier gebe ich „FD00“ an.

In vielen Anleitungen lese ich, dass der Typ der Partition auf 0xFD gestellt werden soll. Das sei der richtige Partitionstyp für RAIDs.

Nun können wir uns mit dem Befehl „p“ das Ergebnis angucken. Und wenn es uns gefällt, können wir es mit „w“ auf die platte schreiben und das Programm verlassen.

Diesen Vorgang müssen wir jetzt mit allen 3 Festplatten durchführen, wobei, die erste haben wir ja schon geschafft. 🙂

Aufbau des RAIDs

Wenn nun alle 3 Festplatten korrekt partitioniert sind, können wir im nächsten Teil das eigentliche RAID aufbauen, ein Dateisystem anlegen und, bevor noch wirklich wichtige Daten auf dem RAID sind, ein paar Experimente machen. Wie z. B. wie erkennt man eine fehlerhafte Platte und welche von denen ist es denn nun? Das sind Dinge, die man gemacht haben sollte, bevor es um wirklich wichtige Daten geht… 🙂