Ein Workshop im Chaos Bildungswerk
Wir werden immer
abhängiger von IT-Systemen, daher ist es uns immer wichtiger,
diese ständig zur Verfügung zu haben. Nun wissen wir alle,
dass Computer gelegentlich einmal kaputtgehen - sei es durch
Hardwareausfälle, Softwareprobleme, oder einen versehentlich
gezogenen Stecker. Mögliche Verfahren, diesem zu begegnen,
sollten in einem Wochenendworkshop im Chaos Bildungswerk erforscht
werden. Als technische Basis hatten wir uns vorab auf PCs unter Linux
verständigt und entsprechendes Gerät koordiniert.
Die Verfügbarkeit eines Systems definiert sich als
Hier wird mit MTTR die mittlere
Reparaturzeit (mean time to repair) bezeichnet. Die Referenzzeit ist
üblicherweise auf ein Jahr bezogen.
Üblicherweise wird
die Verfügbarkeit in Prozent angegeben. Eine Verfügbarkeit
von 99% bedeutet beispielsweise, dass das System etwa 3,6 Tage im
Jahr ausfallen darf, bei 99,9% sind es noch knapp 9 Stunden, bei
99,99% noch etwa 53 Minuten pro Jahr.
Wenn ein System aus
mehreren Komponenten besteht, so müssen die
Einzelverfügbarkeiten miteinander multipliziert werden, bei drei
Komponenten, die jede für sich 99% verfügbar sind, ergibt
sich z.B. eine Gesamtverfügbarkeit von nur noch 97%.
Hochverfügbarkeit
Eine im Folgende wichtige Abstraktion ist der Dienst. Es
ist uns schließlich nicht so wichtig, ob ein bestimmtes Stück
Technik funktioniert, sondern es interessiert uns, dass dieses oder
ein anderes Stück Technik für uns eine bestimmte Leistung
erbringt. Ein Dienst wäre z.B. eine Datenbank, ein Webserver,
E-Mail-Verkehr oder Eisenbahntransport (uns ist es egal, welcher
Waggon genau uns befördert, Hauptsache, wir kommen pünktlich
und in einem Stück an).
Zur Erhöhung der Verfügbarkeit
kann man zweierlei tun:
Man kann die Ausfallwahrscheinlichkeit verringern, also die Komponenten robuster auslegen
Man kann die Reparaturzeit verringern, also die Ausfallzeit reduzieren
Zum ersten Punkt gehört im wesentlichen die Auswahl qualifizierter Komponenten, Unterbrechungsfreie Stromversorgungen, gute Kühlung usw. Zum zweiten Punkt gehört die Hochverfügbarkeit im engeren Sinne: Durch gezielte Redundanz die Reparaturzeit so kurz wie möglich zu machen, idealerweise so kurz, dass der Anwender keine Unterbrechung des Dienstes bemerkt.
Wie kann man dies nun erreichen?
Redundant ausgelegte Systeme erlauben es, den Ausfall einzelner Komponenten zu "überleben". Ein klassisches Beispiel sind gespiegelte Platten: Da Festplatten als mechanisch bewegte Teile relativ störanfällig sind, wurde schon früh durch Spiegelung (auch als RAID1 bezeichnet) der Ausfall einzelner Platten verschmerzbar gemacht. Dazu wird (vom Betriebssystem oder dem Plattencontroller) jeder Datenblock automatisch auf zwei identische Platten geschrieben. Sollte eine Platte ausfallen, so kann mit der Kopie auf der zweiten Platte unterbrechungsfrei weitergearbeitet werden, allerdings ohne die zusätzliche Sicherheit der Spiegelung ("degraded mode"). Nach Austausch der defekten Platte wird auf der neuen Platte wieder eine vollständige Kopie der Daten angelegt, um die Sicherheit wieder herzustellen ("rebuild"). Verfeinerungen dieses Schemas sind z.B. RAID 5. Auch mehrere Controller, Kabel usw. sind möglich, um die Anzahl der möglichen Ausfallpunkte ("single point of failure") weiter zu reduzieren.
Weiter treiben läßt sich das Verfahren, wenn man vom
Server auf den Dienst (Service) abstrahiert: Man installiert mehrere
Systeme, die jedes für sich den Dienst leisten können. Ein
einfaches Beispiel sind Mirrors populärer Webserver oder mehrere
DNS-Nameserver.
Hieran wird auch deutlich, wo die entscheidenden
Schwierigkeiten bei diesem Ansatz liegen:
Nutzer müssen den Dienst finden können, unabhängig davon, welches System ihn erbringt
Datenbestände müssen auf allen Systemen konsistent gehalten werden
Aktive Verbindungen sollen von einem System zu einem anderen migrieren können, wenn der Dienst migriert wird
Ein Backup-System muß zuverlässig erkennen, daß das Master-System nicht (mehr) verfügbar ist, und den Dienst übernehmen (failover). Es sollte sicherstellen können, daß das Master-System den Dienst freigibt und ihn nur koordiniert wieder übernimmt (failback) Der Failover muß automatisch stattfinden, der failback kann automatisch oder manuell angestoßen werden.
Eine typische, einfache Clusterkonfiguration besteht aus zwei Systemen und einer gemeinsam genutzen oder gespiegelten Platte sowie mindestens einer sog. Heartbeat-Leitung, über die die Systeme gegenseitig ihren Status abfragen
In der kommerziellen UNIX-Welt hat jeder namhafte Hersteller seoin eigenes Produkt im Rennen: IBM HACMP unter AIX, HP MC/ServiceGuard unter HPUX, Compaq TruCluster unter Tru64, Sun SunCluster unter Solaris, SGI FailSafe unter IRIX. Unter Linux sind mehrere Implementationen, teils in Aplpha- oder Beta-Stadium, verfügbar. Näher beschäftigt haben wir uns auf dem Workshop nur mit einer Auswahl. Zur Klarheit sei noch angemerkt, dass man Clustering auch zur Erhöhung der Rechenleistung statt der Ausfallsicherheit betreiben kann, besonders bei gut parallelisierbaren Aufgaben (z.B. Animation, SETI@home, RC5). Dazu wird aber ganz andere Software benötigt (z.B. Beowulf), dies soll hier auch nicht unser Thema sein.
Linux FailSafe von SGI, seit
August Open Source
Ein professionelles, komplexes System. Die
umfangreiche Dokumentation (ca. 200 Seiten) ist derzeit erst
unvollständig von IRIX auf Linux umgestellt und stellenweise
auch nicht ganz korrekt. Die Source ließ sich übersetzen,
nachdem ein Teil der Hilfe im Makefile auskommentiert wurde. Wir
haben es geschafft, die beiden Partner im Cluster zur Kommunikation
zu bewegen, eine Übernahme haben wir aus Zeitgründen nicht
mehr hinbekommen (das Wochenende war zu Ende).
FailSafe arbeitet
mit FibreChannel-Platten (-subsystemen) oder SCSI-Platten zusammen,
die multi homed an beide Systeme angeschlossen werden. Damit
dies wirklich fuinktionert, werden bei SCSI sog. Y-Terminatoren
gebraucht (damit auch bei Ausfall eines Systems die korrekte
Terminierung gewährleistet ist). Bei FibreChannel ist dies
nicht nötig., dafür ist FibreChannel allerdings eher
teuer.
Siehe [failsafe]
heartbeat und DRBD (und fake)
Ein
einfaches System. Der Cluster-Manager heartbeat kümmert
sich darum, den Ausfall eines Partners im Cluster zu erkennen und
die Übernahme einzuleiten. fake erlaubt es, daß
der übernehmende Rechner die IP- und auch die MAC-Adresse des
ausgefallenen Systems übernimmt, so daß Clients den
Service weiterhin finden. DRBD ist eine Zwischenschicht zwischen
Filesystem und Festplatte, die eine Soiegelung über das Netz
erlaubt. Es kann immer nur ein Partner auf die Partition schreibend
zugreifen (die Partition darf nur auf einem Knoten gemountet
werden). Ein gewisser Performanceverlust (der durchaus erträglich
ist) wird für viele Anwendungen durch den Verzicht auf
jegliches Spezialequipment ausgeglichen. Sogar IDE-Platten lassen
sich problemlos verwenden.
Siehe [linux-ha] und [drbd]
heartbeat und GFS
Das Global File System arbeitet
ebenfalls mit SCSI- und FibreChannel-Platten. Im Gegensazu zu
anderen Systemem können bei GFS alle Partber im Cluster
die Platte(n) gemeinsam lesend und schreibend nutzen. Dafür
werden Platten benötigt, die in der Firmware Locking-Funktionen
unterstützen, z.B. diverse Seagate Barracuda-Modelle.
Alternativ läßt sich ein Lockdaemon über IP
verwenden.
Siehe [gfs]
Die Anwendung dieser Systeme, besonders FailSafe, stellte sich als
schwieriger heraus als zunächst gehofft. Der Einfluß
unzureichender Dokumentation sollte nicht unterschätzt werden,
besonders bei hochkomplexen Systemen. Das einfachere heartbeat+DRBD
sollte dagegen erheblich weniger Schwierigkeiten bereiten.
Ein
zweiter Teil dieses Artikels in der nächsten Datenschleuder wird
auf die dann hoffentlich vorliegenden Erfahrungswerte eingehen.