Login
Login-Name Passwort


 
Newsletter
Werbung

So, 21. Juni 2009, 00:00

High Availability Computer Center (hacc-) - Update

Teil 1: Einführung und erste Schritte

Einführung

Ein Sprichwort sagt: »Man baut nur zweimal«. Gemeint ist damit, dass man beim zweiten Bau seines Eigenheims so manchen Fehler vermeide würde. Die meisten Eigenheimbauer werden aber nicht in die Lage kommen, ein zweites Mal zu bauen.

Allerdings ist es mir vergönnt, das hochverfügbare Rechenzentrum mit neuer Hardware ein zweites Mal zu bauen.

Was ist gemeint? Eine der wichtigsten Anwendungen der Stadt Dresden ist die Web-Präsentation. Diese besteht aus mehreren Apache-Servern, verbunden mit einem Load-Balancer. Dazu gehören eine MySQL-Datenbank und ein proprietäres Redaktionssystem. Weitere Bestandteile der Web-Präsentation sind diverse Tomcat- und Zope-Anwendungen. Außerdem läuft auch noch ein Postgis-Service und nicht zu vergessen das 3D-Modell von Dresden. All dies soll hochverfügbar sein und möglichst nie ausfallen. Und wenn es dann wirklich einmal zum Ausfall kommt, so soll nach wenigen Minuten die Lauffähigkeit wieder hergestellt werden.

Realisiert wurde dies bisher mit hacc- (siehe [1], [2], [3]). Dieses System sorgt automatisch für die Wiederherstellung einer Anwendung nach Ausfall eines Services durch einen Restart der Anwendung oder des Servers. Bei Hardwareausfall wird die gesamte Software einschließlich des zugehörigen Betriebssystems und der Daten einfach auf einem anderen Server gestartet. Dieses hacc- besteht ausschließlich aus freier Software. Hardwarebasis ist bisher eine BX600. Die BX600 ist ein Blade-Center, also ein Rack, in dem mehrere Server stecken (10 Server in diesem Fall), die alle möglichst gleich ausgestattet sind und alle gemeinsame Schnittstellen haben. Diese gemeinsamen Schnittstellen sind die Anbindungen an das Netzwerk und an das Management-Blade, mit dem die Server-Hardware überwacht wird und die Server ein- und ausgeschaltet werden können. Dazu gehört auch eine ausfallsichere Stromversorgung und eine gemeinsame Konsolenanbindung.

Basis der Lösung hacc- war die physische Trennung der Daten und der Software von den Servern (Siehe Bild: Grundaufbau hacc-). Für die Server wurde ein internes Netz aufgebaut, welches nur von diesen Servern aus erreichbar ist. Über dieses Netz erfolgt der Boot der Anwendungsserver und die Anbindung der Anwendungsdaten. Aus Kostengründen und der Einfachheit halber wurde NFS gewählt. Mit künftig 10 GBit/s hat man damit auch in Zukunft genügend Power.

Grundaufbau hacc-

Josef Müller

Grundaufbau hacc-

Jeder physische Server 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 NFS-Server wird dabei bisher eine lokale Netapp-Lösung eingesetzt.

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. Diese Exits initiieren bei Ausfall eines Services oder Servers einen Neustart der Anwendung oder des Servers. Bei hardwaremäßigem Serverausfall führt das Host-Exit einen Neustart des Server-Images auf einem anderen physischen Server durch. Damit die Überwachung selbst nicht ausfällt, gibt es dafür zwei Server. Diese überwachen sich mit »Heartbeat« gegenseitig.

Die bisherigen Grundprinzipien und die praktizierte Trennung von Server-Hardware, Überwachungsservern und Daten hat sich bewährt. Aber die Software kommt in die Jahre. Die Leistungsanforderungen sind auch gestiegen. Das bisherige System besteht aus nur einer BX600. Gefordert ist aber eine räumlichen Trennung aus Gründen der Katastrophenschutzes. Dazu sind mindestens zwei BX600 erforderlich.

Da bietet sich ein Neuaufbau an und ein allmählicher Umzug der Anwendungen mit den zugehörigen Daten. Dabei sollen auch gleich die erkannten Schwächen beseitigt werden.

Voraussetzungen

Für die Spiegelung der Daten stehen diesmal zwei hochverfügbare Cellerix-Speicher (NS20) bereit, welche die NFS-Daten synchron an zwei Orten speichern sollen. Ob der Speicher diese versprochenen Eigenschaften hat, die man mit einem selbst gebauten Cluster ohne Probleme realisieren kann (Heartbeat, DRDB, ..., siehe [4] u.a.), und auch zu den Test-Methoden, dazu später mehr.

Kommentare (Insgesamt: 0 || Kommentieren )
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung