Login
Login-Name Passwort


 
Newsletter
Werbung

Do, 18. Oktober 2007, 00:00

High Availability Computer Center (hacc-) Teil 1

Teil 1: Übersicht, Bootvorgang und Arbeitsknoten

Wie baut man ein Rechenzentrum, das Ausfälle autonom repariert, sowohl Hardware-Ausfälle als auch Software-Ausfälle, die mit einem Reboot behebbar sind? Man nehme hacc-.

Einleitung

Wer kennt das Problem nicht, dass ein entscheidendes Hardware-Teil am wichtigsten Server ausfällt und der Server steht. Dies passiert natürlich immer am Wochenende, immer wenn keiner da ist. Oder dass durch einen Fehler bei der Administration der Applikation diese ein klein bisschen stehen bleibt und dies auch nicht bemerkt wird. Durch einen Neustart der Applikation oder des Servers wäre dies behebbar.

Diese Probleme soll hacc- mit freier Software lösen.

Die Grundidee

Basis der Lösung ist die physische Trennung der Daten und der Software von den Servern. Für die Server wird ein internes Netz aufgebaut, welches nur von diesen Servern aus erreichbar ist. Aus Kostengründen und der Einfachheit halber wurde NFS gewählt. Mit zukünftig 10 Gbit/s hat man damit auch in Zukunft genügend Power.

Jeder Applikationsserver (Node) kann jede Applikation (jedes Applikations-Image) booten und betreiben. Sie werden per DHCP, PXE, TFTP und NFS gebootet und mounten das Betriebssystem, die Applikationssoftware und die Daten per NFS.

Als dritte Komponente braucht man dann noch eine ausfallsichere Überwachung und Steuerung. Für die Überwachung und Steuerung der Applikationsserver wird Nagios verwendet. Die Ausfallreaktionen übernehmen Service-Exits und Host-Exits. Damit die Überwachung nicht ausfällt, gibt es dafür zwei Server. Diese überwachen sich mit Heartbeat gegenseitig.

Ursprünglich war noch angedacht, auf allen Applikationsservern ein einheitliches Betriebssystem zu benutzen. Das hätte das Einspielen von Änderungen vereinfacht. Spezifische Änderungen einer Server-Applikation etwa sollten per UnionFS, bekannt von Knoppix, realisiert werden. Aufgrund mehrerer Kernel-Änderungen und Release-Änderungen (Umstieg von SUSE 9.x auf 10.0, 10.1 und zuletzt auf SLES10) wurde es aber immer zu einem Risikofaktor, welche Version von UnionFS denn verwendbar sei. Schließlich verlangte jemand noch SUSE 10.2 für seine Applikationen. Deshalb wurde diese Idee wieder verworfen und darauf gesetzt, dass jeder Applikations-Server sein eigenes Betriebssystem exklusiv benutzt.

Die verwendete Hardware

Das gesamte System ist so konzipiert, dass es auch an zwei Standorten betrieben werden kann. Das heißt, bei Totalausfall eines Standortes soll auf einen zweiten Standort umgeschaltet werden können. Bei entsprechender Ausstattung mit einem hochverfügbaren, synchron gespiegelten NFS-Server ist dies auch automatisch möglich. Zur Zeit ist dies aber noch nicht realisiert.

Als NFS-Server wurde die NetApp FAS270 vorgegeben, die nicht synchron spiegeln kann. Auf dieses Thema soll auch hier nicht weiter eingegangen werden. Eine ausfallsichere Lösung wäre auch mit Linux möglich (siehe [1] und [2]).

Als Server wurde ein Blade Center gewählt, BX600 von FSC. Zwei Server sind die Steuer-Server (Control Nodes). Sie besitzen ein eigenes, auf internen Platten gespeichertes, Betriebssystem. Die Konfigurationsdaten liegen weitgehend auf einer NFS-Partition.

Die Arbeitsknoten (Nodes) beziehen alle Software und Daten per DHCP, PXE, TFTP und NFS. Lediglich ein lokales Swap und /tmp existiert. Damit sind die Arbeitsknoten austauschbar.

Jeder Knoten (Control Nodes und Nodes) ist mit zwei Ethernet-Schnittstellen am Hausnetz angebunden (IP-Bonding). Eine dritte Schnittstelle ist am internen Netzwerk angebunden. Über diese Schnittstelle werden das Betriebssystem und die Daten gemountet (NFS). Routing ist an allen Knoten ausgeschaltet. Die NFS-Ressourcen besitzen keine Anbindung an das Hausnetz. Sie sind nur über die innere Schnittstelle der Control Nodes und Nodes erreichbar.

Die Lösung im Einzelnen

Bei den Nodes ist eine Trennung zwischen der Software (Applikationen und Daten eines Nodes) und der konkreten Hardware erreicht worden. Jedem physischen Arbeitsknoten (jeder Hardware) wird fest eine interne IP-Adresse zugeordnet. Diese wird dem Knoten beim Boot mitgeteilt. Sie ist nicht Bestandteil der Boot-»Images« (der Software). Ein Teil dieser internen IP-Adresse wird aber als Link auf das konkret zu bootende »Image« (die Software) genutzt. In diesem »Image« (welches kein Image, sondern eine normale NFS-Ressource ist) sind als IP-Adressen nur die externen IP-Adressen der Applikationen fest hinterlegt. Per symbolischem Link wird also festgelegt, auf welchem physischen Knoten welches Betriebssystem (welche Applikations-Software mit welcher Konfiguration) gestartet wird (Siehe Bild 2).

Die Knoten-Nummer ist Bestandteil der internen IP-Adresse der Knotens. Das Image »XXX« ist dabei ein Platzhalter für defekte Knoten. Bei einer automatischen Erkennung eines Ausfalls eines Knotens und nicht erfolgreichem Reboot wird der Knoten als defekt (»XXX«) gekennzeichnet. Der untere Teil in Bild 1 zeigt die Zuordnung der Applikationsimages, n00 .. n99 zu den physischen Knoten. Die Node-Nummer ist dabei die letzte Stelle der IP-Adresse des Knotens. Es wird das Teilnetz 192.168.100 benutzt.

Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung