Cluster-Lösungen im Vergleich (Teil 2)

Digital Equipment macht mit Clustern unter Open VMS die beste Figur

27.03.1998

Als Grund hierfür muß man DECs lange Historie und damit große Erfahrung als Entwickler von Cluster-Konzepten sehen. Nicht von ungefähr seien wesentliche Cluster-Charakteristika schon im Design des Open-VMS-Betriebssystems vorgesehen, schreiben die TBR-Analysten.

Im ersten Teil dieses Artikels über die TBR-Untersuchung zu neun am Markt verfügbaren Cluster-Lösungen (siehe CW Nr. 12 vom 20. März 1998, Seite 59: "Digital-Cluster...") wurden die Ergebnisse bezüglich des Skalierverhaltens der verschiedenen Angebote referiert. Bei der Frage, wie sich zu Clustern verbundene Rechner im Falle einer Havarie verhalten, wie ausfallsicher (availability) also Computerkomplexe sind, attestieren die TBR-Autoren Digitals Cluster-Variante ebenfalls höchste Noten.

Automatische Rekonstruktion

Open VMS speichert bei Systemabstürzen den jeweils aktuellen Stand von Applikationen und rekonstruiert diesen automatisch wieder, nachdem eine Anwendung auf einen intakten Cluster-Komplex umgelagert wurde. Darüber hinaus erstellt das DEC-Betriebssystem ein sogenanntes Two-phase-Commit-Protokoll von aktiven Jobs. Diese Vorkehrungen schützen die Integrität von während einer Havarie gerade laufenden Transaktionen.

Ähnlich arbeitet NCRs "Lifekeeper"-Cluster-Lösung. NCR nutzt hierzu den bekannten Transaction-Processing-Monitor (TPM) "Top End". Der Rekonstruktionsvorgang läuft ohne Zutun des Anwenders ab, im Branchensprachduktus wird das als "transparent" bezeichnet.

Anders die "Parallel-Sysplex"-Variante der IBM für ihre S/390-Großrechner: Aus Sicherheitsgründen, wie die TBR-Experten in ihren Bericht schreiben, muß sich der Benutzer nach einem Rechnerausfall neu bei der vorher benutzten und nun auf einen anderen Rechnerknoten verlagerten Anwendung anmelden.

Bei Hewlett-Packards (HPs) "MC/Service-Guard"- und "X-Class"- sowie bei Suns "PDB-Cluster"-Varianten muß der Benutzer nach dem Ausfall eines Rechnerknotens eine vorher etablierte Session neu starten.

Ein ganz anderes, dabei aber nicht minder wichtiges Thema ist, wie man die Verfügbarkeit einer DV-Anlage sichern kann, indem man einzelne Rechnerknoten eines Clusters voneinander getrennt plaziert. Auch diesbezüglich kann, so die TBR-Autoren, DECs Open-VMS-Lösung überzeugen. Sie sei die einzige (TBR untersuchte Cluster-Angebote, die 1997 am Markt verfügbar waren), die die Möglichkeit biete, im Falle von Rechnerabstürzen ein Fail- over-Szenario zu initiieren sowie Arbeiten und Lasten automatisch auf verschiedene, geografisch auseinanderliegende Rechenzentren zu verteilen. Dabei können in Open-VMS-Clustern Rechnerknoten bis zu 500 Meilen entfernt voneinander aufgebaut werden. Mit Software-Tools, die allerdings nicht von DEC, sondern von Drittfirmen angeboten werden, und die sogenannte asynchrone File-Commits erlauben, läßt sich diese Entfernung sogar auf bis zu 3000 Meilen ausdehnen.

Auch die IBM bietet für ihre High-Availability-Cluster-Multi-Processing-(HACMP-)Lösung unter Unix solch eine Technologie an. Zur Zeit der Drucklegung des TBR-Reports war das nur in Verbindung mit HACMP zu nutzende Hageo-Feature (Hageo = High Availability Geographic) noch nicht verfügbar, was sich laut Hans-Jürgen Rehm, dem IBM-Zuständigen für Großsysteme, aber mittlerweile geändert hat. Analog zur Variante von Digital Equipment erlaubt auch Hageo, so TBR, gleichermaßen synchrone oder asynchrone Schreibzugriffe auf Systeme, die mehrere tausend Meilen voneinander getrennt stehen.

Unterschiedliche räumliche Trennung

Bei allen anderen getesteten Cluster-Lösungen hat der Anwender bezüglich der räumlichen Trennung nicht im entferntesten solche Möglichkeiten: Hier müssen die gekoppelten Rechnerknoten entweder im selben Gebäude oder zumindest auf dem gleichen Firmenanwesen aufgestellt werden. Ganz stimmt das allerdings auch nicht: Nutzt man bei IBMs Parallel-Sysplex-Clustern eine Coupling Facility, so lassen sich auch hier räumliche Trennungen von bis zu zehn Kilometern überbrücken.

Kommt es zum GAU in Rechenzentren, ist auch das RZ-Personal gefragt. Je weniger die DV-Experten bei Systemabstürzen dabei selbst Hand anlegen müssen, um Daten und Transaktionen zu retten, desto besser. Bis auf HPs "Service-Guard"- und "X-Class"-Varianten unterstützen alle anderen Cluster-Lösungen automatisch, also ohne Zutun der DV-Experten, ablaufende Failover-Konzepte.

Bei Suns "PDB Cluster" und HPs "MC/Lock Manager" handelt es sich im eigentlichen Sinn allerdings nicht um klassische Failover-Mechanismen. Beide begegnen Abstürzen von Rechnerknoten insofern, als sie Kopien von Anwendungen und von parallelen Datenbankapplikationen auf jedem Knoten fahren. Das bedeutet, schreiben die TBR-Analysten, aber auch: Sollte eine Applikation nur auf einem Knoten aktiv sein und dieser havariert, so muß das DV-Personal händisch intervenieren, um ihren exakt gleichen Zustand auf dem zweiten Rechnerknoten wiederherzustellen. Sun bietet für seine PDB-Lösung allerdings seit jüngerem Schnittstellen an, die, vorausgesetzt sie werden von Applikationen unterstützt, den automatisierten Failover-Prozeß abdecken.

Um auf Failover-Situationen vorbereitet zu sein, müssen in Cluster-Systemen entsprechende Vorkehrungen getroffen werden: Hierzu gehört etwa, im Vorfeld Scripts zu schreiben. Diese beschreiben unter anderem die physikalischen oder logischen Zuordnungen von Applikationsdateien. Sie legen ferner fest, welche Aktionen gestartet werden müssen, um Daten im Fall einer Havarie zu retten. Die TBR-Analysten bewerteten bei der Kategorie "Verfügbarkeit" deshalb auch, wie leicht solche Scripts und Software-Agenten entwickelt werden können und welche Wirkung sie entfalten. Nur Digitals Open-VMS-Lösung, betonen die Autoren der Untersuchung, benötigt überhaupt keine Präparation wie etwa die Entwicklung von Scripts oder spezielle Veränderungen an Applikationen.