🤵🏾 🧘 ⛩️ Cluster à deux nœuds - le diable en détail 💠 🥠 🧙🏻

Bonjour, Habr! Je vous présente la traduction de l'article "Deux nœuds - Le diable est dans les détails" par Andrew Beekhof.

Beaucoup de gens préfèrent les clusters à deux nœuds car ils semblent conceptuellement plus simples et également 33% moins chers que leurs homologues à trois nœuds. Bien qu'il soit tout à fait possible d'assembler un bon cluster de deux nœuds, dans la plupart des cas, en raison de scénarios non pris en compte, une telle configuration créera de nombreux problèmes non évidents.

La première étape de la création d'un système à haute disponibilité consiste à rechercher et à tenter d'éliminer les points de défaillance individuels, souvent abrégés en SPoF (point de défaillance unique).

Il convient de garder à l'esprit que dans tout système, il est impossible d'éliminer tous les risques possibles de temps d'arrêt. Cela découle même du fait qu'une protection contre les risques typique est l'introduction d'une certaine redondance, ce qui conduit à une augmentation de la complexité du système et à l'émergence de nouveaux points de défaillance. Par conséquent, nous faisons d'abord des compromis et nous nous concentrons sur les événements liés à des points de défaillance individuels, plutôt que sur des chaînes d'événements liés et, par conséquent, de moins en moins probables.

Compte tenu des compromis, nous recherchons non seulement le SPoF, mais également l'équilibre des risques et des conséquences.En conséquence, la conclusion est ce qui est essentiel et ce qui ne peut pas être différent pour chaque déploiement.

Tout le monde n'a pas besoin de fournisseurs d'électricité alternatifs avec des lignes électriques indépendantes. Bien que la paranoïa ait payé pour au moins un client lorsque sa surveillance a détecté un transformateur défectueux. Le client a appelé par téléphone, essayant d'avertir la compagnie d'énergie, jusqu'à ce qu'un transformateur défectueux explose.

Le point de départ naturel est la présence de plusieurs nœuds dans le système. Cependant, avant que le système ne puisse déplacer les services vers le nœud survivant après l'échec, en général, vous devez vous assurer que les services déplacés ne sont actifs à aucun autre endroit.

Un cluster à deux nœuds n'a aucun inconvénient si, à la suite d'une défaillance, les deux nœuds desservent le même site Web statique. Cependant, tout change si, par conséquent, les deux parties gèrent indépendamment la file d'attente de travaux partagée ou fournissent un accès en écriture non coordonné à la base de données répliquée ou au système de fichiers partagé.

Par conséquent, pour éviter la corruption des données due à la défaillance d'un nœud - nous nous appuyons sur ce qu'on appelle la «dissociation» (clôture).

Principe de séparation

Le principe de séparation repose sur la question: un nœud concurrent peut-il provoquer une corruption des données? Dans le cas où la corruption des données est un scénario probable, isoler le nœud des demandes entrantes et du stockage persistant est une bonne solution. L'approche la plus courante de désengagement consiste à désactiver les nœuds défectueux.

Il y a deux catégories de méthodes de séparation que j'appellerai directes et indirectes , mais elles peuvent également être appelées actives et passives. Les méthodes directes incluent les actions des pairs survivants, telles que l'interaction avec un périphérique IPMI (Intelligent Platform Management Interface - une interface pour surveiller et gérer à distance l'état physique d'un serveur) ou iLO (un mécanisme de gestion de serveur en l'absence d'accès physique à ceux-ci), tandis que les méthodes indirectes s'appuient sur le nœud défaillant pour reconnaître d'une manière ou d'une autre qu'il est dans un état malsain (ou du moins empêcher le reste des membres de récupérer) et pour signaler au chien de garde matériel la nécessité de déconnecter le nœud défaillant.

Un quorum est utile dans le cas de l'utilisation de méthodes directes et indirectes.

Dissociation directe

En cas de dissociation directe, nous pouvons utiliser un quorum pour éviter les courses d'exclusion en cas de panne du réseau.

Ayant le concept de quorum, le système dispose de suffisamment d'informations (même sans connexion à ses partenaires) pour que les nœuds sachent automatiquement s'ils doivent initier la séparation et / ou la récupération.

Sans quorum, les deux côtés du partage de réseau supposent à juste titre que l'autre côté est mort et chercheront à dissocier l'autre. Dans le pire des cas, les deux parties parviennent à déconnecter l'ensemble du cluster. Un scénario alternatif est deathmatch, une boucle sans fin de nœuds apparaissant, ne voyant pas leurs homologues, les rechargeant et initiant la récupération uniquement pour un redémarrage lorsque leur homologue suit la même logique.

Le problème de l'exclusion est que les appareils les plus fréquemment utilisés deviennent inaccessibles en raison des mêmes événements de défaillance sur lesquels nous voulons nous concentrer pour la récupération. La plupart des cartes IPMI et iLO sont installées sur les hôtes qu'elles contrôlent et, par défaut, utilisent le même réseau, à cause duquel les nœuds cibles supposent que les autres nœuds sont hors ligne.

Malheureusement, les caractéristiques de fonctionnement des appareils IPMI et iLo sont rarement prises en compte au moment de l'achat de l'équipement.

Séparation indirecte

Un quorum est également important pour gérer l'exclusion indirecte; si tout est fait correctement, le quorum peut permettre aux survivants de supposer que les nœuds perdus entreront dans un état sûr après une certaine période de temps.

Avec ce paramètre, le temporisateur de surveillance du matériel se réinitialise toutes les N secondes si le quorum n'est pas perdu. Si la minuterie (généralement un multiple de N) expire, l'appareil effectue un arrêt disgracieux de l'alimentation (pas un arrêt).

Cette approche est très efficace, mais sans quorum, il n'y a pas suffisamment d'informations à l'intérieur du cluster pour le gérer. Il n'est pas facile de déterminer la différence entre une panne de réseau et une panne d'hôte partenaire. La raison pour laquelle cela est important est que sans la possibilité de distinguer deux cas, vous êtes obligé de choisir le même comportement dans les deux cas.

Le problème avec le choix d'un mode est qu'il n'y a aucun moyen d'action qui maximiserait l'accessibilité et empêcherait la perte de données.

Si vous décidez de supposer que le nœud partenaire est actif, mais qu'il y a en fait eu un échec, le cluster arrêtera inutilement les services qui devraient fonctionner pour compenser la perte de services du nœud partenaire tombé en panne.
Si vous décidez de supposer que le nœud ne fonctionne pas, mais qu'il s'agissait simplement d'une panne de réseau et que le nœud distant fonctionne réellement, alors, au mieux, vous vous abonnez à une future réconciliation manuelle des ensembles de données résultants.

Quelle que soit l'heuristique que vous utilisez, il est trivial de créer une défaillance qui oblige les deux parties à travailler ou force le cluster à déconnecter les nœuds survivants. Ne pas utiliser le quorum prive vraiment le cluster de l'un des outils les plus puissants de son arsenal.

S'il n'y a pas d'autre alternative, la meilleure approche serait de sacrifier l'accessibilité (ici, l'auteur se réfère au théorème CAP). La haute disponibilité des données corrompues n'aide personne, et la réconciliation manuelle de divers ensembles de données n'est pas non plus un plaisir.

Quorum

Le quorum sonne bien, non?

Le seul inconvénient est que pour l'avoir dans un cluster avec N membres, vous devez conserver la connexion entre N / 2 + 1 de vos nœuds. Ce qui est impossible dans un cluster à deux nœuds après la défaillance d'un nœud.

Ce qui nous conduit finalement à un problème fondamental avec deux nœuds: un
quorum n'a pas de sens dans deux grappes de nœuds, et sans cela, il est impossible de déterminer de manière fiable le plan d'action qui maximise l'accessibilité et empêche la perte de données
Même dans un système de deux nœuds connectés par un câble croisé, il est impossible de distinguer enfin entre la déconnexion du réseau et la défaillance d'un autre nœud. La déconnexion d'une extrémité (dont la probabilité est, bien entendu, proportionnelle à la distance entre les nœuds) sera suffisante pour réfuter toute hypothèse selon laquelle le canal fonctionne de manière égale à la santé du nœud partenaire.

Faire fonctionner le cluster de deux nœuds

Parfois, le client ne peut pas ou ne veut pas acheter un troisième nœud, et nous sommes obligés de chercher une alternative.

Option 1 - Méthode de séparation en double

Le périphérique iLO ou IPMI du nœud est un point de défaillance car, en cas de défaillance, les survivants ne peuvent pas l'utiliser pour mettre le nœud dans un état sûr. Dans un cluster de 3 nœuds ou plus, nous pouvons atténuer cela en calculant le quorum et en utilisant le chien de garde matériel (un mécanisme de désengagement indirect, comme expliqué précédemment). Dans le cas de deux nœuds, nous devrions plutôt utiliser des commutateurs d'alimentation réseau (unités de distribution d'alimentation ou PDU).

Après l'échec, le survivant essaie d'abord de contacter le périphérique de séparation principal (iLO ou IPMI intégré). Si cela réussit, la reprise se poursuit comme d'habitude. Ce n'est qu'en cas de défaillance d'un périphérique iLO / IPMI que l'appel à la PDU se produit, si l'appel réussit, la récupération peut continuer.

Veillez à placer la PDU sur un réseau autre que le trafic de cluster, sinon une seule défaillance du réseau bloquera l'accès aux périphériques d'isolement et bloquera la récupération du service.

Ici, vous pouvez vous demander - la PDU n'est-elle pas un point de défaillance unique? À laquelle la réponse est bien sûr.

Si ce risque est important pour vous, vous n'êtes pas seul: connectez les deux nœuds à deux PDU et demandez au logiciel du cluster de les utiliser lors de l'activation et de la désactivation des nœuds. Désormais, le cluster reste actif si une PDU meurt et qu'une deuxième défaillance d'un autre PDU ou périphérique IPMI est nécessaire pour bloquer la récupération.

Option 2 - Ajout d'un arbitre

Dans certains scénarios, bien que la méthode de séparation en double soit techniquement possible, elle est politiquement complexe. De nombreuses entreprises aiment avoir une certaine séparation entre les administrateurs et les propriétaires d'applications, et les administrateurs réseau soucieux de la sécurité ne sont pas toujours enthousiastes à l'idée de transmettre les paramètres d'accès aux PDU à quiconque.

Dans ce cas, l'alternative recommandée consiste à créer un tiers neutre pouvant compléter le calcul du quorum.

En cas de panne, le nœud devrait pouvoir voir la diffusion de son partenaire ou arbitre afin de restaurer les services. L'arbitre comprend également la fonction de rupture de la connexion, si les deux nœuds peuvent voir l'arbitre, mais ne se voient pas.

Cette option doit être utilisée conjointement avec une méthode indirecte de dissociation, telle qu'une horloge de surveillance matérielle, qui est configurée pour éteindre la machine si elle perd la connexion avec son nœud partenaire et l'arbitre. Ainsi, le survivant peut supposer en toute confiance que son nœud partenaire sera dans un état sûr après l'expiration du temporisateur de surveillance du matériel.

La différence pratique entre l'arbitre et le troisième nœud est que l'arbitre nécessite beaucoup moins de ressources pour son travail et, potentiellement, peut servir plus d'un cluster.

Option 3 - Le facteur humain

La dernière approche consiste pour les survivants à continuer d'exécuter tous les services qu'ils ont déjà effectués, mais pas à en commencer de nouveaux, jusqu'à ce que le problème soit résolu lui-même (restauration du réseau, redémarrage du nœud) ou que la personne n'assume pas la responsabilité de confirmer manuellement que l'autre côté est mort.

Option bonus

Ai-je mentionné que vous pouvez ajouter un troisième nœud?

Deux racks

Pour les besoins de l'argument, imaginons que je vous ai convaincu des mérites du troisième nœud, maintenant nous devons considérer l'emplacement physique des nœuds. S'ils sont placés (et alimentés) dans le même rack, cela représente également SPoF, et celui qui ne peut pas être résolu en ajoutant un deuxième rack.

Si cela est surprenant, réfléchissez à ce qui se passera si le rack à deux nœuds tombe en panne et comment le nœud survivant fera la distinction entre ce cas et la défaillance du réseau.

Réponse courte: ce n'est pas possible, et là encore nous traitons tous les problèmes dans le cas de deux nœuds. Ou survivant:

ignore le quorum et tente de manière incorrecte de lancer la récupération pendant les pannes de réseau (la possibilité de terminer la séparation est une histoire distincte et dépend si les PDU sont impliquées et si elles partagent la puissance de l'un des racks), ou
respecte le quorum et se déconnecte prématurément lorsque son nœud partenaire tombe en panne

Dans tous les cas, deux racks ne valent pas mieux qu'un, et les nœuds doivent soit recevoir des alimentations indépendantes, soit être répartis sur trois (ou plus, selon le nombre de nœuds que vous possédez).

Deux centres de données

À ce stade, les lecteurs qui ne sont plus opposés au risque peuvent envisager de se remettre d'un accident. Que se passe-t-il lorsqu'un astéroïde entre dans un centre de données unique avec nos trois nœuds répartis sur trois racks différents? Évidemment, Bad Things, mais selon vos besoins, l'ajout d'un deuxième centre de données peut ne pas suffire.

Si tout est fait correctement, le deuxième centre de données vous fournit (et cela est raisonnable) une copie à jour et cohérente de vos services et de leurs données. Cependant, comme dans les scénarios avec deux nœuds et deux racks, le système ne dispose pas de suffisamment d'informations pour garantir une disponibilité maximale et éviter les dommages (ou la divergence des ensembles de données). Même s'il y a trois nœuds (ou racks), leur distribution uniquement dans deux centres de données laisse le système incapable de prendre de manière fiable la bonne décision en cas (maintenant beaucoup plus probable) d'un événement que les deux parties ne peuvent pas se connecter.

Cela ne signifie pas qu'une solution avec deux centres de données ne convient jamais. Les entreprises veulent souvent que les gens soient au courant avant de prendre une mesure exceptionnelle lors du passage à un centre de données de sauvegarde. Gardez à l'esprit que si vous souhaitez automatiser l'échec, vous aurez besoin d'un troisième centre de données pour que le quorum soit logique (directement ou via un arbitre), ou vous trouverez un moyen de désactiver de manière fiable l'ensemble du centre de données.

Cluster à deux nœuds - le diable en détail