Share via


Ajouter un troisième site HSR à un cluster HANA Pacemaker

Cet article décrit les exigences et la configuration d’un troisième site de réplication HANA pour compléter un cluster Pacemaker existant. Les spécificités SUSE Linux Enterprise Server (SLES) et RedHat Enterprise Linux (RHEL) sont couvertes.

Vue d’ensemble

SAP HANA prend en charge la réplication système (HSR) avec plus de deux sites connectés. Vous pouvez ajouter un troisième site à une paire HSR existante, gérée par Pacemaker dans une configuration hautement disponible. Vous pouvez déployer le troisième site dans une deuxième région Azure à des fins de récupération d’urgence.

Pacemaker et l’agent de ressources de cluster HANA gèrent les deux premiers sites. Le cluster Pacemaker ne contrôle pas le troisième site.

SAP HANA prend en charge un troisième site de réplication système en deux modes :

  • Multicible réplique les modifications de données du système principal vers plusieurs systèmes cibles. Le troisième site est connecté à la réplication principale dans une topologie en étoile.
  • Multiniveau est une réplication à deux niveaux. Configuration en cascade ou chaînée de trois niveaux HANA différents. Le troisième site se connecte au site secondaire.

Pour plus d’informations conceptuelles sur le HSR HANA au sein d’une région et dans différentes régions, consultez la disponibilité de SAP HANA dans les régions Azure.

Conditions préalables pour SLES

Les exigences d’un troisième site HSR sont différentes pour le scale-up HANA et le scale-out HANA.

Remarque

Les exigences décrites dans cet article sont valides uniquement pour un paysage avec Pacemaker. Sans Pacemaker, les exigences de version de SAP HANA s’appliquent au mode de réplication choisi. Pacemaker et l’agent de ressources de cluster HANA gèrent uniquement deux sites. Le troisième site HSR n’est pas contrôlé par le cluster Pacemaker.

  • Scale-up et scale-out: SAP HANA SPS 04 ou version ultérieure est nécessaire pour utiliser un HSR multicible avec un cluster Pacemaker.
  • Scale-up et scale-out: maximum d’une réplication système SAP HANA connectée à partir de l’extérieur du cluster Linux.
  • Scale-out HANA uniquement: SLES 15 SP1 ou version ultérieure.
  • Scale-out HANA uniquement: package de système d’exploitation SAPHanaSR-ScaleOut version 0.180 ou ultérieure.
  • Scale-out HANA uniquement: raccordement SAP HANA à haute disponibilité (HA) SAPHanaSrMultiTarget en cours d’utilisation. Le raccordement HANA à haute disponibilité SAPHanaSR en préversion ne prend pas en charge le multicible pour le scale-out.

Conditions préalables pour RHEL

Les exigences d’un troisième site HSR sont différentes pour le scale-up HANA et le scale-out HANA.

Remarque

Les exigences décrites dans cet article sont valides uniquement pour un paysage avec Pacemaker. Sans Pacemaker, les exigences de version de SAP HANA s’appliquent au mode de réplication choisi. Pacemaker et l’agent de ressources de cluster HANA gèrent uniquement deux sites. Le troisième site HSR n’est pas contrôlé par le cluster Pacemaker.

  • Scale-up HANA uniquement: consultez les stratégies de prise en charge des clusters à haute disponibilité RHEL de RedHat pour plus d’informations sur le système d’exploitation minimal, SAP HANA, et la version des agents de ressources de cluster.
  • Scale-out HANA uniquement: la réplication multicible HANA n’est pas prise en charge sur Azure avec un cluster Pacemaker.

Scale-up HANA : ajouter la réplication du système multicible HANA à des fins de récupération d’urgence

Avec le raccordement à haute disponibilité SAP HANA SAPHanaSR pour SLES et RHEL, vous pouvez ajouter un troisième nœud à des fins de récupération d’urgence. L’environnement Pacemaker est conscient d’une configuration de récupération d’urgence multicible HANA.

L’échec du troisième nœud ne déclenche aucune action de cluster. Le cluster détecte l’état de réplication des sites connectés et l’attribut surveillé pour le troisième site peut passer de l’état SOK à l’état SFAIL. Les tests de prise en charge sur le troisième site/site de récupération d’urgence ou l’exécution de votre processus d’exercice de récupération d’urgence doivent d’abord placer les ressources du cluster en mode maintenance pour empêcher toute action de cluster non souhaitée.

L’exemple suivant montre un système de réplication système multicible. Pour plus d’informations, consultez la documentation SAP. Diagram that shows an example of a HANA scale-up multitarget system replication system.

  1. Déployez des ressources Azure pour le troisième nœud. Selon vos besoins, vous pouvez utiliser une autre région Azure à des fins de récupération d’urgence.

    Les étapes requises pour le troisième site sont similaires aux machines virtuelles pour le cluster de scale-up HANA. Le troisième site utilise l’infrastructure Azure. La version du système d’exploitation et de HANA correspond au cluster Pacemaker existant, avec les exceptions suivantes :

    • Aucun équilibreur de charge n’est déployé pour le troisième site. Il n’existe aucune intégration avec l’équilibreur de charge de cluster existant pour la machine virtuelle du troisième site.
    • N’installez pas les packages de système d’exploitation SAPHanaSR, SAPHanaSR-doc et le modèle de package de système d’exploitation ha_sles sur la machine virtuelle du troisième site.
    • Aucune intégration au cluster pour les ressources de machine virtuelle ou HANA du troisième site.
    • Aucune configuration de raccordement à haute disponibilité HANA pour le troisième site dans global.ini.
  2. Installez SAP HANA sur le troisième nœud.

    Le même SID HANA et le même numéro d’installation HANA doivent être utilisés pour le troisième site.

  3. Une fois SAP HANA installé sur le troisième site et en cours d’exécution, inscrivez le troisième site auprès du site principal.

    L’exemple suivant utilise SITE-DR comme nom du troisième site.

    # Execute on the third site 
    su - hn1adm
    # Register the HANA third site to the primary. Switch --online will shutdown the HANA instance on third site.
    hdbnsutil -sr_register --name=SITE-DR --remoteHost=hn1-db-0 --remoteInstance=03 --replicationMode=async --online
    
  4. Vérifiez que la réplication du système HANA affiche le site secondaire et le troisième site.

    # Verify HANA HSR is in sync, execute on primary
    sudo su - hn1adm -c "python /usr/sap/HN1/HDB03/exe/python_support/systemReplicationStatus.py"
    
  5. Vérifiez l’attribut SAPHanaSR du troisième site. SITE-DR doit apparaître avec l’état SOK dans la section Sites.

    # Check SAPHanaSR attribute on any cluster managed host (first or second site)
    sudo SAPHanaSR-showAttr
    # Example result
    # Global cib-time                 maintenance
    # --------------------------------------------
    # global Tue Feb 21 19:28:21 2023 false
    # 
    # Sites     srHook
    # -----------------
    # HN1-SITE1 PRIM
    # HN1-SITE2 SOK
    # SITE-DR   SOK
    

    Le cluster détecte l’état de réplication des sites connectés. Les attributs surveillés peuvent passer de SOK à SFAIL. Aucune action de cluster n’est effectuée si la réplication vers le site de récupération d’urgence échoue.

Scale-out HANA : ajouter la réplication du système multicible HANA à des fins de récupération d’urgence

Avec le fournisseur SAP HANA HA SAPHanaSrMultiTarget, vous pouvez ajouter un troisième site de scale-out HANA. Ce troisième site est souvent utilisé pour la récupération d’urgence dans une autre région Azure. L’environnement Pacemaker est conscient d’une configuration de récupération d’urgence multicible HANA. Cette section s’applique uniquement aux systèmes exécutant Pacemaker sur SUSE. Pour plus d’informations, consultez la section « Prérequis » de ce document.

L’échec du troisième nœud ne déclenche aucune action de cluster. Le cluster détecte l’état de réplication des sites connectés et l’attribut surveillé pour le troisième site peut passer de l’état SOK à l’état SFAIL. Les tests de prise en charge sur le troisième site/site de récupération d’urgence ou l’exécution de votre processus d’exercice de récupération d’urgence doivent d’abord placer les ressources du cluster en mode maintenance pour empêcher toute action de cluster non souhaitée.

L’exemple suivant montre un système de réplication système multicible. Pour plus d’informations, consultez la documentation SAP. Diagram that shows an example of a HANA scale-out multitarget system replication system.

  1. Déployez des ressources Azure pour le troisième site. Selon vos besoins, vous pouvez utiliser une autre région Azure à des fins de récupération d’urgence.

    Les étapes requises pour le scale-out HANA sur le troisième site reflètent les étapes de déploiement du cluster de scale-out HANA. Le troisième site utilise l’infrastructure Azure, le système d’exploitation et les étapes d’installation de HANA pour SITE1 du cluster scale-out, avec les exceptions suivantes :

    • Aucun équilibreur de charge n’est déployé pour le troisième site. Il n’existe aucune intégration avec l’équilibreur de charge de cluster existant pour les machines virtuelles du troisième site.
    • N’installez pas les packages de système d’exploitation SAPHanaSR-ScaleOut, SAPHanaSR-ScaleOut-doc et le modèle de package de système d’exploitation ha_sles sur les machines virtuelles du troisième site.
    • Aucune machine virtuelle de fabricant majoritaire pour le troisième site, car il n’y a pas d’intégration de cluster.
    • Créez le volume NFS /hana/shared pour l’utilisation exclusive du troisième site.
    • Aucune intégration au cluster pour les machines virtuelles ou les ressources HANA du troisième site.
    • Aucune configuration de raccordement à haute disponibilité HANA pour le troisième site dans global.ini.

    Vous devez utiliser le même SID HANA et le même numéro d’installation HANA pour le troisième site.

  2. Une fois le scale-out SAP HANA installé sur le troisième site et en cours d’exécution, inscrivez le troisième site auprès du site principal.

    L’exemple suivant utilise SITE-DR comme nom du troisième site.

    # Execute on the third site 
    su - hn1adm
    # Register the HANA third site to the primary. Switch --online will shutdown the HANA instance on third site.
    hdbnsutil -sr_register --name=SITE-DR --remoteHost=hana-s1-db1 --remoteInstance=03 --replicationMode=async --online
    
  3. Vérifiez que la réplication du système HANA affiche le site secondaire et le troisième site.

    # Verify HANA HSR is in sync, execute on primary
    sudo su - hn1adm -c "python /usr/sap/HN1/HDB03/exe/python_support/systemReplicationStatus.py"
    
  4. Vérifiez l’attribut SAPHanaSR du troisième site. SITE-DR doit apparaître avec l’état SOK dans la section Sites.

    # Check SAPHanaSR attribute on any cluster managed host (first or second site)
    sudo SAPHanaSR-showAttr
    # Expected result
    # Global cib-time                 maintenance prim  sec sync_state upd
    # ---------------------------------------------------------------------
    # HN1    Fri Jan 27 10:38:46 2023 false       HANA_S1 -   SOK        ok
    # 
    # Sites     lpt        lss mns         srHook srr
    # ------------------------------------------------
    # SITE-DR                              SOK
    # HANA_S1   1674815869 4   hana-s1-db1 PRIM   P
    # HANA_S2   30         4   hana-s2-db1 SOK    S
    

    Le cluster détecte l’état de réplication des sites connectés. L’attribut surveillé peut passer de SOK à SFAIL. Aucune action de cluster n’est effectuée si la réplication vers le site de récupération d’urgence échoue.

Inscription automatique du troisième site

Lors d’un événement de prise de contrôle planifié ou non planifié entre les deux sites de cluster Pacemaker, HSR vers le troisième site est également interrompu. Pacemaker ne modifie pas la réplication HANA vers le troisième site.

SAP fournit depuis le paramètre HANA 2 SPS 04 register_secondaries_on_takeover. Une fois le paramètre défini sur la valeur true, après la prise de contrôle du HSR entre les sites de cluster 1 et 2, HANA inscrit automatiquement le troisième site sur le nouveau serveur principal pour conserver automatiquement une configuration HSR multicible. Configurez le paramètre HANA register_secondaries_on_takeover = true configuré dans le bloc [system_replication] de global.ini sur les deux sites SAP HANA dans le cluster Linux. SITE1 et SITE2 ont besoin du paramètre dans le fichier de configuration HANA global.ini respectif. Le paramètre peut également être utilisé en dehors d’un cluster Pacemaker.

Pour HSR multiniveau, aucune inscription SAP HANA automatique du troisième site n’existe. Vous devez inscrire manuellement le troisième site sur le site secondaire actuel pour conserver la chaîne de réplication HSR pour multiniveau.

Diagram flow that shows how a HANA autoregistration works with a third site during a takeover.

Étapes suivantes