Cluster-Lösungen im Verbund mit SAP Netweaver
Hochverfügbarkeit für SAP-Umgebungen
"SAP Netweaver" als moderne Application-Server-Technik ist Grundlage der Anwendungen der "SAP Business Suite" und sorgt für deren nahtlose Vernetzung. Daher ist es unabdingbar, dieses System ohne Ausfallzeiten hochverfügbar zu betreiben. Doch nicht alle Techniken sind für alle Größen und vor allem für jede Dynamik von SAP Netweaver geeignet. Für dessen Version 7.30 ist erstmals eine Schnittstelle für externe Hochverfügbarkeitssoftware definiert, die Anforderungen an die Produkte festgelegt und den Support der Gesamtlösung durchgängig ermöglicht.Unabhängig vom Lösungsansatz sind zwei wichtige Komponenten zu erfüllen: die Verfügbarkeit der Services selbst sowie die der dazugehörigen Daten. Im SAP-Umfeld gilt es, für die spezifischen "Single Points of Failure" (Datenbank, "SAP Message Service", "SAP Enqueue Service" und SAP-File-Systeme) Redundanz herzustellen. Ein ausfallsicheres Design beinhaltet dabei Cluster-Techniken als Bestandteil einer Hochverfügbarkeitslösung sowie Replikation für ein Disaster Recovery. Stehen identische Daten auf zwei lokalen Volumes bereit, so spricht man gemeinhin von Spiegelung (Mirroring). Schreibvorgänge erfolgen dabei synchron. Lesevorgänge können auf beiden Seiten erfolgen, was die Performance erhöht. Üblicherweise geschieht dies Storage-basierend per Software-RAID mit Level 1 oder auch über zwei getrennte Storage-Systeme mit SAN-Infrastruktur. Die Replikation erfolgt dagegen auf ein zweites, remote zur Verfügung stehendes Storage Device und lässt sich vollkommen transparent und performant konfigurieren. Die Notwendigkeit zweier Storages und entsprechender Softwarelizenzen macht diesen Ansatz jedoch kostenintensiv. Alternativ zu reinen Storage-basierenden Ansätzen gibt es auch Lösungen für die Host-basierende Spiegelung: Dabei werden zwei oder mehr lokal verfügbare Volumes zu einem Spiegel zusammengefasst. Die Volumes können sich dabei auf verschiedenen Storage-Systemen befinden, um Hardwareredundanz zu erreichen. Die Spiegelung erfolgt synchron. Der Spiegel wird dort als Multiple-Disk-(MD-)Device bezeichnet und ist ein weit verbreiteter Ansatz im Linux-Umfeld. Diese Art der Spiegelung setzt jedoch einen Shared Storage voraus, auf den alle Cluster-Knoten Zugriff haben. Es entfallen die üblichen Lizenzkosten für Storage-basierende Replikation, eine SAN-Infrastruktur ist dennoch erforderlich. Deshalb kann für kleine und mittlere SAP-Anwender die Host-basierende Replikation mit einer Hochverfügbarkeits-Cluster-Software die Lösung sein. Durch diesen Ansatz verringert sich die Komplexität. Die Daten liegen auf lokalen Platten und werden über das Netzwerk auf andere Cluster-Knoten repliziert. Diese Replikation kann synchron oder asynchron stattfinden. Nachteilig wirkt sich die synchrone Replikation auf die Performance aus, da das System einen Schreibvorgang erst dann als erfolgreich meldet, wenn dieser auf beiden Seiten erfolgt ist. Deshalb ist im Einzelfall zu prüfen, welcher Ansatz zur jeweiligen Gesamtumgebung und -anforderung passt. SAP Netweaver 7.3 und zu sichernde Komponenten SAP bietet in der gesamten Architektur eine skalierbare und fehlertolerante mehrschichtige Lösung an, die sich durch Skalierbarkeit der Netweaver-7.3-Applikations-Server sowie Cluster-Lösungen von Fremdherstellern gegen Ausfälle schützen lässt. Eine der ersten zertifizierten Lösungen ist beispielsweise die "Steeleye Lifekeeper Protection Suite for SAP" von Sios Technology. Solche Cluster-Lösungen können sowohl in physischen als auch in virtualisierten Umgebungen zum Schutz der als Single Point of Failure identifizierten Komponenten zum Einsatz kommen. Wie im Bild 1 ersichtlich, lässt sich SAP Netweaver in mehrere Funktionseinheiten strukturieren, für die verschiedene Werkzeuge zur Verfügung stehen, um die geforderte Verfügbarkeit abzusichern. Alle aufgeführten Funktionseinheiten benötigen Daten, die in den entsprechenden File-Systemen auf Storage-Einheiten abgelegt sind. Dabei handelt es sich um einen Mix aus strukturierten und unstrukturierten Daten, die entweder fast statisch sind oder sich mit hoher Frequenz ändern. Innerhalb einer SAP-Architektur existieren die folgenden "Single Points of Failure" (SPoF), die nicht redundant ausgelegt sind und mittels geeigneter Hochverfügbarkeits-Tools zu schützen sind und deren Daten der Anwender redundant vorhalten sollte, um die Verfügbarkeit des Gesamtsystems zu sichern: Datenbank: Diese nimmt aus Sicht der Performance und des Funktionsumfangs eine besondere Stellung ein. Jeder SAP-Work-Prozess stellt beim Start eine private Verbindung zur Datenbank her. Zum Schutz der Datenbank gehört die Verfügbarkeit der abgelegten Datenbank-Files. SAP Message Service: Er ist erforderlich, um Informationen zwischen SAP-Instanzen auszutauschen und diesen Informationsaustausch zu regeln. SAP Enqueue Service: Dieser Dienst organisiert das Sperren von Geschäftsobjekten auf der SAP-Transaktionsebene. SAP-File-Systeme: Darunter fallen erstens die für die Instanzen benötigten File-Systeme sowie das Systemverzeichnis "/sapmnt" mit den Profilen der Instanzen und der zentralen Ablage des SAP-Kernels. Zweitens zählt dazu das Transportverzeichnis, das für die gesamte Systemkette vom Entwicklungssystem bis hin zum Produktivsystem notwendig ist. Des Weiteren lassen sich auf den Message- und Enqueue-Services die folgenden SAP-Komponenten für eine Absicherung definieren: Central Instance (CI): Die CI als erste installierte Application-Server-Instanz umfasst Message- und Enqueue-Services und zusätzliche SAP-Work-Prozesse, die das Ausführen von Dialog- und Hintergrund-Workloads ermöglichen. Sie stellt einen möglichen SPoF dar, wenn sie die beschriebenen Message- und Enqueue-Services enthält. Central Services: In den neueren Versionen von SAP Netweaver sind die Message- und Enqueue- Services aus der CI separiert und arbeiten als selbstständige Services. Separate Central Services existieren sowohl für SAP-ABAP- (Advanced Business Application Programming) als auch für Java-basierende Netweaver-Application-Server. Replicated Enqueue Server: Dieser Server läuft auf einem anderen Host-System und hält ein Replikat der Sperrtabelle in einem Shared-Memory-Segment vor. Nach Ausfall des eigenständigen Enqueue-Servers ist es Aufgabe einer Hochverfügbarkeitslösung (Cluster-Software) diesen auf dem Server neu zu starten. Der neu gestartete Enqueue-Server verbindet sich dann mit dem Shared-Memory-Segment des Replicated-Enqueue-Servers und stellt nach dem Umzug auf den neuen Host die vorhanden Sperren wieder zur Verfügung. Danach kann die Administration den Replicated-Enqueue-Server auf einem anderen Host starten, um weiterhin Redundanz zu gewährleisten. Die Isolation der Message- und Enqueue-Services aus der Central Instance in Netweaver Release 7.3 vereinfacht den Aufbau einer High-Availability-(HA-)Lösung für diesen Teil der SAP-Architektur. Zusätzlich ist erreicht, dass die nun um diese Funktionen bereinigte Central Instance schneller startet und sich damit die Zeit der Betriebsunterbrechung verringert. SAP immer verfügbar Mit Hochverfügbarkeits-Clustern wie Steeleye Lifekeeper lassen sich nun in Verbindung mit Netweaver 7.3 unternehmenskritische Applikationen und Daten in HA-Konzepte integrieren. Derartige Cluster-Lösungen sind sowohl für verschiedene Linux-Distributionen als auch für Microsoft Windows verfügbar. Der Hochverfügbarkeits-Cluster kann die geschäftskritischen Applikationen einzeln auf den jeweiligen Servern überwachen und schützen. Fällt eine geschützte Applikation aus, wird nur diese mit allen benötigten Komponenten (den Ressourcen) neu gestartet oder auf den Backup-Knoten verschoben. Andere, nicht ursächlich mit dieser Anwendung zusammenhängende Applikationen bleiben von dem Failover unberührt. Das Wissen um den Aufbau und die möglichen Fehlerszenarien für die Applikation steckt in "Application Recoverv Kits", die je nach Anbieter für verschiedenste geschäftskritische Anwendungen verfügbar sind. Auf den Knoten eines Clusters lassen sich auch geschützte und ungeschützte Applikationen gleichzeitig betreiben. Natürlich stehen nach Ausfall eines Knotens ungeschützte Applikationen nicht mehr zur Verfügung. Eine Hochverfügbarkeits-Cluster-Lösung sollte skalierbare Möglichkeiten bieten, um die aktuellen Daten den Cluster-Knoten zur Verfügung zu stellen und die Datenkonsistenz zu sichern. Die Datenreplikation kann lokal auf einem gemeinsamen Datenspeicher oder mittels geeigneter WAN-Verbindungen über Standorte hinweg erfolgen. Neben x86- und x64-basierenden Server-Systemen, SCSI- oder FC-basierenden Storage-Systemen, gängigen SAN- und NAS-Speichern können die HA-Cluster selbst üblicherweise auch aus heterogener Hardware bestehen. Die Konfiguration der Server bestimmen im Wesentlichen die Anforderungen der jeweiligen Applikationen. Dabei ist sowohl die Konstellation im Normalbetrieb als auch in allen Failover-Szenarien zu beachten.
Lesen Sie mehr zum Thema
