Anlegen eines Datenbankbenutzers in der Produktionsdatenbank SAP HANA

Gehen Sie wie folgt vor, um einen Datenbankbenutzer in der Produktionsdatenbank SAP HANA anzulegen.

1. Legen Sie einen Datenbankbenutzer im Verzeichnis SystemDB des Produktionssystems SAP HANA an, oder geben Sie die Anmeldedaten eines bestehenden Benutzers an. Das Hook-Skript verwendet diesen Datenbankbenutzer, um sich mit der Produktionsdatenbank zu verbinden und die Konfigurationsparameter zu ändern.

   Melden Sie sich an die SystemDB der primären Instanz an, indem Sie das interaktive Datenbankterminal hdbsql von SAP HANA oder das SAP HANA Cockpit verwenden, und legen Sie einen neuen Benutzer an.

   Verbinden Sie sich zum Beispiel mit der Datenbank, indem Sie hdbsql in einer Terminalsitzung verwenden.

   sudo -i -u ${sid}adm -- hdbsql -i ${INSTNO} -d SYSTEMDB -u SYSTEM
   

   Einen Benutzer erstellen.

   CREATE USER HA_HOOK PASSWORD <Password> no force_first_password_change;
   

   Gewähren Sie dem Benutzer die erforderlichen Berechtigungen.

   Erteilen Sie das Privileg INIFILE ADMIN, um Änderungen der Profilparameter zu ermöglichen.

   GRANT INIFILE ADMIN TO HA_HOOK;
   

   Überprüfen Sie den Benutzer HA_HOOK.

    sudo -i -u ${sid}adm -- hdbsql -d SYSTEMDB -u SYSTEM select \* from users where user_name = \'HA_HOOK\';
   

2. Fügen Sie die Benutzeranmeldedaten dem sicheren Benutzerspeicher hdbuserstore hinzu.

   Führen Sie auf beiden Knoten den folgenden Befehl aus. Verwenden Sie das Passwort, das Sie im vorherigen Schritt festgelegt haben.

   sudo -i -u ${sid}adm -- hdbuserstore SET HA_HOOK_KEY localhost:3${INSTNO}13 HA_HOOK <Password>
   

   Überprüfen Sie die Aktualisierung des hdbuserstore.

   sudo -i -u ${sid}adm -- hdbuserstore list
   

   Testen Sie auf der primären Instanz die Verbindung mit dem gespeicherten Benutzerschlüssel.

   sudo -i -u ${sid}adm  -- hdbsql -U HA_HOOK_KEY select \* from m_inifiles;
   

Erstellen des Hook-Skripts

Python beispieldateien für die Erstellung von Hook-Skripten werden als Teil der SAP HANA Installation mitgeliefert. Die Beispiele befinden sich im Verzeichnis $DIR_INSTANCE/exe/python_support/hdb_ha_dr.

Das Zielverzeichnis /hana/shared/myHooks wurde bereits für den Hook SAPHanaSR.py angelegt. Erstellen Sie einen HA/DR-Provider-Haken in /hana/shared/myHooks. Das folgende Hook-Skript basiert auf dem Beispiel von HADRdummy.py.

Bearbeiten Sie auf NODE2 die Datei /hana/shared/myHooks/SAPHanaCostOptSR.py und fügen Sie den folgenden Inhalt hinzu.

"""
Sample for a HA/DR hook provider.

When using your own code in here, please copy this file to location on /hana/shared outside the HANA installation.
This file will be overwritten with each hdbupd call! To configure your own changed version of this file, please add
to your global.ini lines similar to this:

    [ha_dr_provider_<className>]
    provider = <className>
    path = /hana/shared/haHook
    execution_order = 1


For all hooks, 0 must be returned in case of success.
"""

from __future__ import absolute_import
from hdb_ha_dr.client import HADRBase, Helper
from hdbcli import dbapi
import os, time

class SAPHanaCostOptSR(HADRBase):

    def __init__(self, *args, **kwargs):
        # delegate construction to base class
        super(SAPHanaCostOptSR, self).__init__(*args, **kwargs)

    def about(self):
        return {"provider_company" :        "SAP",
                "provider_name" :           "SAPHanaCostOptSR", # provider name = class name
                "provider_description" :    "Handle reconfiguration event for cost-optimized system replication",
                "provider_version" :        "1.0"}

    def postTakeover(self, rc, **kwargs):
        """Post takeover hook."""

        # prepared SQL statements to remove memory allocation limit and pre-load of column tables
        stmnt1 = "ALTER SYSTEM ALTER CONFIGURATION ('global.ini','SYSTEM') UNSET ('memorymanager','global_allocation_limit') WITH RECONFIGURE"
        stmnt2 = "ALTER SYSTEM ALTER CONFIGURATION ('global.ini','SYSTEM') UNSET ('system_replication','preload_column_tables') WITH RECONFIGURE"

        myPort = int('3' + os.environ.get('DIR_INSTANCE')[-2:] + '15')
        myKey = self.config.get("userkey") if self.config.hasKey("userkey") else "HA_HOOK_KEY"

        self.tracer.info("%s.postTakeover method called with rc=%s" % (self.__class__.__name__, rc))
        self.tracer.info("%s.postTakeover method: userkey: %s, port: %s" % (self.__class__.__name__, myKey, myPort))

        if rc in (0, 1):
            # rc == 0: normal takeover succeeded
            # rc == 1: waiting for force takeover
            conn = dbapi.connect(userkey=myKey, address='localhost', port=myPort)
            self.tracer.info("%s: Connect using userkey %s - %s" % (self.__class__.__name__, myKey, conn.isconnected()))
            cursor = conn.cursor()
            rc1 = cursor.execute(stmnt1)
            self.tracer.info("%s: (%s) - %s" % (self.__class__.__name__, stmnt1, rc1))
            rc2 = cursor.execute(stmnt2)
            self.tracer.info("%s: (%s) - %s" % (self.__class__.__name__, stmnt2, rc2))
            return 0
        elif rc == 2:
            # rc == 2: error, something went wrong
            return 0

Aktivieren des kostenoptimierten Hakens

Gehen Sie wie folgt vor, um den kostenoptimierten Haken zu aktivieren.

1. Halten Sie den Cluster an.

   Führen Sie auf einem beliebigen Clusterknoten den folgenden Befehl aus.

   pcs cluster stop --all
   

2. Legen Sie die Dateibesitzrechte für das Hook-Skript fest.

   Führen Sie unter NODE2 den folgenden Befehl aus.

   chown -R ${sid}adm:sapsys /hana/shared/myHooks
   

3. Aktualisieren Sie die Konfigurationsdatei global.ini auf NODE2, um das Hook-Skript zu aktivieren.

   Führen Sie auf NODE2 den folgenden Befehl aus, um der Datei global.ini die erforderlichen Parameter hinzuzufügen.

   sudo -i -u ${sid}adm -- <<EOT
       python \$DIR_INSTANCE/exe/python_support/setParameter.py \
         -set SYSTEM/global.ini/ha_dr_provider_SAPHanaCostOptSR/provider=SAPHanaCostOptSR \
         -set SYSTEM/global.ini/ha_dr_provider_SAPHanaCostOptSR/path=/hana/shared/myHooks \
         -set SYSTEM/global.ini/ha_dr_provider_SAPHanaCostOptSR/userkey=HA_HOOK_KEY \
         -set SYSTEM/global.ini/ha_dr_provider_SAPHanaCostOptSR/execution_order=2 \
         -set SYSTEM/global.ini/trace/ha_dr_saphanacostoptsr=info
   EOT
   

4. Überprüfen Sie den Inhalt der Datei global.ini.

   cat /hana/shared/${SID}/global/hdb/custom/config/global.ini
   

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

   • Starten Sie die HANA-Instanz auf NODE2 neu und überprüfen Sie, ob das Hook-Skript wie erwartet funktioniert.
   • Lösen Sie den Haken mit einer SAP HANA Übernahmeoperation aus.
   • Prüfen Sie, ob der Hook etwas in den Trace-Dateien protokolliert hat.

   sudo -i -u ${sid}adm -- \
       sh -c 'grep SAPHanaCostOptSR $DIR_INSTANCE/$VTHOSTNAME/trace/nameserver_*.trc'
   

   Nachdem Sie überprüft haben, dass der Hook funktioniert, können Sie den HA-Cluster neu starten.

6. Starten Sie den HA-Cluster.

   Führen Sie auf einem beliebigen Clusterknoten den folgenden Befehl aus.

   pcs cluster start --all
   

   Überprüfen Sie den Status des Clusters.

   pcs status --full
   

Test1- Beschreibung

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

Test1- Voraussetzungen

• Ein funktionsfähiger RHEL HA Add-On-Cluster mit zwei Knoten für die HANA-Systemreplikation.
• Beide Clusterknoten sind aktiv.
• Der Cluster wird auf NODE1 und NODE2 gestartet.
• Cluster Resource SAPHana_${SID}_${INSTNO} wird mit AUTOMATED_REGISTER=false 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.
• Die sekundäre Datenbank SAP HANA auf NODE2 wird mit reduzierter Speicherkonfiguration ausgeführt.
  • Die global_allocation_limit wird reduziert.
  • Das Vorladen von Spaltentabellen ist deaktiviert (preload_column_tables = false).
• Ein nicht produktives System SAP HANA ${SID_NP} läuft auf NODE2.

Test1- Testverfahren

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

Test1- Erwartetes Verhalten

• 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 fördert die sekundäre HANA-Datenbank auf NODE2, um sie als neue primäre Datenbank zu übernehmen.
  • Der Cluster stoppt die nicht produktive Datenbank ${SID_NP} auf NODE2.
  • Bei der Aktivierung werden die Parameter global_allocation_limit und preload_column_tables auf die Standardwerte zurückgesetzt.
• 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.

Führen Sie auf NODE2 die folgenden Befehle aus, um zu überprüfen, ob global_allocation_limit und preload_column_tables nicht gesetzt sind.

sudo -i -u ${sid}adm -- hdbcons "mm globallimit" | grep limit

grep -E "global_allocation_limit|preload_column_tables" \
     /hana/shared/${SID}/global/hdb/custom/config/global.ini

Test1- Einziehungsverfahren

Da die Cluster-Ressource SAPHana_${SID}_${INSTNO} mit AUTOMATED_REGISTER=false konfiguriert ist, startet der Cluster die ausgefallene HANA-Datenbank nicht neu und registriert sie nicht bei der neuen Primärdatenbank. Der Status auf der neuen Primärseite ( NODE2 ) zeigt die Sekundärseite im Status 'CONNECTION TIMEOUT'.

Führen Sie auf NODE1 die folgenden Befehle aus, um den vorherigen Primärserver als neuen Sekundärserver zu registrieren.

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

Überprüfen Sie den Status der Systemreplikation.

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

Führen Sie auf NODE1 den folgenden Befehl aus, um den Clusterknoten zu starten.

pcs cluster start

Die neue sekundäre Instanz startet neu und wird im Status synchronisiert angezeigt (SOK).

pcs status --full

Konfigurieren Sie die Cluster-Ressource SAPHana_${SID}_${INSTNO} mit AUTOMATED_REGISTER=true.

Führen Sie unter NODE1 den folgenden Befehl aus.

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

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

Test2- Beschreibung

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

Test2- Voraussetzungen

• Ein funktionsfähiger RHEL HA Add-On-Cluster mit zwei Knoten für die HANA-Systemreplikation.
• Beide Clusterknoten 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 NODE2.
  • Die sekundäre Datenbank SAP HANA läuft auf NODE1.
  • Die HANA-Systemreplikation ist aktiviert und synchronisiert.
• Das nicht-produktive System SAP HANA ${SID_NP} wird auf NODE2 gestoppt.

Test2- Vorbereitung auf den Test

Heben Sie die Verwaltung der Cluster-Ressource für das nicht produktive System SAP HANA auf, um zu verhindern, dass es startet, wenn die Speicherressourcen des sekundären Systems nicht beschränkt sind.

Führen Sie unter NODE1 den folgenden Befehl aus.

pcs resource unmanage group_${sid_np}_non_prod

Test2- Testverfahren

Führen Sie auf NODE1 den folgenden Befehl aus, um die Primärdatei SAP HANA zurück nach NODE1 zu verschieben.

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

Test2- Erwartetes Verhalten

• Der Cluster erstellt eine Ortsbeschränkung, um die Ressource zu verschieben.
• Der Cluster löst einen Takeover auf die sekundäre HANA-Datenbank auf NODE1 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.
• Die Ressource des nicht produktiven Systems SAP HANA ${SID_NP} befindet sich im unverwalteten Zustand und wird nicht automatisch gestartet.

Test2- Einziehungsverfahren

Um das komplette HA-Szenario wiederherzustellen, müssen mehrere Schritte durchgeführt werden.

1. Warten Sie, bis die primäre HANA-Instanz aktiv ist. Verringern Sie dann den Speicherbedarf des sekundären Systems.

   Führen Sie unter NODE2 die folgenden Befehle aus, um den Speicher zu reduzieren.

   export GLOBAL_ALLOCATION_LIMIT=<size_in_mb_for_hana_secondary>
   

   sudo -i -u ${sid}adm -- <<EOT
       python \$DIR_INSTANCE/exe/python_support/setParameter.py \
         -set SYSTEM/global.ini/system_replication/preload_column_tables=false \
         -set SYSTEM/global.ini/memorymanager/global_allocation_limit=$GLOBAL_ALLOCATION_LIMIT
   EOT
   

2. Entfernen Sie die Ortsbeschränkung, die den Start der sekundären Instanz auslöst.

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

   Überprüfen Sie, ob die Einschränkung aufgehoben ist.

   pcs constraint
   

   Überprüfen Sie den Status des Clusters.

   pcs status --full
   

3. Führen Sie auf NODE2 die folgenden Befehle aus, um zu überprüfen, ob global_allocation_limit und preload_column_tables eingestellt sind.

   sudo -i -u ${sid}adm -- hdbcons "mm globallimit" | grep limit
   

   grep -E "global_allocation_limit|preload_column_tables" \
        /hana/shared/${SID}/global/hdb/custom/config/global.ini
   

4. Reaktivieren Sie die Ressource für das nicht produktive System SAP HANA.

   Führen Sie unter NODE2 den folgenden Befehl aus.

   pcs resource manage group_${sid_np}_non_prod
   

   Die Ressource des nicht produktiven Systems SAP HANA ${SID_NP} wird verwaltet und das nicht produktive System startet auf NODE2.

   pcs status --full
   

Test3- Beschreibung

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

Test3- Voraussetzungen

• Ein funktionsfähiger RHEL HA Add-On-Cluster mit zwei Knoten für die HANA-Systemreplikation.
• Beide Clusterknoten 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.
• Die sekundäre Datenbank SAP HANA auf NODE2 wird mit reduzierter Speicherkonfiguration ausgeführt.
  • Die global_allocation_limit wird reduziert.
  • Das Vorladen von Spaltentabellen ist deaktiviert (preload_column_tables = false).
• Ein nicht produktives System SAP HANA ${SID_NP} läuft auf NODE2.

Test3- Testverfahren

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

Führen Sie unter NODE1 den folgenden Befehl aus.

sync; echo c > /proc/sysrq-trigger

Test3- Erwartetes Verhalten

• NODE1 schaltet sich ab.
• Der Cluster erkennt den ausgefallenen Knoten und setzt seinen Status auf OFFLINE.
• Der Cluster fördert die sekundäre HANA-Datenbank auf NODE2, um sie als neue primäre Datenbank zu übernehmen.
  • Der Cluster stoppt die nicht produktive Datenbank ${SID_NP} auf NODE2.
  • Bei der Aktivierung werden die Parameter global_allocation_limit und preload_column_tables von SAP HANA ${SID} zurückgesetzt.
• Der Cluster erwirbt die virtuelle IP-Adresse auf NODE2 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.

Test3- Einziehungsverfahren

Melden Sie sich an der Konsole IBM Cloud® an und starten Sie NODE1. Warten Sie, bis NODE1 wieder verfügbar ist, und starten Sie dann das Cluster-Framework neu.

Führen Sie unter NODE1 den folgenden Befehl aus.

pcs cluster start

pcs status --full

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

Wiederholen Sie dann die Schritte unter Test2- Testen Sie die manuelle Verschiebung der SAPHana-Ressource auf einen anderen Knoten um zur Ausgangssituation zurückzukehren.

Test4- Beschreibung

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

Test4- Voraussetzungen

• Ein funktionsfähiger RHEL HA Add-On-Cluster mit zwei Knoten für die HANA-Systemreplikation.
• Beide Knotenpunkte 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 System Replication ist aktiviert und synchronisiert.

Test4- Testverfahren

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

Führen Sie unter NODE2 den folgenden Befehl aus.

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

Test4- Erwartetes Verhalten

• 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.

Test4- Einziehungsverfahren

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

Führen Sie unter NODE2 den folgenden Befehl aus.

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

pcs status --full