Salut Habr ! Je présente à votre attention la traduction de l'article par Andrew Beekhof.
De nombreuses personnes préfèrent les clusters à deux nœuds car ils semblent conceptuellement plus simples et sont également 33 % moins chers que leurs homologues à trois nœuds. Bien qu'il soit tout à fait possible de constituer un bon cluster de deux nœuds, dans la plupart des cas, en raison de scénarios non envisagés, une telle configuration créera de nombreux problèmes peu évidents.
La première étape pour créer 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 qu’il est impossible d’éliminer tous les risques possibles d’indisponibilité d’un système. Cela vient du fait qu’une défense typique contre le risque consiste à introduire une certaine redondance, ce qui conduit à une complexité accrue du système et à l’émergence de nouveaux points de défaillance. C’est pourquoi nous faisons d’abord un compromis et nous concentrons sur les événements associés à des points de défaillance individuels, et non sur des chaînes d’événements liés et donc de moins en moins probables.
Compte tenu des compromis, nous recherchons non seulement le SPoF, mais nous équilibrons également les risques et les conséquences, de sorte que la conclusion sur ce qui est critique et ce qui ne l'est pas peut différer pour chaque déploiement.
Tout le monde n’a pas besoin de fournisseurs d’électricité alternatifs disposant de lignes électriques indépendantes. Bien que la paranoïa ait porté ses fruits pour au moins un client lorsque leur surveillance a détecté un transformateur défectueux. Le client a passé des appels téléphoniques pour tenter d'alerter la compagnie d'électricité jusqu'à ce que le transformateur défectueux explose.
Un point de départ naturel consiste à avoir plus d’un nœud dans le système. Cependant, avant que le système puisse déplacer les services vers le nœud survivant après une panne, il doit généralement s'assurer que les services déplacés ne sont pas actifs ailleurs.
Il n'y a aucun inconvénient à un cluster à deux nœuds si une panne entraîne les deux nœuds desservant le même site Web statique. Cependant, les choses changent si le résultat est que les deux parties gèrent indépendamment une file d'attente de tâches partagée ou fournissent un accès en écriture non coordonné à une base de données répliquée ou à un système de fichiers partagé.
Par conséquent, pour éviter la corruption des données suite à la défaillance d'un seul nœud, nous nous appuyons sur quelque chose appelé "dissociation" (escrime).
Le principe de dissociation
Au cœur du principe de dissociation se trouve 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, une bonne solution serait d'isoler le nœud à la fois des requêtes entrantes et du stockage persistant. L'approche la plus courante en matière de dissociation consiste à déconnecter les nœuds défectueux.
Il existe deux catégories de méthodes de dissociation, que j'appellerai droit и indirect, mais on peut également les appeler actif и passif. Les méthodes directes incluent des actions de la part des pairs survivants, telles que l'interaction avec un périphérique IPMI (Intelligent Platform Management Interface) ou iLO (un mécanisme de gestion des serveurs en l'absence d'accès physique à ceux-ci), tandis que les méthodes indirectes reposent sur le périphérique défaillant. nœud pour reconnaître d'une manière ou d'une autre qu'il est dans un état malsain (ou au moins empêcher les autres membres de récupérer) et signaler sur la nécessité de déconnecter le nœud défaillant.
Quorum est utile lors de l'utilisation de méthodes directes et indirectes.
Dissociation directe
Dans le cas d'une dissociation directe, nous pouvons utiliser le quorum pour empêcher les courses à la dissociation en cas de panne du réseau.
Avec le concept de quorum, il y a suffisamment d'informations dans le système (même sans se connecter à ses pairs) pour que les nœuds sachent automatiquement s'ils doivent initier la dissociation et/ou la récupération.
Sans quorum, les deux côtés d’un réseau divisé supposeront à juste titre que l’autre côté est mort et chercheront à se dissocier de l’autre. Dans le pire des cas, les deux parties parviennent à arrêter l’ensemble du cluster. Un scénario alternatif est un match à mort, une boucle sans fin de nœuds apparaissant, ne voyant pas leurs pairs, les redémarrant et initiant une récupération uniquement pour redémarrer lorsque leur homologue suit la même logique.
Le problème de la dissociation est que les appareils les plus couramment utilisés deviennent indisponibles en raison des mêmes événements de panne que ceux que nous souhaitons cibler 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, ce qui fait croire aux hôtes cibles que les autres hôtes sont hors ligne.
Malheureusement, les fonctionnalités de fonctionnement des appareils IPMI et iLo sont rarement prises en compte au moment de l'achat de l'équipement.
Dissociation indirecte
Le quorum est également important pour gérer la dissociation indirecte ; s'il est effectué correctement, le quorum peut permettre aux survivants de supposer que les nœuds perdus passeront à un état sûr après une certaine période de temps.
Avec cette configuration, le temporisateur de surveillance matérielle est réinitialisé toutes les N secondes si le quorum n'est pas perdu. Si la minuterie (généralement plusieurs multiples de N) expire, l'appareil effectue une mise hors tension disgracieuse (pas un arrêt).
Cette approche est très efficace, mais sans quorum, il n'y a pas suffisamment d'informations au sein du cluster pour la gérer. Il n’est pas facile de faire la différence entre une panne de réseau et une panne de nœud homologue. La raison pour laquelle cela est important est que sans la possibilité de faire la différence entre les deux cas, vous êtes obligé de choisir le même comportement dans les deux cas.
Le problème lié au choix d’un mode est qu’il n’existe aucun plan d’action permettant d’optimiser la disponibilité et d’éviter la perte de données.
- Si vous choisissez de supposer qu'un nœud homologue est actif mais qu'il échoue en fait, le cluster arrêtera inutilement les services qui seraient en cours d'exécution pour compenser la perte de services du nœud homologue défaillant.
- Si vous décidez de supposer qu'un nœud est en panne, mais qu'il s'agit simplement d'une panne de réseau et qu'en fait le nœud distant est fonctionnel, alors au mieux, vous vous inscrivez à un futur rapprochement manuel des ensembles de données résultants.
Quelle que soit l'heuristique que vous utilisez, il est trivial de créer un échec qui entraînera soit l'échec des deux côtés, soit l'arrêt du cluster par les nœuds survivants. Ne pas utiliser le quorum prive véritablement le cluster d’un des outils les plus puissants de son arsenal.
S’il n’y a pas d’autre alternative, la meilleure approche est de sacrifier la disponibilité (l’auteur fait ici référence au théorème CAP). La haute disponibilité des données corrompues n’aide personne, et réconcilier manuellement différents ensembles de données n’est pas non plus amusant.
Quorum
Le quorum semble génial, non ?
Le seul inconvénient est que pour l'avoir dans un cluster avec N membres, vous devez avoir une connexion entre N/2+1 de vos nœuds restants. Ce qui n'est pas possible dans un cluster à deux nœuds après la panne d'un nœud.
Ce qui nous amène finalement au problème fondamental avec deux nœuds :
Le quorum n'a pas de sens dans les clusters à deux nœuds, et sans lui, il est impossible de déterminer de manière fiable la marche à suivre qui maximise la disponibilité et évite la perte de données.
Même dans un système de deux nœuds reliés par un câble croisé, il est impossible de distinguer définitivement entre une panne de réseau et une panne de l'autre nœud. Désactiver une extrémité (dont la probabilité est bien entendu proportionnelle à la distance entre les nœuds) suffira à invalider toute hypothèse selon laquelle la santé du lien est égale à la santé du nœud partenaire.
Faire fonctionner un cluster à deux nœuds
Parfois, le client ne peut ou ne veut pas acheter un troisième nœud et nous sommes obligés de chercher une alternative.
Option 1 - Méthode de dissociation en double
Le périphérique iLO ou IPMI d'un nœud représente un point de défaillance car, s'il tombe en panne, les survivants ne peuvent pas l'utiliser pour amener le nœud dans un état sûr. Dans un cluster de 3 nœuds ou plus, nous pouvons atténuer ce problème en calculant le quorum et en utilisant un système de surveillance matériel (un mécanisme de dissociation indirect, comme indiqué précédemment). Dans le cas de deux nœuds, nous devons plutôt utiliser des unités de distribution d’énergie (PDU) réseau.
Après un échec, le survivant tente d'abord de contacter le périphérique de dissociation principal (iLO ou IPMI intégré). Si cela réussit, la récupération se poursuit comme d'habitude. La PDU n'est accessible que si le périphérique iLO/IPMI tombe en panne ; si l'accès réussit, la récupération peut continuer.
Assurez-vous de placer la PDU sur un réseau différent de celui du trafic du cluster, sinon une seule panne de réseau bloquera l'accès aux deux périphériques de dissociation et bloquera la restauration des services.
Ici, vous pouvez vous demander : la PDU est-elle un point de défaillance unique ? À cela 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 indiquez au logiciel de clustering d'utiliser les deux lors de la mise sous et hors tension des nœuds. Le cluster reste désormais actif si une PDU meurt, et une deuxième panne de l'autre PDU ou du périphérique IPMI sera nécessaire pour bloquer la récupération.
Option 2 - Ajout d'un arbitre
Dans certains scénarios, même si la méthode de dissociation en double est techniquement possible, elle est politiquement difficile. 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 partager les paramètres d'accès aux PDU avec qui que ce soit.
Dans ce cas, l’alternative préconisée est de créer un tiers neutre pouvant compléter le calcul du quorum.
En cas de panne, un nœud doit pouvoir voir les ondes de son homologue ou de son arbitre afin de restaurer les services. L'arbitre inclut également une fonction de déconnexion si les deux nœuds peuvent voir l'arbitre mais ne peuvent pas se voir.
Cette option doit être utilisée conjointement avec une méthode de dissociation indirecte, telle qu'un minuteur de surveillance matériel, configuré pour arrêter une machine si elle perd la connexion avec son homologue et son nœud arbitre. Ainsi, un survivant peut raisonnablement supposer que son nœud homologue sera dans un état sécurisé après l'expiration du délai de surveillance matériel.
La différence pratique entre un arbitre et un troisième nœud est qu'un arbitre nécessite beaucoup moins de ressources pour fonctionner et peut potentiellement servir plusieurs clusters.
Option 3 - Facteur humain
L'approche finale consiste pour les survivants à continuer d'exécuter les services qu'ils exécutaient déjà, mais à ne pas en démarrer de nouveaux jusqu'à ce que le problème se résolve de lui-même (restauration du réseau, redémarrage du nœud) ou qu'une personne prenne 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 supports
Pour les besoins de l'argumentation, supposons que je vous ai convaincu des mérites du troisième nœud, il faut maintenant considérer la disposition physique des nœuds. S'ils sont hébergés (et alimentés) dans le même rack, cela constitue également un SPoF, qui ne peut être résolu en ajoutant un deuxième rack.
Si cela vous surprend, réfléchissez à ce qui se passerait si un rack comportant deux nœuds tombait en panne et à la manière dont le nœud survivant ferait la différence entre cela et une panne de réseau.
La réponse courte est que ce n'est pas possible, et encore une fois, nous sommes confrontés à tous les problèmes du cas à deux nœuds. Ou survivant :
- ignore le quorum et tente de manière incorrecte de lancer la restauration lors de pannes de réseau (la capacité à terminer la dissociation est une autre histoire et dépend si la PDU est impliquée et si elle partage l'alimentation avec l'un des racks), ou
- respecte le quorum et se déconnecte prématurément lorsque son nœud homologue échoue
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 racks (ou plus, selon le nombre de nœuds dont vous disposez).
Deux centres de données
À ce stade, les lecteurs qui ne sont plus réticents à prendre des risques voudront peut-être envisager la reprise après sinistre. Que se passe-t-il lorsqu'un astéroïde frappe le même centre de données avec nos trois nœuds répartis sur trois racks différents ? C'est évidemment de mauvaises choses, mais selon vos besoins, l'ajout d'un deuxième centre de données peut ne pas suffire.
S'il est fait correctement, le deuxième centre de données vous fournit (et raisonnablement) une copie à jour et cohérente de vos services et de leurs données. Cependant, comme dans les scénarios à deux nœuds et deux racks, il n'y a pas suffisamment d'informations dans le système pour garantir une disponibilité maximale et éviter toute corruption (ou divergences dans les ensembles de données). Même avec trois nœuds (ou racks), leur répartition sur seulement deux centres de données empêche le système de prendre la bonne décision de manière fiable en cas d'événement (désormais beaucoup plus probable) où les deux parties ne peuvent pas communiquer.
Cela ne veut pas dire qu’une solution à double datacenter n’est jamais adaptée. Les entreprises souhaitent souvent qu’une personne soit informée avant de prendre la décision extraordinaire de migrer vers un centre de données de sauvegarde. Gardez simplement à l'esprit que si vous souhaitez automatiser la panne, vous aurez soit besoin d'un troisième centre de données pour que le quorum ait un sens (soit directement, soit par l'intermédiaire d'un arbitre), ou vous trouverez un moyen d'arrêter de manière fiable l'intégralité des données. centre.
Source: habr.com