Échec de l'examen d'un nœud SAP HANA Worker

L'auto-basculement de l'hôte est une solution locale de récupération des erreurs qui peut être utilisée en plus de la réplication du système ou comme mesure alternative à celle-ci. Un (ou plusieurs) hôte(s) de secours sont ajoutés à un système SAP HANA et configurés pour fonctionner en mode de secours. S'ils sont en mode veille, les bases de données sur ces hôtes ne contiennent aucune donnée et n'acceptent pas les requêtes. Cela signifie qu'ils ne peuvent pas être utilisés à d'autres fins, telles que les systèmes de qualité ou de test.

Lorsqu'un hôte principal (de travail) échoue, un hôte de secours prend automatiquement sa place. Si ni le serveur de noms ne traite hdbnameserver, ni hdbdaemon ne répond aux requêtes réseau (parce que l'instance est arrêtée ou que le système d'exploitation a été arrêté ou éteint), un hôte est marqué comme inactif et un basculement automatique est déclenché. Étant donné que l'hôte de secours peut reprendre l'opération de n'importe lequel des hôtes primaires, il a besoin d'un accès partagé à tous les volumes de base de données. Cela peut être réalisé par un serveur de stockage partagé et en réseau, à l'aide d'un système de fichiers distribué ou avec des solutions spécifiques au fournisseur qui utilisent une interface programmatique SAP HANA, l'API du connecteur de stockage, pour détacher et attacher (monter) dynamiquement le stockage en réseau lors du basculement.

Pour garantir la cohérence des données à tout moment, il faut s'assurer qu'un basculement n'a pas lieu (ou au moins ne réussit pas et ne peut pas entraîner de données corrompues) si l'hôte défaillant peut potentiellement encore écrire des données. Pour ce faire, le basculement automatique de l'hôte SAP HANA utilise une combinaison de pulsation et d'escrime.

Les types de pulsations suivants sont utilisés pour vérifier si un autre hôte est actif en tant que coordinateur avant de lancer l'hôte actuel en tant que coordinateur ou d'effectuer un basculement :

• Beats cardiaques basés sur la communication TCP :

  • Effectuer un ping entre le serveur de noms et le serveur de noms avec le protocole de communication interne SAP HANA

  • Effectuer un ping du serveur de noms au hdbdaemon avec le protocole de communication interne SAP HANA

• battements de cœur basés sur le stockage :

  Le serveur de noms du coordinateur actuel met à jour périodiquement les fichiers heartbeat situés sur différentes partitions de stockage :

  • Stockage partagé pour les fichiers binaires SAP HANA

  • Partition de stockage 1 pour les données du nœud coordinateur

  Ces types de stockage sont typiquement connectés à d'autres réseaux que le réseau inter-noeuds utilisé pour la communication service-service (comme le canal fibre pour SAN ou Ethernet dédié pour NFS) et donc ces battements cardiaques apportent une valeur supplémentaire.

Dans de rares cas, les battements de cœur ne peuvent pas détecter si un autre hôte est vivant, par exemple dans des situations de split-cerveau où aucune communication n'est possible entre les hôtes. La clôture E/S garantit que l'autre côté n'accède plus aux données ou au stockage des journaux.

L'API du connecteur de stockage SAP HANA, associée à un connecteur de stockage spécifique, permet d'utiliser les types de stockage et d'architecture réseau suivants pour garantir une clôture d'E/S appropriée :

• Stockage SAN : connecteur de stockage SAP HANA Fiber Channel [2] utilisant des réservations persistantes SCSI-3 (SCSI-3 PGR).

• NFSv3 : utilisé sans verrouillage de fichier, mais avec un connecteur de stockage fourni par des fournisseurs de stockage certifiés. Ce type de connecteur de stockage implémente un appel Shoot The Other Node In The Head (STONITH) pour redémarrer un hôte défaillant.

  Si un client NFSv3 meurt (c'est-à-dire le serveur SAP HANA), les verrouillages de fichiers ne sont pas libérés côté serveur NFS, ce qui entraîne un interblocage pour tout hôte souhaitant accéder à ces fichiers. L'utilisation de l'option de montage nolock résout le problème de verrouillage, mais avec cette option, les données ne sont pas protégées contre la lecture et l'écriture parallèles à partir de différents hôtes. Pour résoudre ce problème, STONITH doit être implémenté.

• NFSv4 ou systèmes de fichiers de cluster comme GPFS : utilisation de verrouillages de fichiers. Un connecteur de stockage n'est pas requis ici car ces verrouillages de fichiers empêchent de manière fiable les faux accès. Cependant, un connecteur de stockage de type STONITH est fourni par certains fournisseurs de stockage pour accélérer le basculement.

La configuration multi-hôte SAP HANA peut également être affichée au niveau du système d'exploitation. Il existe un script Python appelé landscapeHostConfiguration.py dans le dossier $DIR_INSTANCE/exe/python_support . L'exécution du script comme illustré dans la figure précédente fournit une synthèse de la configuration.

Les colonnes d'hôte suivantes sont affichées par ce script en plus de la vue SAP HANA Cockpit 2.0 :

• STORAGE_CONFIG_PARTITION / Storage Partition (Configuré - nouveau dans SPS 12) : sous-chemin stable pour réaffecter la même partition de stockage après les basculements.

• WORKER_CONFIG_GROUPS/Worker Groups (Configuré – nouveau dans HANA 2 SPS 00) : valeurs de classification stables pour affecter des hôtes à des groupes de travail logiques.

• WORKER_ACTUAL_GROUPS/Worker Groups (Réel – nouveau dans HANA 2 SPS 00) : valeurs de classification actuelles pour affecter des hôtes à des groupes de travail logiques.

Le code retour peut être utilisé par les gestionnaires de cluster (par exemple, pour la réplication du système SAP HANA) pour prendre une décision sur l'état de fonctionnement du système, comme suit :

• 0 = Fatal. Par exemple, base de données hors ligne.

• 1 = Erreur. Par exemple, un basculement n'a pas eu lieu, car il n'y avait pas d'hôte de secours disponible.

• 2 = Avertissement. Par exemple, un basculement est possible.

• 4 = OK.

• 5 = Ignorer. Par exemple, le système a changé de rôle (basculement), mais il est entièrement fonctionnel.

Un code de retour >= 4 indique le fonctionnement normal du système. Lorsque le système est arrêté, ce script peut également être utilisé, mais ne renseigne qu'un sous-ensemble des colonnes.

Une défaillance de l'hôte est tout état dysfonctionnel d'un hôte qui affecte la communication entre les hôtes d'un système SAP HANA distribué. Pour vérifier l'état fonctionnel d'un hôte, les serveurs de noms envoient régulièrement un ping sur la couche de communication réseau interne aux serveurs de noms sur d'autres hôtes. Un ping supplémentaire vers le processus hdbdaemon est exécuté dans le cas où le serveur de noms distant ne répond pas plusieurs fois. Ce n'est que lorsque les deux services ne répondent pas à temps que l'hôte est considéré comme ayant échoué.

Un plantage d'un service unique ne déclenche pas de basculement, car les services sont normalement redémarrés par le hdbdaemon. Si un service ne peut pas être redémarré pour une raison quelconque, il est supposé qu'il ne peut pas non plus démarrer sur un autre hôte.

Une exception est si le serveur de noms s'interrompt lors du démarrage si le connecteur de stockage renvoie une erreur. Il demande ensuite à hdbdaemon d'arrêter l'ensemble de l'instance de base de données sur l'hôte, y compris le hdbdaemon lui-même, ce qui permet la détection des pannes et le traitement de basculement par d'autres hôtes.

• Le heartbeat de communication du serveur de noms : le serveur de noms du coordinateur actuel pie tous les autres serveurs de noms toutes les 10 secondes. Si un serveur de noms était actif et que cinq pings ont échoué (immédiatement ou après un délai d'expiration de 60 secondes de ping), le serveur de noms est considéré comme inactif. En envoyant un ping plusieurs fois, SAP HANA peut récupérer après de courtes pannes de réseau sans déclencher de basculement.

• Le heartbeat de communication hdbdaemon : Si un serveur de nom de travailleur était considéré comme inactif (ou s'était défini comme inactif), le serveur de noms de coordinateur pie le processus de travail hdbdaemon. Si le ping hdbdaemon échoue (immédiatement ou après un délai d'expiration de 60 secondes), l'hôte est considéré comme inactif et un basculement est lancé.

• Le pulsateur de communication du serveur de noms : candidats du serveur de noms, qui ne sont pas actuellement le coordinateur, en exécutant un test ping toutes les 10 secondes sur d'autres candidats de priorité inférieure. Avec le heartbeat du serveur de nom de travailleur décrit précédemment (le serveur de noms de coordinateur actuel pie tous les autres serveurs de noms), normalement COORDINATOR 1 pings COORDINATOR 2 et COORDINATOR 3, et COORDINATOR 2 pings COORDINATOR 3. Si un candidat coordinateur ne reçoit aucun ping dans les 30 secondes, il pend le serveur de noms de coordinateur lui-même.

• Le heartbeat de communication hdbdaemon : si le ping vers le serveur de noms de coordinateur échoue, le processus hdbdaemon sur l'hôte coordinateur est pingé. Si le hdbdaemon ne répond pas dans les 60 secondes, l'hôte coordinateur actuel est considéré comme inactif.

• Le heartbeat de stockage du serveur de noms : l'hôte candidat du serveur de noms vérifie les modifications dans les fichiers heartbeat pendant une période de 60 secondes. Ces fichiers sont mis à jour par le serveur de noms de coordinateur actuel toutes les 10 secondes avec le nom d'hôte et une chaîne aléatoire. Un basculement commence uniquement si tous les fichiers n'affichent aucun signe de changement pendant 60 secondes.

Lorsqu'une défaillance est détectée et qu'un hôte de remplacement est déterminé, le processus de basculement réel démarre.

La figure précédente est une visualisation du basculement d'un hôte de travail vers un hôte de secours. À gauche, l'état d'origine du système est affiché. À droite, le deuxième hôte échoue et son rôle est déplacé vers le quatrième hôte.

Basculement étape par étape :

1. Sélection de l'hôte cible

   • S'il existe un hôte de secours avec une concordance exacte des rôles d'hôte réels correspondants, il est utilisé.

   • S'il existe un hôte de secours avec l'un des rôles qui correspond à l'hôte défaillant, il est utilisé.

   • Si l'hôte défaillant a un rôle de travailleur SAP HANA, tout standby non affecté est utilisé.

2. Le serveur de noms de coordinateur appelle la méthode stonith() de tous les hooks de fournisseur HA/DR installés et la méthode stonith() du connecteur de stockage. Généralement, la méthode stonith() n'est implémentée que dans les connecteurs de stockage liés à NFSv3 et redémarre l'hôte défaillant.

   Remarque

   Si STONITH échoue, le basculement est interrompu et tous les hôtes restent dans leurs anciens rôles.

3. Échangez les services réels, les rôles d'hôte, le numéro de partition de stockage et les ID de volume de tous les services entre les deux hôtes dans la topologie et informez tous les autres hôtes.

4. Le serveur de noms du coordinateur (qui a sélectionné un hôte de remplacement) appelle le serveur de noms sur l'hôte cible pour effectuer le basculement.

5. L'hôte promu à un nouveau rôle appelle la méthode de connexion () des connecteurs de stockage pour acquérir la partition de stockage correcte (le cas échéant) et appelle la méthode failover() de tous les hooks de fournisseurs HD/DR installés.

   Remarque

   En cas d'échec, l'hôte s'arrête. Si des hôtes en attente sont toujours disponibles, un autre basculement est déclenché et cet hôte est défini sur ERREUR.

6. Reconfigurez les services de secours en cours d'exécution pour charger leur volume nouvellement affecté.

   Remarque

   En cas d'échec, cela équivaut à une panne de service et ne déclenche pas de nouveau basculement.

7. Reconfigurez hdbdaemon pour démarrer/arrêter les services qui doivent s'exécuter sur un seul des deux hôtes.

   Remarque

   En cas d'échec, cela équivaut à une panne de service et n'a pas initié un nouveau basculement.

Le serveur de noms de coordinateur est la seule entité dans l'ensemble du système à pouvoir effectuer une sélection d'hôte cible de basculement. Étant donné que le coordinateur a des mécanismes pour éviter les situations de fracture du cerveau, il n'y a conceptuellement aucune situation cérébrale fractionnée possible pour les hôtes travailleurs. Si un travailleur perd sa connexion au serveur de noms du coordinateur, il attend et est informé par le nouveau coordinateur. Si un travailleur ne peut pas se connecter à un coordinateur lors du démarrage, il se termine lui-même.