Lorsque le mécanisme du quorum est activé, tous les serveurs de catalogue dans le quorum doivent être disponibles pour que les opérations de placement puissent être exécutées dans la grille de données.
Serveurs de conteneur et groupes centraux
Le service de catalogue place les serveurs de conteneur dans des groupes centraux dont la taille est limitée. Un groupe central essaie de détecter la défaillance de ses membres. Un membre du groupe central est déclaré responsable du groupe. Il indique régulièrement au service de catalogue que le groupe central est actif et lui signale les modifications des membres. Une modification de membre peut être une machine JVM défaillante ou une machine JVM ajoutée au groupe central.
Si un socket JVM est fermé, la machine JVM est considérée ne plus être disponible. Chaque membre du groupe central envoie également des pulsations sur ces sockets à une fréquence définie par la configuration. Si une machine JVM ne répond pas à ces pulsations dans un délai maximum défini, la machine JVM est considérée ne plus être disponible, ce qui déclenche un échec de détection.
Si le service de catalogue marque une machine virtuelle Java de conteneur comme étant défaillante et que le serveur de conteneur est ultérieurement signalé comme étant disponible, il est demandé à la machine virtuelle d'arrêter le serveur de conteneur WebSphere eXtreme Scale. Une machine virtuelle Java dans cet état n'est pas visible dans les requêtes de commande de l'utilitaire xscmd. Des messages dans les journaux de la machine virtuelle Java conteneur indiqueront que cette machine est tombée en panne. Vous devrez la redémarrer manuellement.
Si le responsable du groupe central ne parvient pas à contacter un membre, il continue d'essayer de contacter le membre.
La défaillance complète de la totalité des membres d'un groupe central est une éventualité qui peut arriver. Si la totalité du groupe central est défaillant, c'est au service de catalogue de détecter cette perte.
Pulsations du domaine de service de catalogue
Le domaine de service de catalogue ressemble à un groupe central privé dont les membres sont statiques avec un mécanisme de quorum. La détection des défaillances s'effectue de la même manière que pour un groupe central normal. La différence tient à la modification de son comportement puisqu'il inclut une logique de quorum. Le service de catalogue utilise aussi une configuration de pulsation moins agressive.
Détection des défaillances
WebSphere eXtreme Scale détecte la fin des processus via des événements de fermeture de socket anormale. Le service de catalogue est immédiatement notifié lorsqu'un processus prend fin.
Pour plus d'informations sur la configuration des pulsations, voir Optimisation de la valeur de l'intervalle des pulsations pour la détection des basculements.
Normalement, les membres du service de catalogue disposent d'une connectivité pleine et entière. Le domaine de service de catalogue est un ensemble statique de machines virtuelles Java. WebSphere eXtreme Scale s'attend à ce que tous les membres du service de catalogue soient en ligne. Lorsque tous les membres sont en ligne, le service de catalogue a le quorum. Le service de catalogue répond aux événements de conteneur uniquement lorsque le service de catalogue a le quorum.
Causes de la perte du quorum
WebSphere eXtreme Scale s'attend à perdre le quorum dans les cas suivants :
Si le service de catalogue perd un quorum, il s'attend à ce que le quorum soit rétabli. Lorsque le service de catalogue ne dispose pas d'un quorum, il ignore les événements provenant des serveurs de conteneur. Les serveurs de conteneur continuent d'essayer toutes les demandes qui sont rejetées par le serveur de catalogue pendant ce temps. Les pulsations sont suspendues jusqu'à ce qu'un quorum soit rétabli.
Perte de quorum due à une défaillance de machine virtuelle Java
Un serveur de catalogue défaillant provoque la perte du quorum. Si une machine JVM échoue, vous devez remplacer le quorum aussi rapidement que possible. Le service de catalogue défaillant ne peut rejoindre la grille de données tant que le quorum n'a pas été redéfini.
Perte de quorum due à une microcoupure réseau
WebSphere eXtreme Scale est conçu pour prendre en charge les microcoupures éventuelles. Une microcoupure est une perte provisoire de connectivité entre des centres de données. Elles sont généralement transitoires et disparaissent en quelques secondes ou minutes. Bien que WebSphere eXtreme Scale essaie de maintenir le fonctionnement pendant la microcoupure, une microcoupure est considérée comme une simple défaillance. La défaillance est censée être résolue et le fonctionnement normal reprend sans intervention.
Une microcoupure qui s'éternise ne pourra être requalifiée en interruption totale que par une intervention d'utilisateur. Le remplacement du quorum sur un côté de la microcoupure est nécessaire pour que l'événement soit classé comme une interruption.
Cycle entre les services de catalogue
Si un serveur de catalogue est arrêté à l'aide de la commande stopOgServer, le quorum diminue d'un serveur. Les serveurs restants ont toujours le quorum. Le redémarrage du serveur de catalogue rétablit le nombre précédent du quorum.
Conséquences de la perte de quorum
Si une machine virtuelle Java conteneur est défaillante pendant que la perte du quorum, la reprise n'a lieu qu'après la récupération du quorum. Dans un scénario d'interruption, la récupération ne se produit que lorsque vous exécutez la commande de remplacement de quorum. La perte de quorum et la défaillance d'un conteneur sont considérées être une double défaillance, ce qui est un événement rare. En raison de la double défaillance, les applications peuvent perdre l'accès en écriture aux données qui étaient stockées sur la machine JVM défaillante. Lorsque le quorum est restauré, la récupération normale est exécutée.
De même, si vous tentez de démarrer un conteneur au cours d'un événement de perte de quorum, le conteneur ne démarre pas.
La connectivité clients complète est autorisée pendant la perte de quorum. S'il ne se produit aucune défaillance de conteneur ou de problèmes de connectivité pendant la perte du quorum, les clients pourront toujours interagir complètement avec les serveurs de conteneur.
Si une microcoupure se produit, certains clients peuvent ne pas avoir accès aux copies primaires ou aux copies de réplique des données jusqu'à la fin de microcoupures.
Les nouveaux clients peuvent être démarrés, car une machine virtuelle Java de service de catalogue doit exister dans chaque centre de données. Par conséquent, au moins un serveur de catalogue est accessible au client, même pendant une microcoupure.
Rétablissement du quorum
Si le quorum est perdu pour une quelconque raison, lorsque le quorum est rétabli, un protocole de récupération est exécuté. Lorsque la perte du quorum se produit, toute vérification d'activité des groupes centraux est suspendue et les rapports signalant des défaillances sont ignorés. Une fois le quorum est rétabli, le service de catalogue contrôle tous les groupes centraux pour déterminer immédiatement leurs membres. Tous les fragments précédemment hébergés sur des machines virtuelles Java signalées comme étant défaillantes sont récupérés. En cas de perte de fragments primaires, les répliques survivantes sont déclarées fragments primaires. Si les fragments de réplique ont été perdus, des fragments de réplique supplémentaires sont créés à partir des survivants.
Redéfinir le quorum
Remplacez le quorum uniquement en cas de défaillance d'un centre de données. Une perte de quorum suite à la défaillance d'une machine virtuelle Java de service de catalogue ou à une microcoupure du réseau est résolue automatiquement une fois la machine virtuelle Java de service de catalogue redémarrée ou la microcoupure du réseau terminée.
Seuls les administrateurs sont informés d'une défaillance de centre de données. WebSphere eXtreme Scale traite une microcoupure et une interruption de la même manière. Vous devez informer l'environnement WebSphere eXtreme Scale de ces échecs avec la commande xscmd -c overrideQuorum. Cette commande indique au service de catalogue de supposer que le quorum est atteint avec les membres actuels, et la reprise complète est effectuée. Lorsque vous émettez une commande de remplacement de quorum, vous garantissez que les machines virtuelles dans le centre de données défaillant sont réellement en panne et ne peuvent pas être récupérées.
Les conteneurs hébergent un ou plusieurs fragments. Les fragments sont soit des fragments primaires, soit des fragments réplique pour une partition spécifique. Le service de catalogue affecte des fragments à un conteneur et le serveur de conteneur utilise cette affectation jusqu'à ce que de nouvelles instructions arrivent du service de catalogue. Par exemple, un fragment primaire continue d'essayer de communiquer avec ses fragments de réplique pendant les microcoupures jusqu'à ce que le service de catalogue fournisse des instructions supplémentaires pour le fragment primaire.
Comportement des fragments de réplique synchrones
Le fragment primaire peut accepter de nouvelles transactions alors que la connexion est interrompue si le nombre de répliques en ligne correspond au moins à la valeur de la propriété minsync du groupe de mappes. Si de nouvelles transactions sont traitées sur le fragment primaire pendant que la liaison avec la réplique synchrone est interrompue, le fragment de réplique est resynchronisé avec l'état actuel du fragment primaire lorsque la liaison est rétablie.
Ne configurez pas une réplication synchrone entre les centres de données ou sur une liaison WAN.
Comportement de la réplique asynchrone
Pendant que la connexion est interrompue, le fragment primaire peut accepter de nouvelles transactions. Le fragment primaire place en mémoire tampon les modifications jusqu'à une certaine limite. Si la connexion au fragment réplique est rétablie avant que cette limite ne soit atteinte, le fragment réplique sera actualisé avec les modifications mises en mémoire tampon. Si la limite est atteinte, le fragment primaire détruit la liste en tampon et, lorsqu'il se reconnecte, le fragment réplique est effacé et resynchronisé.
Les clients sont toujours en mesure de se connecter au serveur de catalogue pour s'amorcer sur la grille de données, que le domaine de service de catalogue ait ou non le quorum. Le client tente de se connecter à n'importe quelle instance de serveur de catalogue pour obtenir une table de routage et il interagit ensuite avec la grille de données La connectivité réseau peut empêcher le client d'interagir avec certaines partitions en raison de la configuration du réseau. Le client peut se connecter aux répliques locales des données distantes s'il a été configuré en conséquence. Les clients ne peuvent pas mettre à jour les données si la partition principale de ces données n'est pas disponible.