IBM Cloud Docs
Configuration de la réplication du système de mise à l'échelle SAP HANA dans un cluster Red Hat Enterprise Linux High Availability Add-On

Configuration de la réplication du système de mise à l'échelle SAP HANA dans un cluster Red Hat Enterprise Linux High Availability Add-On

Les informations suivantes décrivent la configuration d'un cluster Red Hat Enterprise Linux (RHEL) High Availability Add-On pour gérer SAP HANA Scale-Up System Replication. Le cluster utilise des instances de serveurs virtuels dans IBM® Power® Virtual Server comme nœuds de cluster.

Les instructions décrivent comment automatiser SAP HANA Scale-Up System Replication pour un déploiement de base de données unique dans un scénario optimisant les performances sur un cluster RHEL HA Add-on.

Ces informations sont destinées aux architectes et aux spécialistes qui planifient un déploiement à haute disponibilité de SAP HANA sur Power Virtual Server.

Avant de commencer

Passez en revue les exigences générales, la documentation produit, les articles de support et les notes SAP répertoriées dans la section Mise en œuvre de la haute disponibilité pour les applications SAP à l'adresse IBM Power Virtual Server Références.

Prérequis

  • Un cluster de haute disponibilité Red Hat est déployé sur deux instances de serveurs virtuels dans Power Virtual Server.
  • Les instances de serveurs virtuels doivent répondre aux exigences en matière de matériel et de ressources pour les systèmes SAP HANA concernés. Suivez les lignes directrices du document Planifier votre déploiement.
  • Les noms d'hôtes des instances de serveurs virtuels doivent répondre à l'exigence SAP HANA.
  • SAP HANA est installé sur les deux instances de serveurs virtuels et SAP HANA System Replication est configuré. L'installation de SAP HANA et la configuration de la réplication du système HANA ne sont pas spécifiques à l'environnement Power Virtual Server et vous devez suivre les procédures standard.
  • Un abonnement valide à RHEL for SAP Applications ou RHEL for SAP Solutions est nécessaire pour activer les référentiels dont vous avez besoin pour installer SAP HANA et les agents de ressources pour les configurations HA.

Configuration de la réplication du système SAP HANA dans un cluster RHEL HA Add-On sur IBM Power Virtual Server

Les instructions sont basées sur la documentation du produit Red Hat et sur les articles énumérés dans Mise en œuvre de la haute disponibilité pour les applications SAP sur IBM Power Virtual Server Références.

Préparation des variables d'environnement

Pour simplifier l'installation, préparez les variables d'environnement suivantes pour root sur les deux nœuds. Ces variables d'environnement sont utilisées avec les commandes ultérieures du système d'exploitation dans ces informations.

Sur les deux nœuds, définissez les variables d'environnement suivantes.

# 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

Définition de variables d'environnement supplémentaires pour la mise en œuvre d'une zone unique

Consultez les informations de la section Réserver des adresses IP virtuelles et réservez une adresse IP virtuelle pour le cluster de réplication du système SAP HANA. Définissez la variable d'environnement VIP avec l'adresse IP réservée.

Définition de variables d'environnement supplémentaires pour la mise en œuvre d'une région multizone

Définissez les variables CLOUD_REGION, APIKEY, IBMCLOUD_CRN_?, POWERVSI_? comme décrit dans la section Collecte des paramètres pour la configuration d'un cluster à haute disponibilité. Définissez la variable API_TYPE sur private pour communiquer avec IBM Cloud IAM et IBM Power Cloud API via des points d'extrémité privés. La variable SUBNET_NAME contient le nom du sous-réseau. La variable CIDR représente la notation CIDR (Classless Inter-Domain Routing) pour le sous-réseau au format <IPv4_address>/number. La variable VIP est l'adresse IP de la ressource d'adresse IP virtuelle et doit appartenir à CIDR du sous-réseau. Définissez la variable JUMBO sur true si vous souhaitez activer le sous-réseau pour une taille de MTU importante.

L'exemple suivant montre comment définir les variables d'environnement supplémentaires nécessaires à la mise en œuvre d'une région multizone.

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"

Installation des agents de ressources SAP HANA

Exécutez la commande suivante pour installer les agents de ressources RHEL HA Add-On pour SAP HANA System Replication.

dnf install -y resource-agents-sap-hana

Démarrage du système SAP HANA

Démarrez SAP HANA et vérifiez que la réplication du système HANA est active. Pour plus d'informations, voir 2.4. Vérification de l'état de la réplication du système SAP HANA.

Sur les deux nœuds, exécutez les commandes suivantes.

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

Activation du crochet SAP HANA srConnectionChanged( )

Les versions récentes de SAP HANA fournissent des crochets permettant à SAP HANA d'envoyer des notifications pour certains événements. Pour plus d'informations, voir Mise en œuvre d'un fournisseur HA/DR.

Le hook srConnectionChanged( ) améliore la capacité du cluster à détecter un changement d'état de la réplication du système HANA nécessitant une action de la part du cluster. L'objectif est de prévenir la perte et la corruption de données en empêchant les prises de contrôle accidentelles.

Activation du crochet srConnectionChanged( ) sur toutes les instances SAP HANA

  1. Arrêter le cluster.

    Sur NODE1, exécutez la commande suivante.

    pcs cluster stop --all
    
  2. Installez le script hook fourni par le package resource-agents-sap-hana dans le répertoire /hana/shared/myHooks pour chaque instance HANA et définissez les droits de propriété requis.

    Sur les deux nœuds, exécutez les commandes suivantes.

    mkdir -p /hana/shared/myHooks
    
    cp /usr/share/SAPHanaSR/srHook/SAPHanaSR.py /hana/shared/myHooks
    
    chown -R ${sid}adm:sapsys /hana/shared/myHooks
    
  3. Mettez à jour le fichier global.ini sur chaque nœud HANA pour activer le script de crochet.

    Sur les deux nœuds, exécutez la commande suivante.

    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. Vérifier le fichier modifié.

    Sur les deux nœuds, exécutez la commande suivante.

    cat /hana/shared/${SID}/global/hdb/custom/config/global.ini
    
  5. Créer les paramètres sudo pour l'utilisateur du système d'exploitation SAP HANA.

    Vous avez besoin des paramètres sudo suivants pour permettre au script de l'utilisateur ${sid}adm de mettre à jour les attributs du nœud lorsque le crochet srConnectionChanged( ) est exécuté.

    Sur les deux nœuds, exécutez les commandes suivantes.

    Créez un fichier contenant les alias sudo et les spécifications de l'utilisateur.

    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
    

    Ajustez les autorisations et vérifiez qu'il n'y a pas d'erreurs de syntaxe.

    chown root:root /etc/sudoers.d/20-saphana
    
    chmod 0440 /etc/sudoers.d/20-saphana
    
    cat /etc/sudoers.d/20-saphana
    
    visudo -c
    

Tout problème signalé par la commande visudo -c doit être corrigé.

  1. Vérifier que le crochet fonctionne.

    • Redémarrez les deux instances HANA et vérifiez que le script hook fonctionne comme prévu.
    • Effectuer une action pour déclencher le crochet, par exemple arrêter une instance HANA.
    • Vérifier si le crochet a enregistré quelque chose dans les fichiers de trace.

    Sur les deux nœuds, exécutez les commandes suivantes.

    Arrêtez l'instance HANA.

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

    Démarrer l'instance HANA.

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

    Vérifier que le hook a enregistré des messages dans les fichiers de trace.

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

    Après avoir vérifié que les crochets fonctionnent, vous pouvez redémarrer le cluster HA.

  2. Démarrez le cluster.

    Sur NODE1, exécutez les commandes suivantes.

    Démarrez le cluster.

    pcs cluster start --all
    

    Vérifier l'état de la grappe.

    pcs status --full
    

Configuration des propriétés générales du cluster

Pour éviter le basculement des ressources lors des tests initiaux et de la post-production, définissez les valeurs par défaut suivantes pour les paramètres d'adhérence des ressources et de seuil de migration.

N'oubliez pas que les valeurs par défaut ne s'appliquent pas aux ressources qui les remplacent par leurs propres valeurs.

Sur NODE1, exécutez les commandes suivantes.

pcs resource defaults update resource-stickiness=1000
pcs resource defaults update migration-threshold=5000

Création d'une ressource clonée SAPHanaTopology

La ressource SAPHanaTopology rassemble l'état et la configuration de SAP HANA System Replication sur chaque nœud. Il démarre et surveille également le SAP HostAgent local, qui est requis pour démarrer, arrêter et surveiller les instances SAP HANA.

Sur NODE1, exécutez les commandes suivantes.

Créer la SAPHanaTopology ressource.

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

Vérifiez la configuration et l'état de la grappe en exécutant les commandes suivantes.

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

Créer une ressource SAPHana promouvable

La ressource SAPHana gère deux instances SAP HANA configurées en tant que nœuds de réplication du système HANA.

Sur NODE1, créez la ressource SAPHana en exécutant la commande suivante.

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

Vérifiez la configuration et l'état de la grappe.

pcs resource config SAPHana_${SID}_${INSTNO}
pcs status --full

Création d'une ressource de cluster d'adresses IP virtuelles

En fonction du scénario, passez à l'une des sections suivantes :

Création d'une ressource de cluster d'adresses IP virtuelles dans un environnement à zone unique

Utilisez l'adresse IP réservée pour créer une ressource de cluster d'adresses IP virtuelles. Cette adresse IP virtuelle est utilisée pour atteindre l'instance primaire de SAP HANA System Replication.

Créez la ressource cluster d'adresses IP virtuelles à l'aide de la commande suivante.

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

Vérifiez la ressource du cluster d'adresses IP virtuelles configurées et l'état du cluster.

pcs resource config vip_${SID}_${INSTNO}
pcs status --full

Passez à la section Création de contraintes de ressources pour les clusters.

Création d'une ressource de cluster d'adresses IP virtuelles dans un environnement de régions multizones

Vérifiez que vous avez effectué toutes les étapes de la section Préparation d'un cluster RHEL HA Add-On multizone pour une ressource d'adresse IP virtuelle.

Exécutez la commande pcs resource describe powervs-subnet pour obtenir des informations sur les paramètres de l'agent de ressources.

Sur NODE1, créez une ressource de cluster powervs-subnet en exécutant la commande suivante.

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

Si vous définissez API_TYPE comme public, vous devez également spécifier un paramètre proxy.

Assurez-vous que les deux instances de serveurs virtuels du cluster ont l'état Active et l'état de santé OK avant d'exécuter la commande pcs resource config.

Vérifiez la ressource d'adresse IP virtuelle configurée et l'état de la grappe.

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

Exemple de sortie :

# 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'exemple suivant est un exemple de sortie d'un cluster SAP HANA System Replication dans une configuration de région multizone.

# 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

Passez à la section Création de contraintes de ressources pour les clusters.

Création de contraintes de ressources pour les clusters

Assurez-vous que SAPHanaTopology sont démarrées avant de démarrer les ressources SAPHana.

L'adresse IP virtuelle doit être présente sur le nœud où s'exécute la ressource primaire de "SAPHana".

  1. Créer une contrainte de ressources pour démarrer "SAPHanaTopology" avant "SAPHana". Cette contrainte impose l'ordre de démarrage de ces ressources.

    Sur NODE1, utilisez la commande suivante pour créer la contrainte de commande SAPHanaTopology contrainte d'ordre :

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

    Vérifier la configuration.

    pcs constraint
    
  2. Créer une contrainte de ressource pour colocaliser l'adresse IP virtuelle avec l'adresse primaire. Cette contrainte permet d'associer la ressource d'adresse IP virtuelle à la ressource SAPHana qui a été promue au rang de ressource principale.

    Sur NODE1, exécutez la commande suivante pour créer la contrainte de colocation d'adresses IP virtuelles.

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

    Vérifiez la configuration et l'état de la grappe.

    pcs constraint
    

    Exemple de sortie :

    # 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:
    

    Vérifier l'état de la grappe.

    pcs status --full
    

    Sur le nœud de cluster promu, vérifiez que l'adresse IP du service de cluster est active.

    ip addr show
    

Activation du crochet SAP HANA srServiceStateChanged( ) (facultatif)

SAP HANA dispose de fonctions intégrées pour surveiller son site indexserver. En cas de problème, SAP HANA tente de se rétablir automatiquement en arrêtant et en redémarrant le processus. Pour arrêter le processus ou le nettoyer après un crash, le noyau Linux doit libérer toute la mémoire allouée par le processus. Pour les grandes bases de données, ce nettoyage peut prendre beaucoup de temps. Pendant cette période, SAP HANA continue à fonctionner et à accepter de nouvelles demandes de clients. Par conséquent, la réplication du système SAP HANA peut être désynchronisée. Si une autre erreur se produit dans l'instance SAP HANA avant que le redémarrage et la récupération de indexserver ne soient terminés, la cohérence des données est menacée.

Le script ChkSrv.py pour le crochet srServiceStateChanged() réagit à une telle situation et peut arrêter toute l'instance SAP HANA pour une récupération plus rapide. Si automated failover est activé dans le cluster et que le nœud secondaire est sain, une opération de reprise est lancée. Dans le cas contraire, la récupération doit se poursuivre localement, mais elle est accélérée par le redémarrage forcé de l'instance SAP HANA.

Le crochet SAP HANA srServiceStateChanged() est disponible à partir de la version 0.162.3 de resource-agents-sap-hana.

Le script hook analyse les événements de l'instance, applique des filtres aux détails de l'événement et déclenche des actions en fonction des résultats. Il fait la distinction entre un processus SAP HANA indexserver qui est arrêté et redémarré par SAP HANA et le processus qui est arrêté lors d'un arrêt de l'instance.

En fonction de la configuration du paramètre action_on_lost, le crochet prend différentes mesures :

Ignorer
Cette action consiste simplement à enregistrer les événements et les informations relatives à la décision dans un fichier journal.
Arrêter
Cette action déclenche un arrêt gracieux de l'instance SAP HANA à l'aide de la commande sapcontrol.
Tuer
Cette action déclenche la commande HDB kill-<signal> avec un signal par défaut de 9. Le signal peut être configuré.

Les actions " stop " et " kill " entraînent toutes deux l'arrêt du site SAP HANA, mais l'action " kill " est légèrement plus rapide.

Activation du crochet srServiceStateChanged( ) sur toutes les instances SAP HANA

Le crochet srServiceStateChanged() peut être ajouté lorsque SAP HANA est en cours d'exécution sur les deux nœuds.

  1. Pour chaque instance HANA, installez le script hook fourni par le package resource-agents-sap-hana dans le répertoire /hana/shared/myHooks et définissez la propriété requise.

    Sur les deux nœuds, exécutez les commandes suivantes.

    cp /usr/share/SAPHanaSR/srHook/ChkSrv.py /hana/shared/myHooks
    
    chown ${sid}adm:sapsys /hana/shared/myHooks/ChkSrv.py
    
  2. Mettez à jour le fichier global.ini sur chaque nœud SAP HANA pour activer le script de crochet.

    Sur les deux nœuds, exécutez la commande suivante.

    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
    

    Dans cet exemple, le paramètre action_on_lost est réglé sur stop, le réglage par défaut étant ignore. Vous pouvez définir les paramètres stop_timeout (par défaut : 20 secondes) et kill_signal (par défaut : 9).

  3. Activer le crochet ChkSrv.py

    Sur les deux nœuds, exécutez la commande suivante pour recharger les fournisseurs HA-DR.

    sudo -i -u ${sid}adm -- hdbnsutil -reloadHADRProviders
    
  4. Vérifier que le hook a enregistré des messages dans les fichiers de trace.

    Sur les deux nœuds, exécutez la commande suivante.

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

Permettre l'enregistrement automatique de l'instance secondaire

Vous devez régler le paramètre AUTOMATED_REGISTER en fonction de vos besoins opérationnels. Si vous souhaitez conserver la possibilité de revenir à l'état de l'instance primaire précédente SAP HANA, AUTOMATED_REGISTER=false évite l'enregistrement automatique de l'instance primaire précédente en tant que nouvelle instance secondaire.

Si vous rencontrez un problème avec les données après une reprise déclenchée par le cluster, vous pouvez revenir manuellement en arrière si AUTOMATED_REGISTER est défini sur false.

Si AUTOMATED_REGISTER est défini sur true, l'instance primaire précédente SAP HANA est automatiquement enregistrée comme secondaire et ne peut pas être activée sur la base de son historique précédent. L'avantage de AUTOMATED_REGISTER=true est que la capacité de haute disponibilité est automatiquement rétablie après la réapparition du nœud défaillant dans la grappe.

Pour l'instant, il est recommandé de laisser AUTOMATED_REGISTER sur la valeur par défaut false jusqu'à ce que le cluster soit entièrement testé et que vous vérifiiez que les scénarios de basculement fonctionnent comme prévu.

La commande pcs resource update est utilisée pour modifier les attributs des ressources et pcs resource update SAPHana_${SID}_${INSTNO} AUTOMATED_REGISTER=true attribue l'attribut à true.

Test de SAP HANA System Replication cluster

Il est essentiel de tester minutieusement la configuration du cluster pour s'assurer qu'il fonctionne correctement. Les informations suivantes fournissent quelques exemples de scénarios de test de basculement, mais ne constituent pas une liste complète de scénarios de test.

Par exemple, la description de chaque cas de test comprend les informations suivantes.

  • Composant testé
  • Description du test
  • Conditions préalables et état du cluster avant de lancer le test de basculement
  • Procédure de test
  • Comportement et résultats attendus
  • Procédure de récupération

Test 1 - Test d'une défaillance de l'instance primaire de la base de données

Utilisez les informations suivantes pour tester la défaillance de l'instance primaire de la base de données.

Test 1 - Description

Simulez un crash de l'instance de base de données HANA primaire qui s'exécute sur NODE1.

Test 1 - Conditions préalables

  • Un cluster fonctionnel RHEL HA Add-On à deux nœuds pour la réplication du système HANA.
  • Les deux nœuds de la grappe sont actifs.
  • Cluster démarré sur NODE1 et NODE2.
  • Cluster Resource SAPHana_${SID}_${INSTNO} qui est configuré avec AUTOMATED_REGISTER=false.
  • Vérifiez l'état de la réplication du système SAP HANA:
    • La base de données primaire SAP HANA est exécutée sur NODE1
    • La base de données secondaire SAP HANA fonctionne sur NODE2
    • La réplication du système HANA est activée et synchronisée

Test 1 - Procédure de test

Crash SAP HANA primary en envoyant un signal SIGKILL au moment où l'utilisateur ${sid}adm.

Sur NODE1, exécutez la commande suivante.

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

Test 1 - Comportement attendu

  • SAP HANA l'instance primaire sur NODE1 tombe en panne.
  • Le cluster détecte la base de données HANA primaire arrêtée et marque la ressource comme failed.
  • Le cluster promeut la base de données HANA secondaire sur NODE2 pour qu'elle prenne le relais en tant que nouvelle base de données primaire.
  • Le cluster libère l'adresse IP virtuelle sur NODE1, et l'acquiert sur le nouveau primaire sur NODE2.
  • Si une application, telle que SAP NetWeaver, est connectée à la base de données d'un locataire de SAP HANA, l'application se reconnecte automatiquement à la nouvelle base de données primaire.

Test 1 - Procédure de récupération

Comme la ressource de cluster SAPHana_${SID}_${INSTNO} est configurée avec AUTOMATED_REGISTER=false, le cluster ne redémarre pas la base de données HANA défaillante et ne l'enregistre pas par rapport à la nouvelle base de données primaire. Ce qui signifie que l'état du nouveau primaire ( NODE2 ) indique également que le secondaire a l'état "TEMPS D'ARRÊT DE LA CONNEXION".

Pour réenregistrer l'ancien primaire en tant que nouveau secondaire, utilisez les commandes suivantes.

Sur NODE1, exécutez la commande suivante.

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

Vérifier l'état de la réplication du système :

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

Après l'enregistrement manuel et l'actualisation des ressources, la nouvelle instance secondaire redémarre et apparaît dans l'état synchronisé (SOK).

Sur NODE1, exécutez la commande suivante.

pcs resource refresh SAPHana_${SID}_${INSTNO}
pcs status --full

Test 2 - Test d'une défaillance du nœud qui exécute la base de données primaire

Utilisez les informations suivantes pour tester la défaillance du nœud qui exécute la base de données principale.

Test 2 - Description

Simulez une panne du nœud qui exécute la base de données HANA primaire.

Test 2 - Préparation

Assurez-vous que la ressource de cluster SAPHana_${SID}_${INSTNO} est configurée avec AUTOMATED_REGISTER=true.

Sur NODE1, exécutez la commande suivante.

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

Test 2 - Conditions préalables

  • Un cluster fonctionnel RHEL HA Add-On à deux nœuds pour la réplication du système HANA.
  • Les deux nœuds sont actifs.
  • Le cluster est démarré sur NODE1 et NODE2.
  • Vérifiez l'état de la réplication du système SAP HANA.
    • La base de données primaire SAP HANA est exécutée sur NODE2
    • La base de données secondaire SAP HANA fonctionne sur NODE1
    • La réplication du système HANA est activée et synchronisée

Test 2 - Procédure de test

Crash primaire sur NODE2 en envoyant une demande de crash système.

Sur NODE2, exécutez la commande suivante.

sync; echo c > /proc/sysrq-trigger

Test 2 - Comportement attendu

  • NODE2 s'éteint.
  • La grappe détecte le nœud défaillant et lui attribue la valeur OFFLINE.
  • Le cluster promeut la base de données HANA secondaire sur NODE1 pour qu'elle prenne le relais en tant que nouvelle base de données primaire.
  • Le cluster acquiert l'adresse IP virtuelle sur NODE1 sur le nouveau primaire.
  • Si une application, telle que SAP NetWeaver, est connectée à la base de données d'un locataire de SAP HANA, l'application se reconnecte automatiquement à la nouvelle base de données primaire.

Test 2 - Procédure de récupération

Connectez-vous à la console IBM Cloud® et démarrez l'instance NODE2. Attendez que NODE2 soit à nouveau disponible, puis redémarrez le cluster framework.

Sur NODE2, exécutez la commande suivante.

pcs cluster start
pcs status --full

Comme la ressource de cluster SAPHana_${SID}_${INSTNO} est configurée avec AUTOMATED_REGISTER=true, SAP HANA redémarre lorsque NODE2 rejoint le cluster et que l'ancien primaire se réenregistre en tant que secondaire.

Test 3 - Test d'une défaillance de l'instance de base de données secondaire

Utilisez les informations suivantes pour tester la défaillance de l'instance de base de données secondaire.

Test 3 - Description

Simuler un crash de la base de données HANA secondaire.

Test 3 - Conditions préalables

  • Un cluster fonctionnel RHEL HA Add-On à deux nœuds pour la réplication du système HANA.
  • Les deux nœuds sont actifs.
  • Le cluster est démarré sur NODE1 et NODE2.
  • La ressource de cluster SAPHana_${SID}_${INSTNO} est configurée avec AUTOMATED_REGISTER=true.
  • Vérifiez l'état de la réplication du système SAP HANA:
    • La base de données primaire SAP HANA est exécutée sur NODE1
    • La base de données secondaire SAP HANA fonctionne sur NODE2
    • La réplication du système HANA est activée et synchronisée

Essai 3 - Procédure d'essai

Crash SAP HANA secondaire en envoyant un signal SIGKILL en tant qu'utilisateur ${sid}adm.

Sur NODE2, exécutez la commande suivante.

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

Test 3 - Comportement attendu

  • SAP HANA secondaire sur NODE2 crashs.
  • Le cluster détecte la base de données HANA secondaire arrêtée et marque la ressource comme failed.
  • Le cluster redémarre la base de données HANA secondaire.
  • Le cluster détecte que la réplication du système est à nouveau synchronisée.

Test 3 - Procédure de récupération

Attendez que l'instance HANA secondaire démarre et se synchronise à nouveau (SOK), puis nettoyez les actions de ressources qui ont échoué, comme indiqué sur le site pcs status.

Sur NODE2, exécutez la commande suivante.

pcs resource refresh SAPHana_${SID}_${INSTNO}
pcs status --full

Test 4 - Test de déplacement manuel d'une ressource SAPHana vers un autre nœud

Utilisez les informations suivantes pour tester le déplacement manuel d'une ressource SAPHana vers un autre nœud.

Test 4 - Description

Utilisez les commandes de cluster pour déplacer l'instance primaire vers l'autre nœud à des fins de maintenance.

Test 4 - Conditions préalables

  • Un cluster fonctionnel RHEL HA Add-On à deux nœuds pour la réplication du système HANA.
  • Les deux nœuds sont actifs.
  • Le cluster est démarré sur NODE1 et NODE2.
  • La ressource de cluster SAPHana_${SID}_${INSTNO} est configurée avec AUTOMATED_REGISTER=true.
  • Vérifiez l'état de la réplication du système SAP HANA:
    • La base de données primaire SAP HANA est exécutée sur NODE1
    • La base de données secondaire SAP HANA fonctionne sur NODE2
    • La réplication du système HANA est activée et synchronisée

Test 4 - Procédure de test

Déplacez SAP HANA primary vers un autre nœud en utilisant la commande pcs resource move.

Sur NODE1, exécutez la commande suivante.

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

Test 4 - Comportement attendu

  • Le cluster crée des contraintes de localisation pour déplacer la ressource.
  • Le cluster déclenche une prise en charge de la base de données HANA secondaire.
  • Si une application, telle que SAP NetWeaver, est connectée à la base de données d'un locataire de SAP HANA, l'application se reconnecte automatiquement à la nouvelle base de données primaire.

Test 4 - Procédure de récupération

Les contraintes de localisation créées automatiquement doivent être supprimées pour permettre le basculement automatique à l'avenir.

Attendez que l'instance HANA primaire soit active et supprimez les contraintes.

Le cluster enregistre et démarre la base de données HANA en tant que nouvelle instance secondaire.

Sur NODE1, exécutez la commande suivante.

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