Microsoft liegt mit den Fähigkeiten, Windows NT oder Windows 2000 als Betriebssystem für Cluster-Installationen zu verwenden, noch Lichtjahre hinter den Unix-Anbietern zurück - soweit das gängige Vorurteil, das vor allem in "religiösen" Diskussionen zu den Vor- und Nachteilen verschiedener Betriebssysteme immer wieder gern geäußert wird. Es gibt jedoch Gegenbeispiele: Dem Advanced Cluster Consortium (AC3) gelang es im August, einen Supercomputer mit einer Rechenleistung von 122 Gigaflops (Milliarden Fließkomma-Rechenoperationen pro Sekunde) auf Basis von NT zum Laufen zu bringen.
Zum Projekt gehören die Cornell-Universität in Ithaca, New York, Intel, Microsoft, Dell und Giganet. Der Number-Cruncher besteht aus 64 Servern vom Typ "Poweredge", die auf die Leistung von insgesamt 256 Pentium-III-Prozessoren mit einer Taktrate von 500 Megahertz zurückgreifen. Das Besondere am AC3-Cluster: Da der Rechnerverbund weitgehend aus Standardhardware besteht, liegen die Kosten bei nur rund drei Millionen Dollar - ein regelrechter Dumpingpreis im Vergleich zu den 15 bis 30 Millionen, die für einen klassischen Supercomputer dieser Leistungsklasse auf den Tisch zu blättern wären.
Solche Projekte laufen durchaus nicht nur im Elfenbeinturm ab, sondern bieten einen ganz realen Nutzen. Es herrscht jedoch ein besonderer Konkurrenzdruck: Ein Cluster aus Alpha-Rechnern von Compaq steht kurz vor dem Einsatz im Labor für Wettervorhersagen der amerikanischen National Oceanic and Atmospheric Administration. 256 Knoten sollen zusammen 256 Gigaflops leisten. Das dort eingesetzte Betriebssystem: Linux.
Im Alltag profitieren NT-Cluster allerdings nur am Rande von solchen Forschungsprojekten. Die Standardanwendung eines Rechnerverbunds unter NT ist immer noch die Failover-Lösung, bei der genau zwei Computer dadurch für Ausfallsicherheit sorgen sollen, daß bei einem Fehler jeweils ein System die Funktion seines Pendants komplett oder teilweise übernimmt.
Die Historie spricht im Grunde nicht gegen eine Eignung von Windows NT als Cluster-Betriebssystem. Im Gegenteil: Viele Konzepte wurden von Digitals VMS übernommen, als 1988 ein ganzes Designteam unter Chefentwickler David Cutler DEC verließ und zur Gates-Company wechselte.
Digitals Vax-Cluster unter VMS gelten bei vielen Experten auch heute noch als State-of-the-Art. Im Hause Microsoft hatte man sich einen Zweiphasenplan zurechtgelegt, nach dem der Microsoft Cluster Server (MSCS) mit dem Codenamen "Wolfpack" zunächst genau die genannte Failover-Funktionalität mit zwei Servern liefern sollte. In Phase zwei sollte das Konzept auf bis zu acht Knoten erweitert werden. Als Zeitrahmen wurde dafür die Mitte des vergangenen Jahres ins Auge gefaßt. Böse Zungen behaupten, der Antitrust-Prozeß und die schwere Geburt von Windows 2000 hätten das Timing für eine Cluster-Lösung unter NT gehörig durcheinandergebracht.
Fast alle notwendigen Fähigkeiten für eine Verbundlösung bringt Windows NT Server 4.0 schon in der Basisversion mit. Dazu gehören das maschinenübergreifende Anmeldeverfahren, die Möglichkeit, Verwaltungswerkzeuge und Monitore verteilt einzusetzen, oder die Weiterleitung von Systemanforderungen (Requests) mittels eines speziellen Programmteils, des Redirectors.
Cluster-Dienste verwalten Ressourcen
Für die Verbundfähigkeit von Windows NT sind der eigentliche Cluster-Service und der Windows NT Load Balancing Service (WLBS) verantwortlich. Als Cluster-Dienst bezeichnet Microsoft eine Kombination verschiedener Software, die auf jedem einzelnen Knoten eingesetzt wird und die Cluster-spezifischen Aufgaben verwaltet. Um die Begriffe zu klären: Das Standardobjekt, auf das der Cluster-Service zugreift, wird als Ressource bezeichnet. Beispiele dafür sind physikalische Festplatten oder Netzwerkkarten, aber auch abstraktere Objekte wie logische Laufwerke, IP-Adressen, ganze Applikationen oder Datenbanken. Fachleute nennen Ressourcen "online" auf einem Knoten, wenn der zugehörige Dienst dort zur Verfügung steht. Innerhalb des Betriebssystems werden sie durch Dynamic Link Libraries (DLLs) repräsentiert. Ressourcen lassen sich intern zu Gruppen zusammenfassen. Diese Konstruktion besitzt ein besonderes Gewicht, da sich eine Gruppe nur jeweils einem Knoten zuordnen läßt.
Anhand der Einteilung von Ressourcen läßt sich auch verdeutlichen, warum das Cluster-Modell von Windows NT als "Shared Nothing" bezeichnet wird: Eine Ressource gehört jeweils zu einem bestimmten Rechner, der auch die alleinige Kontrolle über sie hat. Beim Alternativmodell nach dem Prinzip "Shared Disk" darf eine Applikation, die auf einem beliebigen Knoten läuft, zum Beispiel auf den gesamten Plattenspeicher innerhalb des Systems zugreifen. Letzteres Konzept erscheint zwar auf den ersten Blick in puncto Effektivität besonders vorteilhaft, bei genauem Hinsehen ergeben sich aber auch Nachteile. Da der Datenzustand auf den verschiedenen Knoten ständig synchronisiert werden muß, tritt bei der Kommunikation unter den Rechnern ein nicht zu unterschätzender Overhead auf.
Typischerweise dient ein spezielles Programm, etwa der Distributed-Lock-Manager (DLM), dazu, die Synchronisation zu regeln. Wenn die Menge der zwischen den Knoten ausgetauschten Nachrichten einen kritischen Wert übersteigt, sinkt die Leistung des Gesamtsystems allerdings erheblich.
Zurück zum Microsoft-Ansatz: Über den Zugang per Cluster-Dienst verbindet sich ein Client-System von außen mit einem sogenannten virtuellen Server. Dazu wird eine bestimmte IP-Adresse verwendet, die für die Cluster-Software zusammen mit der zugehörigen Anwendung zu einer Ressourcen-Gruppe zusammengefaßt wird. Tritt nun ein Fehler auf, geht die gesamte Gruppe an die Ersatzmaschine über. Der Client verbindet sich auf genau dieselbe Weise mit dem zweiten Server, dem die IP-Adresse der brachliegenden Maschine zugewiesen wurde. Dieses Failover-Szenario stellt natürlich nur das einfachste denkbare Beispiel dar und bietet noch keinerlei Fehlertoleranz.
Das Umschalten wird von zwei Softwarekomponenten, dem Resource-Manager und dem Failover-Manager bewerkstelligt (siehe nebenstehende Abbildung). Der Resource-Manager startet und stoppt einzelne Ressourcen, regelt die Abhängigkeiten der einzelnen Ressourcen untereinander und löst das Failover ganzer Gruppen aus.
Der Failover-Manager entscheidet darüber, welches System im Cluster die Hoheit über eine bestimmte Ressource hat. Die interne Kommunikation wird über den RPC-Mechanismus (Remote Procedure Calls) abgewickelt. In kleineren Verbundsystemen besteht zu jedem Zeitpunkt eine Verbindung aller Knoten miteinander.
Das Konzept dieser Technik erscheint auf den ersten Blick einfach; sobald die Anzahl der Knoten zunimmt, wächst jedoch auch die Komplexität erheblich. Ein Knackpunkt ist auch hier der Overhead bei der Kommunikation der einzelnen Maschinen untereinander, für die ab einer bestimmten Größe eine hierarchische Struktur gefunden werden muß.
Wie effizient große Anwendungen auf einem Rechnersystem laufen können, hängt unter anderem vom maximal adressierbaren Arbeitsspeicher ab. Der Speicherraum unter NT ist bei 32-Bit-Systemen auf 4 GB RAM beschränkt. Mit Hilfe eines Eintrags in der Registrierungsdatenbank läßt sich die Aufteilung von 2 GB für den Kernel und 2 GB für Benutzerprozesse auf ein Verhältnis von eins zu drei zugunsten der Prozesse umstellen. Auf diese Weise können auch speicherhungrige Applikationen ausgeführt werden. Als Betriebssystem ist dabei allerdings zwingend die "Enterprise Edition" von NT notwendig.
Um die vorhandenen Ressourcen, etwa den Speicher, sinnvoll unter den einzelnen Komponenten eines Rechnerverbunds aufzuteilen, verwendet Microsoft den Windows NT Load Balancing Service (WLBS). Theoretisch lassen sich damit bis zu 32 Knoten zu einem Cluster zusammenfassen. Der WLBS arbeitet ebenfalls TCP/IP-basierend und stellt das Gesamtsystem nach außen durch eine einzige IP-Adresse dar. Das Know-how für den WLBS stammt übrigens nicht von Microsoft, sondern kam durch eine Übernahme ins Haus: Die Balancing-Software war von Valance Research unter dem Namen "Convoy Cluster Software" entwickelt worden. Interessierte Anwender, die ihre NT Enterprise Edition mit dem WLBS-Zusatz aufrüsten wollen, können sich die nötigen Dateien kostenlos von der Microsoft-Website laden.
Bei Windows 2000 war die Gates-Company in puncto Cluster wieder für eine Überraschung gut. Bis ins späte Betastadium des Microsoft-Betriebssystems für das nächste Jahrtausend hatten die Strategen in Redmond geplant, den Cluster-Dienst in die "Data Center Edition" zu integrieren. Nach neuesten Informationen heißt es nun, die Cluster-Fähigkeiten kämen in einem separaten Produkt, dem "App-Center"-Server, auf den Markt. Das Konzept bietet mehr als eine reine Failover-Lösung, denn es regelt ebenfalls, wie Teile von Applikationen unter den einzelnen Knoten verteilt werden. Microsoft bezeichnet dies als Application Cluster.
In einem Paket aus Diensten ist beim App-Center neben dem Component Load Balancing (CLB) und einem Service für das Netzwerk-Balancing der Cluster-Server untergebracht. Die CLB-Technik dient dazu, die Fähigkeiten von Applikationen, die auf dem Component Object Model (COM+) basieren, in einem Rechnerverbund zu nutzen. Der entsprechende Dienst fungiert als Router, der die Verteilung der COM+-Objekte innerhalb einer Server-Farm regelt. Ein spezieller Mechanismus zum Messen der Antwortzeit bei der Kommunikation soll dabei garantieren, daß die Anfrage nach COM+-Objekten möglichst schnell erfüllt wird. App-Center dient als Management-Konsole für die Steuerung der Lastverteilung von Objekten in dafür geeigneten Anwendungen. Zum Funktionsumfang des Verwaltungswerkzeugs gehören außerdem Replikationsdienste für Komponenten und Dateien.
Angeklickt
Windows NT bringt mit dem Cluster-Dienst MSCS und einem Werkzeug zur Lastverteilung die wichtigsten Voraussetzungen mit, um größere Verbundsysteme aufzubauen. Detailprobleme sorgen jedoch im Moment noch dafür, daß die Standardlösung aus nur zwei Maschinen mit Failover-Funktionalität besteht. Der "App-Center Server" von Windows 2000 bietet auf Basis des COM+-Modells zusätzliche Cluster-Funktionen auf Anwendungsebene. Mehrere Hersteller (zum Beispiel Vinca, Fujitsu-Siemens, IBM) haben eigene Soft- und Hardware für NT-Cluster im Programm.
Servershield
Fujitsu-Siemens bietet mit "Servershield" einen Aufsatz für Windows NT Server an, dessen Softwarekomponenten eine ähnliche Funktionalität wie die Vinca-Variante liefern. Ein System besteht grundsätzlich aus zwei "Primergy"-Rechnern, von denen einer als primäre Maschine die unternehmenskritischen Aufgaben übernimmt, während der zweite als Standby-Server temporär für weniger wichtige Anwendungen genutzt werden kann, zum Beispiel als Testrechner. Ein spezieller SCSI-Switch regelt das Umschalten des externen Speichersystems bei einem Ausfall. Im Normalbetrieb liegt die Kontrolle beim primären Server.
Der Standby-Rechner überwacht das Hauptgerät, indem er von diesem permanent ein Signal (Heartbeat) abfragt. Bleibt das Lebenszeichen aus, interpretiert der Standby-Rechner dies als einen Defekt der primären Maschine. Er beendet die eigenen Anwendungen in diesem Fall und übernimmt über den Switch die Nutzdaten aus dem Speichersystem. Anschließend startet er neu und führt die Datenbank und die Applikationen wie auf dem Hauptrechner aus. Dieser steht nun für Wartungsarbeiten zur Verfügung. Vorteil des Konzepts ist nach Siemens-Angaben, daß die Anwendungen für den Betrieb im Cluster-System nicht modifiziert werden müssen.
Das Cornhusker-Projekt von IBM
Unter dem Codenamen "Cornhusker" arbeitet IBM am Projekt eines NT-Clusters mit acht Maschinen. Als Hardware kommen Netfinity-Server unter NT Server 4.0 zum Einsatz, denen eine proprietäre Software zur gewünschten Verbundfähigkeit verhilft. Das System basiert auf MSCS (Microsoft Cluster Server) und ist als n+1-Lösung ausgelegt. Ein Reserverechner fungiert hierbei als Sicherungs-Server für die übrigen Cluster-Mitglieder. Die Anwendungssoftware muß allerdings speziell für den MSCS-Verbund gestrickt sein, um die Cornhusker-Fähigkeiten zu nutzen. Keine Probleme bereitet in dieser Hinsicht die DB2-Datenbank: Sie läuft als ein einziges Anwendungs-Image im gesamten Verbund. Hier kann IBM den Vorteil des Komplettanbieters ausspielen: Die hauseigene Cluster-Software war mit der Vorgabe konzipiert worden, DB2 zu unterstützen.
Co-Standby Server von Vinca
Eine reine Softwarelösung für einen Failover-Cluster bietet Vinca an. Der von OS/2 und Netware bekannte Software-Aufsatz ist seit geraumer Zeit als "Co-Standby Server" auch unter NT erhältlich. Die Softwerker, die seit August zum Speicher-Management-Anbieter Legato gehören, setzen dabei auf die sogenannte Mirroring-Technik: Wichtige Ressourcen wie Daten oder Applikationen sind zweifach vorhanden und bei einem Ausfall kann auf das Spiegelbild zurückgegriffen werden. Der heikle Punkt ist dabei die Notwendigkeit, den Datenzustand zu jedem Zeitpunkt zu kennen. Für die Kommunikation wird ein besonderer Interserver Link verwendet, der die herkömmliche LAN-Verbindung für Applikationen, Nachrichten oder das Datei-Sharing freihält. Vinca setzt beim Informationsaustausch zwischen den Knoten auf das TCP/IP-Protokoll und unterstützt handelsübliche Netzwerkkarten. Identische Hardware auf den gespiegelten Maschinen ist nicht erforderlich.