Neues Partitionierungs- und Boot-Konzept für Hardware-Systeme und VServer

Eine auf den ersten Blick einfache, auf den zweiten Blick jedoch alles andere als triviale Frage ist, wie auf einem Server das Betriebssystem geladen wird. Generell ist der Ablauf auf Linux-Systemen so, dass man an den Anfang der Festplatte einen Bootloader (Grub, LILO) installiert. Das BIOS lädt diesen. Der Bootloader lädt dann von der Festplatte den Kernel nach, welcher danach wiederum gestartet wird und seinerseits den ersten Prozess, init, aufruft.

Kompliziert wird es dann, wenn man nicht nur eine einzelne Festplatte im Rechner hat, sondern zum Beispiel ein Software-RAID betreibt – am besten ein relativ komplexes, wie RAID 6 – und dazu noch LVM (Logical Volume Manager) nutzen möchte. Das RAID ist aufgrund der Datensicherheit oft unerlässlich und LVM erleichtert die Partitionierung eines Servers ungemein, so dass man darauf nicht mehr verzichten möchte, wenn man es einmal im Einsatz hatte.

Bisheriges Vorgehen

Wir haben auf unseren Servern in der Regel sowohl ein RAID, als auch LVM im Einsatz. Damit dies mit den bisherigen Bootladern funktionierte, haben wir Festplatten in mehrere Partitionen unterteilt. Die erste Partition ist dabei eine nicht-LVM-Partition mit einem einfachen RAID, wie z.B. RAID 1. Auf dieser befindet sich das Betriebssystem. Der restliche Festplattenplatz ist dann dem eigentlich gewünschten RAID, z.B. einem RAID 6 zugewiesen. Auf diesem ist LVM aufgesetzt, welches es ermöglicht, flexibel virtuelle Partitionen zur Verfügung zu stellen, z.B. für die /var-Partition des Betriebssystems, aber auch für Datenablagen oder Partitionen für zusätzliche virtuelle Server.

Damit der Kernel die erste RAID-Partion beim Booten erkennt, bedienen wir uns eines Tricks: md-raid kennt verschiedene Metadatenformate. Version 0.9 ist zwar bereits etwas älter, wird jedoch als einziges Datenformat direkt vom Kernel erkannt. Der Linux-Kernel ist somit in der Lage, direkt aus den vorhandenen Festplatten ein RAID beim Booten zu erzeugen und auf dieses zuzugreifen. Version 0.9 des Metadatenformats hat jedoch den Nachteil, dass es nur Partitionen bis zu einer Größe von 2 TB unterstützt. Somit ist es z.B. nicht möglich, eine 3 TB-Festplatte am Stück zu partitionieren. Da wir jedoch LVM einsetzen lässt sich diese Einschränkung umgehen, indem man einfach mehrere, kleinere Partitionen anlegt und diese später mittels vgcreate zu einer großen Volumegroup zusammenfasst. Da wir LVM nicht für die Bootpartition einsetzen kommt unser Kernel ganz ohne initrd aus.

Virtuelle Server, welche auf den Hardware-Maschinen eingerichtet sind, haben wir bislang in ähnlicher Weise angelegt und gebootet. Da die VServer meist kleiner sind haben wir dabei auf LVM verzichtet. VServern wird eine einzelne virtuelle Festplatte zugewiesen, welche dann ganz klassisch partitioniert und mit einem Bootloader versehen wird. Vorteil ist, dass sich der VServer wie ein ganz normaler Rechner verhält und ein System z.B. auch 1:1 auf reale Hardware kopiert werden kann und dann dort lauffähig ist. Nachteilig ist die fehlende Flexibilität bei einer späteren Umpartitionierung. Hierfür würde es sich anbieten, auf dem Wirtssystem mehrere LVM-Partitionen anzulegen und diese als verschiedene virtuelle Festplatten an den VServer durchzureichen. Die meisten Bootloader kommen jedoch nicht mit einer Bootpartition /dev/sda zurecht. Sie erwarten stattdessen eine echte Partitionierung der Festplatte. D.h. man müsste zumindest die erste virtuelle Festplatte nochmals unterteilen, so dass man ein Boot-Device /dev/sda1 erhält. Das verkompliziert das Konzept jedoch bereits wieder so sehr, dass wir von solchen Systemeinrichtungen in der Regel bislang abgesehen haben.

Neues Partitionierungsschema

Die Möglichkeit der automatischen Erkennung von RAIDs durch den Kernel bei Verwendung des Metadatenformats 0.9 ist zwar komfortabel, jedoch auf Dauer keine Lösung. Spätestens mit der Einführung der ersten 100TB-Festplatte müssten wir uns wohl nach neuen Lösungen umsehen. Zudem wäre es schön, wenn wir die gesamte Festplatte per LVM flexibel in Partitionen unterteilen könnten und nicht nur den Teil hinter der ersten Partition, deren Größe somit bereits am Anfang feststeht und sehr schlecht im späteren Betrieb angepasst werden kann.

Wir haben daher für das Booten unserer Hardware-Maschinen und der VServer ein komplett neues Konzept erarbeitet, welches wir nun seit einigen Monaten erfolgreich auf unseren neuen Servern einsetzen. Kern der Änderung ist eine Umstellung des Bootloaders auf GRUB2. GRUB2 bietet deutlich mehr Möglichkeiten, auch von speziellen Partitionen zu booten, als es bislang LILO oder GRUB1 getan haben. Hierdurch ist es möglich, Festplatten z.B. direkt mit einem RAID 6 zu versehen und auf diesem RAID ein LVM aufzusetzen.

Damit der Kernel selbst jedoch auch auf die LVM-Partitionen zugreifen kann, muss er während des Bootvorgangs sowohl das RAID (welches nun im modernen Metadatenformat 1.2 vorliegt) als auch das LVM automatisch erkennen. Wir setzen hierfür eine Initial Ramdisk (initrd) ein. Hierbei handelt es sich um eine Sammlung von Skripten und Programmen, welche in den Kernel eingebettet sind. Sie werden während des Bootvorgangs vom Kernel in den Arbeitsspeicher geladen und dann wie eine Festplattenpartition behandelt. Die Programmsammlung wurde von uns zusammengestellt und enthält alle Tools zur automatischen Erkennung von RAIDs und des LVMs.

Um zukünftig auch VServer flexibler ändern zu können, erstellen wir nun für jeden VServer nicht mehr eine große, sondern mehrere kleinere LVM-Partitionen im Wirtssystem des Servers. Diese werden dann als Festplatten /dev/sda, /dev/sdb, /dev/sdc, etc. an den VServer weiter gereicht. Bei notwendigen Änderungen können Partitionen dadurch schnell im LVM vergrößert, verkleinert oder ausgetauscht werden. Ein weiterer Vorteil ist, dass Partitionen sowohl im Vserver, als auch im Wirtssystem ohne zusätzliche Schritte gemountet werden können. Damit der VServer trotz fehlender /dev/sda1-Partition weiter booten kann verzichten wir nun ganz auf einen im VServer installierten Bootloader und Kernel. Der Kernel liegt stattdessen außerhalb des VServers und wird vom Virtualisierungssystem geladen. Dies vereinfacht den Bootprozess erheblich. Für Kernel-Updates muss zudem nur noch eine einzige Datei auf dem Wirtssystem augetauscht werden. Ein- und dieselbe Datei kann dabei für mehrere VServer verwendet werden. Da auf den VServern weder RAID noch LVM eingesetzt werden (diese gibt es ja bereits auf dem Wirtssystem) kommt der VServer-Kernel außerdem auch ohne initrd aus.

Fazit

Wir hatten bereits in den früheren Jahren ein sehr ausgereiftes, einfaches und dennoch flexibles System zum Booten unserer Server im Einsatz. Durch die Umstellung auf das neue Schema wird dieses Konzept nun nochmals vereinfacht und somit übersichtlicher gestaltet. Wir gewinnen durch den Verzicht auf eine Boot-Partition und Partitionierung innerhalb der VServer noch mehr Flexibilität und durch die Verwendung des neuen Metadatenformats auch Zukunftssicherheit.