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.
- Installez et configurez le cluster de modules complémentaires RHEL HA conformément à la section Implémentation d'un cluster de modules complémentaires Red Hat Enterprise Linux High Availability.
- Configurez et vérifiez les clôtures comme décrit dans le document précédent.
- 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
-
Arrêter le cluster.
Sur NODE1, exécutez la commande suivante.
pcs cluster stop --all
-
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
-
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
-
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
-
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é.
-
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.
-
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 si les nœuds de cluster sont exécutés dans un espace de travail unique Power Virtual Server
- Création d'une ressource de cluster à adresse IP virtuelle dans un environnement de région multizone si les nœuds de cluster s'exécutent dans des espaces de travail Power Virtual Server distincts
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".
-
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
-
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.
-
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
-
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é surstop
, le réglage par défaut étantignore
. Vous pouvez définir les paramètresstop_timeout
(par défaut :20
secondes) etkill_signal
(par défaut :9
). -
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
-
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é avecAUTOMATED_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 avecAUTOMATED_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 avecAUTOMATED_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