Debian Etch auf Strato HighQ-Server XPro4 mit RAID 1 Installation

Sonntag, 09. Dezember 2007

Strato hat neue Root-Server im Angebot.

Das größte Modell ist der HighQ-Server Xpro4, mit 4 Gbyte Arbeitsspeicher, einem Opteron 1218 HE (energiesparende Version) und 2 400 Gbyte SATA-Festplatten.

Leider bildet der verbaute RAID-Controller das Array nicht als sda ab, sonder man kann beide Festplatten direkt ansprechen und muss sich also sein Software-Raid selbst basteln.

Performancetechnisch sollte das kein Problem sein, da RAID-Controller in dieser Preisklasse sowie keine eigene Recheneinheit haben, sondern nur die Verwaltung des Arrays übernehmen. Die CPU muss also in jedem Fall die Arbeit übernehmen.

Strato bietet zwar mittlerweile ein Debian 4.0 "Etch" Image an, hier ist die Festplatte aber in meinen Augen ungünstig partitioniert.

Ich möchte mehrere Partitionen, da ich mir davon einen Performancevorteil aufgrund der kleineren Datei-Zuordnungstabellen verspreche, außerdem muss ich dann bei Verlust eines FileSystems nur eben dieses eine FileSystem restoren.
Auf LVM verzichte ich, da ich bei der Laufzeit eines gemieteten Servers keine großartigen Änderungen am Platten-Layout erwarte.

Diese Installationsanleitung behandelt die Installation der aktuellen Debian Version 4.0 "Etch" auf diesem Server. Folgende Features werden verwendet:

1. Debian 4 "Etch" Minimalsystem
2. Festplatten als RAID Arrays (Software-Raid)
3. GNU Grub kommt als Boot-Loader zum Einsatz
4. Automatische Boot-Loader-Konfiguration nach Kernel-Änderungen
5. Netzwerkkonfiguration via DHCP

Bei einem RAID-System muss man natürlich gewisse Überlegungen bezüglich der Ausfallsicherheit treffen.

Hierbei gibt es aber Einiges zu bedenken:

• Wenn eine Festplatte defekte Sektoren hat, bleibt der Server beim Booten evt. stehen, da der Boot-Loader nicht gelesen werden kann
• Fällt die Platte physikalisch aus, erkennt der Server die verbleibende Platte als sda, man müsste also, falls die erste Platte ausfällt, auf der 2ten Platte einen Boot-Loader so einrichten, dass er beide Platten zu laden versucht.
  
  Das ist zwar mit Grub kein Problem, aber....

Ziel war ja, wie oben beschrieben, eine Automatisierbarkeit des Boot-Loaders, da wird es hier schwierig.

Erstes Ziel ist ja die Spiegelung der Daten, sollte eine Platte ausfallen, muss man dann auf die konkrete Gegebenheit reagieren und die getauschte Platte entsprechend einbinden. Alle möglichen Szenario zu testen, ist bei einem Mietserver nicht möglich, daher soll der Artikel dies nicht berücksichtigen.