Konfigurieren von SAP HANA Scale-up-Systemreplikation in einem SUSE Linux Enterprise High Availability Extension-Cluster

Setzen zusätzlicher Umgebungsvariablen für die Implementierung einer einzelnen Zone

Lesen Sie die Informationen unter Reservieren von virtuellen IP-Adressen und reservieren Sie eine virtuelle IP-Adresse für den SAP HANA System Replication-Cluster. Setzen Sie die Umgebungsvariable VIP auf die reservierte IP-Adresse.

Aktivieren des srConnectionChanged( ) Hooks auf allen SAP HANA Instanzen

1. Halten Sie den Cluster an.

   Führen Sie unter NODE1 den folgenden Befehl aus.

   crm cluster stop --all
   

   Führen Sie dann die Schritte aus, die unter SAP HANA HA/DR-Provider einrichten beschrieben sind.

2. Überprüfen Sie, ob der Haken funktioniert.

   • Starten Sie beide HANA-Instanzen neu und überprüfen Sie, ob das Hook-Skript wie erwartet funktioniert.
   • Führen Sie eine Aktion durch, um den Hook auszulösen, z. B. das Anhalten einer HANA-Instanz.
   • Prüfen Sie, ob der Hook etwas in den Trace-Dateien protokolliert hat.

   Führen Sie auf beiden Knoten die folgenden Befehle aus.

   Stoppen Sie die HANA-Instanz.

   sudo -i -u ${sid}adm -- HDB stop
   

   Starten Sie die HANA-Instanz.

   sudo -i -u ${sid}adm -- HDB start
   

   Prüfen Sie, ob der Hook Meldungen in den Trace-Dateien protokolliert hat.

   sudo -i -u ${sid}adm -- sh -c 'grep "ha_dr_SAPHanaSR.*crm_attribute" $DIR_INSTANCE/$VTHOSTNAME/trace/nameserver_* | cut -d" " -f2,3,5,17'
   

   Nachdem Sie überprüft haben, dass die Hooks funktionieren, können Sie den HA-Cluster neu starten.

3. Starten Sie das Cluster.

   Führen Sie unter NODE1 die folgenden Befehle aus.

   Starten Sie das Cluster.

   crm cluster start --all
   

   Überprüfen Sie den Status des Clusters.

   crm status --full
   

Test 1 - Beschreibung

Simulieren Sie einen Absturz der primären HANA-Datenbankinstanz, die auf NODE1 ausgeführt wird.

Test 1 - Voraussetzungen

• Ein funktionsfähiger SLES HA Extension-Cluster mit zwei Knoten für die HANA-Systemreplikation.
• Beide Clusterknoten sind aktiv.
• Cluster, der auf NODE1 und NODE2 gestartet wird.
• Cluster Resource SAPHana_${SID}_${INSTNO}, die mit AUTOMATED_REGISTER=false konfiguriert ist.
• Prüfen Sie den Status der SAP HANA Systemreplikation:
  • Die primäre Datenbank SAP HANA läuft auf NODE1
  • Die sekundäre Datenbank SAP HANA läuft auf NODE2
  • HANA Systemreplikation ist aktiviert und synchronisiert

Eine Variante von Test 1 ist in den Testfällen für die Halbautomatik beschrieben.

Verfahren für Test 1

Verwenden Sie den folgenden Befehl, um Test 1 auszuführen.

Absturz von SAP HANA primary durch Senden eines SIGKILL-Signals als Benutzer ${sid}adm.

Führen Sie unter NODE1 den folgenden Befehl aus.

sudo -i -u ${sid}adm -- HDB kill-9

Test 1 - Erwartetes Verhalten

Sie können das folgende Verhalten von dem Test erwarten.

• SAP HANA die primäre Instanz auf NODE1 stürzt ab.
• Der Cluster erkennt die gestoppte primäre HANA-Datenbank und markiert die Ressource als failed.
• Der Cluster stellt die sekundäre HANA-Datenbank auf NODE2 als neue primäre Datenbank zur Verfügung.
• Der Cluster gibt die virtuelle IP-Adresse auf NODE1 frei und erwirbt sie auf der neuen primären Adresse auf NODE2.
• Wenn eine Anwendung, z. B. SAP NetWeaver, mit einer Mieterdatenbank von SAP HANA verbunden wird, stellt die Anwendung automatisch eine neue Verbindung zur neuen Primärdatenbank her.

Test 1 - Einziehungsverfahren

Da die Cluster-Ressource SAPHana_${SID}_${INSTNO} mit AUTOMATED_REGISTER=false konfiguriert ist, startet der Cluster die ausgefallene HANA-Datenbank nicht neu und meldet sie nicht bei der neuen primären Datenbank an. Das bedeutet, dass der Status des neuen primären Systems ( NODE2 ) auch das sekundäre System im Status "CONNECTION TIMEOUT" anzeigt.

Verwenden Sie die folgenden Befehle, um den vorherigen Primärserver als neuen Sekundärserver neu zu registrieren.

Führen Sie unter NODE1 den folgenden Befehl aus.

sudo -i -u ${sid}adm -- <<EOT
    hdbnsutil -sr_register \
      --name=${DC1} \
      --remoteHost=${NODE2} \
      --remoteInstance=00 \
      --replicationMode=sync \
      --operationMode=logreplay \
      --online
EOT

Überprüfen Sie den Status der Systemreplikation mit dem folgenden Befehl.

sudo -i -u ${sid}adm -- <<EOT
    hdbnsutil -sr_state
    HDBSettings.sh systemReplicationStatus.py
EOT

Nach der manuellen Registrierung und der Aktualisierung der Ressourcen wird die neue sekundäre Instanz neu gestartet und zeigt den Status "synchronisiert" (SOK).

Führen Sie unter NODE1 den folgenden Befehl aus.

crm resource refresh SAPHana_${SID}_${INSTNO}

Test 2 - Beschreibung

Simulieren Sie einen Absturz des Knotens, auf dem die primäre HANA-Datenbank läuft.

Test 2 - Voraussetzungen

Beachten Sie die folgenden Voraussetzungen, bevor Sie Test 2 durchführen.

• Für die HANA-Systemreplikation benötigen Sie einen funktionsfähigen SLES HA Extension-Cluster mit zwei Knoten.
• Stellen Sie sicher, dass beide Knoten aktiv sind.
• Bestätigen Sie, dass der Cluster auf NODE1 und NODE2 gestartet ist.
• Prüfen Sie den Status der SAP HANA Systemreplikation.
  • Die primäre Datenbank SAP HANA läuft auf NODE2.
  • Die sekundäre Datenbank SAP HANA läuft auf NODE1.
  • Die HANA-Systemreplikation ist aktiviert und synchronisiert.

Test 2 - Vorbereitung

Stellen Sie sicher, dass die Cluster-Ressource SAPHana_${SID}_${INSTNO} mit AUTOMATED_REGISTER=true konfiguriert ist.

Führen Sie unter NODE1 die folgenden Befehle aus.

crm resource update SAPHana_${SID}_${INSTNO} AUTOMATED_REGISTER=true

crm resource config SAPHana_${SID}_${INSTNO}

Test 2 - Testverfahren

Stürzen Sie die Primärseite auf NODE2 ab, indem Sie eine Systemabsturzanforderung senden.

Führen Sie unter NODE2 den folgenden Befehl aus.

sync; echo c > /proc/sysrq-trigger

Test 2 - Erwartetes Verhalten

Sie können das folgende Verhalten von dem Test erwarten.

• NODE2 schaltet sich ab.
• Der Cluster erkennt den ausgefallenen Knoten und setzt seinen Status auf OFFLINE.
• Der Cluster stellt die sekundäre HANA-Datenbank auf NODE1 als neue primäre Datenbank zur Verfügung.
• Der Cluster erwirbt die virtuelle IP-Adresse auf NODE1 auf dem neuen primären Rechner.
• Wenn eine Anwendung, z. B. SAP NetWeaver, mit einer Mieterdatenbank von SAP HANA verbunden wird, stellt die Anwendung automatisch eine neue Verbindung zur neuen Primärdatenbank her.

Test 2 - Einziehungsverfahren

Verwenden Sie die folgenden Informationen, um sich von Test 2 zu erholen.

1. Melden Sie sich bei der IBM Cloud® Konsole an und starten Sie die Instanz NODE2.

2. Warten Sie, bis NODE2 wieder verfügbar ist, und starten Sie dann das Cluster-Framework neu.

   • Führen Sie unter NODE2 die folgenden Befehle aus.

   crm cluster start
   

   crm status --full
   

Da die Cluster-Ressource SAPHana_${SID}_${INSTNO} mit AUTOMATED_REGISTER=true konfiguriert ist, wird SAP HANA neu gestartet, wenn NODE2 dem Cluster wieder beitritt und der ehemalige Primärserver sich erneut als Sekundärserver registriert.

Test 3 - Beschreibung

Simulieren Sie einen Absturz der sekundären HANA-Datenbank.

Test 3 - Voraussetzungen

Beachten Sie die folgenden Voraussetzungen, bevor Sie Test 3 durchführen.

• Ein funktionsfähiger SLES HA Extension-Cluster mit zwei Knoten für die HANA-Systemreplikation.
• Beide Knotenpunkte sind aktiv.
• Der Cluster wird auf NODE1 und NODE2 gestartet.
• Cluster Resource SAPHana_${SID}_${INSTNO} wird mit AUTOMATED_REGISTER=true konfiguriert.
• Prüfen Sie den Status der SAP HANA Systemreplikation.
  • Die primäre Datenbank SAP HANA läuft auf NODE1.
  • Die sekundäre Datenbank SAP HANA läuft auf NODE2.
  • Die HANA-Systemreplikation ist aktiviert und synchronisiert.

Test 3 - Testverfahren

Absturz SAP HANA sekundär durch Senden eines SIGKILL-Signals als der Benutzer ${sid}adm.

Führen Sie unter NODE2 den folgenden Befehl aus.

sudo -i -u ${sid}adm -- HDB kill-9

Test 3 - Erwartetes Verhalten

Sie können das folgende Verhalten von dem Test erwarten.

• SAP HANA sekundär auf NODE2 abstürzt.
• Der Cluster erkennt die gestoppte sekundäre HANA-Datenbank und markiert die Ressource als failed.
• Der Cluster startet die sekundäre HANA-Datenbank neu.
• Der Cluster stellt fest, dass die Systemreplikation wieder synchronisiert ist.

Test 3 - Einziehungsverfahren

Verwenden Sie die folgenden Informationen, um sich von Test 2 zu erholen.

1. Warten Sie, bis die sekundäre HANA-Instanz gestartet und wieder synchronisiert ist (SOK), und bereinigen Sie dann die fehlgeschlagenen Ressourcenaktionen wie in crm status gezeigt.

2. Führen Sie unter NODE2 den folgenden Befehl aus.

   crm resource refresh SAPHana_${SID}_${INSTNO}
   

   crm status --full
   

Test 4 - Beschreibung

Verwenden Sie Cluster-Befehle, um die primäre Instanz zu Wartungszwecken auf den anderen Knoten zu verschieben.

Test 4 - Voraussetzungen

Beachten Sie die folgenden Voraussetzungen, bevor Sie Test 4 durchführen.

• Ein funktionsfähiger SLES HA Extension-Cluster mit zwei Knoten für die HANA-Systemreplikation.
• Beide Knotenpunkte sind aktiv.
• Der Cluster wird auf NODE1 und NODE2 gestartet.
• Cluster Resource SAPHana_${SID}_${INSTNO} wird mit AUTOMATED_REGISTER=true konfiguriert.
• Prüfen Sie den Status der SAP HANA Systemreplikation:
  • Die primäre Datenbank SAP HANA läuft auf NODE1
  • Die sekundäre Datenbank SAP HANA läuft auf NODE2
  • HANA Systemreplikation ist aktiviert und synchronisiert

Test 4 - Testverfahren

Verschieben Sie SAP HANA primary mit dem Befehl crm resource move auf einen anderen Knoten.

Führen Sie unter NODE1 den folgenden Befehl aus.

crm resource move SAPHana_${SID}_${INSTNO}-clone

Test 4 - Erwartetes Verhalten

Sie können das folgende Verhalten von dem Test erwarten.

• Der Cluster erstellt Ortsbeschränkungen, um die Ressource zu verschieben.
• Der Cluster löst einen Takeover auf die sekundäre HANA-Datenbank aus.
• Wenn eine Anwendung, z. B. SAP NetWeaver, mit einer Mieterdatenbank von SAP HANA verbunden wird, stellt die Anwendung automatisch eine neue Verbindung zur neuen Primärdatenbank her.

Test 4 - Einziehungsverfahren

Verwenden Sie die folgenden Informationen, um sich von Test 2 zu erholen.

Die automatisch erstellten Standortbeschränkungen müssen entfernt werden, um in Zukunft ein automatisches Failover zu ermöglichen.

Warten Sie, bis die primäre HANA-Instanz aktiv ist, und entfernen Sie die Beschränkungen.

Der Cluster registriert und startet die HANA-Datenbank als neue sekundäre Instanz.

Führen Sie unter NODE1 den folgenden Befehl aus.

crm constraint

crm resource clear SAPHana_${SID}_${INSTNO}-clone

crm constraint

crm status --full