Ubuntu 12.04 Server Software Raid 1 Installation

In diesem Tutorial geht es um eine Ubuntu 12.04 Server Installation im Software-Raid-1-Verbund (Spiegelung).

Der Vorteil von Raid 1 (Spiegelung) liegt in der Ausfallsicherheit. Fällt eine Festplatte aus, so sind die Daten noch nicht verloren, da in einem Raid 1 Verbund alle Daten doppelt vorhanden sind. Ein weiterer Vorteil ist die Lese und Schreibgeschwindigkeit, die natürlich mit zwei Festplatten im Raid 1 Verbund auch schneller ist, als mit nur einer Festplatte.

Ich habe mit VMWare Workstation eine neue Virtuelle Machine für Linux erstellt und dem ganzen zwei virtuelle 20 GB Festplatten spendiert auf dem wir unseren Raid-Verbund erzeugen wollen.

Führen wir das Ubuntu Setup aus, so werden wir nach der Partitionierung der Festplatten gefragt. Hier wählen wir, wie auf dem folgenden Bild ersichtlich “Manuell” aus.

Nun bekommen wir angezeigt, dass wir zwei 20 GB Festplatten zur Partitionierung zur Verfügung haben. Wir wählen zunächst die erste Festplatte (sda) aus und bestätigen das ganze mit der Enter Taste.

Auf die nächste Frage, ob wir die Partitionstabelle anlegen wollen, antworten wir mit “Ja”.

Jetzt markieren wir die erste primäre freie Partition und bestätigen mit der Enter Taste. “pri/log 21.5 GB FREIER SPEICHER” wählen.

Wir legen nun eine neue Partition an.

Da es sich bei der zu erstellenden Partition um die sogenannte Swap Partition (Auslagerungsspeicher) teilen wir selbiger 10% der Gesamtgröße zu. Man kann einfach “10%” eintragen (Ohne die Anführungszeichen natürlich).

Im nächsten Schritt wählen wir “Primär” aus, damit die Swap Partition auch eine primäre Partition wird.

Auf die Frage, wo die neue Partition angelegt werden soll, wählen wir “Anfang” aus.

Nun müssen wir Ubuntu noch mitteilen, wofür wir die eben erstellte Partition verwenden wollen. Dazu markieren wir “Benutzer als : ” und bestätigen mit der Enter Taste.

Als Zweck der Partition wählen wir “physikalisches Volume für RAID”.

Damit Ubuntu die Änderungen auch erkennt müssen wir im nächsten Dialog noch “Anlegen der Partition beenden” auswählen.

Danach sind wir wieder in Hauptansicht der Partitionierung und können schon deutlich erkennen, dass sich eine primäre Swap Partition mit der Größe 2.1 GB angelegt hat. Darunter sehen wir das von der ersten Festplatte noch 19.3 GB nicht zugeordnet sind. Dort wollen wir unsere Root Partition anlegen. Wir markieren also den entsprechenden freien Bereich wie auf dem nächsten Bild und drücken die Enter Taste. “pri/log 19.3 GB FREIER SPEICHER” wählen.

Auch hier wählen wir wie schon zuvor “Eine neue Partition erstellen” aus.

Im nächsten Dialog Fenster werden wir nach der Größe der Partition gefragt. Hier schlägt uns Ubuntu die gesamten restlichen 19.3 GB vor, was wir mit der Enter Taste bestätigen.

Und auch hier erzeugen wir eine Primäre Partition.

Wie zuvor müssen wir nun wieder festlegen, für was genau wir diese Partition später nutzen wollen. Wir müssen also “Benutzen als : ” auswählen um die entsprechenden Änderungen vorzunehmen.

Da auch unsere Root Partition später in einem Raid Verbund sein soll, wählen wir hier natürlich “physikalisches Volume für RAID” aus.

Zusätzlich müssen wir bei dieser Partition das Boot-Flag setzen, damit Ubuntu auch von dieser Partition booten kann. Das geht ganz einfach, indem man, wie auf dem nächsten Bild ersichtlich, “Boot-Flag” markiert und Enter drückt. Danach sollte dort “Boot-Flag : Ein stehen”.

Jetzt das ganze noch abspeichern, indem wir “Anlegen der Partition beenden” wählen.

In der Übersicht kann man gut erkennen, dass die erste Festplatte für unser Raid Verbund fertig ist. Damit unser Raid 1 funktioniert, müssen wir die Änderungen natürlich auch auf der zweiten Festplatte (sdb) genauso machen, wie zuvor mit der ersten Festplatte. Dazu markieren wir einfach die zweite Festplatte und führen dieselben Schritte durch wie Festplatte sda.

Wenn die zweite Festplatte genauso eingerichtet ist wie die erste Festplatte, sollte alles so aussehen wie auf dem folgendem Bild.

Wir haben jetzt zwar alle nötigen Partitionen angelegt und haben Ubuntu gesagt, dass wir die Partitionen für einen Raid Verbund benötigen. Was nun noch fehlt ist die eigentliche Software-Raid Konfiguration. Wir wählen dazu, wie auf dem nächsten Bild, “Software-RAID konfigurieren” aus.

Natürlich wählen wir im nächsten Dialog “Ja”, um die Änderungen auf das Speichergerät zu schreiben.

Nun müssen wir ein MD-Gerät erstellen. MD steht für Multiple Devices.

Als Typ für unser Software-RAID wählen wir “RAID1″ aus

Raid 1 benötigt minimal 2 Festplatten, wir haben nur 2 Festplatten, also wählen wir auch nur 2 Festplatten.

Reserve-Geräte für unser Raid1-Array sind nicht vorhanden, also lassen wir die “0″ stehen.

Jetzt markieren wir unsere beiden Swap Partitionen /dev/sda1 und /dev/sdb1 und bestätigen mit Weiter.

Als nächstes müssen wir noch den zweiten Raid-Array anlegen. Hierzu erstellen wir wieder ein MD-Gerät.

Auch hier wählen wir Raid1 aus.

Wie zuvor lassen wir auch hier die “2″ stehen.

Da wir auch hierfür kein Reserve-Gerät haben, verändern wir auch hier nichts und lassen die “0″ stehen.

Als Auswahlmöglichkeit bleiben uns nur noch die anderen beiden Partitionen /dev/sda2 und /dev/sdb2. Mit diesen beiden Partitionen erstellen wir unser zweites Raid-Array. Wir wählen beide Partitionen aus und bestätigen mit Weiter.

Nun müssen wir das ganze noch “Fertigstellen” indem wir selbigen Knopf drücken.

Wir kommen wieder auf die Partitionsübersicht, bei der wir erkennen können, dass nun Raid 1 Geräte erstellt wurden. Raid1 Gerät #0 ist unser Swap-Partitions-Raid-1-Array und Gerät #1 ist das Boot-Partitions-Raid-1-Array. Das müssen wir aber unserem Ubuntu noch explizit sagen. Wir wählen hierfür, wie auf dem folgendem Bild, das erste Raid1–Array aus und drücken die Enter Taste.”Nr. 1 2.1 GB” wählen.

Jetzt können wir Ubuntu mitteilen, was er mit dem ersten Raid-Array eigentlich tun soll. Wir ändern dazu das “Benutzen als : ”

Das es unsere Swap Partition werden soll, wählen wir es auch aus.

Nun das ganze noch durch die Auswahl von “Anlegen der Partition beenden” abspeichern.

In der Übersicht erkennt man nun, dass das erste Raid Gerät nun eine Swap Partition ist.

Nun müssen wir noch den zweiten Software-Raid-1-Array konfigurieren. Wir markieren ihn dazu, wie im folgenden Bild und drücken die Enter Taste. “Nr. 1 19.3 GB” wählen.

Auch hier müssen wir Ubuntu noch mitteilen, wozu wir dieses Array benutzen wollen, indem wir “Benutzen als : ” ändern.

Da es sich hierbei um unsere spätere Root Partition handelt, wählen wir als Zweck der Partition “Ext4-Journaling-Dateisystem” aus.

Nun müssen wir in den Partitionseinstellungen der eben erstellen Partition noch den Einbindungspunkt einstellen. Wir markieren dazu “Einbindungspunkt : Keiner” und bestätigen mit der Enter Taste.

Wir wählen im nächsten Dialog das Wurzelsystem “/” aus.

Abschließend muss nun noch die eben gemachte Konfiguration abgespeichert werden, indem wir “Anlegen der Partition beenden” auswählen.

Das ganze wird nun noch abgespeichert, indem wir ganz unten “Partitionierung beenden und Änderungen übernehmen” wählen.

Nun werden wir noch gefragt, ob das System bei Ausfall einer Raid Festplatte weiterhin booten soll. Wir wählen hier “Ja” aus.

Ein allerletztes Mal wird nun die Konfiguration abgespeichert, bevor die Installation von Ubuntu beginnt. Auch hier wählen wir “Ja”.

Die Installation von Ubuntu Server 12.04 beginnt.

Nach der Installation und dem Login sollte es ungefähr so aussehen.

Als erstes wollen wir uns nun mal die Konfigurationsdatei von mdadm ansehen. Das geschieht durch die Eingabe von:

sudo nano /etc/initramfs-tools/conf.d/mdadm

Dort steht BOOT_DEGRADED=true. Das ist so, weil wir beim Setup des Raid Verbundes “Ja” auf die Frage antworteten, ob beim Ausfall einer Festplatte der laufende Serverbetrieb weiterhin laufen soll oder ob man erst wieder auf die Dienste des Servers zugreifen kann, wenn die defekte Festplatte ersetzt und das Raid repariert wurde.

Man kann aber auch jederzeit das mdadm Setup neu aufrufen indem man folgendes eingibt :

sudo dpkg-reconfigure mdadm

Führt man diesen Befehl aus, so gibt es noch 2 weitere Optionen, die man dort einstellen kann und nach denen zuvor nicht gefragt wurde. Das wären zum Einen eine monatliche Redundanzüberprüfung und zum Anderen der MD-Überwachungs Dienst, der uns beim Ausfall per Email benachrichtigen würde. Für dieses Tutorial wählen wir für beide Einstellungen “Nein”.

Zuletzt werden wir dann noch gefragt, was beim Ausfall einer Festplatte passieren soll. Wir entscheiden uns wieder für “Ja”. Aus dieser letzten Einstellung ergibt sich dann auch die mdadm Konfigurationszeile BOOT_DEGRADED=true.

Nun müssen wir dem Kernel noch erlauben bei kaputtem Raid Verbund zu booten, indem wir folgendes eingeben:

sudo nano /etc/default/grub

Uns interessieren hier nur 2 Einträge. GRUB_TIMEOUT und GRUB_CMDLINE_LINUX_DEFAULT.

Den Timeout Wert setzen wir auf 10, damit beim Booten ein wenig mehr Zeit ist, die Bootdetails einzusehen.

GRUB_TIMEOUT=10

In der CMDLINE_LINUX_DEFAULT muss dem Kernel nun noch erlaubt werden auch bei Ausfall einer Raid Festplatte noch zu Booten. Das erreichen wir indem wir bootdegraded=true eintragen :

GRUB_CMDLINE_LINUX_DEFAULT=”bootdegraded=true”

Nun bootet der Server auch dann wenn eine Raid Platte ausfällt. Jetzt noch den veränderten GRUB updaten mit :

sudo update-grub

Zum Testen ob alles funktioniert starten wir unseren Server neu :

sudo reboot

Nach dem Neustart wollen wir uns den Raid-Status einmal etwas genauer ansehen. Das machen wir mit folgendem Befehl:

sudo cat /proc/mdstat

Wir sehen unsere beiden Raid-Verbunde md0 und md1

md0 setzt sich aus sda1 und sdb1 zusammen, unser Swap Bereich. md1 besteht aus sda2 und sdb2, unser Root Bereich.

An den [2/2] sieht man das der Verbund aus 2 Festplatten besteht und an dem [UU] sieht man, ob der Verbund in Ordnung ist. Wäre er es nicht, würde da [U_] zu sehen sein.

Betrachten wir nun die Details zur Raid Konfiguration anzeigen mit :

sudo cat /etc/mdadm/mdadm.conf

ARRAY /dev/md/0 metadata=1.2 UUID=4202e0c0:553680b5:aa264c59:d97c200d name=ubun$ ARRAY /dev/md/1 metadata=1.2 UUID=d32fc5c3:8a90272f:06186f46:4c2e1086 name=ubun$

Hier stehen die Informationen über die Raid Verbunde sowie die UUID´s.

Unser Raid-1-Verbund ist somit voll funktionsfähig. Nun wollen wir einen Ausfall simulieren um anschließend eine neue Festplatte einzubauen und den Raid Verbund letztendlich wieder herzustellen.

Um das zu erreichen fahren wir unseren Server erst einmal herunter mit :

sudo shutdown -h now

Jetzt entfernen wir in der VMWare die zweite Platte und simulieren somit einen Festplattenausfall.

Wir booten normal um festzustellen, ob der Server auch bei Ausfall einer Platte noch funktioniert. Etwas Geduld, da das Booten nun etwas länger dauert.

Nach dem erfolgreichem Booten und Login lassen wir uns den Raid Status erneut anzeigen mit :

sudo cat /proc/mdstat

Wir sehen das die Einträge von sdb nicht mehr vorhanden sind (Festplatte 2)

An dem [U_] oder auch [_U] erkennt man, dass eine unserer Festplatten nicht synchron ist. Wie schon zuvor erwähnt würde bei einem intakten Raid-Array dort [UU] stehen. Man sieht auch an dem [2/1] das irgendwas nicht mehr stimmt. Bei intaktem Raid stand dort ja noch [2/2].

Betrachten wir nun erneut die Details zur Raid Konfiguration :

sudo cat /etc/mdadm/mdadm.conf

Das alte Raid-Array ist somit in der Konfiguration noch vorhanden

Wir wollen uns nun die beiden Raid-Arrays noch genauer betrachten. Das machen wir mit folgenden Befehlen:

Für den ersten Verbund :

sudo mdadm --detail /dev/md0

Und für den zweiten Verbund :

sudo mdadm --detail /dev/md1

Man kann gut erkennen, dass bei beiden Arrays unter Total Devices nur noch eine 1 steht. Ein deutliches Zeichen dafür, dass eine Platte ausgefallen sein muss. Wir fahren unseren Server erneut herunter mit:

sudo shutdown -h now

Als nächstes müssen wir uns zunächst in der VMWare eine neue 20 GB Platte erstellen und somit den Einbau einer neuen Platte simulieren.

Es gibt 2 Möglichkeiten : Beide Festplatten im Array müssen die exakt gleiche Partitionierung haben. Je nach verwendeter Partitionstabelle (MBR oder GPT) sind dafür verschiedene

Vorgehensweisen notwendig. Die GPT Partitionstabelle kommt in der Regel auf Systemen mit Festplatten größer 2Terrabyte zum Einsatz.

In unserem Beispiel verwenden wir Festplatten mit MBR, würden wir Festplatten mit GPT verwenden, so würden wir die nächsten Zeilen überspringen und bei Festplatten mit GPT weiterlesen.

Festplatten mit MBR:

Die MBR Partitionstabelle einer Festplatte lässt sich mittels sfdisk einfach kopieren :

sudo sfdisk -d /dev/sda | sfdisk /dev/sdb

Falls die Partitionen im System nicht sichtbar werden, muss die Partitionstabelle durch den Kernel neu eingelesen werden. Das erreichen wir durch den Befehl :

sudo sfdisk -R /dev/sdb

Auch hier müssen wir sdb1 ins md0 Array und sdb2 ins md1 Array ein, indem wir folgende Befehle ausführen:

sudo mdadm /dev/md0 -a /dev/sdb1

und

sudo mdadm /dev/md1 -a /dev/sdb2

Führt man die Reparatur im gebooteten System durch, genügt bei GRUB2 ein grub-install auf die neue Festplatte:

sudo grub-install /dev/sdb

Details zu den neuen Arrays anzeigen lassen mit :

sudo mdadm --detail /dev/md0 sudo mdadm --detail /dev/md1

Noch mehr Einzelheiten mit :

sudo mdadm --examine /dev/sda1 sudo mdadm --examine /dev/sda2 sudo mdadm --examine /dev/sdb1 sudo mdadm --examine /dev/sdb2

Um sicher zu gehen, das alles richtig funktioniert folgenden Befehl eintippen :

sudo echo check > /sys/block/md0/md/sync_action sudo echo check > /sys/block/md1/md/sync_action

Hiermit wird die Synchronisation neu ausgeführt. Anschließend können wir uns das Ergebnis angucken :

sudo cat /proc/mdstat

Ist die Synchronisation abgeschlossen, sieht das ganze dann so aus:

Festplatten mit GPT:

Ist die Festplatte eingebaut, booten wir den Server und installieren die Software sgdisk mit folgendem Befehl :

sudo apt-get install gdisk

Das Tool sgdisk macht es uns sehr einfach, die Partitionstabelle auf die neue Festplatte zu kopieren.

Um genau das zu erreichen geben wir folgenden Befehl ein :

sudo sgdisk -R /dev/sdb /dev/sda

Anzumerken ist, dass sdb unsere neue Festplatte ist und sda die alte, von der wir die Partitionstabelle kopieren.

Anschließend gibt man der Festplatte eine neue zufällig UUID mit folgendem Befehl :

sudo sgdisk -G /dev/sdb

Nun kann die neue Festplatte, bzw. Ihre Partitionen eingebunden werden. Wir binden sdb1 ins md0 Array und sdb2 ins md1 Array ein, indem wir folgende Befehle ausführen:

sudo mdadm /dev/md0 -a /dev/sdb1

und

sudo mdadm /dev/md1 -a /dev/sdb2

Die neue Festplatte ist somit Teil des Arrays und wird nun synchronisiert. Dieser Vorgang kann je nach Größe eine ganze Weile dauern. Den Status der Synchronisation lassen sich sehr gut mit folgendem Befehl einsehen:

sudo cat /proc/mdstat

Führt man die Reparatur im gebooteten System durch, genügt bei GRUB2 ein grub-install auf die neue Festplatte:

sudo grub-install /dev/sdb

Details zu den neuen Arrays anzeigen lassen mit :

sudo mdadm --detail /dev/md0 sudo mdadm --detail /dev/md1

Noch mehr Einzelheiten mit :

sudo mdadm --examine /dev/sda1 sudo mdadm --examine /dev/sda2 sudo mdadm --examine /dev/sdb1 sudo mdadm --examine /dev/sdb2

Um sicher zu gehen, das alles richtig funktioniert folgenden Befehl eintippen :

sudo echo check > /sys/block/md0/md/sync_action sudo echo check > /sys/block/md1/md/sync_action

Hiermit wird die Synchronisation neu ausgeführt. Anschließend können wir uns das Ergebnis angucken :

sudo cat /proc/mdstat

Praxistipps: In der Praxis sollte man natürlich nicht die heile Platte ausbauen. Damit das nicht passiert kann man sich die Seriennummern der Festplatten am Bildschirm ausgeben lassen, und das geht mit folgendem Befehl :

sudo smartctl -i /dev/sda

Sollte smartctl nicht installiert sein, kann man das durch Eingabe folgendes Befehls nachholen:

sudo apt-get install smartmontools

Alternativ kann man sich die Seriennummer auch mit folgendem Befehl anzeigen lassen :

sudo hdparm -i /dev/sda

Das klappt in der VMWare natürlich nicht, weil die Festplatten ja nur virtueller Natur sind und keine eigene Seriennummer besitzen.