Hinzufügen eines dritten HSR-Standorts zu einem HANA Pacemaker-Cluster

Artikel
03/01/2024

In diesem Artikel werden die Anforderungen und die Einrichtung eines dritten HANA-Replikationsstandorts zur Ergänzung eines vorhandenen Pacemaker-Clusters beschrieben. Es werden auch Besonderheiten von SUSE Linux Enterprise Server (SLES) und Red Hat Enterprise Linux (RHEL) behandelt.

Übersicht

SAP HANA unterstützt die Systemreplikation (HSR) mit mehr als zwei verbundenen Standorten. Sie können einem vorhandenen HSR-Paar, das von Pacemaker in einem hochverfügbaren Setup verwaltet wird, einen dritten Standort hinzufügen. Sie können den dritten Standort für Notfallwiederherstellungszwecke in einer zweiten Azure-Region bereitstellen.

Pacemaker und der HANA-Clusterressourcen-Agent verwalten die ersten beiden Standorte. Der Pacemaker-Cluster steuert nicht den dritten Standort.

SAP HANA unterstützt einen dritten Systemreplikationsstandort in zwei Modi:

Mehrere Ziele: Datenänderungen werden vom primären auf mehrere Zielsysteme repliziert. Der dritte Standort ist mit dem primären Replikat in einer Sterntopologie verbunden.
Mehrere Ebenen: Die Replikation erfolgt auf zwei Ebenen. Ein kaskadierendes oder verkettetes Setup von drei verschiedenen HANA-Ebenen. Der dritte Standort stellt eine Verbindung mit der sekundären Ebene bereit.

Weitere konzeptionelle Details zu HANA HSR in einer und in mehreren Regionen finden Sie unter SAP HANA-Verfügbarkeit in verschiedenen Azure-Regionen.

Voraussetzungen für SLES

Die Anforderungen an einen dritten HSR-Standort unterscheiden sich bei der Hochskalierung und der horizontalen Skalierung für HANA.

Hinweis

Die Anforderungen in diesem Artikel gelten nur für eine Pacemaker-fähige Umgebung. Ohne Pacemaker gelten die SAP HANA-Versionsanforderungen für den gewählten Replikationsmodus. Pacemaker und der HANA-Clusterressourcen-Agent verwalten nur zwei Standorte. Der dritte HSR-Standort wird nicht vom Pacemaker-Cluster gesteuert.

Sowohl Hochskalierung als auch horizontale Skalierung: SAP HANA SPS 04 oder höher ist erforderlich, um HSR mit mehreren Zielen mit einem Pacemaker-Cluster zu verwenden.
Sowohl Hochskalierung als auch horizontale Skalierung: Es ist maximal eine SAP HANA-Systemreplikation zulässig, die von außerhalb des Linux-Clusters verbunden ist.
Nur horizontale HANA-Skalierung: SLES 15 SP1 oder höher.
Nur horizontale HANA-Skalierung: Betriebssystempaket „SAPHanaSR-ScaleOut“ Version 0.180 oder höher.
Nur horizontale HANA-Skalierung: Verwendung des SAP HANA-Hochverfügbarkeitshooks SAPHanaSrMultiTarget. Der HANA-Hochverfügbarkeitshook SAPHanaSR in der Vorschauversion kann nicht mehrere Ziele für die Skalierung nutzen.

Voraussetzungen für RHEL

Die Anforderungen an einen dritten HSR-Standort unterscheiden sich bei der Hochskalierung und der horizontalen Skalierung für HANA.

Hinweis

Nur HANA-Hochskalierung: Weitere Informationen zur Mindestversion von Betriebssystem, SAP HANA und Clusterressourcen-Agents finden Sie in den Red Hat-Supportrichtlinien für RHEL-Hochverfügbarkeitscluster.
Nur horizontale HANA-Skalierung: Eine HANA-Replikation mit mehreren Zielen wird in Azure mit einem Pacemaker-Cluster nicht unterstützt.

HANA-Hochskalierung: Hinzufügen der HANA-Systemreplikation mit mehreren Zielen für Notfallwiederherstellungszwecke

Mit den SAP HANA-Hochverfügbarkeitshooks SAPHanaSR/susHanaSR für SLES und RHEL können Sie einen dritten Knoten für Notfallwiederherstellungszwecke hinzufügen. In einer Pacemaker-Umgebung ist ein HANA-Setup mit mehreren Zielen für die Notfallwiederherstellung bekannt.

Fehler am dritten Knoten lösen keine Clusteraktion aus. Der Cluster erkennt den Replikationsstatus von verbundenen Standorten, und das überwachte Attribut für den dritten Standort kann zwischen den Zuständen SOK und SFAIL wechseln. Bei Übernahmetests am dritten/Notfallwiederherstellungsstandort oder beim Ausführen von Übungsprozessen für die Notfallwiederherstellung sollten Sie zuerst die Clusterressourcen in den Wartungsmodus versetzen, um unerwünschte Clusteraktionen zu vermeiden.

Das folgende Beispiel zeigt ein Systemreplikationssystem mit mehreren Zielen. Weitere Informationen finden Sie in der SAP-Dokumentation. Diagramm, das ein Beispiel für ein HANA-Replikationssystem zur vertikalen Skalierung eines Systems mit mehreren Zielen zeigt.

Stellen Sie Azure-Ressourcen für den dritten Knoten bereit. Je nach Ihren Anforderungen können Sie für die Notfallwiederherstellung eine andere Azure-Region auswählen.

Die Schritte für den dritten Standort ähneln denen für VMs (virtuelle Computer) für HANA-Hochskalierungscluster. Der dritte Standort verwendet die Azure-Infrastruktur. Die Betriebssystem- und HANA-Versionen entsprechen denen im vorhandenen Pacemaker-Cluster mit den folgenden Ausnahmen:
- Am dritten Standort wird kein Lastenausgleich bereitgestellt. Es erfolgt keine Integration in den Lastenausgleich im vorhandenen Cluster für die VM am dritten Standort.
- Installieren Sie nicht die Betriebssystempakete „SAPHanaSR“ und „SAPHanaSR-doc“ sowie das Betriebssystempaketmuster „ha_sles“ auf der VM am dritten Standort.
- Es erfolgt keine Integration in den Cluster für VM- oder HANA-Ressourcen am dritten Standort.
- Es erfolgt kein Setup für den HANA-Hochverfügbarkeitshook am dritten Standort in global.ini.
Installieren Sie SAP HANA auf dem dritten Knoten.

Sie müssen am dritten Standort dieselbe HANA-SID und HANA-Installationsnummer verwenden.

Wenn SAP HANA am dritten Standort installiert ist und ausgeführt wird, registrieren Sie den dritten Standort beim primären Standort.

Im folgenden Beispiel wird SITE-DR als Name für den dritten Standort verwendet.

# Execute on the third site 
su - hn1adm
# Register the HANA third site to the primary. Switch --online will shutdown the HANA instance on third site.
hdbnsutil -sr_register --name=SITE-DR --remoteHost=hn1-db-0 --remoteInstance=03 --replicationMode=async --online

Überprüfen Sie, ob bei der HANA-Systemreplikation der sekundäre und der dritte Standort anzeigt werden.

# Verify HANA HSR is in sync, execute on primary
sudo su - hn1adm -c "python /usr/sap/HN1/HDB03/exe/python_support/systemReplicationStatus.py"

Überprüfen Sie das SAPHanaSR-Attribut für den dritten Standort. Für SITE-DR sollte im Abschnitt Sites der Status SOK angezeigt werden.
```
# Check SAPHanaSR attribute on any cluster managed host (first or second site)
sudo SAPHanaSR-showAttr
# Example result
# Global cib-time                 maintenance
# --------------------------------------------
# global Tue Feb 21 19:28:21 2023 false
# 
# Sites     srHook
# -----------------
# HN1-SITE1 PRIM
# HN1-SITE2 SOK
# SITE-DR   SOK
```
Der Cluster erkennt den Replikationsstatus verbundener Standorte. Die überwachten Attribute können zwischen SOK und SFAIL wechseln. Es erfolgt keine Clusteraktion, wenn bei der Replikation am Notfallwiederherstellungsstandort ein Fehler auftritt.

Horizontale HANA-Skalierung: Hinzufügen der HANA-Systemreplikation mit mehreren Zielen für Notfallwiederherstellungszwecke

Beim SAP HANA-Hochverfügbarkeitsanbieter SAPHanaSrMultiTarget können Sie einen dritten HANA-Standort für die horizontale Skalierung hinzufügen. Dieser dritte Standort wird häufig für die Notfallwiederherstellung in einer anderen Azure-Region verwendet. In einer Pacemaker-Umgebung ist ein HANA-Setup mit mehreren Zielen für die Notfallwiederherstellung bekannt. Dieser Abschnitt gilt nur für Systeme, auf denen Pacemaker unter SUSE ausgeführt wird. Ausführliche Informationen finden Sie im Abschnitt „Voraussetzungen“ in diesem Dokument.

Das folgende Beispiel zeigt ein Systemreplikationssystem mit mehreren Zielen. Weitere Informationen finden Sie in der SAP-Dokumentation. Diagramm, das ein Beispiel für ein HANA-Replikationssystem zur horizontalen Skalierung eines Systems mit mehreren Zielen zeigt.

Stellen Sie Azure-Ressourcen für den dritten Standort bereit. Je nach Ihren Anforderungen können Sie für die Notfallwiederherstellung eine andere Azure-Region auswählen.

Die Schritte für die horizontale HANA-Skalierung am dritten Standort gleichen denen für das Bereitstellen des HANA-Clusters mit horizontaler Skalierung. Am dritten Standort werden dieselben Schritte wie für den SITE1 des Clusters mit horizontaler Skalierung in Bezug auf Azure-Infrastruktur, Betriebssystems und HANA-Installation angewandt, jedoch mit den folgenden Ausnahmen:
- Am dritten Standort wird kein Lastenausgleich bereitgestellt. Es erfolgt keine Integration in den Lastenausgleich im vorhandenen Cluster für die VMs am dritten Standort.
- Installieren Sie nicht die Betriebssystempakete „SAPHanaSR-ScaleOut“ und „SAPHanaSR-ScaleOut-doc“ sowie das Betriebssystempaketmuster „ha_sles“ auf den VMs am dritten Standort.
- Es gibt keine Majority Maker-VM am dritten Standort, da keine Clusterintegration erfolgt.
- Erstellen Sie das NFS-Volume „/hana/shared“ für die exklusive Nutzung am dritten Standort.
- Es erfolgt keine Integration in den Cluster für die VM- oder HANA-Ressourcen am dritten Standort.
- Es erfolgt kein Setup für den HANA-Hochverfügbarkeitshook am dritten Standort in global.ini.
Sie müssen am dritten Standort dieselbe HANA-SID und HANA-Installationsnummer verwenden.

Wenn SAP HANA mit horizontaler Skalierung am dritten Standort installiert ist und ausgeführt wird, registrieren Sie den dritten Standort beim primären Standort.

Im folgenden Beispiel wird SITE-DR als Name für den dritten Standort verwendet.

# Execute on the third site 
su - hn1adm
# Register the HANA third site to the primary. Switch --online will shutdown the HANA instance on third site.
hdbnsutil -sr_register --name=SITE-DR --remoteHost=hana-s1-db1 --remoteInstance=03 --replicationMode=async --online

Überprüfen Sie, ob bei der HANA-Systemreplikation der sekundäre und der dritte Standort anzeigt werden.

# Verify HANA HSR is in sync, execute on primary
sudo su - hn1adm -c "python /usr/sap/HN1/HDB03/exe/python_support/systemReplicationStatus.py"

Überprüfen Sie das SAPHanaSR-Attribut für den dritten Standort. Für SITE-DR sollte im Abschnitt Sites der Status SOK angezeigt werden.

# Check SAPHanaSR attribute on any cluster managed host (first or second site)
sudo SAPHanaSR-showAttr
# Expected result
# Global cib-time                 maintenance prim  sec sync_state upd
# ---------------------------------------------------------------------
# HN1    Fri Jan 27 10:38:46 2023 false       HANA_S1 -   SOK        ok
# 
# Sites     lpt        lss mns         srHook srr
# ------------------------------------------------
# SITE-DR                              SOK
# HANA_S1   1674815869 4   hana-s1-db1 PRIM   P
# HANA_S2   30         4   hana-s2-db1 SOK    S

Der Cluster erkennt den Replikationsstatus verbundener Standorte. Das überwachte Attribut kann zwischen SOK und SFAIL wechseln. Es erfolgt keine Clusteraktion, wenn bei der Replikation am Notfallwiederherstellungsstandort ein Fehler auftritt.

Automatische Registrierung des dritten Standorts

Während eines geplanten oder ungeplanten Übernahmeereignisses zwischen den beiden Pacemaker-Clusterstandorten wird auch eine HSR zum dritten Standort unterbrochen. Pacemaker ändert die HANA-Replikation an den dritten Standort nicht.

SAP stellt seit dem HANA 2 SPS 04 den register_secondaries_on_takeover-Parameter bereit. Wenn der Parameter auf den Wert true festgelegt ist, registriert HANA nach der HSR-Übernahme zwischen Clusterstandort 1 und 2 automatisch den dritten Standort am neuen primären Standort, um das HSR-Setup mit mehreren Zielen aufrechtzuerhalten. Konfigurieren Sie den HANA-Parameter register_secondaries_on_takeover = true, der im [system_replication]-Block von global.ini konfiguriert ist, an beiden SAP HANA-Standorten im Linux-Cluster. Sowohl SITE1 als auch SITE2 benötigen den Parameter in der jeweiligen HANA-Konfigurationsdatei global.ini. Der Parameter kann auch außerhalb eines Pacemaker-Clusters verwendet werden.

Bei einer HSR mit mehreren Ebenen erfolgt keine automatische SAP HANA-Registrierung des dritten Standorts. Sie müssen den dritten Standort manuell beim aktuellen sekundären Standort registrieren, um die HSR-Replikationskette für mehrere Ebenen beizubehalten.

Diagrammfluss, der zeigt, wie eine HANA-Autoregistrierung mit einem dritten Standort während einer Übernahme funktioniert.

Freigeben über