Debian Sarge auf Hetzner DS3000 mit RAID1 auf VIA Chipsatz installieren

Dienstag, 25. Dezember 2007

Diese Anleitung behandelt den Hetzner Root-Server DS 3000 mit VIA Chipset. Klar, einer der größeren Server wäre mir zum Testen lieber gewesen, die Anleitung wird bei abweichender Hardware natürlich nicht mehr funktionieren.

# lspci
0000:00:0f.0 RAID bus controller: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80)

Das verwendete Mainboard MSI Neo2-F mit VIA Chipsatz hat zwar die Möglichkeit, ein Array zu erstellen:

...

Hetzner Lara BIOS Config RAID Array VIA

Das Array wird hinterher auch angezeigt:

...nutzbar ist es aber nicht, da unter Debian weiterhin beiden Platten erscheinen, und kein Array zu sehen ist, auch zwischen den Platten nicht synchronisiert wird. Der Sinn dieser Funktion erschliesst sich mir nicht.

Ob Debian diesen Controller standardmäßig unterstützen würde, habe ich gar nicht probiert, sicherheitshalber sagen wir Debian bei der Installation, dass es die benötigten Module in die initrd packen soll, damit gehen wir auf Nummer sicher. Debian wird diese Einstellung auch bei Kernel Updates (z.B. bei Sicherheitslücken) berücksichtigen, dadurch sollten wir immer einen Kernel erhalten, der auf dieser Hardware sauber bootet.

Wir installieren wieder ein reines 32 Bit System, da 64 Bit-Systeme bei dieser Hardware (1 Gbyte RAM) unsinng sind und der 64-Bit Overhead den Rechner nur ausbremst.

Das vorinstallierte Hetzner-Image war bei mir nicht mit RAID eingerichtet. Prinzipiell installiere ich meine Systeme sowieso lieber selbst, dann weiss ich wenigstens genau, was am Ende auf dem Server installiert ist.

Praktisch bieten preiswerte RAID-Controller (wie sie auf Mainboards oft verbaut werden) aber sowieso nur einen geringen Nutzen, da sie keine eigene CPU haben und hauptsächlich das Initalisieren der Arrays verwalten. Der Rechenaufwand wird bei diesen Controllern durch die CPU geleistet, insofern sollte ein reines Software-RAID vergleichbar performant sein.

Hetzner bietet durch seine seriellen Konsolen Zugriff auf das BIOS des Rechners.

Meinem Wunsch nach RAID-Arrays liegt aber nicht die Performance, sondern die Datensicherheit, zu Grunde. Mein Ziel ist es, alle Datenpartitionen als gespiegeltes RAID-1 zu betreiben. Die Masterbootrecords der beiden Festplatten bleiben eigenständig, d.h. den Bootloader installiere ich nur auf der ersten Festplatte, eine Installation kann aber optional auch auf der 2ten Festplatte vorgenommen werden, damit auch die 2te Festplatte allein bootfähig ist.

Ob dies dann im Havariefall auch wirklich funktioniert, ist meiner Ansicht nach nicht so relevant, denn eine hoch verfügbare Webanwendung wird man sicher nicht auf einem solchen System laufen lassen. Außerdem gibt es dann verschiedene Dinge zu bedenken:

1. Der Bootloader muss an die 2te Festplatte angepasst werden
2. Im / nach einem Havariefall muss die Festplatte auch weiterhin an der bekannten Hardwareadresse ansprechbar sein

Letztendlich ist dies bei einem Root-Server ohne physikalische Zugriffsmöglichkeit nicht vorher testbar, exakt gleiche Hardware hat man regulär auch nicht daheim herumstehen. Erst im Havariefall wird man schlauer sein.

• Nun wird sich manch einer fragen: Warum dann das RAID 1?

Die Plattengrößen von 2mal 160 Gbyte bietet einem klassischen Webserver mehr als genügend Platz. Durch das RAID1 bleiben wenigstens 160 Gbyte nutzbar und die Daten werden auf beiden Platten redundant abgelegt. Beim Ausfall der ersten Festplatte würde das System zwar nicht mehr rebooten, dies muss es regulär aber gar nicht, da die SATA-Platten und Chipsatz hoffentlich HotPlug fähig sind, ich also davon ausgehe, dass im Havariefall der Server weiter läuft und die Platte im laufenden Betrieb getauscht werden kann. Selbst wenn diese Voraussetzung nicht gegeben sein sollte, kann man sicher mit dem Techniker eine Übereinkunft bezüglich der Uhrzeit des Plattenwechsels treffen. Für das Recovery der Arrays muss man in jedem Fall eine Downtime einplanen -> es könnte ja etwas schief gehen.

Recovery-Überlegungen:

• Ausfall sdb:

1. sdb tauschen lassen
2. sdb einrichten
3. Array Recovery

• Ausfall sda:

1. sda tauschen lassen
2. sda einrichten
3. Array Recovery
4. Bootmanager in den MBR schreiben

• Ausfall sda und notweniger Reboot

1. Rescue System booten
2. sdb nach / mounten
3. Bootmanager in den MBR installieren

Dieser Schritt kann durch eine Vorinstallation des Bootmanagers in den MBR der sdb vorbereitet werden.

In jedem Fall sollte die Downtime drastisch geringer ausfallen, als bei einer Neuinstallation mit anschliessendem Restore der Daten aus dem Backup.

Beim Bootvorgang muss nun der Bootloader den Kernel usw. anfangs direkt von einer Partition (nicht vom Array) laden, was aber read-only erfolgt und somit kein Problem ist.

Folgendes Partitionierungsschema habe ich mir überlegt:

Die Aufteilung kann natürlich jedermann selbst an seine Bedürfnisse anpassen. Die /backuppartition könnte man natürlich auch als RAID0 gestalten, man sollte jedoch bedenken, dass im Havariefall eine beachtliche Zeit vergehen kann, bis man große Datenmengen vom Backup-FTP (falls man einen hat) zurückgeholt hat, denn bei einem RAID0 ist ja beim Ausfall einer Platte das gesamte Array verloren. Die Backuppartition ist wegen der geplanten Nutzung von differentiellen Backups größer als der Rest. Nicht alle Webs sind in der Sicherung inbegriffen, es gibt Daten in den web Verzeichnissen, die auf Datenträgern vorliegen und notfalls auch von dort wieder eingespielt werden können. Für meine Zwecke werden ca 60 Gbyte auf der /var Partition, auf der ich die webs anlege, mehr als ausreichend sein.

Dass die Backuppartition nicht /backup heisst liegt in der Handhabung meiner Backup-Excludelisten begründet.

Auf den nächsten Seiten schilde ich nun detailiert die Installation des Servers mit Debian GNU/Linux Sarge aus dem Rescue-System heraus.