Lors d'une reprise, vous passez votre système actif du système primaire actuel au système secondaire.
Si votre centre de données principal n'est pas disponible, en raison d'un sinistre ou d'un temps d'arrêt planifié par exemple, et qu'une décision a été prise de basculer vers le centre de données secondaire, vous pouvez effectuer une reprise dans votre système secondaire.
Outre les outils qui peuvent être utilisés pour surveiller le statut système global lorsque la réplication du système est activée, un script est fourni avec SAP HANA, ce qui vous aide à décider quand une reprise doit être effectuée.
Nous vous recommandons d'utiliser des outils externes tiers pour vérifier si les hôtes, le réseau et le centre de données sont toujours disponibles.
En outre, un script appelé landscapeHostConfiguration.py est fourni pour que SAP HANA puisse communiquer le statut du système primaire. Il peut communiquer les statuts suivants :
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.
Une reprise n'est recommandée que lorsque le code retour du script est 1 (erreur).
Remarque
Le script ne vous indique pas si le système secondaire est prêt pour une reprise.
Si une reprise a lieu, le site secondaire trouve le dernier point de sauvegarde dans la zone du disque de données. Il s'agit du point de départ d'un redémarrage habituel de la base de données, mais de nombreux paquets de données volumineux (index principaux) sont préchargés en mémoire, comme sur le centre de données principal avant la reprise. Cela supporte considérablement le redémarrage. En fonction de ce point de sauvegarde initial sur le centre de données secondaire, la reproduction du journal peut démarrer et déplacer la base de données à la dernière date/heure.
La directive de décision suivante peut vous aider à décider si une reprise est recommandée.
Directive relative à la prise de décision
Il y a trois questions principales à se poser pour décider si une prise de contrôle améliorera ou non la situation.
- Une reprise peut-elle aider du tout ?
Non : n'effectuez pas de reprise.
Oui : passez à la question 2.
- Une reprise peut-elle réduire la durée des temps d'arrêt ?
Non : n'effectuez pas de reprise.
Oui : passez à la question 3.
- Peut-on garantir qu'aucune perte de données ne résultera de la reprise ?
Non : Évaluer le risque de perte de données en cas de reprise par rapport à celui de perte de données en cas d'absence de reprise, et contre l'impact d'un temps d'arrêt plus long pour ramener le site primaire à la place.
Oui : effectuer une reprise.
Remarque
Pour plus d'informations sur la manière de répondre à ces questions, voir la note SAP : 2063657.
Vous pouvez utiliser le script getTakeoverRecommendation.py pour obtenir des recommandations de reprise.
Les recommandations de reprise sont données par le script :
getTakeoverRecommendation.py
Évalue le statut renvoyé par les scripts Python :
- landscapeHostConfiguration.py
- systemReplicationStatus.py
Ces trois états possibles sont retournés :
Reprise requise
Non décidable
Possible
Lorsque le script getTakeoverRecommendation est appelé, il affiche la recommandation de reprise en fonction de l'état actuel du système. Cependant, lorsque le système primaire est confronté à une situation d'erreur, le statut de réplication du système ne peut plus être déterminé. Par conséquent, l'état précédent doit être sauvegardé et comparé à l'état actuel.
Exemple
Site principal
Il s'agit d'un exemple d'implémentation d'un script python qui utilise getTakeoverRecommendation pour agir comme un gestionnaire de cluster minimaliste :
1234567891011121314import time
import subprocess
from getTakeoverRecommendation import TakeoverDecision
def main():
wasInSync = False
while True:
recommendation =
subprocess.call(["python","getTakeoverRecommendation.py","--sapcontrol=1"])
if not wasInSync and recommendation is TakeoverDecision.Required:
print "Primary defect & no sync => NO TAKEOVER"
if wasInSync and recommendation is TakeoverDecision.Required:
print "Primary defect & sync => TAKEOVER"
nowInSync = recommendation is TakeoverDecision.Possible
wasInSync = nowInSyncLa sortie dépend de l'état précédent avec le résultat de l'appel actuel de getTakeoverRecommendation. Si aucun état de synchronisation n'est atteint, une reprise n'est pas conseillée. Mais une fois les systèmes synchronisés, l'erreur suivante du système principal suggère une reprise. Toute valeur de retour négative ultérieure réinitialisera l'état de synchronisation, car il n'est plus garanti que les données répliquées sont actuelles.
Outils pour effectuer une reprise
La reprise peut être déclenchée à l'aide des outils suivants :
Cockpit SAP HANA
SAP HANA Studio
hdbnsutil
Les étapes suivantes sont exécutées :
Déclencher une reprise sur le système secondaire en cas de sinistre.
Enregistrez l'ancien système primaire comme nouveau système secondaire lorsqu'il redevient disponible.
Outil de ligne de commande hdbnsutil
- Effectuer une reprise sur le site secondaire :Code Snippet1hdbnsutil –sr_takeover
- Lorsque l'ancien site principal est à nouveau disponible, il peut être enregistré comme nouveau site secondaire :Code Snippet12345hdbnsutil -sr_register --remoteHost=<new primary hostname> --remoteInstance=<instance number> --replicationMode=<sync/syncmem/async> --operationMode=<delta_datashipping|logreplay> --name=<siteName>
Remarque
Un logiciel de gestion de cluster externe peut être utilisé pour effectuer la reconnexion du client après la reprise. Certains partenaires matériels de SAP offrent une intégration de la haute disponibilité de SAP HANA dans leurs solutions de gestion de clusters.
Récupération de la connexion client
Pour effectuer la reprise uniquement sur le système SAP HANA dans la plupart des cas, cela ne suffit pas. D'une certaine manière, le client ou le serveur d'application doit pouvoir accéder en permanence au système SAP HANA, quel que soit le site principal actuellement.
Méthodes de restauration de la connexion client
Redirection IP
Une adresse IP virtuelle est affectée au nom d'hôte virtuel. Dans le cas d'une reprise, l'IP virtuelle se délie de l'adaptateur réseau du système primaire et se lie à l'adaptateur réseau du système secondaire.
Redirection DNS
Dans ce scénario, l'adresse IP du nom d'hôte dans le DNS passe de l'adresse du système principal à l'adresse du système secondaire.
Les deux méthodes ont leurs avantages, mais la méthode est principalement décidée par les politiques informatiques et la configuration existante. S'il n'y a pas de contraintes existantes, la redirection d'IP a clairement l'avantage d'être plus rapide à traiter dans un script plutôt que de synchroniser les modifications des entrées DNS sur un réseau global.
SAP HANA propose des fournisseurs de restauration après sinistre/haute disponibilité capables d'informer les entités externes des activités au sein du scale-out SAP HANA (comme le basculement automatique des hôtes) et des configurations de réplication du système SAP HANA. Dans un script Python, les actions peuvent être exécutées avant ou après certaines activités SAP HANA, telles que le démarrage, l'arrêt, le basculement, la reprise, la modification de la connexion, etc. Un exemple de ces fournisseurs HD/DR, ou « hooks », est le déplacement d'adresses IP virtuelles après une reprise dans la réplication du système SAP HANA.
En outre, un logiciel de gestion de cluster externe peut être utilisé pour effectuer la reconnexion du client après la reprise.
Vue de suivi fournissant des informations sur l'historique de reprise
La vue de suivi M_SYSTEM_REPLICATION_TAKEOVER_HISTORYfournit des informations sur les prises de contrôle dans la réplication du système SAP HANA (HSR) et sur le moment où HSR a été activé ou réactivé.
Lors de la reprise, le contenu de la vue est également déplacé vers la reprise du système, de sorte que l'historique complet de reprise soit disponible.
Historique de reprise
| Informations fournies par la vue système M_SYSTEM_REPLICATION_TAKEOVER_HISTORY |
|---|
| Heure de fin d'exécution pour la reprise du domaine de transaction |
| Heure de début d'exécution pour la reprise du domaine de transaction |
| Position du journal principal atteinte par la reprise |
| Heure atteinte par la reprise |
| Hôte serveur de noms principal au moment de la reprise |
| Mode d'exploitation au moment de la reprise |
| Mode de réplication au moment de la reprise |
| Statut de réplication au moment de la reprise |
| Position de journal maître la plus élevée, qui a été expédiée avant l'exécution de la reprise |
| Il s'agit de l'heure de la dernière mémoire tampon de journal expédiée avant l'exécution de la reprise. |
| Nom logique fourni par l'administrateur du site lors de la reprise |
| ID généré du site secondaire au moment de la reprise |
| Hôte du serveur de noms principal du site source au moment de la reprise |
| Nom logique du site source fourni par l'administrateur du site lors de la reprise |
| ID généré du site source au moment de la reprise |
| Version SAP HANA du site source |
| Heure de fin de la commande de reprise |
| Heure de début de la commande de reprise |
Indique comment le système est passé en ligne : EN LIGNE : reprise en ligne, OFFLINE : reprise hors ligne, TIMETRAVEL : après voyage dans le temps |
| Version SAP HANA pour le site qui exécute la reprise |
Implémentation des crochets de reprise
Crochets de reprise
Les hooks de reprise sont fournis par SAP HANA sous la forme d'un modèle de script Python.
Des actions de pré- et post-reprise sont implémentées dans ce script, qui sont ensuite exécutées par le serveur de noms avant ou après la reprise.
Par conséquent, le serveur de noms SAP HANA fournit une API basée sur Python qui est appelée aux points importants du basculement automatique de l'hôte et du processus de reprise de la réplication du système.
Il existe un certain nombre de prises de contrôle préalables, postérieures à la prise de contrôle et de crochets généraux.
Ces dits « crochets » peuvent être utilisés pour des opérations arbitraires qui doivent être exécutées. L'une des utilisations les plus importantes des crochets de basculement est de se déplacer autour d'une adresse IP virtuelle (en conjonction avec STONITH).
Il existe d'autres objectifs, tels que le lancement d'outils et d'applications sur certains hôtes après le basculement, ou même l'arrêt des instances DEV ou QA SAP HANA sur des sites secondaires avant la reprise. Plusieurs crochets de basculement peuvent être installés et utilisés en parallèle avec un ordre d'exécution défini.
Les crochets de basculement sont inclus dans SAP HANA. SAP HANA est fourni avec son propre interpréteur Python, qui est utilisé pour interpréter les crochets de basculement définis par l'utilisateur. L'API hook de basculement a également un numéro de version.
Vous pouvez adapter les fichiers Python fournis avec SAP HANA pour créer votre propre fournisseur HD/DR. Cela vous permet d'intégrer, par exemple, des mécanismes de basculement SAP HANA dans vos scripts existants.
Pour créer votre propre fournisseur HD/DR, utilisez le script HADRDummy.py (situé dans le répertoire $DIR_SYSEXE/python_support/hdb_ha_dr ) comme modèle pour implémenter des mécanismes de basculement SAP HANA dans vos propres scripts.
Après l'implémentation du fournisseur HA/DR de base, vous pouvez ajouter les méthodes répertoriées dans la figure, Méthodes Hook, à votre fournisseur.
Méthodes Hook
| Nom | Déclencheur |
|---|---|
| démarrage () | Début de la phase de démarrage du serveur de noms |
| shutdown() | Juste avant l'existence du serveur de noms |
| reprise () | Dès que le serveur de noms a pris une décision sur le nouveau rôle |
| stonith() | Dès que le serveur de noms a pris la décision concernant le nouveau rôle |
| preTakeover() | Dès que la commande hdbnsutil -sr_takover est émise |
| postTakeover() | Dès que tous les services avec un retour de volume de leur assign-call (port Open SQL) |
| srConnectionChanged() | Dès que l'un des services de réplication perd ou (réétablit) la connexion de réplication du système |
| srServiceStateChanged() | Dès que le serveur de noms a pris une décision sur le nouvel état |
| srReadAccessInitialized() | Dès qu'une base de données mutualisée ou la base de données système est prête à accepter des requêtes de lecture SQL sur un système secondaire accessible en lecture |
Par exemple, srServiceStateChanged() HA/DR Provider Hook signale les états de service modifiés. Il remarque qu'un service SAP HANA est en cours d'arrêt ou de plantage. Ces connaissances peuvent être utilisées pour réduire le temps de prise de contrôle (détection), en particulier dans les systèmes avec d'énormes serveurs d'index.
Remarque
La procédure de création d'un fournisseur HD/DR et les méthodes crochet disponibles sont décrites en détail dans le Guide d'administration SAP HANA.
Reprise avec poignée de main
La reprise avec poignée de main garantit que tous les journaux de restauration envoyés sont écrits sur le disque du système secondaire.
Lors d'une reprise planifiée, il est important de s'assurer qu'aucune donnée n'est perdue (toutes les mises à jour primaires doivent être disponibles sur le système secondaire) et que l'ancien système primaire est isolé pour éviter une situation de fracture cérébrale avec plusieurs systèmes primaires actifs.
La reprise avec poignée de main est idéale pour une reprise planifiée sûre alors que la primaire est toujours en cours d'exécution. Toutes les nouvelles transactions d'écriture dans le système primaire sont suspendues et la reprise est exécutée uniquement lorsque le journal de restauration est disponible dans le système secondaire. Lors de l'exécution d'une reprise avec poignée de main, il n'est pas nécessaire de vérifier le statut de réplication ou d'arrêter l'ancien primaire avant la reprise.
Vous pouvez déclencher une reprise avec poignée de main à l'aide de hdbnsutil -sr_takeover -–suspendPrimary dans le système secondaire.
Si un service primaire n'est pas accessible ou si une réplication de service n'est pas active ou synchronisée, la reprise sera interrompue et signalée comme une erreur. Dans ce cas, il n'y a aucun impact sur le système et la réplication reste telle quelle. Le service principal suspendu peut être débloqué à l'aide de la commande -sr_register hdnsutil.
