Configuration de la réplication du système SAP HANA

À partir de SAP HANA 2.0, des étapes de configuration supplémentaires sont requises pour configurer la réplication du système SAP HANA, car les connexions de réplication utilisent désormais l'authentification par certificat.

La réplication du système avec SAP HANA 2.0 requiert une authentification pour les canaux de données et d'expédition des journaux. L'authentification est effectuée à l'aide des certificats dans le magasin PKI SSFS du système. Une étape de configuration manuelle supplémentaire est requise pour échanger des certificats dans le stockage SSFS PKI du système entre les sites principaux et secondaires. Pour plus d'informations, voir la note SAP : 2369981.

Pour plus d'informations, voir la note SAP 2369981 - Étapes de configuration requises pour l'authentification avec la réplication du système HANA.

Les fichiers copiés deviennent actifs lors du redémarrage du système. Par conséquent, il est recommandé de copier les fichiers lorsque le système SAP HANA secondaire est hors ligne, par exemple, avant l'enregistrement.

Il existe deux façons de configurer la réplication du système SAP HANA dans le cockpit SAP HANA :

• Activez le système principal, puis enregistrez le système secondaire du système principal en une seule étape de configuration.

• Activez la réplication du système sur le système principal, puis enregistrez le système secondaire dans une deuxième étape.

Les étapes de configuration du système principal et du système secondaire à l'aide du cockpit SAP HANA sont décrites dans la figure « Activer la réplication du système ».

Vous avez activé la réplication du système et enregistré le système secondaire avec le système principal. Le système secondaire fonctionne en mode de récupération. Tous les services système secondaires communiquent en permanence avec leurs homologues principaux, répliquent et conservent les données et les journaux, et chargent les données dans la mémoire. Cependant, le système secondaire n'accepte pas les connexions SQL.

Pour configurer la réplication du système SAP HANA entre deux systèmes SAP HANA identiques, vous devez d'abord activer la réplication du système sur le système principal, puis enregistrer le système secondaire.

Il est également possible de configurer la réplication du système SAP HANA avec l'outil de ligne de commande hdbnsutil comme <sid>adm au niveau du système d'exploitation. L'outil de ligne de commande peut faire partie d'un script qui exécute d'autres étapes au-delà de la réplication du système.

1. Créez une sauvegarde des données du système primaire.

2. Activez le système principal et attribuez-lui un nom logique :

   hdbnsutil -sr_enable --name=PRIMARY

3. Arrêter le système secondaire :

   sapcontrol –nr <instance_number> -function StopSystem HDB

4. Enregistrez le système secondaire (sélectionnez le mode de réplication et le mode d'exploitation) :

   Code Snippet

   Copy codeSwitch to dark mode

   12345
   hdbnsutil -sr_register --remoteHost=<primary hostname> 
   --remoteInstance=<instance number> 
   --replicationMode=<sync|syncmem|async> 
   --operationMode=<delta_datashipping|logreplay> 
   --name=SECONDARY

5. Lancez le système secondaire pour lancer la réplication :

   sapcontrol –nr <instance_number> -function StartSystem HDB

Une fois le système secondaire lancé, le processus de réplication démarre automatiquement.

Lorsqu'elle est activée, l'option de synchronisation complète pour la réplication du système SAP HANA garantit qu'une mémoire tampon de journal est envoyée au système secondaire avant qu'un commit n'ait lieu sur le système principal local.

L'option de synchronisation complète peut être activée pour la réplication SYNC (c'est-à-dire pas pour SYNCMEM). Lorsque l'option de synchronisation complète est activée, le traitement des transactions s'effectue sur les blocs primaires. Si le système secondaire n'est pas connecté actuellement, les tampons de journal nouvellement créés ne peuvent pas être envoyés au site secondaire. Ce comportement garantit qu'aucune transaction ne peut être validée localement sans envoyer les tampons de journal au site secondaire. L'option de synchronisation complète peut être activée et désactivée à l'aide de la commande : hdbnsutil -sr_fullsync --enable|--disable

Cette commande modifie en conséquence le paramètre enable_full_sync dans la section system_Replication du fichier global.ini. Cependant, dans un système en cours d'exécution, la synchronisation complète ne devient pas active immédiatement. Cela permet d'éviter que le système bloque les transactions immédiatement lorsque le paramètre est défini sur Vrai. Au lieu de cela, la synchronisation complète doit d'abord être activée par l'administrateur. Dans un deuxième temps, il est activé en interne lorsque le secondaire est connecté et devient ACTIF.

Dans la vue système M_SERVICE_REPLICATION, le paramétrage de l'option de synchronisation complète peut être affiché dans à l'aide de SQL.

L'option de synchronisation complète peut avoir les valeurs suivantes :

• DÉSACTIVÉ : la synchronisation complète n'est pas du tout configurée. Le paramètre enable_full_sync = false dans la section system_replication du fichier global.ini.

• ACTIVÉ : la synchronisation complète est configurée, mais elle n'est pas encore active. Les transactions ne bloquent donc pas ce statut. Pour devenir actif, le secondaire doit se connecter et REPLICATION_STATUS doit être ACTIF.

• ACTIF : le mode de synchronisation complète est configuré et actif. Si la connexion réseau à un secondaire connecté est fermée, les transactions sur le bloc latéral principal dans cet état.

Si la synchronisation complète est activée lorsqu'une secondaire active est actuellement connectée, FULL_SYNC est immédiatement défini sur ACTIF.

La réplication du système SAP HANA prend en charge un certain nombre de méthodes de compression pour l'envoi de journaux et de données.

Les types de compression suivants sont pris en charge pour le journal et l'envoi de données :

Journalisation

Compression de la fin de la mémoire tampon du journal (par défaut)

Compression du contenu de la mémoire tampon du journal

Data

Compression de page de données

La compression de la queue du tampon de journal est activée par défaut. Tous les tampons de journal sont alignés sur les limites de 4 Ko par une entrée de remplissage. Avec la compression de la queue du tampon journal, l'entrée de remplissage est coupée de la mémoire tampon avant de l'envoyer sur le réseau et ajoutée à nouveau lorsque la mémoire tampon a atteint le site secondaire. Ainsi, seule la taille de la mémoire tampon nette est transférée au site secondaire.

La taille de l'entrée de remplissage est inférieure à 4 Ko. Il s'agit de la réduction maximale de la taille par tampon de journal envoyé. Si la taille des tampons de journal est assez importante, le taux de compression est assez limité.

La compression de la mémoire tampon du journal et du contenu de la page peut être activée par le paramétrage.

Les tampons de journaux et les pages de données envoyées au site secondaire peuvent être compressés à l'aide d'un algorithme de compression sans perte (LZ4). Par défaut, la compression du contenu est désactivée. Vous pouvez l'activer en définissant les paramètres de configuration suivants sur le site secondaire dans la section system_replication du fichier global.ini.

La compression du journal et des données est particulièrement utile lorsque la réplication du système est utilisée sur de longues distances, par exemple, à l'aide du mode de réplication ASYNC.

L'algorithme de compression open source LZ4 a été sélectionné en raison de sa vitesse et de ses taux de compression, et de l'avance de temps relativement faible introduite pour la compression/décompression. La compression du contenu de la mémoire tampon du journal fonctionne également en combinaison avec la compression finale de la mémoire tampon du journal. Par conséquent, seule la partie du contenu de la mémoire tampon du journal est comprimée, sans tenir compte de l'entrée de remplissage.

L'activation de la compression réduit la bande passante réseau requise, mais en même temps, il y a des frais généraux du processeur pour compresser et décompresser les informations. L'utilisation de la compression est particulièrement utile dans le cas de longues distances entre sites primaires et secondaires ou dans le cas de limitations de bande passante.

Pour surveiller la réplication du système SAP HANA, vous pouvez utiliser la vignette Réplication du système dans le cockpit SAP HANA.

Si la réplication du système est configurée, la vignette Réplication du système fournit des informations sur le type d'infrastructure (à deux ou trois niveaux), le mode de réplication entre le primaire et le secondaire de niveau 2, le mode d'exploitation et le statut de réplication global.

La vignette Réplication du système affiche les états suivants d'un seul coup d'œil :

• Non configuré (ce qui signifie que la réplication du système n'est pas configurée)

• Tous les services sont actifs et synchronisés.

• Tous les services sont actifs, mais pas encore synchronisés.

• Erreurs dans la réplication

Pour vérifier le statut de la réplication en détail, sélectionnez la vignette Réplication du système. L'écran de synthèse Réplication du système affiche une représentation graphique de l'infrastructure, de la configuration et du statut de réplication du système. En haut, la "chaîne" de systèmes avec leurs modes de réplication est affichée, contenant des informations supplémentaires sur les sites et les connexions réseau entre eux.

L'écran Réplication du système fournit les informations suivantes :

• Le nom et le rôle du système, ainsi que le mode d'exploitation sélectionné.

  Pour les modes d'exploitation logreplay et logreplay_readaccess, une estimation de la période de rétention est également affichée. Il s'agit d'une estimation du temps restant avant que le système primaire ne commence à écraser les segments de journal marqués RetainedFree, et une expédition complète des données devient nécessaire pour que les systèmes primaire et secondaire soient de nouveau synchronisés après une situation de déconnexion. Le temps plein estimé du journal est une estimation du temps restant avant que le système primaire n'exécute un journal plein. La valeur affichée dans l'en-tête indique la situation dans laquelle le système a pu s'exécuter en premier : conservation du journal ou journal complet.

• Si les ports SQL du système secondaire sont ouverts pour l'accès en lecture.

• Mode de réplication utilisé entre les systèmes.

• Le temps moyen actuel d'envoi du journal de restauration et la taille moyenne des tampons de journal redo expédiés.

  Cela décrit le temps moyen nécessaire pour envoyer des tampons de redo log au site secondaire, sur la base des mesures effectuées au cours des dernières 24 heures.

En outre, des informations détaillées sur la réplication du système sont fournies dans les onglets illustrés dans la figure Détails du statut d'un service spécifique.

La sélection d'une ligne dans l'onglet Services répliqués affiche les détails du service correspondant regroupé par thème, comme dans l'exemple suivant pour le serveur d'index. Comme ces informations sont contextuelles, vous ne voyez que les informations requises pour ce système. Par conséquent, comme cet exemple de système est exécuté en mode d'exploitation de lecture, aucune information sur l'envoi de données delta n'est affichée ici. Cependant, les informations contextuelles sur le délai de reproduction du journal sont affichées. Le delta entre la dernière position du journal et la position du journal de lecture répétée indique le niveau de retard de la reprise du journal sur le secondaire.

Le cockpit SAP HANA fait la distinction entre un système primaire et un système secondaire. Dans le cockpit SAP HANA du système secondaire, la vignette Réplication du système fournit une synthèse initiale de l'état de ce site. À partir de la Synthèse de réplication du système, vous pouvez lancer une reprise.

Les scripts Python se trouvent dans le répertoire $DIR_INSTANCE/exe/python_support.

Vous pouvez également collecter des informations sur le statut global des sites et la réplication du système à l'aide de scripts Python.

Le script landcapeHostConfiguration.py affiche le statut du système primaire :

• SAP HANA est correct.

• SAP HANA sera OK après un basculement automatique de l'hôte, par exemple.

• Le nombre d'instances démarrées est insuffisant et une reprise serait utile.

Le script fournit un statut global et un code retour pour correspondre au statut global de l'hôte.

Une reprise n'est recommandée que lorsque le code retour du script est 1 (erreur).

1234567
<sid>adm># python $DIR_INSTANCE/exe/python_support/landscapeHostConfiguration.py
| Host  | Host   | Host   |    ...    | NameServer | NameServer  | ...
|       | Active | Status |           | Config Role| Actual Role |
| ----- | ------ | ------ | --------- | ---------- | ----------- | ------
| host1 | yes    | ok     |    ...    | master 1   | master      | ...
| host2 | yes    | ok     |    ...    | master 2   | slave       | ...
overall host status: ok

Les statuts d'hôte suivants sont possibles :

• OK : le système est OK.

• AVERTISSEMENT : un basculement automatique de l'hôte vers un hôte de secours a lieu.

• INFORMATIONS : l'infrastructure est entièrement fonctionnelle, mais le rôle actuel (réel) de l'hôte diffère du rôle configuré.

• ERREUR : Il n'y a pas assez d'hôtes actifs.

Le script systemReplicationStatus.py affiche le statut de la réplication du système.

L'utilisation de systemReplicationStatus.py a l'avantage de montrer si les systèmes secondaires sont synchronisés ou non. Cela fournit plus de confiance si une reprise est justifiée car si la réplication du système n'a jamais été synchronisée ou est obsolète, une perte de données inattendue peut survenir.

Exemple :

123456789101112131415161718
h10adm@wdflbmt7346:/> python $DIR_INSTANCE/exe/python_support/systemReplicationStatus.py
| Database | Host        | Service Name | Site Name   | Secondary   | Secondary     | Replication |
|          |             |              |             | Host        | Site Name     | Status      |
| -------- | ----------- | ------------ | ----------- | ----------- | ------------- | ----------- |
| SYSTEMDB | wdflbmt7346 | nameserver   | PrimarySite | wdflbmt7347 | SecondarySite | ACTIVE      |
| H10      | wdflbmt7346 | xsengine     | PrimarySite | wdflbmt7347 | SecondarySite | ACTIVE      |
| H10      | wdflbmt7346 | indexserver  | PrimarySite | wdflbmt7347 | SecondarySite | ACTIVE      |

status system replication site "2": ACTIVE
overall system replication status: ACTIVE

Local System Replication State
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

mode: PRIMARY
site id: 1
site name: PrimarySite

Le paramètre supplémentaire systemReplicationStatus.py --localhost limite l'exécution du script Python à l'hôte sur lequel il est exécuté.

Le script fournit les codes retour suivants :

• 10 : aucune réplication du système

• 11 : Erreur

• 12 : Inconnu

• 13 : Initialisation

• 14 : Synchronisation

• 15 : Actif

Vous pouvez également obtenir des informations spécifiques à la réplication du système directement à partir des vues système.

Des alertes spécifiques sont émises par le système principal pour vous avertir de problèmes potentiels.

Les alertes Connexion fermée et Non-concordance des paramètres de configuration sont déclenchées lorsqu'une connexion de réplication système est fermée ou qu'il existe une incohérence de paramètres de configuration de réplication système.

L'alerte Backlog Logreplay est déclenchée lorsque la réplication du système augmente. Dans ce cas, logreplay est retardé sur le site secondaire, provoquant un temps de reprise plus long.

Pour identifier la raison de l'augmentation de la réplication du système, vérifiez le statut des services dans le système secondaire. Pour obtenir plus d'informations, suivez le site secondaire. Les causes possibles de l'augmentation de la réplication du système peuvent être, par exemple, un rejeu de journal lent ou non fonctionnel ou un service non en cours d'exécution sur le système secondaire.

L'alerte Augmentation de la réserve de travail d'expédition du journal est déclenchée lorsque le journal de réplication du système augmente le retard d'expédition. Dans ce cas, l'envoi du journal au système secondaire est retardé ou ne fonctionne pas correctement, ce qui entraîne une perte de données dans le système secondaire dans le cas où une reprise est exécutée.

Pour identifier le motif de l'augmentation du retard d'expédition du journal de réplication du système, vérifiez le statut du système secondaire. Les causes possibles de l'augmentation du délai d'expédition du journal de réplication du système peuvent être un ralentissement des performances du réseau, des problèmes de connexion ou d'autres problèmes internes (par exemple, dans les modes de réplication synchro ou syncmem).

Les paramètres de base de données doivent être identiques dans les systèmes primaire et secondaire et sont contrôlés automatiquement. Le contrôleur des paramètres de configuration signale les différences entre les systèmes primaire, secondaire et secondaire de niveau 3. Dans ce cas, le contrôleur de paramètres génère une alerte.

Lorsque la réplication des paramètres est activée, toutes les modifications apportées au site primaire sont automatiquement répliquées sur les sites secondaires. Si la réplication de ce paramètre n'est pas activée, les modifications doivent être dupliquées manuellement dans l'autre système.

La réplication des paramètres est désactivée par défaut. Il peut être activé et désactivé sur le site principal à l'aide du paramètre suivant :

[inifile_checker]/replicate = true | false

Le contrôleur de paramètres est activé par défaut. Il peut être activé et désactivé sur le site principal à l'aide du paramètre suivant :

[inifile_checker]/enable = true | false

Certains paramètres peuvent avoir des paramètres différents sur les sites principal et secondaire. Un exemple est le paramètre global_allocation_limit , où le secondaire est utilisé pour d'autres systèmes. En ajoutant ces paramètres à la liste d'exclusion, vous pouvez les exclure du contrôle.