Debian Sarge auf STRATO MR2 Server mit RAID1 auf AMD Chipsatz

Freitag, 07. Dezember 2007

Updates vom 01.03.2006:

1. Kernel: Wird nun K7 Version verwendet
2. dhcp Client: Verwendung eines dhcpd der ohne Scripte auskommt

Strato bietet neuerdings Rootserver mit AMD Opteron Prozessoren und mehreren Festplatten zu attraktiven Preisen an.

Sicher gibt es auch andere gute Root-Server-Anbieter, in Bezug auf Preis/Leistung fällt es jedoch schwer, Strato das Wasser zu reichen. Immerhin stattet Strato jeden Root-Server mit serieller Konsole aus, so dass ein Zugriff auch bei verkonfigurierten Netzwerk möglich ist. Dieses Feature muss man woanders oft extra bezahlen. Auch 100% Backupspace auf einem FTP-Server sind nicht zu verachten.

In dem AMD Rootserver bei Strato sind meines Wissens (so ists bei meinem Server) AMD Chipsätze verbaut, im Gegensatz zu SiS Chipsätzen, wie das teilweise woanders der Fall sein soll.

Strato liefert neuerdings leider kein Confixx mehr dazu, sondern Plesk. Ich bin nun beleibe kein Confixx-Fan, aber beim Lesen der Plesk Dokumentation kamen mir starke Zweifel, ob ein halbwegs verantwortungsvoller Administrator Plesk installieren sollte. So schreibt die Doku zum Beispiel, dass der Safe Mode von Plesk während der Installation ausgeschaltet wird, man könne ihn ja pro Domain wieder einschalten. Umgekehrt würde der Ansatz aus meiner Sicht mehr Sinn machen. Außerdem muss man qmail als Mailserver nehmen, die Pakete stammen zu einem gewissen Teil für Debian nicht aus dem Debian Repository, sondern kommen mit Plesk daher, dies schmeckt mir auch nicht.

Strato bietet die AMD64 Opteron Linux Server in verschiedenen Varianten an. Die kleinen und mittleren Modelle haben allerdings keinen RAID-Controller.

Strato bewirbt diesen Server nicht aktiv mit RAID, sondern nur mit RAID-ready, demnach steht keine Image-Installation mit eingerichteten RAID zur Verfügung. Nach meinem Wissen ist dies selbst bei dem nächst größeren Server, welcher mit RAID-Controller beworben wird, nicht der Fall.

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. Mangels Zugang zum BIOS des Controllers relativiert sich der Nutzen nochmals deutlich. Der Rechenaufwand wird bei diesen Controllern durch die CPU geleistet, insofern sollte ein reines Software-RAID vergleichbar performant sein.

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, was bei den verwendeten Hitachi-Festplatten sowieso eine absolute Notwendigkeit ist.

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 Strato 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 hdc:

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

• Ausfall hda:

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

• Ausfall hda und notweniger Reboot

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

Dieser Schritt kann durch eine Vorinstallation des Bootmanagers in den MBR der hdc 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 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.

Dieser Artikel bezieht sich auf den Strato Server MR2 mit folgender Hardware (AMD Chipsatz):

0000:00:06.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8111 PCI (rev 07)
0000:00:07.0 ISA bridge: Advanced Micro Devices [AMD] AMD-8111 LPC (rev 05)
0000:00:07.1 IDE interface: Advanced Micro Devices [AMD] AMD-8111 IDE (rev 03)
0000:00:07.2 SMBus: Advanced Micro Devices [AMD] AMD-8111 SMBus 2.0 (rev 02)
0000:00:07.3 Bridge: Advanced Micro Devices [AMD] AMD-8111 ACPI (rev 05)
0000:00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge
0000:00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge
0000:00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge
0000:00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge
0000:01:00.0 USB Controller: Advanced Micro Devices [AMD] AMD-8111 USB (rev 0b)
0000:01:00.1 USB Controller: Advanced Micro Devices [AMD] AMD-8111 USB (rev 0b)
0000:01:0b.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27)
0000:01:0d.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5705 Gigabit Ethernet (rev 03)
0000:01:0e.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5705 Gigabit Ethernet (rev 03)