Spätestens seit Microsofts Cluster-Applikation "Wolfpack", mit der man zwei Windows-NT-Server ausfallsicher zusammenschalten kann, spielt der Begriff "Availability" eine zentrale Rolle im IT-Vokabular. Die Microsoft-Lösung befreite den Cluster aus seinem Nischendasein im Highend-Segment. Dabei ist die Cluster-Technik keine Errungenschaft der New Economy, sondern bereits rund 15 Jahre alt. Ursprünglich stammt sie aus der Minicomputer-Welt, wo man durch das Zusammenschalten von Systemen einerseits näher an die Rechenleistung von Großrechnern heranrücken wollte und andererseits ein Mehr an Ausfallsicherheit erreichen konnte.
Beides, Ausfallsicherheit und Skalierbarkeit, sind auch heute noch die Hauptgründe für die Installation eines Clusters. Dazu kommt der Wunsch vieler Anwender, in einen Cluster auch Rechner mit verschiedenen Betriebssystemen einzubinden und die Ressourcen so zentral verwalten zu können. Damit lässt sich zwar in der Regel keine Ausfallsicherheit erreichen, weil die Binärdateien der Programme unterschiedlich sind und beispielsweise beim Ausfall eines Unix-Rechners die Daten nicht an einen NT-Server übergeben werden können. Voraussetzung dafür ist jedoch, dass der Hersteller der Cluster-Software, die unter anderem die eingebrachten Ressourcen verwaltet, Varianten für die anderen Betriebssysteme bereitstellt.
Das können oder wollen heute allerdings nur wenige Unternehmen leisten. Denn selbst innerhalb der eigenen Betriebssystemumgebung ist es schwierig, eine Anwendung auf mehrere Knoten zu verteilen beziehungsweise ausfallsicher zu implementieren. "Wenn man dann noch interoperabel sein will, dann ist das, wenn es überhaupt geht, ein Mammutprojekt", weiß Henrik Klagges, der als unabhängiger Analyst einige Cluster-Implementierungen begleitet hat. Dazu kommt, dass sich einige Hardwarehersteller nur ungern mit dem schwierigen Thema Cluster auseinandersetzen. "Server-Hersteller müssen bei manchen Kunden ausfallsichere Systeme anbieten können, sonst erhalten sie den Auftrag nicht", glaubt Klagges.
Die traditionellen Anbieter wie IBM, Fujitsu-Siemens oder Compaq/DEC verfügen seiner Meinung nach wegen ihrer großen Erfahrung über das beste Know-how im Bereich Clustering.
Darüber hinaus gibt es gute Ansätze von unabhängigen Softwarefirmen wie zum Beispiel Veritas, die passable Failover-Lösungen anbieten. Selbst Microsoft zollt der Analyst Lob, zumindest was den Cluster-Service für zwei Knoten angeht: "Wolfpack mit R/3 und SQL 7 lief zwar nicht superschnell, aber relativ stabil." Ein Vorteil der Lösung sei die einfach zu bedienende Management-Konsole, die anderen Herstellern als Vorbild dienen könne.
Damit spielt der Analyst unter anderem auf Sun Microsystems an, dessen Cluster-Software in der alten Version 2.2 sehr schwierig zu konfigurieren war. Die jetzt vorgestellte Variante "Sun Cluster 3.0" wurde hauptsächlich in diesem Bereich stark überarbeitet, wie der Hersteller selbst zugibt. "Suns Entscheidung, eine Management-Konsole einzuklinken und für Homogenität etwa beim Cluster-File-System zu sorgen, war sicher richtig", lobt Klagges die eingeschlagene Richtung. Die neue Version unterstützt Cluster mit bis zu acht Knoten und 512 Prozessoren. Sun hat in die Software nach eigenen Angaben 40 patentierte oder zum Patent angemeldete Komponenten eingebaut. So sind beispielsweise "HA"(High-Availability-)Agenten integriert, die die Cluster-Software für bestimmte Anwendungen optimieren sollen.
Den Trend, die Verbundsoftware auf die Hauptanwendung im Cluster zu optimieren, unterstützt auch Joseph Reger, Vice President Strategic Marketing von Fujitsu-Siemens Computers (FSC). In den hauseigenen "Reliant-Cluster" wurden "Wizards" eingebaut, "die den Cluster auf die Bedürfnisse einer Anwendung hin konfigurieren". Bei FSC steht R/3 im Vordergrund, so dass ein Reliant-Cluster anhand von SAP-Parametern aufgebaut werden kann. Die Münchner haben ihr Cluster-System, das ursprünglich für das hauseigene Reliant-Unix geschrieben war, auch für Sparc-Rechner unter Solaris ("Primepower"-Maschinen) und seit kurzem auch für Linux nutzbar gemacht. Demnächst soll in den USA eine Probelizenz auf den Markt kommen, die allerdings noch eingeschränkte Funktionalität aufweist. So sollen zunächst nur Vier-Knoten-Verbünde möglich sein. Eine NT-Variante von Reliant-Cluster ist in Vorbereitung, die Unterstützung von IBM und HP wäre theoretisch denkbar.
Dennoch erwartet der FSC-Chefstratege, dass dem Linux-Cluster die Zukunft gehört, obwohl die Unix-Systeme mit mindestens zwei Jahren Entwicklungsvorsprung ins Rennen gehen. Innerhalb der Open-Source-Welt wird das Thema von zwei Seiten vorangetrieben. Die Gemeinde selbst forciert Linux für den Einsatz im Enterprise-Bereich, wo man ohne Cluster-Fähigkeit nicht mehr auskommt. Dazu gibt es an vielen Universitäten gigantische Linux-Forschungsprojekte. Die Qualität der Entwicklungen bezeichnet Klagges schon als so ausgereift, "dass ich das heute schon zusammen mit einem starken Partner im Unternehmenseinsatz riskieren würde".
Die zweite treibende Linux-Kraft sind die (Hardware-)Hersteller wie IBM, FSC oder SGI. Erst kürzlich hat SGI die allseits gelobte Clustering-Lösung "Irix-Failsafe" auf Suse-Linux portiert. Einer der Vorteile von Linux im Cluster-Umfeld ist die rapide anwachsende Benutzerzahl. Dazu Klagges: "Ein Problem beim Clustern ist das Debugging. Meist stehen nicht genug Installationen zur Verfügung, um umfassend zu testen. Das ist bei Linux anders." Er glaubt deshalb, dass sich Cluster auf Basis des Open-Source-Unix "schnell entwickeln und einen hohen Standard" erreichen werden.
Hinzu kommt der Preisvorteil. Am günstigsten kann eine Cluster-Lösung über die Partner der Linux-Distributoren bezogen werden. So verlangt beispielsweise das Suse-Systemhaus Quant-X aus dem österreichischen St. Veit an der Glan, das sich auf Alpha-Maschinen unter Linux spezialisiert hat, 720 Euro für ein Cluster-Utility. Damit kann der Benutzer in der Regel 16, im Ausnahmefall sogar 32 Knoten mit je zwei Prozessoren verbinden. Hersteller wie FSC verlangen für ihre Linux-Cluster-Software wesentlich mehr. So wird die Linux-Version von Reliant-Cluster zu solch einem niedrigen Preis nicht angeboten werden können. "Die Hersteller müssen ihr geistiges Eigentum schützen", begründet FSC-Manager Reger. Das erklärt auch, warum die Software nicht als Source-, sondern als Binärcode ausgeliefert werden wird. "Sonst ließen sich ja auch Unix- und Solaris-Lösungen kostenlos realisieren."
Dennoch räumt Reger ein, dass die Linux-Version von Reliant-Cluster billiger auf den Markt kommen wird als die Unix-Variante. Was so eine Lösung kosten kann, erklärt ein Rechenbeispiel von Sun Microsystems. Kostenpunkt von Sun Cluster 3.0 für einen Knoten einer "E250"-Maschine: 2900 Euro. Die HA-Agenten, die nur auf einem Rechner installiert werden müssen, schlagen mit 5800 Euro zu Buche. Im Highend-Bereich wird es noch teurer: Will der Anwender zwei leistungsstarke Maschinen vom Typ "E 10000" ausfallsicher verbinden, dann kostet die Lizenz für einen Rechner rund 100000 Euro.
Hersteller von Cluster-Software können also schon jetzt viel Geld verdienen. In Zukunft könnte es noch mehr werden, wenn die Prognosen von International Data Corp. (IDC) stimmen. Die Marktforscher schätzen, dass 2002 bereits 57 Prozent aller Intel-basierten Unix-Rechner in Clustern gekoppelt sind. Die neuesten Ergebnisse von Meta Group betreffen das Transaktionsvolumen in Rechenzentren, wo oft geclusterte Systeme stehen: Es soll sich bis 2010 verfünfzigfachen. Nutznießer dieser Transaktionslast sollen Windows-Server sein, die dann knapp die Hälfte (48 Prozent) der Arbeit erledigen. Unix-Systeme bewältigen 41 Prozent und IBMs "Z"-Server (ehemals S/390) elf Prozent der Transaktionen.
Anwender, die den Aufbau eines Clusters planen, sollten sich in jedem Fall einen starken Partner mit ins Boot nehmen, rät Analyst Klagges. Das sei nicht nur für die Beratung notwendig, etwa die Frage, welche Interconnect-Verbindungen unterstützt werden, sondern auch für die Implementierung. Selbst wenn man glaubt, alles sei richtig installiert und eingerichtet, könne etwa die Ausfallsicherheit nicht theoretisch überprüft werden. Sein Tipp, um den Ernstfall zu simulieren: Den Stecker an einem Server ziehen!
Single System ImageGroßrechner werden im Cluster eng gekoppelt und meist als "Single System Image" (SSI) betrieben. Das bedeutet, dass sich der Cluster der Anwendung als ein einziger großer Rechner darstellt. In einem solchen Verbund, etwa IBMs Parallel-Sysplex, wird die Applikation mehr oder minder automatisch, gleichmäßig über alle Knoten verteilt. Anders als bei Unix-Verbünden, wo jeder Knoten im Cluster über eine Kopie des Betriebssystems verfügt, profitieren Anwendungsentwickler und Systemadministratoren "von dieser bequemen und zielführenden Art der Zusammenführung", wie FSC-Manager Reger einräumt. Compaq benutzt für seine "Tru-64-Cluster" diese Technik.
Ein Nachteil von SSI-Clustern besteht darin, dass sie sich nicht sehr gut skalieren lassen. Die Anzahl der Knoten in einem solchen Verbund ist auf etwa zwölf beschränkt. Allerdings dürfen die einzelnen Server-Knoten mit mehr als einem Prozessorkomplex bestückt sein. Aus geclusterten Zehn-Wege-Mainframes lässt sich also eine enorme Rechenleistung erzielen, die allerdings auch viel Geld kostet.
Gerade Rechenzentren nutzen zusammengeschaltete Großrechner sowohl zur Leistungssteigerung als auch um Ausfallsicherheit zu erreichen. Dabei sind die einzelnen Server in Partitionen eingeteilt. "Nehmen Sie als Beispiel einen Rechnerverbund aus acht Mainframes, die jeweils in drei Partitions unterteilt sind. Dann können etwa fünf Server-Partitions eine Datenbank betreiben, drei andere sind für ein ERP-System reserviert, und die Partitions von zwei Rechnern sind ausfallsicher organisiert", erklärt IBM-Manger Karl-Georg Martin, Spezialist für Z-Server, die IBM-Architektur.
Scale out - scale inUnter dem Begriff "Scale out" versteht man das Bestreben, den Bedarf nach mehr Leistung dadurch zu decken, dass die vorhandenen Server erweitert werden. Meist geht damit die Implementierung von Ausfallsicherheit einher, sprich, ein zweiter Server wird angeschafft und ein Failover-Cluster eingerichtet. Gerade im Backend-Bereich wächst der Bedarf an solchen Lösungen. Meist reicht aber ein Cluster aus zwei starken Servern aus, um die permanente Verfügbarkeit der Anwendung zu garantieren. Die kritische Frage dürfte hier die I/O-Geschwindigkeit sein und indirekt damit die nach den von der Cluster-Software unterstützten Interconnect-Verbindungen.
"Scale in" bezeichnet das Verfahren, mehr Leistung durch zusätzlich installierte Rechner zu erhalten. Gerade im Hosting-Bereich findet man Rechnerverbünde mit 100 oder mehr Intel-Maschinen. Recovery-Probleme treten dabei nicht auf. Fällt ein Rechner aus, stirbt der Service (Internet-Benutzer kennen das), oder ein anderer Rechner übernimmt die Aufgaben. Interessanterweise wird heute dazu oftmals Citrix/Metaframe verwendet. Die eigentlich als "Thin-Client"-Produkt bekannte Software lässt sich auch als abgespeckte Cluster-Lösung betreiben. Schließlich gibt es für die Zusammenschaltung vieler kleiner Server die neuen Programmiermodelle mit den Application-Servern, etwa IBMs "Websphere" oder "Weblogic" von Bea.
Abb: Im Modell von FSC sollen im Cluster zusammengeschaltete Datenbank-Server Ausfallsicherheit garantieren. Quelle: FSC