Bonjour Habr ! Je vous présente la traduction de l'article de l'auteur Andrew Beekhof.
Beaucoup de gens préfèrent les clusters composés de deux nœuds, car ils semblent conceptuellement plus simples, et en plus, ils sont aussi 33 % moins chers que leurs homologues à trois nœuds. Bien qu'il soit tout à fait possible de créer un bon cluster à partir de deux nœuds, dans la plupart des cas, en raison de scénarios non pris en compte, cette configuration entraînera de nombreux problèmes non évidents.
La première étape pour créer tout système à haute disponibilité est d'identifier et d'essayer d'éliminer les points de défaillance uniques, souvent abrégés par 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 d'indisponibilité. Cela découle au moins du fait que la protection typique contre le risque consiste à introduire une certaine redondance, ce qui conduit à une augmentation de la complexité du système et à l'apparition de nouveaux points de défaillance. Par conséquent, nous acceptons dès le départ des compromis et nous nous concentrons sur les événements liés aux points de défaillance uniques, plutôt que sur des chaînes d'événements connexes et donc de moins en moins probables.
Compte tenu des compromis, nous ne cherchons pas seulement des SPoF, mais nous équilibrons également les risques et les conséquences, ce qui peut entraîner des conclusions différentes sur ce qui est critique et ce qui ne l'est pas pour chaque déploiement.
Tout le monde n'a pas besoin de fournisseurs d'électricité alternatifs avec des lignes de transmission 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 appelé, essayant de prévenir la compagnie d'électricité, jusqu'à ce que le transformateur défectueux explose.
Un point de départ naturel est d'avoir plus d'un nœud dans le système. Cependant, avant qu'un système puisse déplacer des services sur le nœud restant en vie après une défaillance, il faut généralement s'assurer que les services déplacés ne sont pas actifs ailleurs.
Un cluster à deux nœuds n'a pas de problèmes si, en cas de défaillance, les deux nœuds gèrent le même site Web statique. Cependant, tout change si les deux parties gèrent indépendamment une queue de tâches partagée ou offrent un accès non coordonné en écriture à une base de données répliquée ou à un système de fichiers partagé.
Ainsi, pour éviter la perte de données due à la défaillance d'un nœud, nous comptons sur ce qu'on appelle la "déconnexion" (fencing).
Le principe de déconnexion
Au cœur du principe de déconnexion se pose la question suivante : un nœud concurrent peut-il endommager des données ? Si la corruption des données est un scénario probable, une bonne solution consiste à isoler le nœud des requêtes entrantes ainsi que de l'espace de stockage persistant. L'approche la plus courante de déconnexion consiste à désactiver les nœuds défaillants.
Il existe deux catégories de méthodes de déconnexion que je vais appeler directes et indirectes, mais qui peuvent également être appelées actives et passives. Les méthodes directes comprennent des actions de la part des nœuds survivants, comme l'interaction avec un dispositif IPMI (Intelligent Platform Management Interface — interface pour le monitoring et la gestion à distance de l'état physique du serveur) ou iLO (mécanisme de gestion des serveurs en l'absence d'accès physique), tandis que les méthodes indirectes dépendent du nœud défaillant pour reconnaître d'une manière ou d'une autre qu'il est en mauvais état (ou, du moins, qu'il empêche les autres membres de se rétablir) et de signaler la nécessité de désactiver le nœud défaillant.
Le quorum aide dans le cas où l'on utilise à la fois des méthodes directes et indirectes.
Déconnexion directe
Dans le cas d'une déconnexion directe, nous pouvons utiliser le quorum pour éviter les courses de déconnexion en cas de défaillance du réseau.
Avec le concept de quorum, le système dispose de suffisamment d'informations (même sans connexion avec ses partenaires) pour que les nœuds sachent automatiquement s'ils doivent initier la déconnexion et/ou la récupération.
Sans quorum, les deux parties d'une séparation réseau supposent légitimement que l'autre partie est morte et vont chercher à se déconnecter l'une de l'autre. Dans le pire des cas, les deux parties parviennent à désactiver l'ensemble du cluster. Un scénario alternatif serait un deathmatch, un cycle infini de nœuds apparaissant, ne voyant pas leurs pairs, les redémarrant et initiant une récupération juste pour redémarrer lorsque leur pair suit la même logique.
Le problème de l'isolement réside dans le fait que les dispositifs les plus souvent utilisés deviennent inaccessibles en raison des mêmes événements de panne sur lesquels nous souhaitons nous appuyer 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 amène les nœuds cibles à croire que les autres nœuds sont hors ligne.
Malheureusement, les particularités du fonctionnement des dispositifs IPMI et iLo sont rarement prises en compte lors de l'achat de matériel.
Isolement indirect
Le quorum est également important pour la gestion des isolations indirectes. Si tout est fait correctement, le quorum peut permettre aux nœuds survivants de supposer que les nœuds perdus passeront à un état sécurisé après une certaine période.
Avec cette configuration, le timer de surveillance matériel est réinitialisé toutes les N secondes, à condition que le quorum ne soit pas perdu. Si le timer (généralement plusieurs multiples de N) expire, l'appareil effectue un arrêt non gracieux (pas de shutdown).
Cette approche est très efficace, mais sans quorum pour sa gestion, il y a pas assez d'informations au sein du cluster. Il n'est pas facile de faire la distinction entre une panne de réseau et un échec de nœud partenaire. La raison pour laquelle cela a de l'importance est que sans la possibilité de différencier les deux cas, vous êtes contraint de choisir le même mode de comportement dans les deux situations.
Le problème avec le choix d'un mode unique est qu'il n'existe pas de plan d'action qui maximise la disponibilité tout en évitant la perte de données.
- Si vous choisissez de supposer que le nœud partenaire est actif alors qu'il s'est réellement arrêté, le cluster cessera trop tôt les services qui auraient dû fonctionner pour compenser la perte des services du nœud partenaire en panne.
- Si vous choisissez de supposer que le nœud ne fonctionne pas alors qu'il ne s'agissait que d'une panne de réseau et que le nœud distant fonctionne en réalité, alors au mieux, vous vous engagez à une certaine vérification manuelle future des ensembles de données résultants.
Quelle que soit l'heuristique que vous utilisez, il est trivial de créer une panne qui mettra soit les deux parties en marche, soit poussera le cluster à arrêter 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 consiste à sacrifier la disponibilité (l'auteur fait ici référence au théorème CAP). Une haute disponibilité de données corrompues ne sert à personne, et la vérification manuelle de divers ensembles de données n'est pas non plus agréable.
Quorum
Le quorum sonne bien, non ?
Le seul inconvénient est que pour l'avoir dans un cluster avec N membres, vous devez maintenir une connexion entre N / 2 + 1 de vos nœuds. Ce qui est impossible dans un cluster avec deux nœuds après la panne d'un nœud.
Ce qui nous amène finalement à un problème fondamental avec deux nœuds :
le quorum n'a pas de sens dans des clusters à deux nœuds, et sans cela, il est impossible de déterminer de manière fiable le cours d'action qui maximise la disponibilité et prévient 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 faire la différence définitive entre une panne réseau et la défaillance d'un autre nœud. Une déconnexion d'une extrémité (la probabilité de cela est évidemment proportionnelle à la distance entre les nœuds) sera suffisante pour invalider toute hypothèse selon laquelle la fonctionnalité du canal est égale à la santé du nœud partenaire.
Faire fonctionner un cluster à deux nœuds
Parfois, le client ne peut pas ou ne souhaite pas acquérir un troisième nœud, et nous devons chercher une alternative.
Option 1 - Méthode de contournement redondante
Le dispositif iLO ou IPMI d'un nœud constitue un point de défaillance, car en cas de panne, les nœuds restants ne peuvent pas l'utiliser pour mettre le nœud en état sûr. Dans un cluster de 3 nœuds ou plus, nous pouvons atténuer cela par le calcul du quorum et l'utilisation d'un surveillance matérielle (mécanisme de contournement indirect, comme discuté précédemment). Dans le cas de deux nœuds, nous devons utiliser plutôt des commutateurs d'alimentation (unités de distribution d'alimentation ou PDUs).
Après une panne, le survivant essaie d'abord de se connecter à l'appareil principal de contournement (iLO ou IPMI intégré). Si cela réussit, la récupération se poursuit normalement. Ce n'est que si l'appareil iLO / IPMI échoue que l'on se tourne vers le PDU ; si l'appel est réussi, la récupération peut se poursuivre.
Assurez-vous de placer le PDU sur un réseau distinct de celui du trafic de cluster, sinon une seule défaillance réseau bloquera l'accès à la fois aux dispositifs de démarcation et empêchera la récupération des services.
Ici, vous pouvez demander : le dispositif PDU n'est-il pas un point de défaillance unique ? La réponse est bien sûr, il l'est.
Si ce risque est significatif pour vous, vous n'êtes pas seul : connectez les deux nœuds à deux PDU et configurez le logiciel de cluster pour utiliser les deux lors du démarrage et de l'arrêt des nœuds. Ainsi, le cluster reste actif si un PDU échoue, et pour bloquer la récupération, il faudra une seconde défaillance soit d'un autre PDU, soit de l'appareil IPMI.
Option 2 - Ajout d'un arbitre
Dans certains scénarios, bien que la méthode de démarcation redondante soit techniquement possible, elle est politiquement complexe. De nombreuses entreprises préfèrent avoir une séparation claire 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 à qui que ce soit les paramètres d'accès au PDU.
Dans ce cas, une alternative recommandée est de créer un tiers neutre qui peut compléter le calcul du quorum.
En cas de défaillance, le nœud doit être capable de voir le partenaire ou l'arbitre pour restaurer les services. L'arbitre inclut également une fonction de rupture de connexion, si les deux nœuds peuvent voir l'arbitre mais pas l'un l'autre.
Cette option doit être utilisée en couple avec une méthode de démarcation indirecte, comme un minuteur de surveillance matériel, qui est configuré pour éteindre la machine si elle perd la connexion avec son nœud partenaire et l'arbitre. Ainsi, celui qui survit peut raisonnablement supposer que son nœud partenaire sera dans un état sécurisé après l'expiration du minuteur de surveillance matériel.
La différence pratique entre un arbitre et un troisième nœud réside dans le fait que l'arbitre nécessite beaucoup moins de ressources pour fonctionner et peut potentiellement servir plus d'un cluster.
Option 3 - Facteur humain
La dernière approche consiste à faire en sorte que les survivants continuent d'exécuter tous les services qu'ils effectuaient déjà, mais qu'ils ne lancent pas de nouveaux tant que le problème ne se résout pas de lui-même (récupération du réseau, redémarrage du nœud) ou qu'un humain ne prenne la responsabilité de confirmer manuellement que l'autre partie est morte.
Option bonus
Je vous ai déjà dit que vous pouvez ajouter un troisième nœud ?
Deux racks
Pour les besoins de l'argument, imaginons que je vous ai convaincu des avantages d'un troisième nœud, maintenant nous devons considérer l'emplacement physique des nœuds. S'ils sont hébergés (et alimentés) dans le même rack, cela constitue également un SPoF, et cela ne peut pas être résolu en ajoutant un deuxième rack.
Si cela semble surprenant, pensez à ce qui se passerait si le rack avec deux nœuds échouait, et comment le nœud survivant distinguerait ce cas d'une panne de réseau.
La réponse courte : c'est impossible, et nous faisons à nouveau face à tous les problèmes liés à deux nœuds. Soit le survivant :
- ignore le quorum et tente incorrectement d'initier une récupération pendant les pannes réseau (la possibilité de terminer le déchaînement est une autre histoire et dépend du PDU impliqué et de s'il partage de l'énergie avec l'un des racks), ou
- respecte le quorum et s'éteint prématurément lorsque son nœud partenaire échoue.
Dans tous les cas, deux racks ne valent pas mieux qu'un, et les nœuds doivent soit avoir des sources d'alimentation indépendantes, soit être répartis sur trois (ou plus, en fonction du nombre de nœuds) racks.
Deux centres de données
À ce stade, les lecteurs qui sont moins enclins à prendre des risques peuvent penser à la reprise après sinistre. Que se passe-t-il lorsque qu'un astéroïde frappe un centre de données avec nos trois nœuds répartis sur trois racks différents ? Évidemment, des choses mauvaises, mais selon vos besoins, ajouter un deuxième centre de données peut ne pas être suffisant.
Si tout est fait correctement, le deuxième data center vous fournit (et c'est raisonnable) une copie actuelle 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 manque d'informations pour garantir une disponibilité maximale et éviter la corruption (ou les divergences des ensembles de données). Même avec trois nœuds (ou racks), leur répartition uniquement sur deux centres de données laisse le système incapable de prendre des décisions fiables en cas d'événements (maintenant beaucoup plus probables) qui affectent les deux parties.
Cela ne signifie pas qu'une solution à deux data centers n'est jamais adaptée. Les entreprises souhaitent souvent qu'une personne soit au courant avant de prendre des mesures exceptionnelles pour passer à un data center de secours. Gardez simplement à l'esprit que si vous souhaitez automatiser la défaillance, vous aurez besoin d'un troisième data center pour que le quorum ait un sens (directement ou via un arbitre), ou vous devrez trouver un moyen de déconnecter de manière fiable l'ensemble du data center.
Source : habr.com
