Information und Bildungsarbeit von und für die SAP-Community

Das neue alte Cluster

Cluster – der Begriff klingt in manchen Ohren wie ein Relikt aus längst vergangenen Jahren. Wozu sollten wir in Zeiten von Cloud und Virtualisierung so etwas noch benötigen?
Gerd Jelinek, CC
17. Juni 2013
Das-aktuelle-Stichwort
avatar

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 BackupRechenzentrum 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 CloudSysteme die nächste Herausforderung. Ein mehrfacher Test ist hier ein wichtiger Erfolgsfaktor.

SAPSysteme

Noch gar nicht betrachtet haben wir die SAPSysteme. 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 SAPZertifizierung 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, SAPSysteme 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.

 

avatar
Gerd Jelinek, CC

Gerd Jelinek ist Manager beim SIOS Competence and Support Center


Schreibe einen Kommentar

Die Arbeit an der SAP-Basis ist entscheidend für die erfolgreiche S/4-Conversion. 

Damit bekommt das sogenannte Competence Center bei den SAP-Bestandskunden strategische Bedeutung. Unhabhängig vom Betriebsmodell eines S/4 Hana sind Themen wie Automatisierung, Monitoring, Security, Application Lifecycle Management und Datenmanagement die Basis für den operativen S/4-Betrieb.

Zum zweiten Mal bereits veranstaltet das E3-Magazin in Salzburg einen Summit für die SAP-Community, um sich über alle Aspekte der S/4-Hana-Basisarbeit umfassend zu informieren.

Veranstaltungsort

Mehr Informationen folgen in Kürze.

Veranstaltungsdatum

Mittwoch, 21. Mai, und
Donnerstag, 22. Mai 2025

Early-Bird-Ticket

Verfügbar bis Freitag, 24. Januar 2025
EUR 390 exkl. USt.

Reguläres Ticket

EUR 590 exkl. USt.

Veranstaltungsort

Hotel Hilton Heidelberg
Kurfürstenanlage 1
D-69115 Heidelberg

Veranstaltungsdatum

Mittwoch, 5. März, und
Donnerstag, 6. März 2025

Tickets

Reguläres Ticket
EUR 590 exkl. USt
Early-Bird-Ticket

Verfügbar bis 20. Dezember 2024

EUR 390 exkl. USt
Veranstalter ist das E3-Magazin des Verlags B4Bmedia.net AG. Die Vorträge werden von einer Ausstellung ausgewählter SAP-Partner begleitet. Der Ticketpreis beinhaltet den Besuch aller Vorträge des Steampunk und BTP Summit 2025, den Besuch des Ausstellungsbereichs, die Teilnahme an der Abendveranstaltung sowie die Verpflegung während des offiziellen Programms. Das Vortragsprogramm und die Liste der Aussteller und Sponsoren (SAP-Partner) wird zeitnah auf dieser Website veröffentlicht.