Das neue alte Cluster

Wir beschäftigen uns seit vielen Jahren mit dem Schutz geschäftskritischer Applikationen durch Cluster. Installation und Verkauf komplexer Systeme ist sicher die erste Etappe des Lebenszyklus.

Ab diesem Punkt beginnt der Betrieb. Ein entscheidender Parameter dabei ist die Verfügbarkeit der Applikation.

Gut, das haben nicht wir entdeckt, sondern das erkannten schon unsere Kollegen in der großen Zeit der Unix-Betriebssysteme.

Das legendäre VMS Cluster, Veritas Cluster Server für Solaris oder die True64 Cluster haben hier hohe Maßstäbe für die Verfügbarkeit gesetzt.

Auch der LifeKeeper war als hauseigenes Produkt für MP-RAS der NCR verfügbar und wurde als eine der ersten Lösungen in die x86-Welt portiert.

Bevorzugte Betriebssystembasis wurde gerade Microsoft Windows NT 3.5. Ob das Zufall war?

Fehlersuche

Das Verfügbarkeitscluster besteht, wie bekannt, aus mindestens zwei Servern, um die Redundanz zu erhöhen.

Damit sollte bei durchdachter Architektur in dem sich daraus ergebenden Gesamtsystem kein Single Point of Failure (SPoF) mehr enthalten sein.

Zweiter und fast noch wichtigerer Ansatzpunkt zur Vermeidung von Systemausfällen ist die Applikationsüberwachung.

Und hier unterscheiden sich die Produkte teilweise sehr.

Je genauer und flexibler das Monitoring der Applikation an den jeweiligen Einsatzfall angepasst werden kann, desto mehr Fehler können erkannt werden.

Die beste Prüftiefe haben hier meist Lösungen, die mit der Applikation selbst geliefert werden.

Sind aber unterschiedliche Clusterlösungen je Applikation der richtige Weg für den Rechenzentrumsbetrieb und können damit alle spezifischen Anpassungen vorgenommen werden?

Unbestritten bringt der Gesamtausfall eines Clusterknotens klare Verhältnisse – nur ist es meist nicht so trivial. Und ohne regelmäßige Prüfung der Funktionalität ist das erwartete Ergebnis im Fehlerfall nicht unbedingt erreichbar.

Neben Hardware und der Applikation müssen natürlich auch die Daten geschützt werden.

Virtualisierung als Lösung

Da bei Aufbau und Betrieb eines Clusters doch einige Punkte zu beachten sind, um das gewünschte Ziel zu erreichen, schien Servervirtualisierung mit ihren Möglichkeiten eine willkommene Lösung, die auch nebenbei die 
Verfügbarkeit der Systeme mit erhöht.

Bestreiten möchte ich das nicht, wenngleich ein zusätzlicher Virtualisierungslayer eingeführt wurde – in der Praxis stellt sich dieser jedoch als stabil dar.

Die Möglichkeit, virtualisierte Systeme einfach von einem Hardwareknoten auf einen anderen zu verschieben, ist zweifellos eine wunderbare Sache.

Nur, wie bemerke ich, wann ich dies tun muss, und löst der Hardwaretausch das Problem?

Die Virtualisierungssoftware bemerkt sowohl den Ausfall eines Host-Systems, kann aber auch das Betriebssystem des Gastsystems überwachen.

Die Applikation bleibt  außen vor

An diesem Punkt lassen sich unsere Erfahrungen aus dem Applikations-Monitoring bestens einbringen. Sicher ist es unter Beachtung bestimmter Randbedingungen möglich, ein klassisches Cluster auch als virtualisiertes System zu implementieren.

Wesentlich eleganter erscheint mir jedoch die Möglichkeit, sich auf die Erfahrungen mit dem Schutz von Applikationen zu beschränken, und das Schalten der Virtualisierung zu überlassen.

Neben den lang ersehnten Erleichterungen zeigt sich, dass Servervirtualisierung auch (ungewollt) zu einem enormen Anstieg der Zahl der Systeme führen kann.

Denn je Applikation noch ein Cluster aufzusetzen, erhöht die Zahl der Systeme noch weiter.

Aus dieser Not wurde der Gedanke des One Node Clusters entwickelt.

Genügt es für viele Fehler, das System oder sogar nur die Applikation zu überwachen und im Bedarfsfall neu zu starten?

Sinnvoll ist das sicher, nur hätte ein schöner Name auch dazugehört. One Node Cluster ist wie Single Familie – aber wir wissen in der IT schon, wovon wir sprechen, jedenfalls meistens.

Die Übersicht bewahren

Um nicht zusätzliche Komplexität und Verwirrung in die Systemadministration zu bringen, achten wir auf eine integrierte Administration der Applikationsüberwachung.

Es kann nicht das Ziel sein, neben der Administration der Virtualisierung der meist sehr vielen Systeme noch daran zu denken, welche Systeme im Cluster betrieben werden oder den verschiedenen Host-Systemen zuzuweisen sind und so weiter.

Diese Erfahrung habe ich schon bei einer unserer ersten Clusterinstallationen zum Schutz einer Datenbank gemacht.

Der Kunde wollte wie gewohnt eine Offline-Sicherung seiner Datenbank erstellen und hielt die Datenbank auf dem ersten Knoten an – offline ging trotzdem nicht: richtig.

Absicherung

Mit der immer weiter wachsenden Abhängigkeit nahezu aller Prozesse von der IT wächst –langsam – die Bereitschaft, sich mit dem Desasterfall zu beschäftigen.

Die nicht ganz billige Perfektion besteht sicher in einem Backup–Rechenzentrum oder -Rechnerraum.

Oft werden Lösungen geboten, die zumindest die Daten an einen zweiten Ort replizieren. Nur: Die Daten allein sind nur Einsen und Nullen.

Der nächste Schritt wäre also, auch die Anwendungen im Desasterfall parat zu haben.

Neben den Möglichkeiten, die auch hier Virtualisierungslösungen bieten, ist das Cluster über Rechenzentrumsgrenzen hinweg – das sogenannte Stretched Cluster – eine gute Option.

Es ist durchaus auch die Konfiguration sinnvoll, Anwendungen auf physischen Servern für den Fehlerfall mit virtualisierten Systemen zu schützen.

Bei passenden Rahmenbedingungen spricht auch nichts gegen das virtuelle Rechenzentrum in der Cloud, um sich gegen den Desasterfall zu schützen.

So einfach wie im Prospekt sind all diese Lösungen nicht, da es meist anders kommt als gedacht. Technische Basis ist sicher die Replikation der Daten in die Cloud.

Nach der Installation der Applikation ist auch der Zugriff der Nutzer auf die Cloud–Systeme die nächste Herausforderung. Ein mehrfacher Test ist hier ein wichtiger Erfolgsfaktor.

SAP–Systeme

Noch gar nicht betrachtet haben wir die SAP–Systeme. Als hoch geschäftskritische Systeme sind sie natürlich prädestiniert für den Applikationsschutz.

Genügend SPoF gibt es am Einzelsystem auch.

Als Bekenntnis zur Applikationsverfügbarkeit ist sicher die High-Availability-Zertifizierung zu verstehen, die durch das LinuxLab der SAP im vergangenen Jahr eingeführt wurde.

Bis zu diesem Zeitpunkt wurden Clusterlösungen als Middleware eingestuft und keinem Test unterzogen.

Aber nicht nur der technische Testkatalog ist Gegenstand der SAP–Zertifizierung für Clusterprodukte.

Für uns und unsere Kunden besonders wichtig war auch die mit der Zertifizierung verbundene Zusage, im Fehlerfall auch in dieser Umgebung ohne Deaktivierung der Clusterkomponenten Support zu leisten.

Dazu werden in einem definierten Supportprozess, dessen Definition Bestandteil der Zertifizierung ist, die Anbieter der Verfügbarkeitslösung mit in den Supportprozess integriert.

Wichtige Komponente der Clusterzertifizierung ist auch die Möglichkeit, SAP-Cluster per SAP Adaptive Computing Controller (ACC) beziehungsweise dem Landscape Virtualization Management (LVM) steuern zu können.

Mit den Kollegen in St. Leon-Rot untersuchen wir derzeit die Sinnfälligkeit und Praktikabilität, SAP–Systeme mit einer Cloud-Lösung gegen den Desasterfall zu schützen.

Fazit

Der Kaiser ist tot – es lebe der Kaiser.

Nein, ich möchte nicht behaupten, dass Cluster ewig so fortbestehen werden, wie sie vor Jahren entwickelt wurden.

Neben der Bedeutung für den Desasterschutz bildet das Wissen um die Applikationsüberwachung immer mehr den Schwerpunkt zur Erhöhung der Verfügbarkeit.

Wichtig ist aber auch die Möglichkeit der Integration der Verfügbarkeitslösung in Managementsysteme, die Hardware beziehungsweise Virtualisierungsumgebungen überwachen und steuern. Beachtet man dies und versucht, die Komplexität der Gesamtlösung zu beherrschen, bilden Cluster auch weiterhin ein gutes Mittel zur Sicherung der Applikationsverfügbarkeit.

Der moderne Kaiser lebt.