Quelqu'un peut-il m'expliquer comment la haute disponibilité ("HA") fonctionne pour une application web ... car je suppose que HA signifie qu'il n'existe pas de point de défaillance unique.
Cependant, même si un équilibreur de charge est utilisé, n'est-ce pas le point de défaillance unique ?
J'ai trouvé cet article sur le sujet : http://www.tenereillo.com/GSLBPageOfShame.htm
En fait, si vous n'avez pas besoin de sessions collantes de longue durée, vous pouvez configurer vos serveurs DNS pour qu'ils renvoient plusieurs enregistrements A (adresses IP) pour votre site web.
Les navigateurs web sont suffisamment intelligents pour essayer toutes les adresses jusqu'à ce qu'ils en trouvent une qui fonctionne.
-1 ; ceci contredit de multiples sources que j'ai vues (exemple : serverfault.com/a/328321/147556 ) qui prétendent que le renvoi de plusieurs enregistrements A (AKA "round robin DNS") fait no ne font pas en sorte que les navigateurs (qui sont le principal type de clients HTTP dont nous nous soucions lorsque nous parlons de sites Web) passent rapidement en revue les IP pour en trouver une qui fonctionne en cas de défaillance, mais au lieu de cela, ils subissent de longs délais d'attente, et qu'en tant que tel, avoir plusieurs IP dans un enregistrement A n'est pas une solution à la "haute disponibilité". Peut-être que tout le monde se trompe, ou peut-être que les choses ont changé depuis 2010, mais je suppose prudemment que non.
En termes simples, la haute disponibilité peut être définie comme le fonctionnement d'un système 24 heures sur 24, 7 jours sur 7, sans temps d'arrêt, même en cas de défaillance matérielle ou logicielle. En d'autres termes, une application à tolérance de pannes. Cela permet de garantir une utilisation ininterrompue de l'application pour les utilisateurs prévus.
Plus d'informations sur Architecture de déploiement à haute disponibilité
Cela fonctionne de la manière suivante : vous configurez deux serveurs Proxy HA avec un battement de cœur, de sorte que lorsque l'un d'entre eux tombe en panne (ne répond plus aux requêtes), il est retiré du cluster. Les requêtes du serveur HA Proxy peuvent être transmises aux serveurs Web en mode round robin, et si un serveur Web tombe en panne, les serveurs HA Proxy n'essaient pas de le contacter tant qu'il n'est pas en vie. Les serveurs web stockent toutes les informations dynamiques dans la base de données, qui est répliquée sur deux instances MySQL. Comme vous pouvez le constater, HA Proxy et Cluster MySQL (ou simplement la réplication MySQL) ainsi que IP Clustering sont ici la clé.
Bien sûr qu'il l'est quand il est utilisé seul. La configuration habituelle de haute disponibilité comprend au moins deux équilibreurs de charge fonctionnant en cluster dans une configuration active/active ou active/passive. Pour augmenter encore la disponibilité, vous pouvez avoir deux fournisseurs d'accès Internet différents (ou des centres de données géographiquement distribués) qui exécutent chacun une paire d'équilibreurs de charge en cluster. Ensuite, vous configurez un enregistrement DNS A qui se résout à deux adresses IP publiques distinctes, ce qui garantit un traitement round-robin répartissant les requêtes DNS de manière égale (CloudFlare est très rapide et fiable à cet égard). Il est également possible de renvoyer l'adresse IP du centre de données le plus proche de votre emplacement géographique d'origine en utilisant quelque chose comme PowerDNS dnsdist. C'est ce que font les grands acteurs pour rendre leurs services hautement disponibles.
Veuillez lire https://docs.oracle.com/cd/E23824_01/html/821-1453/gkkky.html pour plus de clarté. En fait, les deux équilibreurs de charge utilisent la même adresse IP virtuelle (vip). https://techterms.com/definition/vip ).
L'architecture des AP est un domaine entier et de nombreux livres ont été écrits sur le sujet, il est donc difficile de répondre à cette question dans un court paragraphe.
Pour résumer la situation idéale, vous utiliseriez plusieurs serveurs, interconnectés à une couche de plusieurs équilibreurs de charge. Les nœuds et les LB seront situés dans plusieurs centres de données différents et connectés à différents réseaux fédérateurs. Idéalement, les centres de données seront situés dans le monde entier.
En bref, tous les composants seront redondants, y compris les équilibreurs de charge.
Pour un point de départ, voir Wikipedia pour Cluster haute disponibilité
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
0 votes
Pas quand vous avez deux équilibreurs de charge configurés pour le basculement.
16 votes
@Dave Newton, mais comment 2 équilibreurs de charge répondent-ils à une seule requête entrante ? J'essaie d'imaginer, donc disons que je veux visiter exemple.com Si mon navigateur résout l'adresse IP et envoie une seule requête à l'adresse IP de example.com, comment est-il possible que plusieurs serveurs (équilibreurs de charge) puissent "répondre" à la requête web provenant de mon navigateur ? À un moment donné, n'y a-t-il pas une seule pièce de matériel qui constitue le point de défaillance ?
1 votes
Ils ne le font pas, l'un d'eux le fait. Si l'un commence à échouer, l'autre prend le relais. Il y a une variété de mécanismes pour gérer cela, tous au-delà de la portée d'une question sur l'OS, vraiment. Desmond a déjà dit tout cela.
9 votes
Argh. Je ressens votre frustration, nickb. Il est très clair que le simple fait de changer votre adresse IP pour pointer vers un load-balancer (ou un load-balancer-balancer, ou un load-balancer-balancer-balancer) ne permet pas d'atteindre la haute disponibilité, car alors que L'équilibreur de charge peut tomber en panne. Pourtant, les réponses à cette question sur l'ensemble du réseau semblent consister soit à "Il suffit d'ajouter une autre couche d'équilibrage de charge !" (ce qui n'est manifestement pas utile) ou "C'est un sujet très compliqué que tu es trop nul pour comprendre". . @DaveNewton a réussi à fournir les deux des renvois inutiles, ici.
0 votes
@MarkAmery La tolérance aux pannes c'est bien au-delà du champ d'application d'une réponse SO, même si elle était sur le sujet. Néanmoins, malgré vos cris de "oh, ça ne sert à rien", c'est la réponse : la mise à l'échelle des équilibreurs/serveurs/infra est la solution.
5 votes
@DaveNewton Non, c'est vraiment, évidemment pas la solution. Faire en sorte que votre IP soit résolue vers un équilibreur de charge à point d'entrée unique est un point de défaillance unique, tout comme le fait de la faire résoudre vers un serveur web unique, que cet équilibreur de charge ait une ou 100 couches supplémentaires d'équilibreurs de charge derrière lui. Qu'est-ce qui est difficile à comprendre ici ? La vraie solution implique clairement autre chose que la simple mise à l'échelle des couches d'équilibreurs de charge. (Je pense que cela implique de faire des choses astucieuses avec BGP, bien que cela dépasse largement mon domaine d'expertise).
0 votes
@MarkAmery C'est pourquoi j'ai dit plusieurs équilibreurs ? Je ne suis pas sûr Ce qui est difficile à comprendre ici, c'est que pour éliminer les points uniques de défaillance, il faut mettre en place des bascules. Ces derniers peuvent également tomber en panne - il s'agit d'avoir une redondance et d'espérer que les pannes puissent être résolues. Comment pensez-vous que les grands sites Web fonctionnent ? Plusieurs points d'entrée, serveurs d'applications, bases de données. Tissu commutable pour réacheminer les demandes, internes ou externes, lorsque des défaillances sont détectées. Je ne connais pas de site de moyenne ou grande envergure qui ait un seul point d'entrée. tout ce qui est . Hausser les épaules - cela a fonctionné pour tous les sites auxquels j'ai participé, de 10sK à 10sM.
3 votes
@DaveNewton "C'est pourquoi j'ai dit plusieurs équilibreurs ?" - coordonné comment si ce n'est par un autre équilibreur de charge en face d'eux ? Toute la question ici est de savoir ce que mécanisme il existe un moyen de laisser un serveur (ou un équilibreur de charge) prendre le relais lorsqu'un autre tombe en panne, en plus de leur coller un autre SPOF en face. Je n'ai aucune idée de ce qu'est ce mécanisme, c'est pourquoi j'ai atterri ici ; le fait de rajouter des couches au problème ne le résout pas. C'est peut-être le "tissu commutable" auquel vous faites allusion, bien que je ne sache pas ce que sont "tissu", "sK" ou "sM" et qu'aucun d'entre eux ne résiste à une recherche sur Google.
0 votes
@MarkAmery Ce sont des nombres d'utilisateurs. Je pense que nous nous dépassons, mais il existe de nombreuses ressources que vous pouvez consulter pour comprendre les bases de l'infrastructure HA.
3 votes
@MarkAmery Je suis d'accord avec vous, c'est pourquoi je lis jusqu'à la fin du chat.
0 votes
En clair, il s'agit de s'assurer que le premier équilibreur de charge résolu par DNS est HA. Il doit y avoir un système pour surveiller sa disponibilité (comme sentinel dans redis), qui -- par exemple par une décision du quorum -- peut décider que l'équilibreur de charge est tombé en panne, et envoyer des commandes à un remplaçant en attente à chaud pour prendre le relais (par exemple en assumant l'IP vers laquelle le DNS se résout).