Nicht der Preis der Hardware sollte die Motivation für ein Cluster ein. Wichtiger ist die Software - und zwar hinsichtlich der Applikationen und der Systemadministration. Zum einen bestimmt die Multiprozessorfähigkeit der Anwendungen die ideale Größe eines Clusters, zum anderen bringt die Zahl der Server in solch einem Netz Probleme für das System-Management mit sich und erhöht die Kosten.
In einem Cluster wird der gewünschte Datendurchsatz dadurch erreicht, dass mehrere Prozesse einer Applikation parallel abgearbeitet werden. Das heißt, die Programme müssen sich splitten lassen. Wenn eine Anwendung beispielsweise maximal vier parallele Prozesse ermöglicht, beansprucht sie auch nur vier CPUs. Das bestimmt schon die Größe eines Clusters. Wenn vier Programme auf einem Cluster bis zu 20 Prozessoren auslasten können, ist man nicht schlecht beraten, das System um einige CPUs größer zu dimensionieren, nur für den Fall, dass ein Rechnerknoten ausfällt.
Der zweite wesentliche Faktor für die Größe eines Clusters ist die Zahl der zugreifenden Anwender. Wenn auf dem Rechnerverbund E-Mails oder Web-basierende Anwendungen abgewickelt werden, ist es sehr wahrscheinlich, dass er zu verschiedenen Tageszeiten unterschiedlich stark beansprucht wird. Der Verlauf der Systemauslastung lässt sich nur anhand von Erfahrungswerten voraussagen. Unvorhersehbare Beanspruchungen eines Rechnernetzes - beispielsweise rapide steigende Web-Zugriffe nach einem TV-Bericht über ein neues Produkt - sind ein weiteres Argument, ein Cluster nicht zu klein auszulegen.
Und schließlich sollten Anwender die Ausfallsicherheit im Auge behalten. Die permanente maximale Auslastung eines Clusters ist kein erstrebenswertes Ziel. Allein Hitzeprobleme erhöhen die Wahrscheinlichkeit eines Defekts. Alle Einzelelemente des Rechnerverbundes haben erfahrungsgemäß eine durchschnittliche Funktionsfähigkeit (Main-time between failure, Mbtf) von 30000 bis 60000 Stunden. Doch ein Tag mit extremen Außentemperaturen und eine schlechte Klimatisierung lassen die CPUs in den engen Racks weit vor dem Durchschnittswert überhitzen und ausfallen. Noch häufiger kommt vor, dass Peripheriemodule, beispielsweise Netzwerkkarten, ihren Dienst versagen und damit einen Rechnerknoten lahm legen.
Die naheliegende Sorge um die Verfügbarkeit der Anwendungen sollte allerdings auch nicht dazu verleiten, ein Cluster zu großzügig auszulegen. Orientierungsgrößen sind die durchschnittliche und die Spitzenauslastung der bisher genutzten Server. Ein Cluster bietet schließlich den Vorteil, sich sehr schnell nach Bedarf ausbauen zu lassen. Wie lange gegebenenfalls eine eingeschränkte Leistung ökonomisch akzeptabel ist, muss jeder Anwender selbst kalkulieren. Im Prinzip lässt sich danach zwischen zwei Cluster-Typen differenzieren.
Einer teile des anderen Last
In einem "Active/passive-Cluster" sind grundsätzlich alle Komponenten zweifach ausgelegt. Es gibt ein Primärsystem und ein Backup, das einspringt, wenn das erste System ausfällt. Dann muss das redundante Teil in der Lage sein, augenblicklich alle Aufgaben eines Rechnerknotens zu übernehmen und Transaktionen weiterzuführen oder neu zu starten. Derlei ist eigentlich nur in wenigen Business-Anwendungen erforderlich, nämlich dort, wo Redundanz die Systemverfügbarkeit hoch halten muss, beispielsweise bei Banken. Doch dann unterscheiden sich Cluster unter betriebswirtschaftlichen Aspekten vordergründig nicht mehr von anderen redundanten oder fehlertoleranten Servern.
Daher verbreiten sich heute in Unternehmen vor allem "Active/active-Cluster". In ihnen ist jede Rechnerkomponente jederzeit aktiv. Beim Ausfall eines Netzknotens übernimmt ein anderer seine Aufgaben. Mit Hilfe des System-Managements lässt sich vermeiden, dass die Umleitung von Tasks zu Flaschenhälsen führt.
Ein häufig zu wenig beachteter Faktor bei der Kalkulation der Cluster-Dimension ist die Verbindung der Knoten untereinander. In einem kleineren Cluster wird ein "Masternode" alle Zugriffe auf die Knoten abwickeln. Dieser Zugangsprozessor lenkt nicht nur die Abfragen der Endanwender. Er verteilt als "Pre-Prozessor" auch die Anwendungen auf die Subsysteme, kontrolliert die Abwicklung der Prozesse und überwacht den Zustand der Einzel-Server. Es kann schon angesichts der Auslastung dieses zentralen Servers empfehlenswert sein, hier ein 64-Bit-System einzusetzen, während der Rest des Clusters mit preisgünstigeren 32-Bit-Prozessoren arbeiten kann. So lässt sich einem möglichen Engpass schon am Zugang des Clusters vorbeugen.
Hardware zur Steuerung des Verbundes
Bei größeren Clustern wird man die vielfältigen Steuerungsaufgaben auf verschiedene spezialisierte Masternodes verteilen, beispielsweise könnte eine separate Einheit für die Systemadministration freigehalten werden. Oder es gibt einen E-Mail-fähigen Spezial-Node für die Überwachung der Prozesse, der die Anwender informiert, wenn ihre Applikationen abgearbeitet sind. Ein separater Masternode zum Handling der Anwender-Requests empfiehlt sich schon allein deshalb, weil sich dadurch die Sicherheit eines Clusters deutlich erhöhen lässt.
Neben den Masternodes arbeiten "Compute-Nodes" an der eigentlichen Erledigung der Aufgaben. Sie sind nach den Multiprozessorfähigkeiten der Applikationen in Gruppen organisiert. Dabei müssen sie nicht nur mit den Masternodes, sondern auch untereinander kommunizieren. Sie parallelisieren die Segmente der Anwendungen und führen die Einzelberechnungen der Nodes am Ende zusammen. Dies geschieht über Message Passing, wobei sie gemeinsame Libraries, die Message Passing Interfaces (MPIs) verwenden.
Hardwareseitig läuft die Kommunikation über verschiedene Interconnect-Techniken. Diese Verbindungen haben unterschiedliche Bandbreiten, nämlich 12 Megabit pro Sekunde (Mbit/s) bei Fast-Ethernet, 125 Mbit/s bei Gigabit-Ethernet, 80 Mbit/s bei 32-Bit-Myrinet, 160 Mbit/s bei 64-Bit-Myrinet, 200 Mbit/s beim "Scalable Coherent Interface" (SCI) von Scali und maximal 30 Gb/s bei Infiniband. Entsprechend langsam oder schnell ist die Latenzzeit, die Zeit, die zur Übergabe eines Datenpakets zwischen zwei Knoten benötigt wird. Die Interconnects arbeiten mit unterschiedlichen Protokollen: mit TCP/IP bei Standard-Ethernet, mit der "Virtual Interface Architecture" (VIA) bei Gigabit-Ethernet, SCI sowie mit dem Protokoll "Grand Message" im Falle Myrinet.
Für eine Entscheidung, welche Interconnects in einem Cluster Verwendung finden sollen, ist nicht nur die Frage zu klären, welche Protokolle von den Applikationen unterstützt werden. Auch der Preis allein - Myrinet-Verbindungen sind deutlich teurer als Ethernet-Karten - ist nicht ausschlaggebend. Schließlich werden sich das Preis-Leistungs-Verhältnis und die Leistungsfähigkeit eines Clusters nicht an abstrakten Benchmarks, sondern nur an der Performance der Anwendungen messen lassen. Entscheidend ist in erster Linie das Verhalten der Applikation im Cluster.
Netzwerk-Know-how ist gefragt
Wenn Anwendungen Rechenaufgaben nur nebeneinander abarbeiten, besteht geringer Bedarf an sehr schnellen Verbindungen zwischen den Nodes. Beispielsweise können viele CPUs weitgehend unabhängig voneinander die einzelnen Bilder eines Computer-animierten Films berechnen. Ethernet-Verbindungen sind dann völlig ausreichend. Soll allerdings das Verformungsverhalten eines großen Bauteils simuliert werden, dessen Einzelelemente jeweils von einer CPU berechnet werden müssen, haben die Nodes eine ausgesprochen hohe Interaktion. Hier braucht man Myrinet-Verbindungen. Ausschlaggebend ist ferner die Häufigkeit, mit der Prozessoren auf externe Datenbanken zugreifen müssen..
Die Interconnects sind für das Leistungsverhalten eines Clusters dermaßen wichtig, dass der Anbieter der Cluster-Software "auf jeden Fall Know-how im Netzwerksektor haben sollte", fordert Thomas Warschko, technischer Direktor Europa beim Anbieter Linux Networx in Kaiserslautern. "Und der Anbieter sollte die Installation vorkonfiguriert und getestet übergeben. Leider wird das viel zu oft vergessen."
Der nächste wichtige Punkt zur Entscheidung über ein Cluster betrifft das Betriebssystem. Microsoft hat nach anfänglich großen Problemen mit Windows-2000-basierenden Clustern langsam Fuß fassen können. Inzwischen bietet das Unternehmen mit dem "Computational Cluster Technical Preview Kit" (CCTP) eine Sammlung von Werkzeugen zum Aufbau und zur Optimierung von Clustern auf Grundlage von Windows 2000 Advanced Server und Windows XP. Wie immer zielt der Anbieter zunächst auf das untere Leistungssegment. Dort ist die Lösung aus Redmond dann zu empfehlen, wenn das IT-Personal in einem Unternehmen Erfahrung mit Microsoft-Umgebungen hat.
Die meisten Cluster werden aber in Firmen eingerichtet, die Unix-Systeme ersetzen. Wegen der Ähnlichkeit der Systeme finden dort vor allem Linux-Cluster Anklang. Den Unix-Spezialisten fällt es leicht, mit der quelloffenen Alternative zu arbeiten. Diese Eingriffe können bei großen Clustern sehr weit gehen: Die von Suse oder Red Hat stammenden Linux-Varianten werden bis auf den Kernel, Libraries und Compiler reduziert.
Den radikalsten "Striptease" verfolgt das Open-Source-Projekt "Linux-BIOS", das sogar das normale BIOS der Intel- beziehungsweise AMD-Rechner ersetzt. Das Linux-BIOS initialisiert die Hardware auf dem Knoten und holt sich dann das Linux-Betriebssystem von der lokalen Festplatte (eher selten) oder (idealerweise) von einem Boot-Server. Das Basis-I/0-System lässt sich genau auf die ohnehin normalerweise stark reduzierten Hardwarekomponenten eines Knotens einrichten. Im Ergebnis sind die Nodes schon in wenigen Sekunden einsatzbereit, Änderungen oder Upgrades lassen sich remote steuern und bestehen dann konsistent über das gesamte Cluster.
Doch auch ein stark reduziertes ClusterLinux wird wieder erweitert, nämlich um Software für das System-Management. Die Administration eines Clusters ist ein besonders kritischer Aspekt. Im Prinzip verlangen die Rechnerverbünde mehr Administrationsarbeiten als traditionelle Systeme mit vielen symmetrischen Multiprozessoren in einer Box. In einem Cluster ist jeder Knoten ein eigener Server. Jeder von ihnen besteht oft aus zwei oder mehr Prozessoren, die gegebenenfalls selbständig arbeiten, obwohl sie sich die I/0-Verbindungen, Hauptspeicher und lokale Festplatte teilen. Und alles soll unter Kontrolle sein.
Tools entlasten den Administrator
Das Ganze ergibt ein Szenario, das "locker ausreicht, im Problemfall Systemadministratoren in den Wahnsinn zu treiben", beobachtet Hakon Bugge, Chefentwickler des norwegischen Tool-Anbieters Scali. Nicht zuletzt deshalb hat sich Intel des Themas Cluster-Management angenommen. So hat der Hersteller das "Intelligent Platform Management Interface" (IPMI) entwickelt, über das ein Node Probleme anzeigt oder sich im Cluster an- und abmeldet. Außerdem stammen von Intel Compiler für seine 32- und 64-Bit-Architekturen, Tools zur Analyse und zum Tuning der Performance ("Vtune"), zum Multithread-Debugging ("Assured Thread Analyser") und zur Verbesserung von Anwendungen durch "Open-MP"-Code ("KAP/Pro").
Weitere Vereinfachungen im Umgang mit einem Cluster bringt "Scyld". Das Management-Tool geht auf die Mutter aller Linux-Cluster-Software zurück, auf "Beowolf". Die Firma Scyld Computing wurde im Juni dieses Jahres von Pengiun Computing übernommen. Im Open-Source-Projekt "Oscar" ist eine ganze Sammlung von Tools für den Aufbau und die Verwaltung von Linux-Clustern mit bis zu 253 Nodes entstanden. Die Oscar-Werkzeuge reichen von der Administration, über die Anwendungsprogrammierung bis zu Job-Scheduling, Batch-Verarbeitung und Workload-Management.
Damit ist es aber noch nicht getan. Die Aufmerksamkeit gilt insbesondere der Prävention von Ausfällen, der Diagnose von Fehlern und dem Recovery wiederhergestellter Nodes. Clusterworx bietet beispielsweise einen Event-Manager an, der die Überwachung von rund 40 Parametern erlaubt. Dazu gehören unter anderem CPU-Temperaturen, Lüfterdrehzahlen, Betriebsspannungen sowie Auslastungen von Prozessoren, RAM, Netzwerk und Festplatten. Im Ernstfall wird der Administrator informiert und Nodes im kritischen Zustand werden automatisch ausgeschaltet.
Automatisiertes Failover
Ähnlich konzentriert sich die Firma Steeleye mit dem hierzulande von Computer Concept, Dresden, vertriebenen Produkt "Lifekeeper" auf Hochverfügbarkeit. Nach Anwender-definierten Szenarien organisiert diese Software ein automatisches Failover von Anwendungen auf wenig ausgelastete Nodes - bei einer Kettenreaktion auch kaskadierend über mehrer Nodes. Der Anbieter Scali hat sich darauf spezialisiert, verteilte Cluster mit unterschiedlichen CPU- und Netzwerk-Layouts Grid-artig unter einen Hut zu bringen. Elementare Tools, um die preisgünstigen Cluster auch so komfortabel administrierbar zu machen wie die massiven Systeme der Unix- und Mainframe-Welt sind also vorhanden. Und das Ende der Entwicklung ist nicht abzusehen.
"Scaling out" ist billiger als "Scaling up"
Einer der entschiedensten Clustering-Befürworter unter den Softwareanbietern ist Oracle. Für die Datenbanklösung "Oracle 9i Real Application Cluster" (RAC) wirbt das Unternehmen vor allem mit Kostenaspekten. "Scaling out", wie Oracle Clustering nennt, ist demnach preiswerter als "Scaling up". Letzteres, der Kauf von Systemen mit mehr CPUs, erfolgt auf Basis einer Kalkulation des voraussichtlichen Bedarfs an Rechenleistung über die nächsten zwei oder drei Jahre. Dabei ist nicht nur das teure System sofort zu zahlen, hinzu kommen auch seine nach der Zahl der Prozessoren berechneten Leistungs- und Lizenzkosten.
Cluster hingegen lassen sich linear entsprechend der Anforderungen ausbauen - oder wieder abbauen. Die über die preiswerten x86-basierenden Server hinaus anfallenden Kosten entsprechen also den tatsächlichen Anforderungen und entlasten so das IT-Budget. Das gilt laut Oracle auch dann noch, wenn nicht jede CPU im Cluster ihre Leistung im vollen Maße den Anwendungen zur Verfügung stellen kann, weil ein Teil ihrer Performance von der Administration und dem Netzverkehr verbraucht wird oder mancher Node nur zur Sicherung der Systemverfügbarkeit mitläuft.
Darüber hinaus argumentiert Oracle damit, dass eine Datenbankanwendung für RAC nicht umgeschrieben werden muss. Die Datenbankvariante sorgt selbst für die Cluster-Fähigkeit der Applikationen, von der Update-intensiven Transaktionsverarbeitung bis zum Data-Warehousing mit hohem Aufkommen an Lesezugriffen. RAC läuft mit den Linux-Distributionen von Red Hat und Suse.