Betrifft: Hochverfügbarkeit in SAP HANA Automatisierte SAP-HANA-System-Replikation

Autor / Redakteur: Thomas Joos / Ulrike Ostler

Die Hochverfügbarkeit in „SAP HANA“ kann unter anderem über „HANA System Replication“ (HSR) erfolgen. Das bezieht auch die Möglichkeit einer SAP-Replikation zwischen verschiedenen Rechenzentren mit ein. Der Beitrag von Thomas Joos zeigt die Möglichkeiten.

Firmen zum Thema

Replikation hilft beim Desaster Recovery aber auch in Sachen Hochverfügbarkeit, auch über verschiedene Rechenzentren hinweg.
Replikation hilft beim Desaster Recovery aber auch in Sachen Hochverfügbarkeit, auch über verschiedene Rechenzentren hinweg.
(Bild: Andrew Martin auf Pixabay)

Die Replikation von SAP HANA kann im gleichen Rechenzentrum, aber auch in andere Rechenzentren erfolgen. Ohnehin setzt SAP hier auf Redundanz. Die Hardware, Software und idealerweise auch das Rechenzentrum sollten redundant ausgelegt sein, um den Ausfall einzelner Komponenten zu verhindern.

Das Primärsystem sendet die Lizenzinformationen an das zweite System. Es sind also keine weiteren Lizenzen für das zweite (active/passive) System notwendig. Eine Replikation der Datenbank auf dem gleichen Host-System ist unmöglich.

Das zweite System in einer SAP-Replikationsumgebung dient als Standby-Knoten. Dieser zweiten Knoten ist eine exakte Kopie des primären Systems.

Replikation in SAP

Für die Replikation sind zwei Datenbanken mit einer möglichst identischen Replikation notwendig. Die integrierte Replikation in SAP HANA kann allerdings kein automatisches Failover durchführen. Dazu sind zusätzliche Technologien notwendig. Normalerweise wird hier auf Funktionen des Betriebssystems zurückgegriffen, zum Beispiel auf das Linux-HA-Add-On in „Red Hat Enterprise Linux“ (RHEL).

Bei der Hochverfügbarkeit in SAP-Umgebungen geht es auch nicht nur darum, Ausfälle zu verhindern. Auch Wartungsarbeiten, Aktualisierungen, Sicherheits-Updates und Anpassungen am System können zu Ausfällen führen, auch wenn diese geplant sind. Bei einer hochverfügbaren Umgebung arbeiten die Anwender am zweiten System weiter, während Administratoren oder Entwickler das erste System warten.

HANA bietet auch eine Zero-Downtime-Wartung zusammen mit der HANA-Systemreplikation für Upgrades. Das sekundäre System kann eine Zeitlang mit einer höheren Version als das primäre laufen. Wenn das erste System nach den Updates gut funktioniert, kann auch das zweite System aktualisiert werden. Durch HA ist aber sichergestellt, dass auch Probleme auf dem ersten System abgefangen werden können, die ein Update verursachen kann.

High Availability (HA) unterscheidet sich vom Disaster Recovery (DR)

Grundsätzlich ist in puncto Hochverfügbarkeit mit SAP zwischen High Availability (HA) und Disaster Recovery (DR) zu unterscheiden. Durch den Einsatz von HA wird ein Single-Point of Failure im Rechenzentrum eliminiert. Die Umgebung bleibt auch dann verfügbar, wenn ein System ausfällt.

Bei Disaster Recovery (DR) handelt es sich um den Prozess, der notwendig ist, um einen kompletten Ausfall einer SAP-Umgebung zu beheben. Liegt ein Fehler im Rechenzentrum oder am Standort vor, kann mit DR die Wiederherstellung durchgeführt werden. In den meisten Fällen kommt dazu HA zum Einsatz.

Wenn der Betrieb einer zweiten Umgebung in einem unabhängigen Rechenzentrum über HA zum Einsatz kommt, dann ist das DR wesentlich einfacher. Bei Ausfall eines Rechenzentrums, arbeitet die Umgebung im zweiten Rechenzentrum weiter. Ist das erste Rechenzentrum wieder einsatzbereit, arbeiten die Anwender wieder mit dieser Umgebung. Mit HA ist es möglich die Ausfallzeit und den Datenverlust zu minimieren oder sogar zu eliminieren.

Um die Hochverfügbarkeit zu verbessern, braucht es Unterstützung durch die High-Availability-Funktionen der Betriebssysteme, auf denen SAP HANA läuft.
Um die Hochverfügbarkeit zu verbessern, braucht es Unterstützung durch die High-Availability-Funktionen der Betriebssysteme, auf denen SAP HANA läuft.
(Bild: Andrew Martin auf Pixabay)

DR hat die Aufgabe auch große Entfernungen zu überbrücken, wenn es darum geht die Verfügbarkeit von Anwendungen wie SAP zu verbessern. SAP HANA und die angedockten Produkte ermöglichen HA und DR mit Bordmitteln. Die Funktionen, die hier noch fehlen liefert das Betriebssystem nach.

Eine Datensicherung kann keine HA und auch kein DR ersetzen. Es fehlt beim Einsatz der Datensicherung die Recovery Time Objective (RTO) und Recovery Point Objective (RPO).

Die Wiederherstellung eines Systems kann Tage dauern. Dazu kommt der Datenverlust, da bei der Wiederherstellung nur die Daten der letzten Datensicherung wiederhergestellt werden können. Alle Daten von der Sicherung bis zum Ausfall sind ohne HA und DR verloren.

HANA-Systemreplikation spielt für die Hochverfügbarkeit eine wichtige Rolle und sollte in jeder SAP-Umgebung zum Einsatz kommen.

Die Verwendung von SAP HANA HSR

Für die Hochverfügbarkeit wird ein Zwei-Knoten-Cluster unterstützt. Beispielsweise kommt bei RHEL das Tool „Pacemaker“ zum Einsatz. DataCenter-Insider hat im einem Beitrag (siehe: „ Der Aufbau eines High Availability-Cluster mit Linux “) die Möglichkeiten gezeigt, wie Linux hochverfügbar werden kann.

Der zweite Standort dient nicht der aktiven Nutzung, sondern lediglich zum Erstellen einer Hochverfügbarkeit (active/passive). Seit HANA 2.0 ist es auch möglich, dass der zweite Standort für Abfragen nutzbar ist, aber nicht für Schreibzugriffe (active/active). SAP HANA HSR bietet verschiedene Modi für die Replikation:

  • Synchronous in-memory (SYNCMEM)
  • Synchronous (SYNC)
  • Asynchronous (ASYNC)

Der Modus kann jederzeit angepasst werden. Eine erneute Synchronisierung ist in diesem Fall unnötig.

Für die Einrichtung von HSR müssen außerdem alle verwendeten Host-Rollen, Failover- und Worker-Gruppen einen identischen Namen haben. Auch die Versionen der eingesetzten Software müssen identisch sein. Beim Failback muss das sekundäre System dieselbe SAP-System-ID (<SID>) und Instanznummer haben wie das primäre System.

Beim Ändern von Einstellungen auf dem primären System ist es zudemnotwendig, die Änderungen auch auf dem zweiten System vorzunehmen. Dazu weist der INI-Parameter-Checker auf Änderungen hin. Auf Anforderung lassen sich die Änderungen auch automatisiert vom primären auf den sekundären Host replizieren.

Einrichtungsschritte für die Replikation

Vor der Einrichtung der Replikation sollte auf dem primären System zunächst eine vollständige Sicherung für alle Container durchgeführt werden. Danach kann die Replikation auf dem Primärsystem aktiviert werden.

Damit das sekundäre System zur Replikation zur Verfügung steht, muss der PKI SSFS .key und die .dat-Datei auf das zweite System kopiert werden. Auch die Secure-Store-Dateien sollten vom primären auf das sekundäre System kopiert werden.

Anschließend lässt sich das sekundäre System beim primären System registrieren und starten. Bei einem Failover übernimmt das sekundäre System den Betrieb.

Damit später das primäre System wieder eingebunden werden kann, muss es beim sekundären System registriert werden. Bei einem Failover wird als das sekundäre System zunächst primär und das wiederhergestellte primäre System wird zum sekundären System, die Rollen sind vertauscht.

Ist das ursprüngliche, primäre System wieder einsatzbereit, lässt sich der Vorgang auch wieder umdrehen, so dass die Systeme wieder ihre ursprüngliche Rolle einnehmen. Soll die Replikation beendet werden, wird die Registrierung des sekundären Systems aufgehoben und auf dem primären wird die Replikation beendet.

* Thomas Joos ist Fachautor und Berater. Aus DataCenter-Insider führt er einen eigenen Blog mit Tiips und Tricks für Administrator*innen: „Toms Admin-Blog

(ID:47478460)

Über den Autor

 Thomas Joos

Thomas Joos

Freiberuflicher Autor und Journalist