Vérifier l'accès en utilisant une connexion explicite en lecture seule

Vérifiez la connexion à l'instance secondaire en utilisant une connexion explicite en lecture seule.

Sur un nœud de cluster, exécutez la commande suivante.

sudo -i -u ${sid}adm -- \
    hdbsql -n $VIP_SECONDARY -i $INSTNO -d SYSTEMDB -u SYSTEM \
      "select * from m_host_information \
      where key = 'net_hostnames' or key = 'net_ip_addresses'"

L'exemple de sortie montre que l'instruction s'est exécutée sur le site secondaire SAP HANA.

HOST,KEY,VALUE
"cl-h4s-2","net_hostnames","cl-h4s-2"
"cl-h4s-2","net_ip_addresses","10.40.10.132,10.40.10.211"
2 rows selected (overall time 7518 usec; server time 291 usec)

Vérification de l'accès à l'aide d'un routage de déclarations basé sur des indices

Vérifiez la connexion à l'instance secondaire en utilisant le routage de déclaration basé sur des indices.

1. Effectuer un test de connexion en utilisant une connexion explicite au primaire SAP HANA sans indice SQL.

   Sur un nœud de cluster, exécutez la commande suivante.

   sudo -i -u ${sid}adm -- \
       hdbsql -n $VIP_PRIMARY -i $INSTNO -d SYSTEMDB -u SYSTEM \
         "select * from m_host_information \
         where key = 'net_hostnames' or key = 'net_ip_addresses'"
   

   L'exemple de sortie montre que l'instruction s'est exécutée sur le primaire SAP HANA.

     HOST,KEY,VALUE
   "cl-h4s-1","net_hostnames","cl-h4s-1"
   "cl-h4s-1","net_ip_addresses","10.40.10.162,10.40.10.201"
   2 rows selected (overall time 5239 usec; server time 361 usec)
   

2. Exécutez un test de connexion en utilisant une connexion explicite au primaire SAP HANA et à l'indice SQL result_lag.

   sudo -i -u ${sid}adm -- \
       hdbsql -n $VIP_PRIMARY -i $INSTNO -d SYSTEMDB -u SYSTEM \
         "select * from m_host_information \
         where key = 'net_hostnames' or key = 'net_ip_addresses' \
         with hint(result_lag('hana_sr'))"
   

   L'exemple de sortie montre que l'instruction s'est exécutée sur le site secondaire SAP HANA.

   HOST,KEY,VALUE
   "cl-h4s-2","net_hostnames","cl-h4s-2"
   "cl-h4s-2","net_ip_addresses","10.40.10.132,10.40.10.211"
   2 rows selected (overall time 40.722 msec; server time 16.428 msec)
   

Test1- Description

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

Test1- Conditions préalables

• Un cluster fonctionnel RHEL HA Add-On à deux nœuds pour la réplication du système SAP 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
  • SAP HANA La réplication du système est activée et synchronisée

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

Test1- Comportement attendu

• SAP HANA l'instance primaire sur NODE1 tombe en panne.
• Le cluster détecte la base de données primaire SAP HANA arrêtée et marque la ressource comme failed.
• Le cluster promeut la base de données secondaire SAP HANA sur NODE2 pour qu'elle devienne la 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.
• Après la reprise, l'instance secondaire SAP HANA est indisponible et l'adresse IP virtuelle secondaire reste 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.

Test1- Procédure de récupération

Comme la ressource du cluster SAPHana_${SID}_${INSTNO} est configurée avec AUTOMATED_REGISTER=false, le cluster ne redémarre pas la base de données SAP HANA défaillante et ne l'enregistre pas contre le nouveau 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 -- \
    hdbnsutil -sr_register \
      --name=${DC1} \
      --remoteHost=${NODE2} \
      --remoteInstance=00 \
      --replicationMode=sync \
      --operationMode=logreplay_readaccess \
      --online

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

sudo -i -u ${sid}adm -- \
    hdbnsutil -sr_state

Sur un nœud de cluster, exécutez la commande suivante pour actualiser la ressource de cluster. Cette commande permet de démarrer l'instance secondaire.

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

Lorsque le secondaire atteint l'état synchronisé (SOK), l'adresse IP virtuelle du secondaire passe à NODE1.

Sur un nœud de la grappe, exécutez la commande suivante pour vérifier l'état de la grappe.

pcs status --full

Test2- Description

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

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

Vérifiez le paramètre AUTOMATED_REGISTER dans la configuration de la ressource.

pcs resource config SAPHana_${SID}_${INSTNO} | grep Attributes

Test2- Conditions préalables

• Un cluster fonctionnel RHEL HA Add-On à deux nœuds pour la réplication du système SAP 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
  • SAP HANA La réplication du système est activée et synchronisée
  • L'adresse IP virtuelle secondaire est active sur NODE1

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

Test2- 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 secondaire SAP HANA sur NODE1 pour qu'elle devienne la nouvelle base de données primaire.
• Le cluster acquiert l'adresse IP virtuelle sur NODE1 sur le nouveau primaire.
• Après la reprise, l'instance secondaire SAP HANA est indisponible et l'adresse IP virtuelle secondaire reste sur NODE1.
• 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.

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

En tant que ressource de cluster, SAPHana_${SID}_${INSTNO} est configuré 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. Lorsque le secondaire atteint l'état synchronisé (SOK), l'adresse IP virtuelle du secondaire passe à NODE2.

Test3- Description

Simuler une panne de la base de données secondaire SAP HANA.

Test3- Conditions préalables

• Un cluster fonctionnel RHEL HA Add-On à deux nœuds pour la réplication du système SAP 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
  • SAP HANA La réplication du système est activée et synchronisée
  • L'adresse IP virtuelle secondaire est active sur NODE2

Test3- Procédure de test

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

Test3- Comportement attendu

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

Test3- Procédure de récupération

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

Sur un nœud du cluster, exécutez les commandes suivantes.

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

pcs status --full

Test4- Description

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

Test4- Conditions préalables

• Un cluster fonctionnel RHEL HA Add-On à deux nœuds pour la réplication du système SAP 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
  • SAP HANA La réplication du système est activée et synchronisée
  • L'adresse IP virtuelle secondaire est active sur NODE2

Test4- Procédure de test

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

Sur un nœud de cluster, exécutez la commande suivante.

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

Exemple de sortie :

# pcs resource move SAPHana_H4S_00-clone
Warning: Creating location constraint 'cli-ban-SAPHana_H4S_00-clone-on-cl-hdb-1' with a score of -INFINITY for resource SAPHana_H4S_00-clone on cl-hdb-1.
        This will prevent SAPHana_H4S_00-clone from running on cl-hdb-1 until the constraint is removed
        This will be the case even if cl-hdb-1 is the last node in the cluster

Test4- Comportement attendu

• Le cluster crée des contraintes de localisation pour déplacer la ressource.
• Le cluster déclenche une reprise sur la base de données secondaire SAP HANA.
• L'adresse IP virtuelle secondaire reste 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.

Test4- 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 primaire SAP HANA soit active et supprimez les contraintes.

Sur un nœud de cluster, exécutez la commande suivante.

pcs constraint

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

pcs constraint

Le cluster enregistre et démarre la base de données SAP HANA en tant que nouvelle instance secondaire. Une fois que l'état de réplication du système est à nouveau synchronisé (SOK), le cluster déplace l'adresse IP virtuelle secondaire vers NODE1.

pcs status --full