Zur Übersicht
Hat dir diese Seite weitergeholfen?
Durchschnittliche Bewertung (Rootserver):
2.93/3 (458 Stimmen)

Rootserver-Umzug mit RAID und LVM

...ein Tapetenwechsel mit Hindernissen

Nachdem Alturo seine Tore schließt, ist meine Seite nun auf einen Rootserver bei Hetzner umgezogen. Allerdings wollte ich weder ein neues System installieren, noch eine der von Hetzner angebotenen Installationen benutzen - Ich habe daher meinen alten Server komplett auf das neue System kopiert, das jedoch nun auch RAID und LVM nutzt.

Ein erster Blick

Nach der Installation durch Hetzner findet sich ein minimales Debian-System (Sarge) auf der ersten der beiden SATA-Platten. Über einen SSH-Daemon und das voreingestellte root-Passwort lässt sich hier der Server in Augenschein nehmen, oder auch das vorhandene System aufbauen. Da wir jedoch die zweite Platte als RAID benutzen möchten, kopieren wir lediglich die Netzwerkkonfiguration aus /etc/network/interfaces.

Die beiden 160GB-SATA-Platten sollen später wie folgt genutzt werden: Auf beiden Festplatten sollen 2GB große Partitionen enstehen, die dann zu einem RAID-1 zusammengefasst das Root-Verzeichnis (/) berhebergen. Danach folgt auf beiden Festplatten je eine 1GB große Swappartition, die nicht gespiegelt wird - stattdessen steht dem System damit ausreichend Auslagerungsspeicher auf zwei verschiedenen Festplatten zur Verfügung. Der verbleidende Platz wird dann wiederum als RAID genutzt, das dem Logical-Volume-Management als "physical Volume" dient; innerhalb des LVMs entstehen dann die weiteren Volumes für /usr/, /var und /home.

Zwar wäre es durchaus möglich, den Umzug aus dem bereits installierten Minimalsystem durchzuführen - da dieses jedoch spätestens nach der Installation des neuen Bootloaders nicht mehr erreichbar wäre, sollte der Server nun über das Rescue-System gestartet werden: Dazu aktiviert man diese Bootoption einfach im Hetzner-Webinterface und startet den Server anschließend neu.

Scheibenwelt

Partitionen: Teile und herrsche

Das Rettungssystem bringt bereits alle notwendigen Pakete mit, um sowohl RAID als auch LVM zu konfigurieren - fehlende Pakete lassen sich jedoch auch einfach mit apt-get install <paketname> nachinstallieren, sofern die RAM-Disk noch nicht vollständig gefüllt ist.

Nun geht es zunächst daran, die Partitionen auf den beiden Festplatten anzulegen: Dazu können entweder das spartanische fdisk oder das etwas komfortablere cfdisk dienen, ich habe mich für das erstgenannte Programm entschieden. Die beiden angelegten RAID-Partionen erhalten den Typ fd (sda1 und sda3), die Swap-Partition sda2 den Typ 82. Damit ist die erste Festplatte bereits eingerichtet, und das folgende Kommando überträgt die fertige Partitionstabelle auch auf deren Zwilling:

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

Um dem System die Arbeit zu erleichtern, können wir nun bereits die beiden Swap-Partitionen in Betrieb nehmen:

# Swapspace einrichten
mkswap /dev/sda2
mkswap /dev/sdb2
# ...und aktivieren
swapon /dev/sda2
swapon /dev/sdb2

RAID-Einrichtung: Die Zwillingsgeburt

Die mit dem Typus fd gekennzeichneten Partitionenspaare sollen nun zu RAID-Arrays zusammengefügt werden; Dazu dient das Programm mdadm:

mdadm --create /dev/md0 --level 1 --raid-devices=2 /dev/sda1 /dev/sdb1
mdadm --create /dev/md1 --level 1 --raid-devices=2 /dev/sda3 /dev/sdb3

Der Kernel beginnt nun damit, die Partitionen der beiden Arrays zu synchronisieren: Den Fortschritt kann man mit dem Kommando cat /proc/mdstat ablesen. Je nach Größe der Festplatten kann die Synchronisierung einige Zeit in Anspruch nehmen, die neuentstandenen RAID-Devices md0 und md1 können jetzt bereits schon genutzt werden.

Root-Dateisystem: An der Wurzel gepackt

Das RAID-Gerät md0 soll später das Wurzel des Dateibaums beherbergen; Dazu kann nun bereits das Dateisystem erstellt werden:

mkfs.ext3 /dev/md0

LVM auf RAID: Digitaler Schichtsalat

Nachdem die Partitionen sda3 und sdb3 nun bereits unter dem RAID-Blockdevice md1 vereint wurden, legt sich nun eine weitere Schicht über die Datenträger: LVM fasst sogenannte Physical Volumes zu Volume Groups zusammen, in denen schließlich dann die Logical Volumes, also die schlussendlichen Dateisysteme entstehen. Hier in unserem Fall besteht die einzige Volume-Gruppe nur aus einem physischen Volume, nämlich dem RAID-Array md1: Mit dem Programm pvcreate (Physical Volume Create) schreibt LVM seine Signatur auf dem Datenträger an:

pvcreate /dev/md1

Da sich nun langsam sehr viele Schichten überlappen, ist Vorsicht geboten: Schnell wendet man Befehle auf die falsche Ebene an, und vertauscht LVM-Volumes, RAID-Array und Partitionen.

Aus dem physischen Volume erzeugen wir nun eine Volume Group namens main:

vgcreate main /dev/md1

Nun fehlen nur noch die logischen Volumes - um später auf sich ändernde Umstände vorbereitet zu sein, habe ich noch Platz in der Volume-Gruppe gelassen.

lvcreate -n usr -L 10G main
lvcreate -n var -L 30G main
lvcreate -n home -L 50G main

Genau wie die Root-Partition werden die logischen Datenträger nun mit dem EXT3-Dateisystem formatiert:

mkfs.ext3 /dev/main/usr
mkfs.ext3 /dev/main/var
mkfs.ext3 /dev/main/home

Damit ist die Einrichtung der Festplatten abgeschlossen - Die Installation des Betriebssystems kann beginnen.

Fernkopierer

Vorbereitendes

Nun soll das bereits installierte System vom alten auf den neuen Rootserver kopiert werden - wer stattdessen eine neue Installation durchführen möchte, kann dies mit debootstrap tun: Die eigentliche Installation sollte sich nicht groß von der bei Alturo unterscheiden.

In jedem Fall müssen die neu angelegten Partitionen gemountet werden, beispielsweise unterhalb des Verzeichnisses /target/:

mkdir /target
mount /dev/md0 /target
# Unterverzeichniss anlegen
mkdir /target/home
mkdir /target/var
mkdir /target/usr
# Weitere Partitionen mounten
mount /dev/main/usr /target/usr/
mount /dev/main/var /target/var/
mount /dev/main/home /target/home/

Damit steht unterhalb von /target/ der künftige Dateibaum bereit, in den nun kopiert werden soll. Zum Kopieren selbst bietet sich das Programm rsync an, dass seine Übertragung standardmäßig über SSH, also gesichert durchführt, und auch unterbrochene Übertragungen fortsetzen kann. Es ist jedoch nicht im Rettungssystem installiert, so dass es mit apt-get install rsync nachinstalliert werden muss.

Los geht's

Bei der Übertragung der Daten spielt die Konsistenz eine wichtige Rolle: Beim Kopieren sich verändernder Daten (Datenbanken, Logfiles) kann es schnell zu Inkonsistenzen kommen. Das Quellsystem sollte sich daher ebenfalls im Rescue-System befinden, oder zumindest du betreffenden Dienste (Apache, MySQL etc.) herunterfahren, um Veränderungen an den betreffenden Datei zu vermeiden. Um die Dienstunterbrechung jedoch so gering ie möglich zu halten, ist es problemlos möglich, die Daten, die sich nicht ändern (wie z.B. die Dateien unter / und /usr) aus dem laufenden System zu kopieren. Dazu dient auf dem Quellsystem (als root) der folgende Befehl:

rsync -vatx --progress / /usr Ziel-IP-Adresse:/target/

Die beiden Rechner kopieren daraufhin die Root- als auch die Usr-Partition auf das neue System; Der Schalter x sorgt dafür, dass rsync keine Dateisystemgrenzen überschreitet, und damit Verzeichnisse wie /proc und /var ausspart - vorausgesetzt, diese befinden sich auf eigenen Partitionen.

Die Übertragung der veränderlichen Daten aus /home/ und /var erfolgt auf die gleiche Weise, jedoch mit möglichst wenig laufenden Diensten - am besten startet man das System dazu im Rescue-Modus, damit sich die Daten während des Kopierens nicht verändern.

Startklar machen

Nun muss noch dafür gesorgt werden, dass das neue System auch startet: Die meisten neuen Systeme benutzen udev, so dass sie eigentlich keine statischen Dateien in /dev mehr benötigen: Beim Systemstart jedoch benötigt der Kernel mindestens die Datei /dev/console, da er ansonsten den Start mit einer Kernelpanic und der Meldung Unable to open initial console abbricht. Diese fehlende Datei kann man einfach vom Rettungssystem übernehmen:

cp -a /dev/console /target/dev/console

Nun müssen wir zudem den Bootloader installieren, damit dieser das neu installierte System starten kann: Grub benötigt ein vollständiges /dev, so dass wir einfach das Dev-Verzeichnis des Rettungssystem vorrübergehend zweimal in den Dateibaum einblenden:

mount /dev/ /target/dev/ -o bind

Dadurch erscheint das Verzeichnis auch innerhalb des neuen Dateibaums, so dass wir nun das Zielverzeichnis /target als neues Root-Verzeichnis setzen können:

chroot /target

Wir befinden uns nun um kopierten System, und können nun alle wichtigen Änderungen vornehmen. Dazu zählen vor allem die zu mountenden Partitionen in der Datei /etc/fstab und die Netzkonfiguration in /etc/network/interfaces.

Ebenso muss natürlich die neue Root-Partition auch in der Grub-Konfiguration angegeben werden, und auch die Installation des Bootloaders im MBR steht noch aus. Dazu bedienen wir uns der Grub-Shell (Aufruf mit grub):

grub> root (hd0,0) 
 Filesystem type is ext2fs, partition type 0xfd

grub> setup (hd0)
 Checking if "/boot/grub/stage1" exists... yes
 Checking if "/boot/grub/stage2" exists... yes
 Checking if "/boot/grub/e2fs_stage1_5" exists... yes
 Running "embed /boot/grub/e2fs_stage1_5 (hd0)"...  16 sectors are embedded.
succeeded
 Running "install /boot/grub/stage1 (hd0) (hd0)1+16 p (hd0,0)/boot/grub/stage2 /boot/grub/menu.lst"... succeeded
Done.

In diesem Fall ist Grub jedoch auf eine funktionsfähige erste Platte angewiesen, fällt diese aus, so ist der Bootloader außer Gefecht gesetzt.

Jetzt ist der Zeitpunkt gekommen, das System neu zu starten: Wenn alles gut lief, sollte sich der Rechner nach einiger Zeit mit dem neuen alten System melden.