Unternehmen wollen Server - billig, leistungsfähig und immer auf Sendung. Doch es gibt keinen Rechner, der ewig läuft. Selbst die ausgefeilteste Hard- und Software fällt irgendwann einmal aus. Im Internet-Zeitalter kann das fatale Folgen haben: Server-Crashes wie im Frühjahr bei Ebay und Etrade kosten nicht nur Umsatz, sondern auch Reputation.
Gestreßte Server-Manager brauchen heute mehr als starke Nerven und viel Kaffee. Lösungen sind gefragt, denn dem Kunden ist es egal, ob eine Motte im Netzteillüfter Karussell gefahren, die Putzfrau über das Ethernet-Kabel gestolpert ist oder der Aushilfsadministrator einen "todsicheren" Kernel-Patch eingespielt hat. Deshalb müssen die Stärken und Schwächen der erhältlichen Rechner eingeschätzt werden. Zu diesem Zweck läßt sich der Markt grob in sechs Klassen einteilen (siehe Tabelle "Server-Klassen", Seite 52).
-Uniprozessoren sind beispielsweise PCs und Workstations mit nur einer CPU. Sie sind billig und vielseitig, in der Leistung aber beschränkt.
-Ein Symmetrischer Multiprozessor (SMP) besitzt mehrere CPUs, die sich gleichberechtigt einen gemeinsamen Hauptspeicher teilen. SMPs sind perfekte Allrounder - bis zu dem Tag, an dem sie ausfallen.
-Ein Cluster ist ein enger Verbund aus Rechnern wie PCs und SMPs. Cluster können mit Abstand am ausfallsichersten sein, sind jedoch teuer und aufwendig zu administrieren.
-Ein Massiv-paralleler Prozessor (MPP) besteht aus einer großen Zahl von CPUs, die jeweils nur einen lokalen, also "privaten", Hauptspeicher besitzen. Ein MPP bringt Superleistung für Spezialfälle, sonst nichts.
-Eine CC-Numa-Maschine (Cache Coherent Non Uniform Memory Architecture) besteht aus kleinen, eng verschalteten SMP-Bauklötzen, bei denen jeder SMP auch auf den Hauptspeicher aller anderen SMPs zugreifen kann, aber langsamer als auf seinen eigenen. CC-Numa-Maschinen sind manchmal schneller als SMPs, oft aber ein schlechterer Kompromiß.
-Bei einem verteilten System werden über das Internet zum Teil mehr als 100000 Computer aller Sorten zu einem bunten Riesen-Cluster zusammengeflickt. In Ausnahmenfällen erreicht man exotische Leistungen zum Spartarif. So deklassiert etwa das System "Seti@home" mit durchschnittlichen 7,5 Teraflops (7,5 Billionen Rechenoperationen pro Sekunde) sogar "Asci Red", den mit gemessenen knapp 2,1 Teraflops schnellsten MPP-Rechner der Welt.
Wenn Hochverfügbarkeit, dann Cluster
In diesem Server-Zoo haben Cluster ein wichtiges Alleinstellungsmerkmal: Richtig konfiguriert, stechen sie in puncto Verfügbarkeit alle anderen Systeme aus. Um das zu messen, werden meistens sechs Klassifizierungen verwendet (siehe Tabelle "Verfügbarkeitsklassen", Seite 52): Ein einzelner NT- oder Unix-Server mit durchschnittlichem System-Management liegt typischerweise in Klasse zwei. Für Klasse drei braucht man einen traditionellen Mainframe oder einen sehr gut gemanagten Unix-Server. Alternativ eignen sich auch Unix- oder manche NT-Cluster. Klasse vier ist die Domäne der besten Mainframes. Sie ist für Unix-Cluster noch erreichbar, aber bereits schwierig. Echte "Five Nines", also 99,999 Prozent sind für allgemeine Computersysteme so etwas wie der Heilige Gral. Außerdem sind Five Nines nicht alles, denn Hochverfügbarkeit ist nicht mit einer Fehlertoleranz gleichzusetzen, wie man sie etwa für die amerikanischen Shuttle-Raumfähren benötigt. Um dort ganz sicherzugehen, werden Berechnungen mehrfach durchgeführt und die Resultate verglichen.
Relativ guten Gewissens kann man IBMs "S/390 Parallel Sysplex"-Clustern und Compaqs "Nonstop"-Systemen eine vorläufige Aufenthaltsberechtigung für diesen Sektor erteilen.
Zwar sehen das viele Marketing-Abteilungen anders, doch über Hochverfügbarkeit zu reden ist leicht, sie zu verwirklichen hingegen sehr schwer. Fällt ein Five-Nines-System nur für einen Tag aus, müßte es 274 Jahre ohne Ausfall weiterlaufen, um den 99,999-Prozentwert wiederherzustellen.
Dabei müssen IT-Verantwortliche immer die Verfügbarkeit des gesamten Systems bewerten. Deshalb sind die "geplanten Ausfallzeiten" stets mitzuzählen. Diese entstehen etwa durch Erweiterungen, Umkonfiguration oder Upgrades. In einer Untersuchung mit gut gemanagten Mainframes überstiegen die geplanten Ausfallzeiten die ungeplanten um den Faktor zehn.
Die Devise zur Absicherung gegen Ausfälle kritischer Teile heißt "Doppelt genäht hält besser", also Redundanz. Dies bedeutet die systematische Vermeidung von "Single Point of Failures". Dafür besitzt ein gut konstruierter SMP redundante Netzteile, Lüfter und manchmal sogar doppelt ausgelegte CPU-Module. In einem Cluster vervielfältigt man zusätzlich den ganzen Server. Dafür wird einem Server A ein bauähnlicher Helfer B zur Seite gestellt. Im Notfall schaltet das System automatisch auf den Helfer um. Der Umschaltvorgang heißt Failover (siehe Abbildung "Failover-Cluster"). Dabei müssen sich die Knoten A und B dauernd gegenseitig über ihren Zustand informieren, was CPU- und Netzwerkressourcen kostet.
Doch was einfach aussieht, ist in der Praxis schwierig. Schon das automatische Auslösen des Failovers erweist sich als trickreich: Ist zum Beispiel Knoten A nahe am Lastlimit, kann es sein, daß A sich erst um seine Daten kümmern will, bevor B informiert wird. Ist B voreilig, übernimmt er das Kommando, obwohl A gar nicht ausgefallen ist. Im schlimmsten Fall versucht B die Daten zu "retten", die A gerade schreibt. Das ist, als ob der Copilot am Steuerknüppel reißt, während der Pilot damit beschäftigt ist, einem entgegenkommenden Flugzeug auszuweichen. Deshalb bauen Hersteller oft allein für den "Heartbeat" zwischen den Servern - also den laufenden Dialog nach dem Muster: "Ich lebe - du auch?" - eigene Netzkarten ein. Clustering ist also ein Feld für Profis. Version 1.0 jedweder Cluster-Software sollte für die Produktion verboten sein.
Mit dem Umschalten der Rechner von A nach B ist es nicht getan. Was passiert mit den Daten? Soll B bereits eine komplette Kopie von As Daten auf den eigenen Platten haben (Replikation), oder soll B erst beim Abschalten von A dessen Platten übernehmen (Switch-over)? Die dafür notwendige Entscheidung zwischen Cluster-globalen (Shared Disk) oder knotenlokalen Platten (Shared Nothing) ist offen und wird heiß diskutiert. Im Shared-Disk-Konzept haben alle Rechner Zugriff auf alle Festplatten im Cluster. Shared Nothing sieht nur den Zugriff auf die direkt am Server-Knoten angeschlossenen Disks vor.
Shared Disk hat den großen Vorteil, daß alle Knoten im Cluster im Prinzip dieselben Daten sehen. Doch dafür müssen sie einen verteilten Lock-Manager (DLM = Distributed Lock Manager) einsetzen. Dieser sorgt dafür, daß jeweils nur ein Rechnerknoten einen Datensatz auf den Platten "locken" und ohne Kollision mit den anderen schreiben kann. Damit ist aber lediglich die Serialisierung der I/O-Zugriffe gewonnen, die Kohärenz der Platten-Caches (Zwischenspeicher) noch nicht (siehe Grafik "Cache-Kohärenz"): Man nehme an, daß Knoten A den Datensatz #1 in seinem lokalen Platten-Cache hält. Woher soll der Cache erfahren, wenn B den Datensatz verändert und zurück auf die Platte schreibt? Hier helfen nur Lösungen wie ein persistentes globales Verzeichnis, das Auskunft darüber gibt, welcher Knoten gerade welche Datenblöcke im Cache hält.
Leider ist man damit immer noch nicht am Ziel, denn Knoten A hätte ja kurz vor seinem Absturz noch die gemeinsam genutzten Daten durcheinanderbringen können. B muß also entweder einen aufwendigen Check über die Daten laufen lassen oder wissen, daß die Daten in Ordnung sind. Letzteres wäre wünschenswert, doch dafür müssen alle Zugriffe auf den gemeinsam genutzten Plattenspeicher als zuverlässige Transaktionen erfolgen, also im "Commit Rollback"-Stil, auf dem relationale Datenbanken aufbauen. Ist eine Datenveränderung "committed", also registriert und nachvollziehbar, überlebt sie auch einen Server-Absturz und das folgende Failover. Deswegen eignen sich nur transaktionsorientierte Applikationen für wirklich ausfallsichere Cluster.
Ein solches System will programmiert, benutzt und administriert werden, am besten als ein Single Image. Dies erlaubt, den Cluster intern und extern als ein Ganzes zu betrachten, nicht nur als eine Ansammlung von Knotenrechnern. Das zu realisieren ist sehr schwierig und erfordert Unterstützung auf allen Ebenen des Betriebssystems und der Applikationen. In der Praxis ist dieses Konzept mit am besten in Compaqs "Galaxy"-Clustern unter VMS verwirklicht. Für offene Systeme ist eine Single-Image-Lösung praktisch nicht verfügbar.
In den bisher diskutierten Szenarien wird die Kapazität des Helfer-Servers B nur beim Failover benutzt, das Clustering dient also nur der Verfügbarkeit. Clustering eignet sich aber auch zur Leistungssteigerung, indem eine Applikation möglichst viele Cluster-Knoten parallel nutzt.
Dafür ist jedoch das von SMPs gewohnte Shared-Memory-Programmiermodell denkbar ungeeignet, da der Hauptspeicher im Cluster eben nicht "shared" ist, also gemeinsam genutzt wird. Meistens muß die Applikation auf das Message-Passing-Programmiermodell umgearbeitet werden. Ein Beispiel dafür ist der "Oracle Parallel Server", die Cluster-Version der Oracle-Datenbank. Solche Cluster-Varianten verbringen allerdings nicht nur viel Zeit mit der Synchronisation zwischen den Knoten, sondern müssen auch die anfallende Arbeit möglichst gleichmäßig zwischen den Knoten verteilen (Workload Balancing). Wenn nicht alles stimmt, ist die Cluster-Version auf mehreren Knoten manchmal sogar langsamer als die Normalversion auf einem einzelnen Rechner.
Deshalb sind auf Leistung abzielende Cluster-Anwendungen selten. Wirklich gut funktionieren sie nur, wenn sie über eine triviale "Außenschleife" parallelisiert werden können. In diesem Fall ist die Arbeit im Cluster in parallele, rechenintensive Stücke zerteilbar, die sich dann ohne aufwendige Kommunikation zwischen den Stücken erledigen läßt.
Genauso funktioniert auch die Cluster-Version des "TPC-C"-Benchmarks, wo die Benchmark-Definition eine Triviallastverteilung im Cluster ermöglicht. Durch diesen Fehler fallen die TPC-C-Ergebnisse für Cluster viel zu gut aus. Der Durchsatz unter realer OLTP-Last (Online Transaction Processing) ist meist viel schlechter. Das macht den wichtigsten Cluster-Benchmark unbrauchbar.
All diese Hürden auf dem Weg zum Rechnerverbund lassen vermuten, daß Cluster nur etwas für verknöcherte Verfügbarkeits-Freaks sind, die lange Nächte mit dem Performance-Tuning ihres DLM verbringen müssen. Doch das Internet hat alles verändert. Inzwischen sind Web-Farmen schlechthin die Killerapplikation für Cluster, denn die gleichzeitigen Zugriffe auf Web-Server sind weitgehend unabhängig voneinander, also auf einfachste Weise parallelisierbar. Außerdem ist Verfügbarkeit ein strategisches Muß für jede ernstzunehmende Web-Präsenz. Deshalb steckt hinter fast jedem "www.großefirma.com" in Wirklichkeit ein Cluster-ähnliches System aus vielen Einzelrechnern mit Namen wie "www00" und "www42" (siehe Grafik "Web-Farm als Cluster", Seite 52).
Application Framework für Cluster-ähnliche Systeme
Das ist noch lange nicht alles. Weltweit tätige Großunternehmen möchten ihre Geschäftsprozesse auf das Web verlagern. Die dafür notwendigen Applikations-Server wie etwa "Weblogic" von BEA werden langsam einsatzfähig. Sie stellen für Enterprise-Javabeans-Applikationen sogenannte Application Frameworks bereit, also einen geschützten Sandkasten zum einfachen Spielen im Netz. Mit einem solchen Object Transaction Monitor (OTM) kann man objektorientiert und transaktionsorientiert arbeiten. Da der Objekt-Container diese Möglichkeiten bietet, muß der Anwender nicht mehr seine eigene Objektinfrastruktur schreiben. Die Applikation muß noch nicht einmal wissen, daß sie überhaupt auf einem Cluster läuft. Sie hat nur mit dem Objekt-Framework einen Vertrag über Dienste und Schnittstellen geschlossen.
Ein solches Betriebssystem für Web-Objekte läuft auf großen Clustern mit beinah beliebig vielen Knoten, die sogar heterogene Hard- und Software haben können. Es liefert den Java-Applikationen automatisches Single Image, automatische Datenreplikation, automatisches Failover und automatisches Workload-Balancing. Das klingt zu schön, um wahr zu sein. Und die meisten Hersteller haben diese Entwicklung auch verschlafen. Tatsächlich ist es allerdings weder so einfach noch so billig, wie es sich anhört. Trotzdem wickeln Kunden wie der Online-Broker Charles Schwab ihre enormen Transaktionslasten längst nach den neuen Methoden ab.
*Henrik Klagges ist Analyst bei der Consol Software GmbH in München.