Creación de un usuario de base de datos en la base de datos de producción SAP HANA

Siga estos pasos para crear un usuario de base de datos en la base de datos de producción SAP HANA.

1. Crear un usuario de base de datos en el SystemDB del sistema de producción SAP HANA, o proporcione las credenciales de un usuario existente. El script gancho utiliza este usuario de base de datos para conectarse a la base de datos de producción y modificar los parámetros de configuración.

   Inicie sesión en el SystemDB de la instancia primaria utilizando el terminal interactivo de base de datos SAP HANA hdbsql o SAP HANA Cockpit, y cree un nuevo usuario.

   Por ejemplo, conéctese a la base de datos utilizando hdbsql en una sesión de terminal.

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

   Crea un usuario de .

   CREATE USER HA_HOOK PASSWORD <Password> no force_first_password_change;
   

   Concede los privilegios necesarios al usuario.

   Conceder privilegio INIFILE ADMIN para permitir cambios en los parámetros del perfil.

   GRANT INIFILE ADMIN TO HA_HOOK;
   

   Verifique el usuario HA_HOOK.

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

2. Añade las credenciales de usuario al almacén seguro de usuarios hdbuserstore.

   En ambos nodos, ejecute el siguiente comando. Utilice la contraseña que estableció en el paso anterior.

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

   Comprueba la actualización del hdbuserstore.

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

   En la instancia primaria, pruebe la conexión con la clave de usuario almacenada.

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

Creación del script gancho

Python como parte de la instalación de SAP HANA se suministran archivos de ejemplo para crear scripts de gancho. Las muestras se encuentran en el directorio $DIR_INSTANCE/exe/python_support/hdb_ha_dr.

El directorio de destino /hana/shared/myHooks ya fue creado para el hook SAPHanaSR.py. Cree un gancho de proveedor HA/DR en /hana/shared/myHooks. El siguiente script hook está basado en el ejemplo de HADRdummy.py.

En NODE2, edite el archivo /hana/shared/myHooks/SAPHanaCostOptSR.py y añada el siguiente contenido.

"""
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

Activar el gancho de optimización de costes

Siga los siguientes pasos para activar el gancho de optimización de costes.

1. Detener el clúster.

   En cualquier nodo del clúster, ejecute el siguiente comando.

   pcs cluster stop --all
   

2. Establece la propiedad del archivo del script gancho.

   En NODE2, ejecute el siguiente comando.

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

3. Actualice el archivo de configuración de global.ini en NODE2 para habilitar el script hook.

   En NODE2, ejecute el siguiente comando para añadir los parámetros necesarios al archivo global.ini.

   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. Compruebe el contenido del archivo global.ini.

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

5. Compruebe que el gancho funciona.

   • Reinicie la instancia de HANA en NODE2 y compruebe que el script de gancho funciona como se espera.
   • Activa el gancho con una operación de toma de posesión en SAP HANA.
   • Comprueba si el gancho ha registrado algo en los archivos de rastreo.

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

   Tras comprobar que el gancho funciona, puede reiniciar el clúster de HA.

6. Inicie el clúster de HA.

   En cualquier nodo del clúster, ejecute el siguiente comando.

   pcs cluster start --all
   

   Compruebe el estado del clúster.

   pcs status --full
   

Test1- Descripción

Simule una caída de la instancia primaria de la base de datos HANA que se ejecuta en NODE1.

Test1- Requisitos previos

• Un clúster funcional RHEL HA Add-On de dos nodos para la replicación de sistemas HANA.
• Ambos nodos del clúster están activos.
• El clúster se inicia en NODE1 y NODE2.
• Cluster Resource SAPHana_${SID}_${INSTNO} está configurado con AUTOMATED_REGISTER=false.
• Compruebe el estado de la replicación del sistema SAP HANA:
  • La base de datos primaria SAP HANA se ejecuta en NODE1.
  • La base de datos secundaria SAP HANA se ejecuta en NODE2.
  • La replicación del sistema HANA está activada y sincronizada.
• La base de datos secundaria SAP HANA en NODE2 funciona con una configuración de memoria reducida.
  • Se reduce la global_allocation_limit.
  • La precarga de las tablas de columnas está desactivada (preload_column_tables = false).
• Un sistema SAP HANA que no es de producción ${SID_NP} se está ejecutando en NODE2.

Test1- Procedimiento de ensayo

Crash SAP HANA primaria mediante el envío de una señal SIGKILL como usuario ${sid}adm.

En NODE1, ejecute el siguiente comando.

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

Test1- Comportamiento esperado

• SAP HANA la instancia primaria en NODE1 se bloquea.
• El clúster detecta la base de datos HANA primaria detenida y marca el recurso como failed.
• El clúster promueve la base de datos HANA secundaria en NODE2 para que asuma el papel de nueva primaria.
  • El clúster detiene la base de datos de no producción ${SID_NP} en NODE2.
  • Durante la activación, los parámetros global_allocation_limit y preload_column_tables se restablecen a los valores predeterminados.
• El clúster libera la dirección IP virtual en NODE1, y la adquiere en el nuevo primario en NODE2.
• Si una aplicación, como SAP NetWeaver, se conecta a una base de datos tenant de SAP HANA, la aplicación se reconecta automáticamente al nuevo primario.

En NODE2, ejecute los siguientes comandos para comprobar que global_allocation_limit y preload_column_tables no están configurados.

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- Procedimiento de recuperación

Como el recurso de cluster SAPHana_${SID}_${INSTNO} está configurado con AUTOMATED_REGISTER=false, el cluster no reinicia la base de datos HANA fallida, y no la registra contra el nuevo primario. El estado en el nuevo primario ( NODE2 ) muestra al secundario en estado 'CONNECTION TIMEOUT'.

En NODE1, ejecute los siguientes comandos para registrar el primario anterior como nuevo secundario.

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

Verificar el estado de replicación del sistema.

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

En NODE1, ejecute el siguiente comando para iniciar el nodo de clúster.

pcs cluster start

La nueva instancia secundaria se reinicia y aparece en estado sincronizado (SOK).

pcs status --full

Configure el recurso de clúster SAPHana_${SID}_${INSTNO} con AUTOMATED_REGISTER=true.

En NODE1, ejecute el siguiente comando.

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

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

Test2- Descripción

Utilice los comandos de clúster para mover la instancia primaria de nuevo al otro nodo.

Test2- Requisitos previos

• Un clúster funcional RHEL HA Add-On de dos nodos para la replicación de sistemas HANA.
• Ambos nodos del clúster están activos.
• El clúster se inicia en NODE1 y NODE2.
• Cluster Resource SAPHana_${SID}_${INSTNO} está configurado con AUTOMATED_REGISTER=true.
• Compruebe el estado de la replicación del sistema SAP HANA:
  • La base de datos primaria SAP HANA se ejecuta en NODE2.
  • La base de datos secundaria SAP HANA se ejecuta en NODE1.
  • La replicación del sistema HANA está activada y sincronizada.
• El sistema de no producción SAP HANA ${SID_NP} se detiene en NODE2.

Test2- Preparación de exámenes

Desgestione el recurso de cluster para el sistema SAP HANA que no es de producción para evitar que se inicie cuando los recursos de memoria del secundario no estén restringidos.

En NODE1, ejecute el siguiente comando.

pcs resource unmanage group_${sid_np}_non_prod

Test2- Procedimiento de ensayo

En NODE1, ejecute el siguiente comando para mover el SAP HANA primario de nuevo a NODE1.

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

Test2- Comportamiento esperado

• El clúster crea una restricción de ubicación para mover el recurso.
• El clúster activa una transferencia a la base de datos HANA secundaria en NODE1.
• Si una aplicación, como SAP NetWeaver, se conecta a una base de datos tenant de SAP HANA, la aplicación se reconecta automáticamente al nuevo primario.
• El recurso del sistema SAP HANA que no está en producción ${SID_NP} está en estado no gestionado y no se inicia automáticamente.

Test2- Procedimiento de recuperación

Es necesario seguir varios pasos para restablecer el escenario completo de HA.

1. Espere hasta que la instancia primaria de HANA esté activa. A continuación, reduzca la huella de memoria del secundario.

   En NODE2, ejecute los siguientes comandos para reducir la memoria.

   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. Elimina la restricción de ubicación, lo que desencadena el inicio de la instancia secundaria.

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

   Compruebe que la restricción está eliminada.

   pcs constraint
   

   Compruebe el estado del clúster.

   pcs status --full
   

3. En NODE2, ejecute los siguientes comandos para comprobar que global_allocation_limit y preload_column_tables están configurados.

   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. Reactivar el recurso para el sistema SAP HANA que no está en producción.

   En NODE2, ejecute el siguiente comando.

   pcs resource manage group_${sid_np}_non_prod
   

   Se gestiona el recurso del sistema de no producción SAP HANA ${SID_NP} y se inicia el sistema de no producción en NODE2.

   pcs status --full
   

Test3- Descripción

Simule una caída del nodo que ejecuta la base de datos HANA primaria.

Test3- Requisitos previos

• Un clúster funcional RHEL HA Add-On de dos nodos para la replicación de sistemas HANA.
• Ambos nodos del clúster están activos.
• El clúster se inicia en NODE1 y NODE2.
• Cluster Resource SAPHana_${SID}_${INSTNO} está configurado con AUTOMATED_REGISTER=true.
• Compruebe el estado de la replicación del sistema SAP HANA:
  • La base de datos primaria SAP HANA se ejecuta en NODE1.
  • La base de datos secundaria SAP HANA se ejecuta en NODE2.
  • La replicación del sistema HANA está activada y sincronizada.
• La base de datos secundaria SAP HANA en NODE2 funciona con una configuración de memoria reducida.
  • Se reduce la global_allocation_limit.
  • La precarga de las tablas de columnas está desactivada (preload_column_tables = false).
• Un sistema SAP HANA que no es de producción ${SID_NP} se está ejecutando en NODE2.

Test3- Procedimiento de ensayo

Bloquea el sistema primario en NODE1 enviando una petición de bloqueo del sistema.

En NODE1, ejecute el siguiente comando.

sync; echo c > /proc/sysrq-trigger

Test3- Comportamiento esperado

• NODE1 se apaga.
• El clúster detecta el nodo que ha fallado y establece su estado en OFFLINE.
• El clúster promueve la base de datos HANA secundaria en NODE2 para que asuma el papel de nueva primaria.
  • El clúster detiene la base de datos de no producción ${SID_NP} en NODE2.
  • Durante la activación, se restablecen los parámetros global_allocation_limit y preload_column_tables de SAP HANA ${SID}.
• El clúster adquiere la dirección IP virtual en NODE2 en el nuevo primario.
• Si una aplicación, como SAP NetWeaver, se conecta a una base de datos tenant de SAP HANA, la aplicación se reconecta automáticamente al nuevo primario.

Test3- Procedimiento de recuperación

Acceda a la consola IBM Cloud® e inicie NODE1. Espere hasta que NODE1 vuelva a estar disponible y, a continuación, reinicie el marco del clúster.

En NODE1, ejecute el siguiente comando.

pcs cluster start

pcs status --full

Como el recurso de clúster SAPHana_${SID}_${INSTNO} está configurado con AUTOMATED_REGISTER=true, SAP HANA se reinicia cuando NODE1 se une al clúster y el antiguo primario se registra como secundario.

A continuación, vuelva a ejecutar los pasos en Test2- Prueba del movimiento manual del recurso SAPHana a otro nodo para volver a la situación inicial.

Test4- Descripción

Simular una caída de la base de datos secundaria HANA.

Test4- Requisitos previos

• Un clúster funcional RHEL HA Add-On de dos nodos para la replicación de sistemas HANA.
• Ambos nodos activos.
• El clúster se inicia en NODE1 y NODE2.
• Cluster Resource SAPHana_${SID}_${INSTNO} está configurado con AUTOMATED_REGISTER=true.
• Compruebe el estado de la replicación del sistema SAP HANA:
  • La base de datos primaria SAP HANA se ejecuta en NODE1.
  • La base de datos secundaria SAP HANA se ejecuta en NODE2.
  • La replicación del sistema HANA está activada y sincronizada.

Test4- Procedimiento de ensayo

Crash SAP HANA secundaria mediante el envío de una señal SIGKILL como usuario ${sid}adm.

En NODE2, ejecute el siguiente comando.

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

Test4- Comportamiento esperado

• SAP HANA secundario en NODE2 accidentes.
• El clúster detecta la base de datos HANA secundaria detenida y marca el recurso como failed.
• El clúster reinicia la base de datos HANA secundaria.
• El clúster detecta que la replicación del sistema vuelve a estar sincronizada.

Test4- Procedimiento de recuperación

Espere hasta que la instancia secundaria de HANA se inicie y sincronice de nuevo (SOK), luego limpie las acciones de recursos fallidos como se muestra en pcs status.

En NODE2, ejecute el siguiente comando.

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

pcs status --full