IBM Cloud Docs
Configurazione della replica del sistema scale-up SAP HANA in un cluster Red Hat Enterprise Linux High Availability Add-On

Configurazione della replica del sistema scale-up SAP HANA in un cluster Red Hat Enterprise Linux High Availability Add-On

Le seguenti informazioni descrivono la configurazione di un cluster Red Hat Enterprise Linux (RHEL) High Availability Add-On per la gestione di SAP HANA Scale-Up System Replication. Il cluster utilizza istanze di server virtuali in IBM® Power® Virtual Server come nodi del cluster.

Le istruzioni descrivono come automatizzare SAP HANA Scale-Up System Replication per un singolo database in uno scenario ottimizzato per le prestazioni su un cluster RHEL HA Add-on.

Queste informazioni sono destinate agli architetti e agli specialisti che stanno pianificando un'implementazione ad alta disponibilità di SAP HANA su Power Virtual Server.

Prima di iniziare

Esaminare i requisiti generali, la documentazione del prodotto, gli articoli di supporto e le note SAP elencate in Implementing high availability for SAP applications on IBM Power Virtual Server References.

Prerequisiti

  • Un cluster Red Hat High Availability è distribuito su due istanze di server virtuale in Power Virtual Server.
  • Le istanze del server virtuale devono soddisfare i requisiti hardware e di risorse per i sistemi SAP HANA. Seguire le linee guida riportate nel documento Pianificazione dell'installazione.
  • I nomi di host delle istanze del server virtuale devono soddisfare il requisito SAP HANA.
  • SAP HANA è installato su entrambe le istanze del server virtuale e SAP HANA System Replication è configurato. L'installazione di SAP HANA e la configurazione di HANA System Replication non sono specifiche dell'ambiente Power Virtual Server e devono essere seguite le procedure standard.
  • Per abilitare i repository necessari all'installazione di SAP HANA e gli agenti di risorse per le configurazioni HA, è necessario un abbonamento valido a RHEL per SAP Applications o RHEL per SAP Solutions.

Configurazione di SAP HANA System Replication in un cluster RHEL HA Add-On su IBM Power Virtual Server

Le istruzioni si basano sulla documentazione del prodotto Red Hat e sugli articoli elencati in Implementing high availability for SAP applications on IBM Power Virtual Server References.

Preparazione delle variabili d'ambiente

Per semplificare la configurazione, preparare le seguenti variabili d'ambiente per root su entrambi i nodi. Queste variabili d'ambiente vengono utilizzate con i comandi del sistema operativo successivi in queste informazioni.

Su entrambi i nodi, impostare le seguenti variabili d'ambiente.

# General settings
export SID=<SID>            # SAP HANA System ID (uppercase)
export sid=<sid>            # SAP HANA System ID (lowercase)
export INSTNO=<INSTNO>      # SAP HANA instance number

# Cluster node 1
export NODE1=<HOSTNAME_1>   # Virtual server instance hostname
export DC1="Site1"          # HANA System Replication site name

# Cluster node 2
export NODE2=<HOSTNAME_2>   # Virtual server instance hostname
export DC2="Site2"          # HANA System Replication site name

# Single zone
export VIP=<IP address>     # SAP HANA System Replication cluster virtual IP address

# Multizone region
export CLOUD_REGION=<CLOUD_REGION>       # Multizone region name
export APIKEY="APIKEY or path to file"   # API Key of the IBM Cloud IAM ServiceID for the resource agent
export API_TYPE="private or public"      # Use private or public API endpoints
export IBMCLOUD_CRN_1=<IBMCLOUD_CRN_1>   # Workspace 1 CRN
export IBMCLOUD_CRN_2=<IBMCLOUD_CRN_2>   # Workspace 2 CRN
export POWERVSI_1=<POWERVSI_1>           # Virtual server instance 1 id
export POWERVSI_2=<POWERVSI_2>           # Virtual server instance 2 id
export SUBNET_NAME="vip-${sid}-net"      # Name which is used to define the subnet in IBM Cloud
export CIDR="CIDR of subnet"             # CIDR of the subnet containing the service IP address
export VIP="Service IP address"          # IP address in the subnet
export JUMBO="true or false"             # Enable Jumbo frames

Impostazione di variabili d'ambiente extra per l'implementazione di una singola zona

Rivedere le informazioni contenute in Riservare gli indirizzi IP virtuali e riservare un indirizzo IP virtuale per il cluster SAP HANA System Replication. Impostare la variabile d'ambiente VIP sull'indirizzo IP riservato.

Impostazione di variabili d'ambiente extra per l'implementazione di una regione multizona

Impostare le variabili CLOUD_REGION, APIKEY, IBMCLOUD_CRN_?, POWERVSI_? come descritto nella sezione Raccolta dei parametri per la configurazione di un cluster ad alta disponibilità. Impostare la variabile API_TYPE su private per comunicare con le API IAM IBM Cloud e Power Cloud IBM tramite endpoint privati. La variabile SUBNET_NAME contiene il nome della sottorete. La variabile CIDR rappresenta la notazione Classless Inter-Domain Routing (CIDR) per la sottorete nel formato <IPv4_address>/number. La variabile VIP è l'indirizzo IP della risorsa di indirizzo IP virtuale e deve appartenere all'indirizzo CIDR della sottorete. Impostare la variabile JUMBO su true se si vuole abilitare la sottorete per una dimensione MTU grande.

Di seguito è riportato un esempio di come impostare le variabili d'ambiente aggiuntive necessarie per l'implementazione di una regione multizona.

export CLOUD_REGION="eu-de"
export IBMCLOUD_CRN_1="crn:v1:bluemix:public:power-iaas:eu-de-2:a/a1b2c3d4e5f60123456789a1b2c3d4e5:a1b2c3d4-0123-4567-89ab-a1b2c3d4e5f6::"
export IBMCLOUD_CRN_2="crn:v1:bluemix:public:power-iaas:eu-de-1:a/a1b2c3d4e5f60123456789a1b2c3d4e5:e5f6a1b2-cdef-0123-4567-a1b2c3d4e5f6::"
export POWERVSI_1="a1b2c3d4-0123-890a-f012-0123456789ab"
export POWERVSI_2="e5f6a1b2-4567-bcde-3456-cdef01234567"
export APIKEY="@/root/.apikey.json"
export API_TYPE="private"
export SUBNET_NAME="vip-mha-net"
export CIDR="10.40.11.100/30"
export VIP="10.40.11.102"
export JUMBO="true"

Installazione degli agenti di risorse SAP HANA

Eseguire il seguente comando per installare gli agenti di risorse RHEL HA Add-On per SAP HANA System Replication.

dnf install -y resource-agents-sap-hana

Avvio del sistema SAP HANA

Avviare SAP HANA e verificare che HANA System Replication sia attivo. Per ulteriori informazioni, vedere 2.4. Controllo dello stato di SAP HANA System Replication.

Su entrambi i nodi, eseguire i seguenti comandi.

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

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

Abilitazione del gancio SAP HANA srConnectionChanged( )

Le versioni recenti di SAP HANA forniscono degli agganci per consentire a SAP HANA di inviare notifiche per determinati eventi. Per ulteriori informazioni, vedere Implementazione di un provider HA/DR.

L'hook srConnectionChanged( ) migliora la capacità del cluster di rilevare un cambiamento di stato di HANA System Replication che richiede un'azione da parte del cluster. L'obiettivo è quello di prevenire la perdita e la corruzione dei dati impedendo le acquisizioni accidentali.

Attivazione del gancio srConnectionChanged( ) su tutte le istanze di SAP HANA

  1. Arrestare il cluster.

    Su NODE1, eseguite il seguente comando.

    pcs cluster stop --all

  2. Installare lo script hook fornito dal pacchetto resource-agents-sap-hana nella directory /hana/shared/myHooks per ogni istanza HANA e impostare la proprietà richiesta.

    Su entrambi i nodi, eseguire i seguenti comandi.

    mkdir -p /hana/shared/myHooks

    cp /usr/share/SAPHanaSR/srHook/SAPHanaSR.py /hana/shared/myHooks

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

  3. Aggiornare il file global.ini su ciascun nodo HANA per abilitare lo script di aggancio.

    Su entrambi i nodi, eseguire il seguente comando.

    sudo -i -u ${sid}adm -- <<EOT
    python \$DIR_INSTANCE/exe/python_support/setParameter.py \
      -set SYSTEM/global.ini/ha_dr_provider_SAPHanaSR/provider=SAPHanaSR \
      -set SYSTEM/global.ini/ha_dr_provider_SAPHanaSR/path=/hana/shared/myHooks \
      -set SYSTEM/global.ini/ha_dr_provider_SAPHanaSR/execution_order=1 \
      -set SYSTEM/global.ini/trace/ha_dr_saphanasr=info
EOT

  4. Verificare il file modificato.

    Su entrambi i nodi, eseguire il seguente comando.

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

  5. Creare le impostazioni sudo per l'utente di SAP HANA OS.

    Sono necessarie le seguenti impostazioni sudo per consentire allo script utente ${sid}adm di aggiornare gli attributi del nodo quando viene eseguito il gancio srConnectionChanged( ).

    Su entrambi i nodi, eseguire i seguenti comandi.

    Creare un file con gli alias sudo e le specifiche utente richieste.

    cat >> /etc/sudoers.d/20-saphana << EOT
Cmnd_Alias DC1_SOK = /usr/sbin/crm_attribute -n hana_${sid}_site_srHook_${DC1} -v SOK -t crm_config -s SAPHanaSR
Cmnd_Alias DC1_SFAIL = /usr/sbin/crm_attribute -n hana_${sid}_site_srHook_${DC1} -v SFAIL -t crm_config -s SAPHanaSR
Cmnd_Alias DC2_SOK = /usr/sbin/crm_attribute -n hana_${sid}_site_srHook_${DC2} -v SOK -t crm_config -s SAPHanaSR
Cmnd_Alias DC2_SFAIL = /usr/sbin/crm_attribute -n hana_${sid}_site_srHook_${DC2} -v SFAIL -t crm_config -s SAPHanaSR
${sid}adm ALL=(ALL) NOPASSWD: DC1_SOK, DC1_SFAIL, DC2_SOK, DC2_SFAIL
Defaults!DC1_SOK, DC1_SFAIL, DC2_SOK, DC2_SFAIL !requiretty
EOT

    Regolare le autorizzazioni e controllare gli errori di sintassi.

    chown root:root /etc/sudoers.d/20-saphana

    chmod 0440 /etc/sudoers.d/20-saphana

    cat /etc/sudoers.d/20-saphana

    visudo -c

Tutti i problemi segnalati dal comando visudo -c devono essere corretti.

  1. Verificare che il gancio funzioni.

    • Riavviare entrambe le istanze di HANA e verificare che lo script di hook funzioni come previsto.
    • Eseguire un'azione per attivare l'hook, ad esempio l'arresto di un'istanza HANA.
    • Controllare se l'hook ha registrato qualcosa nei file di traccia.

    Su entrambi i nodi, eseguire i seguenti comandi.

    Arrestare l'istanza HANA.

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

    Avviare l'istanza HANA.

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

    Verificare che l'hook abbia registrato alcuni messaggi nei file di traccia.

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

    Dopo aver verificato il funzionamento dei ganci, è possibile riavviare il cluster HA.

  2. Avviare il cluster.

    Su NODE1, eseguire i seguenti comandi.

    Avviare il cluster.

    pcs cluster start --all

    Controllare lo stato del cluster.

    pcs status --full

Configurazione delle proprietà generali del cluster

Per evitare il failover delle risorse durante i test iniziali e la post-produzione, impostare i seguenti valori predefiniti per i parametri resource-stickiness e migration-threshold.

Tenere presente che le impostazioni predefinite non si applicano alle risorse che le sovrascrivono con i propri valori definiti.

Su NODE1, eseguire i seguenti comandi.

pcs resource defaults update resource-stickiness=1000

pcs resource defaults update migration-threshold=5000

Creare una risorsa clonata di SAPHanaTopology

La risorsa SAPHanaTopology raccoglie lo stato e la configurazione di SAP HANA System Replication su ogni nodo. Avvia e monitora anche l' SAP HostAgent locale, necessario per avviare, arrestare e monitorare le istanze SAP HANA.

Su NODE1, eseguire i seguenti comandi.

Creare la SAPHanaTopology risorsa.

pcs resource create SAPHanaTopology_${SID}_${INSTNO} SAPHanaTopology \
    SID=${SID} InstanceNumber=${INSTNO} \
    op start timeout=600 \
    op stop timeout=300 \
    op monitor interval=10 timeout=600 \
    clone clone-max=2 clone-node-max=1 interleave=true

Controllare la configurazione e lo stato del cluster eseguendo i seguenti comandi.

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

pcs resource config SAPHanaTopology_${SID}_${INSTNO}-clone

pcs status --full

Creare una risorsa SAPHana promuovibile

La risorsa SAPHana gestisce due istanze SAP HANA configurate come nodi di replica del sistema HANA.

Su NODE1, creare la risorsa SAPHana eseguendo il seguente comando.

pcs resource create SAPHana_${SID}_${INSTNO} SAPHana \
    SID=${SID} InstanceNumber=${INSTNO} \
    PREFER_SITE_TAKEOVER=true \
    DUPLICATE_PRIMARY_TIMEOUT=7200 \
    AUTOMATED_REGISTER=false \
    op start timeout=3600 \
    op stop timeout=3600 \
    op monitor interval=61 role="Unpromoted" timeout=700 \
    op monitor interval=59 role="Promoted" timeout=700 \
    op promote timeout=3600 \
    op demote timeout=3600 \
    promotable notify=true clone-max=2 clone-node-max=1 interleave=true

Controllare la configurazione e lo stato del cluster.

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

pcs status --full

Creazione di una risorsa cluster di indirizzi IP virtuali

A seconda dello scenario, passare a una delle seguenti sezioni:

Creazione di una risorsa cluster di indirizzi IP virtuali in un ambiente a zona singola

Utilizzare l'indirizzo IP riservato per creare una risorsa cluster di indirizzi IP virtuali. Questo indirizzo IP virtuale viene utilizzato per raggiungere l'istanza primaria di SAP HANA System Replication.

Creare la risorsa cluster di indirizzi IP virtuali con il seguente comando.

pcs resource create vip_${SID}_${INSTNO} IPaddr2 ip=$VIP

Controllare la risorsa cluster dell'indirizzo IP virtuale configurato e lo stato del cluster.

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

pcs status --full

Passare alla sezione Creazione dei vincoli delle risorse del cluster.

Creazione di una risorsa cluster di indirizzi IP virtuali in un ambiente di regioni multizona

Verificare di aver completato tutti i passaggi della sezione Preparazione di un cluster RHEL HA Add-On multizona per una risorsa di indirizzo IP virtuale.

Eseguire il comando pcs resource describe powervs-subnet per ottenere informazioni sui parametri dell'agente di risorse.

Su NODE1, creare una risorsa del cluster powervs-subnet eseguendo il seguente comando.

pcs resource create vip_${SID}_${INSTNO} powervs-subnet \
    api_key=${APIKEY} \
    api_type=${API_TYPE} \
    cidr=${CIDR} \
    ip=${VIP} \
    crn_host_map="${NODE1}:${IBMCLOUD_CRN_1};${NODE2}:${IBMCLOUD_CRN_2}" \
    vsi_host_map="${NODE1}:${POWERVSI_1};${NODE2}:${POWERVSI_2}" \
    jumbo=${JUMBO} \
    region=${CLOUD_REGION} \
    subnet_name=${SUBNET_NAME} \
    op start timeout=720 \
    op stop timeout=300 \
    op monitor interval=60 timeout=30

Se si imposta API_TYPE su public, è necessario specificare anche il parametro proxy.

Assicuratevi che entrambe le istanze di server virtuale nel cluster abbiano lo stato Active e lo stato di salute OK prima di eseguire il comando pcs resource config.

Controllare la risorsa dell'indirizzo IP virtuale configurato e lo stato del cluster.

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

Output di esempio:

# pcs resource config vip_MHA_00
Resource: vip_MHA_00 (class=ocf provider=heartbeat type=powervs-subnet)
  Attributes: vip_MHA_00-instance_attributes
    api_key=@/root/.apikey.json
    api_type=private
    cidr=10.40.11.100/30
    crn_host_map=cl-mha-1:crn:v1:bluemix:public:power-iaas:eu-de-2:**********************************:************************************::;cl-mha-2:crn:v1:bluemix:public:power-iaas:eu-
        de-1:**********************************:************************************::
    ip=10.40.11.102
    jumbo=true
    proxy=http://10.30.40.4:3128
    region=eu-de
    subnet_name=vip-mha-net
    vsi_host_map=cl-mha-1:************************************;cl-mha-2:************************************
  Operations:
    monitor: res_vip_MHA_00-monitor-interval-60
      interval=60
      timeout=60
    start: res_vip_MHA_00-start-interval-0s
      interval=0s
      timeout=720
    stop: res_vip_MHA_00-stop-interval-0s
      interval=0s
      timeout=300

pcs status --full

L'esempio seguente è un esempio di output di un cluster SAP HANA System Replication in una configurazione di regione multizona.

# pcs status --full
Cluster name: SAP_MHA
Status of pacemakerd: 'Pacemaker is running' (last updated 2024-07-31 11:37:49 +02:00)
Cluster Summary:
  * Stack: corosync
  * Current DC: cl-mha-2 (2) (version 2.1.5-9.el9_2.4-a3f44794f94) - partition with quorum
  * Last updated: Wed Jul 31 11:37:50 2024
  * Last change:  Wed Jul 31 11:37:31 2024 by root via crm_attribute on cl-mha-1
  * 2 nodes configured
  * 7 resource instances configured

Node List:
  * Node cl-mha-1 (1): online, feature set 3.16.2
  * Node cl-mha-2 (2): online, feature set 3.16.2

Full List of Resources:
  * fence_node1	(stonith:fence_ibm_powervs):	 Started cl-mha-1
  * fence_node2	(stonith:fence_ibm_powervs):	 Started cl-mha-2
  * Clone Set: SAPHanaTopology_MHA_00-clone [SAPHanaTopology_MHA_00]:
    * SAPHanaTopology_MHA_00	(ocf:heartbeat:SAPHanaTopology):	 Started cl-mha-2
    * SAPHanaTopology_MHA_00	(ocf:heartbeat:SAPHanaTopology):	 Started cl-mha-1
  * Clone Set: SAPHana_MHA_00-clone [SAPHana_MHA_00] (promotable):
    * SAPHana_MHA_00	(ocf:heartbeat:SAPHana):	 Unpromoted cl-mha-2
    * SAPHana_MHA_00	(ocf:heartbeat:SAPHana):	 Promoted cl-mha-1
  * vip_MHA_00	(ocf:heartbeat:powervs-subnet):	 Started cl-mha-1

Node Attributes:
  * Node: cl-mha-1 (1):
    * hana_mha_clone_state            	: PROMOTED
    * hana_mha_op_mode                	: logreplay
    * hana_mha_remoteHost             	: cl-mha-2
    * hana_mha_roles                  	: 4:P:master1:master:worker:master
    * hana_mha_site                   	: SiteA
    * hana_mha_sra                    	: -
    * hana_mha_srah                   	: -
    * hana_mha_srmode                 	: syncmem
    * hana_mha_sync_state             	: PRIM
    * hana_mha_version                	: 2.00.075.00
    * hana_mha_vhost                  	: cl-mha-1
    * lpa_mha_lpt                     	: 1722418651
    * master-SAPHana_MHA_00           	: 150
  * Node: cl-mha-2 (2):
    * hana_mha_clone_state            	: DEMOTED
    * hana_mha_op_mode                	: logreplay
    * hana_mha_remoteHost             	: cl-mha-1
    * hana_mha_roles                  	: 4:S:master1:master:worker:master
    * hana_mha_site                   	: SiteB
    * hana_mha_sra                    	: -
    * hana_mha_srah                   	: -
    * hana_mha_srmode                 	: syncmem
    * hana_mha_sync_state             	: SOK
    * hana_mha_version                	: 2.00.075.00
    * hana_mha_vhost                  	: cl-mha-2
    * lpa_mha_lpt                     	: 30
    * master-SAPHana_MHA_00           	: 100

Migration Summary:

Tickets:

PCSD Status:
  cl-mha-1: Online
  cl-mha-2: Online

Daemon Status:
  corosync: active/disabled
  pacemaker: active/disabled
  pcsd: active/enabled

Passare alla sezione Creazione dei vincoli delle risorse del cluster.

Creazione di vincoli sulle risorse del cluster

Assicurarsi che le SAPHanaTopology siano avviate prima di avviare le risorse SAPHana.

L'indirizzo IP virtuale deve essere presente sul nodo in cui è in esecuzione la risorsa primaria di "SAPHana".

  1. Creare un vincolo di risorse per avviare "SAPHanaTopology" prima di "SAPHana". Questo vincolo impone l'ordine di inizio di queste risorse.

    Su NODE1, utilizzare il seguente comando per creare il vincolo SAPHanaTopology per creare il vincolo d'ordine:

    pcs constraint order SAPHanaTopology_${SID}_${INSTNO}-clone \
    then SAPHana_${SID}_${INSTNO}-clone symmetrical=false

    Controllare la configurazione.

    pcs constraint

  2. Creare un vincolo di risorse per colocare l'indirizzo IP virtuale con quello primario. Questo vincolo coloca la risorsa dell'indirizzo IP virtuale con la risorsa SAPHana promossa come primaria.

    Su NODE1, eseguire il seguente comando per creare il vincolo di colocazione dell'indirizzo IP virtuale.

    pcs constraint colocation add vip_${SID}_${INSTNO} \
    with Promoted SAPHana_${SID}_${INSTNO}-clone 2000

    Controllare la configurazione e lo stato del cluster.

    pcs constraint

    Output di esempio:

    # pcs constraint
Location Constraints:
Ordering Constraints:
  start SAPHanaTopology_HDB_00-clone then start SAPHana_HDB_00-clone (kind:Mandatory) (non-symmetrical)
Colocation Constraints:
  vip_HDB_00 with SAPHana_HDB_00-clone (score:2000) (rsc-role:Started) (with-rsc-role:Promoted)
Ticket Constraints:

    Verificare lo stato del cluster.

    pcs status --full

    Sul nodo cluster promosso, verificare che l'indirizzo IP del servizio cluster sia attivo.

    ip addr show

Abilitazione del gancio SAP HANA srServiceStateChanged( ) (opzionale)

SAP HANA ha funzioni integrate per monitorare il sito indexserver. In caso di problemi, SAP HANA cerca di ripristinare automaticamente il processo arrestandolo e riavviandolo. Per arrestare il processo o ripulirlo dopo un arresto anomalo, il kernel Linux deve rilasciare tutta la memoria allocata dal processo. Per i database di grandi dimensioni, questa pulizia può richiedere molto tempo. Durante questo periodo, SAP HANA continua a operare e ad accettare nuove richieste di clienti. Di conseguenza, la replica del sistema SAP HANA può risultare non sincronizzata. Se si verifica un altro errore nell'istanza SAP HANA prima che il riavvio e il ripristino di indexserver siano completati, la coerenza dei dati è a rischio.

Lo script ChkSrv.py per il gancio srServiceStateChanged() reagisce a tale situazione e può arrestare l'intera istanza SAP HANA per un recupero più rapido. Se automated failover è abilitato nel cluster e il nodo secondario è in stato di salute, viene avviata un'operazione di takeover. In caso contrario, il ripristino deve continuare localmente, ma è accelerato dal riavvio forzato dell'istanza SAP HANA.

Il gancio SAP HANA srServiceStateChanged() è disponibile con la versione resource-agents-sap-hana 0.162.3 e successive.

Lo script hook analizza gli eventi dell'istanza, applica filtri ai dettagli dell'evento e attiva azioni in base ai risultati. Si distingue tra un processo SAP HANA indexserver che viene fermato e riavviato da SAP HANA e il processo che viene fermato durante l'arresto di un'istanza.

A seconda della configurazione del parametro action_on_lost, il gancio esegue azioni diverse:

Ignora
Questa azione registra semplicemente gli eventi e le informazioni sulle decisioni in un file di registro.
Arresta
Quest'azione innesca l'arresto graduale dell'istanza SAP HANA utilizzando il comando sapcontrol.
Termina
Questa azione attiva il comando HDB kill-<signal> con un segnale predefinito 9. Il segnale può essere configurato.

Sia l'azione di stop che quella di kill producono l'arresto dell'istanza di SAP HANA, ma l'azione di kill è leggermente più veloce.

Attivazione del gancio srServiceStateChanged( ) su tutte le istanze di SAP HANA

L'hook srServiceStateChanged() può essere aggiunto mentre SAP HANA è in esecuzione su entrambi i nodi.

  1. Per ogni istanza HANA, installare lo script hook fornito dal pacchetto resource-agents-sap-hana nella directory /hana/shared/myHooks e impostare la proprietà richiesta.

    Su entrambi i nodi, eseguire i seguenti comandi.

    cp /usr/share/SAPHanaSR/srHook/ChkSrv.py /hana/shared/myHooks

    chown ${sid}adm:sapsys /hana/shared/myHooks/ChkSrv.py

  2. Aggiornare il file global.ini su ogni nodo SAP HANA per abilitare lo script di aggancio.

    Su entrambi i nodi, eseguire il seguente comando.

    sudo -i -u ${sid}adm -- <<EOT
    python \$DIR_INSTANCE/exe/python_support/setParameter.py \
      -set SYSTEM/global.ini/ha_dr_provider_ChkSrv/provider=ChkSrv \
      -set SYSTEM/global.ini/ha_dr_provider_ChkSrv/path=/hana/shared/myHooks \
      -set SYSTEM/global.ini/ha_dr_provider_ChkSrv/execution_order=2 \
      -set SYSTEM/global.ini/ha_dr_provider_ChkSrv/action_on_lost=stop \
      -set SYSTEM/global.ini/trace/ha_dr_chksrv=info
EOT

    Il parametro action_on_lost in questo esempio è impostato su stop, l'impostazione predefinita è ignore. È possibile impostare facoltativamente i parametri stop_timeout (valore predefinito: 20 secondi) e kill_signal (valore predefinito: 9).

  3. Attivare il gancio ChkSrv.py

    Su entrambi i nodi, eseguire il seguente comando per ricaricare i provider HA-DR.

    sudo -i -u ${sid}adm -- hdbnsutil -reloadHADRProviders

  4. Verificare che l'hook abbia registrato alcuni messaggi nei file di traccia.

    Su entrambi i nodi, eseguire il seguente comando.

    sudo -i -u ${sid}adm -- sh -c 'grep "ha_dr_ChkSrv" $DIR_INSTANCE/$VTHOSTNAME/trace/nameserver_* | cut -d" " -f2,3,6-'

Abilitazione della registrazione automatica dell'istanza secondaria

È necessario impostare il parametro AUTOMATED_REGISTER in base alle proprie esigenze operative. Se si vuole mantenere la possibilità di tornare allo stato dell'istanza primaria precedente di SAP HANA, AUTOMATED_REGISTER=false evita la registrazione automatica del primario precedente come nuovo secondario.

Se si riscontra un problema con i dati dopo un'acquisizione attivata dal cluster, è possibile ripristinare manualmente se AUTOMATED_REGISTER è impostato su false.

Se AUTOMATED_REGISTER è impostato su true, la precedente istanza primaria SAP HANA si registra automaticamente come secondaria e non può essere attivata sulla sua storia precedente. Il vantaggio di AUTOMATED_REGISTER=true è che la capacità di alta disponibilità viene ristabilita automaticamente dopo la ricomparsa del nodo guasto nel cluster.

Per il momento, si consiglia di mantenere AUTOMATED_REGISTER sul valore predefinito false fino a quando il cluster non sarà completamente testato e si verificherà che gli scenari di failover funzionino come previsto.

Il comando pcs resource update viene utilizzato per modificare gli attributi delle risorse e pcs resource update SAPHana_${SID}_${INSTNO} AUTOMATED_REGISTER=true imposta l'attributo a true.

Test del cluster SAP HANA System Replication

È fondamentale testare a fondo la configurazione del cluster per assicurarsi che funzioni correttamente. Le seguenti informazioni forniscono alcuni esempi di scenari di test del failover, ma non costituiscono un elenco completo di scenari di test.

Ad esempio, la descrizione di ogni caso di test include le seguenti informazioni.

  • Componente da testare
  • Descrizione del test
  • Prerequisiti e stato del cluster prima di avviare il test di failover
  • Procedura di prova
  • Comportamento e risultati attesi
  • Procedura di recupero

Test 1 - Verifica di un guasto dell'istanza del database primario

Utilizzate le seguenti informazioni per verificare il guasto dell'istanza del database primario.

Test 1 - Descrizione

Simulare un crash dell'istanza primaria del database HANA in esecuzione su NODE1.

Test 1 - Prerequisiti

  • Un cluster funzionale a due nodi RHEL HA Add-On per la replica del sistema HANA.
  • Entrambi i nodi del cluster sono attivi.
  • Cluster avviato su NODE1 e NODE2.
  • Cluster Resource SAPHana_${SID}_${INSTNO} configurato con AUTOMATED_REGISTER=false.
  • Controllare lo stato di SAP HANA System Replication:
    • Il database primario SAP HANA è in esecuzione su NODE1
    • Il database secondario SAP HANA è in esecuzione su NODE2
    • La replica del sistema HANA è attivata e sincronizzata

Prova 1 - Procedura di prova

Crash SAP HANA primario inviando un segnale SIGKILL all'utente ${sid}adm.

Su NODE1, eseguite il seguente comando.

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

Test 1 - Comportamento previsto

  • SAP HANA l'istanza primaria su NODE1 si blocca.
  • Il cluster rileva l'arresto del database primario HANA e contrassegna la risorsa come failed.
  • Il cluster promuove il database HANA secondario su NODE2 a nuovo primario.
  • Il cluster rilascia l'indirizzo IP virtuale su NODE1 e lo acquisisce sul nuovo primario su NODE2.
  • Se un'applicazione, ad esempio SAP NetWeaver, è collegata a un database tenant di SAP HANA, l'applicazione si ricollega automaticamente al nuovo primario.

Test 1 - Procedura di recupero

Poiché la risorsa del cluster SAPHana_${SID}_${INSTNO} è configurata con AUTOMATED_REGISTER=false, il cluster non riavvia il database HANA fallito e non lo registra rispetto al nuovo primario. Ciò significa che lo stato del nuovo primario ( NODE2 ) mostra anche il secondario nello stato 'CONNECTION TIMEOUT'.

Per registrare nuovamente il precedente primario come nuovo secondario, utilizzare i seguenti comandi.

Su NODE1, eseguite il seguente comando.

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

Verificare lo stato di replica del sistema:

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

Dopo la registrazione manuale e l'aggiornamento delle risorse, la nuova istanza secondaria si riavvia e appare in stato di sincronizzazione (SOK).

Su NODE1, eseguite il seguente comando.

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

pcs status --full

Test 2 - Verifica di un guasto del nodo che esegue il database primario

Utilizzare le seguenti informazioni per verificare il guasto del nodo che esegue il database primario.

Test 2 - Descrizione

Simulare un arresto anomalo del nodo che esegue il database primario di HANA.

Test 2 - Preparazione

Assicurarsi che la risorsa del cluster SAPHana_${SID}_${INSTNO} sia configurata con AUTOMATED_REGISTER=true.

Su NODE1, eseguite il seguente comando.

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

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

Test 2 - Prerequisiti

  • Un cluster funzionale a due nodi RHEL HA Add-On per la replica del sistema HANA.
  • Entrambi i nodi sono attivi.
  • Il cluster viene avviato su NODE1 e NODE2.
  • Controllare lo stato di SAP HANA System Replication.
    • Il database primario SAP HANA è in esecuzione su NODE2
    • Il database secondario SAP HANA è in esecuzione su NODE1
    • La replica del sistema HANA è attivata e sincronizzata

Prova 2 - Procedura di prova

Il crash del primario su NODE2 si ottiene inviando una richiesta di crash del sistema.

Su NODE2, eseguite il seguente comando.

sync; echo c > /proc/sysrq-trigger

Test 2 - Comportamento previsto

  • NODE2 si spegne.
  • Il cluster rileva il nodo guasto e imposta il suo stato su OFFLINE.
  • Il cluster promuove il database HANA secondario su NODE1 a nuovo primario.
  • Il cluster acquisisce l'indirizzo IP virtuale su NODE1 sul nuovo primario.
  • Se un'applicazione, ad esempio SAP NetWeaver, è collegata a un database tenant di SAP HANA, l'applicazione si ricollega automaticamente al nuovo primario.

Test 2 - Procedura di recupero

Accedere alla console IBM Cloud® e avviare l'istanza NODE2. Attendere che NODE2 sia nuovamente disponibile, quindi riavviare il framework cluster.

Su NODE2, eseguite il seguente comando.

pcs cluster start

pcs status --full

Poiché la risorsa del cluster SAPHana_${SID}_${INSTNO} è configurata con AUTOMATED_REGISTER=true, SAP HANA si riavvia quando NODE2 rientra nel cluster e il precedente primario si registra nuovamente come secondario.

Test 3 - Verifica di un guasto dell'istanza del database secondario

Utilizzate le seguenti informazioni per verificare il fallimento dell'istanza del database secondario.

Test 3 - Descrizione

Simulare un crash del database HANA secondario.

Test 3 - Prerequisiti

  • Un cluster funzionale a due nodi RHEL HA Add-On per la replica del sistema HANA.
  • Entrambi i nodi sono attivi.
  • Il cluster viene avviato su NODE1 e NODE2.
  • Cluster Resource SAPHana_${SID}_${INSTNO} è configurato con AUTOMATED_REGISTER=true.
  • Controllare lo stato di SAP HANA System Replication:
    • Il database primario SAP HANA è in esecuzione su NODE1
    • Il database secondario SAP HANA è in esecuzione su NODE2
    • La replica del sistema HANA è attivata e sincronizzata

Prova 3 - Procedura di prova

Crash SAP HANA secondario inviando un segnale SIGKILL mentre l'utente ${sid}adm.

Su NODE2, eseguite il seguente comando.

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

Test 3 - Comportamento previsto

  • SAP HANA secondario su NODE2 si schianta.
  • Il cluster rileva l'arresto del database secondario HANA e contrassegna la risorsa come failed.
  • Il cluster riavvia il database HANA secondario.
  • Il cluster rileva che la replica del sistema è di nuovo sincronizzata.

Test 3 - Procedura di recupero

Attendere che l'istanza HANA secondaria si avvii e si sincronizzi di nuovo (SOK), quindi ripulire le azioni delle risorse non riuscite come mostrato in pcs status.

Su NODE2, eseguite il seguente comando.

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

pcs status --full

Test 4 - Prova di spostamento manuale di una risorsa SAPHana su un altro nodo

Utilizzate le seguenti informazioni per testare lo spostamento manuale di una risorsa SAPHana su un altro nodo.

Test 4 - Descrizione

Utilizzare i comandi del cluster per spostare l'istanza primaria sull'altro nodo a scopo di manutenzione.

Test 4 - Prerequisiti

  • Un cluster funzionale a due nodi RHEL HA Add-On per la replica del sistema HANA.
  • Entrambi i nodi sono attivi.
  • Il cluster viene avviato su NODE1 e NODE2.
  • Cluster Resource SAPHana_${SID}_${INSTNO} è configurato con AUTOMATED_REGISTER=true.
  • Controllare lo stato di SAP HANA System Replication:
    • Il database primario SAP HANA è in esecuzione su NODE1
    • Il database secondario SAP HANA è in esecuzione su NODE2
    • La replica del sistema HANA è attivata e sincronizzata

Prova 4 - Procedura di prova

Spostare il primario SAP HANA in un altro nodo utilizzando il comando pcs resource move.

Su NODE1, eseguite il seguente comando.

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

Test 4 - Comportamento previsto

  • Il cluster crea vincoli di posizione per spostare la risorsa.
  • Il cluster attiva un takeover sul database HANA secondario.
  • Se un'applicazione, ad esempio SAP NetWeaver, è collegata a un database tenant di SAP HANA, l'applicazione si ricollega automaticamente al nuovo primario.

Test 4 - Procedura di recupero

I vincoli di posizione creati automaticamente devono essere rimossi per consentire il failover automatico in futuro.

Attendere che l'istanza primaria di HANA sia attiva e rimuovere i vincoli.

Il cluster registra e avvia il database HANA come nuova istanza secondaria.

Su NODE1, eseguite il seguente comando.

pcs constraint

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

pcs constraint

pcs status --full