Examen de l'échec du nœud Coordinateur

Contrairement aux autres solutions de haute disponibilité, SAP HANA n'utilise pas de quorum composé de plusieurs hôtes SAP HANA pour décider quel hôte peut devenir coordinateur lors du démarrage initial ou du basculement du coordinateur. Avec les battements de cœur et l'escrime, un seul hôte peut décider de manière fiable du basculement initial de démarrage ou de coordinateur.

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

Basculement étape par étape :

1. Si aucun candidat de serveur de noms de coordinateur avec standby comme rôle de serveur d'index réel n'est disponible, l'un des candidats coordinateur actuellement utilisé comme travailleur de serveur d'index est choisi comme nouveau coordinateur.

2. Les étapes de basculement pour l'hôte coordinateur sont similaires au scénario décrit dans la figure Basculement de l'hôte coordinateur sans hôtes de secours disponibles.

3. Le travailleur précédemment attribué est marqué comme ayant échoué et entre dans la file d'attente de basculement. Étant donné qu'un hôte de secours est disponible, le basculement du collaborateur commence peu de temps après le basculement du coordinateur.

4. Les deux basculements sont exécutés en parallèle.

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

Basculement étape par étape :

1. Le candidat coordinateur de serveur de noms ayant la priorité la plus élevée (= le plus petit numéro dans le rôle configuré du serveur de noms) détecte la condition d'échec et lance le basculement.

2. Si un serveur de noms candidat est disponible et qu'il s'agit actuellement d'un hôte de secours, le basculement est transféré vers cet hôte. Cela évite un double basculement (voir le deuxième exemple ci-dessous).

3. Le basculement inclut les mêmes étapes que dans le scénario de basculement de l'hôte de travail décrit précédemment.

4. Le serveur de noms recharge sa persistance à partir du disque.

Cette section décrit le processus de sélection de l'hôte de remplacement. À partir de SPS11, les rôles hôte réels (HOST_ACTUAL_ROLES) sont pris en compte.

• 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é.

• S'il existe un hôte de secours, il est utilisé.

• Si plusieurs options équivalentes sont disponibles, le premier hôte est utilisé.

Les étapes de recherche sont limitées au même groupe de basculement, sauf si global.ini/[failover]/cross_failover_groups=false a été configuré.

Si aucun hôte n'est disponible, aucun basculement n'a lieu et HOST_STATUS affiche ERROR.

Les infrastructures distribuées sans hôte de secours peuvent également effectuer un basculement pour garantir que l'hôte coordinateur est toujours disponible. Bien sûr, un hôte ouvrier (et toutes les tables qui s'y trouvent) est inaccessible après le basculement.

Ce mécanisme de basculement peut être désactivé en supprimant les rôles de serveur de noms COORDINATOR 2 et COORDINATOR 3 dans le cockpit SAP HANA. La désactivation est requise si vous utilisez un stockage local (non recommandé) sur chaque hôte ou si l'infrastructure est contrôlée par un gestionnaire de cluster externe.

Le délai d'attente d'un employé de serveur de noms (candidat non coordinateur) sur un redémarrage du système est différent de celui d'un candidat coordinateur. Le nombre de tentatives d'accès au serveur de noms du coordinateur avant l'interruption du démarrage est contrôlé à l'aide du paramètre suivant : nameserver.ini/[failover]/slave_to_master_startup_retries=10.

Comme l'intervalle d'attente après un nouvel essai infructueux est de 5 secondes, la valeur de paramètre par défaut de 10 entraîne un temps d'attente maximal de 50 secondes.

La figure précédente illustre un basculement d'hôte de coordinateur vers un hôte de travail. À gauche, l'état d'origine du système est affiché. À droite, le premier hôte échoue et son rôle est déplacé vers le deuxième hôte. Le rôle d'origine du deuxième hôte n'est pas disponible tant qu'un hôte de secours n'a pas été ajouté au système ou que le premier hôte ayant échoué n'est pas réactivé.

Basculement étape par étape :

1. Le candidat coordinateur de serveur de noms ayant la priorité la plus élevée détecte les conditions d'échec et exécute lui-même les étapes de basculement.

2. Le nouveau serveur de noms de coordinateur appelle la méthode stonith() de tous les hooks de fournisseur HD/DR installés et la méthode stonith() du connecteur de stockage (le cas échéant) pour redémarrer l'hôte en échec.

   1. Si STONITH échoue, le basculement est interrompu et le nouveau coordinateur s'arrête.

   2. Le (éventuellement) candidat au troisième coordinateur restant retente alors le basculement.

   3. Si cela échoue également, aucun coordinateur n'est disponible dans l'ensemble du paysage et les hôtes des travailleurs finissent par s'arrêter.

3. Le nouveau coordinateur arrête tous ses services (sauf hdbdaemon et nameserver).

4. Le nouveau coordinateur appelle la méthode detach() du Storage Connector pour l'ancienne partition de stockage, la méthode join() pour la partition de stockage 1 (répertoire mnt00001) et appelle la méthode failover() de tous les hooks de basculement installés :

   1. En cas d'échec, le basculement est interrompu et le nouveau coordinateur s'arrête.

   2. Le (éventuellement) candidat au troisième coordinateur restant retente alors le basculement.

   3. Si cela échoue également, aucun coordinateur n'est disponible dans l'ensemble du paysage et les hôtes du travailleur s'arrêtent.

5. Le nouveau serveur de noms de coordinateur charge sa persistance à partir du disque.

6. Les services existants, les rôles d'hôte, le numéro de partition de stockage, les ID de volume de tous les services sont échangés entre les deux hôtes dans la topologie et tous les serveurs de noms sont informés.

7. Le processus hdbdaemon est reconfiguré, ce qui lance tous les services requis.

8. Le rôle de l'hôte travailleur déplacé reste inactif ; le système n'est que partiellement disponible.

Au lieu d'utiliser le basculement automatique de l'hôte SAP HANA intégré, vous pouvez surveiller et (ré)démarrer les hôtes virtualisés sur différents matériels à l'aide d'un gestionnaire de clusters externe. Avec plusieurs instances SAP HANA, cela présenterait l'avantage que moins d'hôtes de secours seraient nécessaires, mais d'un autre côté, toute la logique de détection de défaillance et d'escrime devrait être implémentée en externe. Pour éviter les basculements inutiles du coordinateur contrôlé par SAP HANA, les rôles COORDINATOR 2 et COORDINATOR 3 du serveur de noms peuvent être supprimés comme décrit précédemment.

Pour chaque service, un nombre fixe de redémarrages peut être défini après lequel le démon s'arrête lui-même. Les paramètres pertinents sont définis pour chaque type de service dans daemon.ini :

1234
# If set to true the daemon will shut down all services on the host if # this service cannot start 
startup_error_shutdown_instance=true
# Number of retries if a service fails in startup procedure 
startup_error_restart_retries=4

Le serveur de noms est le seul service dont le dernier paramètre est défini sur vrai par défaut. Cela signifie que tout problème impliquant un plantage constant du serveur de noms arrête finalement le démon. Par exemple, les paramètres présentés peuvent être utilisés pour le serveur d'index si des problèmes récurrents de démarrage de ce service doivent arrêter l'instance de base de données concernée.

Dans la solution de basculement coordinateur/collaborateur/de secours de SAP HANA, il n'existe qu'une seule entité dans l'ensemble du système qui peut prendre des décisions de basculement, c'est-à-dire le serveur de noms du coordinateur. Un hôte de travail ou de secours n'exécute jamais un basculement par lui-même. Par conséquent, seul l'hôte coordinateur doit être pris en compte pour les situations de cerveau divisé.

SAP HANA se heurterait à une situation de cerveau divisé si plusieurs hôtes tentent de devenir un serveur de noms/d'index coordinateur et accèdent au même ensemble de données (persistance) à partir du disque. Cela détruirait irrémédiablement les données. Pour résoudre ce problème, SAP HANA utilise la clôture d'E/S pour empêcher l'autre hôte d'accéder au stockage, comme suit :

• Stockage SAN : les périphériques de stockage sont verrouillés par l'hôte actif actuel avec des réservations persistantes SCSI-3. Si un autre hôte tente de monter ces périphériques, l'ancien hôte perd automatiquement les autorisations d'écriture et les services s'interrompent.

• Stockage partagé NFSv3 : l'implémentation de verrouillage de fichier NFSv3 ne peut pas être utilisée car les verrous ne seraient pas libérés si un client NFSv3 décède, une procédure STONITH doit donc être fournie par le fournisseur de stockage, qui redémarre un hôte défaillant.

• NFSv4 stockage partagé ou systèmes de fichiers cluster comme GPFS: L'implémentation de verrouillage de fichier fonctionne de manière fiable sur les hôtes. La non-disponibilité d'un hôte, et donc la libération du blocage, est gérée par le système de fichiers. Un hôte qui tente d'ouvrir une persistance qui est déjà ouverte échoue et s'interrompt lui-même.

Les pulsations basées sur le réseau de communication et le réseau de stockage sont utilisées pour détecter l'activité d'autres hôtes et éviter les tentatives de basculement inutiles. Si l'hôte du coordinateur cible détecte qu'un autre coordinateur est toujours actif, il se termine pour laisser l'autre coordinateur continuer. Sans cela, différents hôtes pourraient essayer de devenir coordinateurs et se cloisonneraient mutuellement à plusieurs reprises.

Dans une situation de fracture du cerveau, un quorum est parfois utilisé pour décider quel côté devrait «survivre». Cela est judicieux dans les clusters de calcul sans état pour que les parties les plus importantes des ressources restent actives. Cependant, dans SAP HANA, les tables sont liées à des partitions de stockage et des instances de service spécifiques. Les tables de l'autre partition ne seraient pas accessibles et les applications ne peuvent généralement pas continuer avec certaines tables inaccessibles. Par conséquent, SAP HANA permet au coordinateur initial de continuer.

Certaines actions, prises en charge par l'exécutable hdbnsutil, accèdent à la persistance pendant que le système est arrêté. Pour éviter la corruption des données causée par des services inattendus actifs ou de relance, ce programme recherche également les serveurs de noms actifs avec des pulsations basées sur le réseau et le stockage et utilise la clôture pour définir la réservation persistante SCSI-3.

Stockages SAN : Après l'arrêt de hdbnsutil (ou du serveur de noms), les réservations persistantes SCSI-3 ne sont intentionnellement pas libérées. Cela garantit qu'aucun autre service n'accède involontairement à une persistance, comme des services toujours en cours d'exécution sur d'autres hôtes après une situation de cerveau fractionné.

La phase de basculement peut être divisée en plusieurs étapes :

1. Détection d'échec

   Plusieurs chiens de garde, tentatives et délais d'expiration sont impliqués. En fonction de la condition de défaillance, le temps de détection peut varier, par example comme suit:

   • Instance SAP HANA interrompue ou hôte arrêté

     L'hôte de contrôle reçoit immédiatement les erreurs de la couche du système d'exploitation et détecte généralement la défaillance en moins d'une minute.

   • Fractionnement du réseau

     L'hôte de contrôle doit attendre l'expiration du réseau, de sorte que la détection des défaillances prend généralement de trois à six minutes. Les délais d'expiration pourraient être réduits, mais cela n'est pas recommandé, car cela ne permettrait pas de récupérer à partir de courtes pannes de réseau, ou pourrait entraîner une fausse décision de basculement dans le cas d'une charge système importante, où les pings peuvent prendre plus de temps.

2. Exécution de basculement

   Le temps de basculement est comparable au temps requis pour le démarrage de SAP HANA, car les services sur un hôte de secours sont initialement démarrés, mais ne fonctionnent pas. Lors du basculement, ils font la même charge d'initialisation et de persistance que dans les startups de service régulier.

Tous les hôtes peuvent être lancés simultanément. Les candidats au serveur de noms du coordinateur ont des priorités différentes comme indiqué par le nom de rôle COORDINATOR 1, 2 et 3. Le premier candidat coordinateur devient le coordinateur actif. Les rôles de serveur d'index, les rôles d'hôte et les partitions de stockage sont réinitialisés, ce qui signifie que tous les hôtes de travail configurés sont utilisés à nouveau en tant que worker, même si l'état de l'infrastructure a échoué avant l'arrêt.

Jusqu'à SPS11, si un hôte était précédemment utilisé comme un collaborateur, sa partition de stockage est conservée telle quelle, afin d'éviter des modèles d'accès inefficaces dans les systèmes de fichiers en cluster. Ainsi, au fil du temps, les partitions de stockage peuvent avoir un tri différent de leur état initial après l'installation.

À partir de SPS12, un redémarrage de l'infrastructure prend en compte les partitions de stockage configurées, ce qui ramène le système à son état d'origine. Comme condition préalable, le serveur de noms du coordinateur doit se trouver sur son hôte d'origine (avec une partition de stockage configurée de 1). Dans une configuration de réplication du système SAP HANA, seul le système principal exécute cette opération de reprise.

Lorsqu'un basculement a été effectué et que l'hôte défaillant est à nouveau disponible, aucun basculement automatique n'a lieu ; l'hôte démarre en mode veille. Un basculement contrôlé peut être effectué en arrêtant ou en redémarrant l'hôte de secours configuré qui, après un basculement précédent, est en fait un worker. La restauration automatique a lieu uniquement lorsque l'infrastructure complète est relancée.

L'hôte initial est un candidat coordinateur et les deux premiers hôtes ajoutés à un paysage deviennent des candidats coordinateurs. Lorsqu'un hôte de secours est ajouté et qu'aucun des candidats coordinateurs n'est un hôte de secours, le dernier candidat coordinateur est déplacé vers le nouvel hôte de secours. Avoir un hôte de secours dans la liste des candidats coordinateurs permet un basculement plus rapide de l'hôte coordinateur car cela évite le double basculement mentionné précédemment.

Lors de l'installation et avec SAP HANA Studio, un groupe de basculement peut être configuré par hôte. Si un hôte cible de basculement est disponible dans le même groupe, il est préféré aux hôtes d'autres groupes. Cela peut être utilisé pour obtenir une meilleure "localité" dans les grands systèmes, pour utiliser des connexions réseau/stockage avec moins de latence. Lorsque le paramètre nameserver.ini/[failover]/cross_failover_group est défini sur false, le basculement est limité aux hôtes du même groupe. Cela peut être utilisé pour séparer du matériel de taille différente ou des entités de stockage distinctes.

Dans les informations de connexion pour les bibliothèques client SQL SAP HANA (par exemple, hdbuserstore), vous pouvez configurer plusieurs noms d'hôte. Tous les candidats du serveur de noms du coordinateur doivent y être configurés. Les candidats coordinateurs peuvent être trouvés à l'aide de l'instruction SQL suivante :

1
select HOST from SYS.M_LANDSCAPE_HOST_CONFIGURATION where NAMESERVER_CONFIG_ROLE like 'MASTER%' order by NAMESERVER_CONFIG_ROLE

Le basculement n'est pas transparent. Les erreurs survenues lors d'une phase d'échec sont renvoyées aux clients. Ni le serveur ni les bibliothèques client ne disposent d'une logique de "réessai" intégrée. Les candidatures doivent être préparées et doivent tenter de se reconnecter.

• Echec de l'hôte du coordinateur : le client reçoit généralement l'erreur -11312 (connexion au serveur de base de données perdue ; vérifiez l'état du serveur et du réseau [Erreur système : ...])

• Échec de l'hôte du travailleur : fondamentalement, tout code d'erreur peut se produire, car la connexion du coordinateur est toujours disponible, mais certaines tables ne sont plus accessibles et les instructions peuvent échouer à différentes étapes.