weidner/archives/2011/12/09/

Hochverfügbarkeit für Arme mit ALIX

Wenn ich einen kritischen Teil meiner Infrastruktur, wie zum Beispiel DHCP-, DNS-, NTP-Server oder einen Zugangsrouter, mit ALIX-Rechnern aufbaue, bin ich natürlich daran interessiert, dass diese "immer" laufen. Dass ich die Geräte an eine USV anschließe und ihren Betrieb überwache ist schon klar. Darum geht es mir hier nicht.

Worauf es mir ankommt, ist, den ständigen Betrieb auch unter solchen Bedingungen wie fehlerhafter Software und eventuell doch ausfallender Hardware nach Möglichkeit aufrecht zu erhalten. Habe ich einen Server oder Router mit ALIX aufgesetzt, ist die Entwicklung zwar vorerst vorbei. Dafür fängt jetzt der laufende Betrieb an, in dem sich meine Lösung bewähren muss.

In unregelmäßigen Abständen - von wenigen Tagen bis mehreren Wochen - kommen Software-Updates. Diese will ich, so schnell es geht, einspielen. Zumindest, wenn sie Sicherheitsprobleme beheben. Kommt ein neuer Kernel, ist ein Neustart notwendig, der schon mal eine Minute - und bei einem notwendigen Dateisystemcheck auch mehr - kosten kann. Hin und wieder, wenn auch sehr selten, ist das System nach einem Update auch unbenutzbar.

Deshalb keine Updates einzuspielen, ist auch keine Lösung.

Also greife ich auf das Mittel der Wahl zu Sicherung der Vefügbarkeit zurück: auf Redundanz. Der allererste Schritt ist, zwei Geräte einzusetzen. Als nächstes konfiguriere ich die Software so, dass die beiden Geräte sich nicht in's Gehege kommen, sondern gegenseitig ergänzen und unterstützen.

Redundanz im Netzwerk

Für den ISC-DHCP-Dämon ist eine redundante Konfiguration zumindest bei den aktuellen Versionen einfach aufzusetzen.

Bei DNS verwende ich einen der Server als Master und den anderen als Slave. Dadurch habe ich eine Asymmetrie bei der Konfiguration, die sich jedoch nur dann auswirkt, wenn der Master für längere Zeit ausfällt. Dem kann mit einem Script entgegenwirken, das den Slave zum Master machen kann und umgekehrt.

Für NTP brauche ich keine weiteren Vorkehrungen zu treffen. Jeder der beiden Server bekommt seine unabhängigen Zeitquellen (Internet, DCF77, GPS, ...) und den jeweils anderen Server als Quelle konfiguriert.

Bei Routern wird es komplexer, je nachdem, ob ich noch Loadbalancing machen will, oder NAT.

Redundanz im Gerät

Nun habe ich zwei Geräte, die sich im Netz wunderbar ergänzen, aber ich will im Falle eines Problems mit einem der Geräte, dieses auch so schnell wie möglich wieder in Betrieb nehmen.

Also spiele ich das Betriebssystem doppelt auf. Wenn ich den Rechner mit PXE-initrd aufgesetzt habe, sind bereits zwei gleichgroße Partitionen für das Betriebssystem vorbereitet, von denen aber nur eine belegt ist.

Hier verwende ich ein Script, dass das Betriebssystem von der ersten OS-Partition auf die zweite kopiert, so dass das Betriebssystem anschließend sofort von der zweiten Partition gestartet werden kann. Mit diesem Script aktualisiere ich vor jedem Update das Betriebssystem auf der zweiten Partition und kann nun im Notfall mit dieser weiterarbeiten, während ich die erste wieder benutzbar mache.

Fehlt noch was? Ja. Der Serverraum ist kalt, die ALIX-Boxen schlecht zugänglich oder es weiss keiner mehr wo sie sind, weil man solange nicht hin musste. Wie komme ich nun an die (serielle) Konsole um beim Start auf die andere Partition umzustellen? Ich verbinde einfach wechselseitig die seriellen Konsolen der Geräte mit einem USB-Seriell-Wandler, der am anderen Gerät angeschlossen ist oder mit der aktivierten zweiten seriellen Schnittstelle. Dabei bietet mir die zweite Variante gleich die Gelegenheit zu ein paar Basteleien mit der Hardware.

Posted 2011-12-09
Tags: