Le nouveau vieux 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 Disponibilité le 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 Disponibilité 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 Serveurs, 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 Erreur können erkannt werden.

Le site 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 Matériel informatique et le Applikation müssen natürlich auch die Données 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 
Disponibilité le 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.

Le site 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?

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

Le site 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 Virtualisation 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 Erreur, 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 le Virtualisation 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 Base de données gemacht.

Le site Client wollte wie gewohnt eine Offline-Sicherung seiner Base de données erstellen und hielt die Base de données 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.

Le site nicht ganz billige Perfektion besteht sicher in einem Sauvegarde–Centre de données oder -Rechnerraum.

Oft werden Lösungen geboten, die zumindest die Données an einen zweiten Ort replizieren. Nur: Le site 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 Serveurs für den Fehlerfall mit virtualisierten Systemen zu schützen.

Bei passenden Rahmenbedingungen spricht auch nichts gegen das virtuelle Centre de données dans la 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 Données in die Cloud.

Après la Installation le 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-Certification 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–Certification für Clusterprodukte.

Für uns und unsere Clients besonders wichtig war auch die mit der Certification 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 Certification 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.

Conclusion

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 Disponibilité.

Wichtig ist aber auch die Möglichkeit der Integration der Verfügbarkeitslösung in Managementsysteme, die Matériel informatique 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.