Rootserver-Umzug mit RAID und LVMEin 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.
