Comment puis-je déployer un cluster haproxy évolutif et fiable sur Amazon EC2?

Nous avons besoin de fonctionnalités plus avancées que celles fournies par ELB (principalement l'inspection L7), mais il n'est pas évident de gérer des choses comme le rythme cardiaque et la haute disponibilité avec quelque chose comme un haproxy utilisant EC2. Il est fort probable que nous ayons besoin de 3 nœuds haproxy ou plus dans le cluster, donc un simple battement de cœur entre deux nœuds ne fonctionnera pas.

On dirait que la couche à battre devant les nœuds haproxy serait la voie à suivre, peut-être en utilisant IPVS, mais en gérant les changements de configuration au fur et à mesure que le cluster EC2 change (soit via des changements intentionnels, comme l'expansion, soit involontaire, comme la perte d'un Nœud EC2) semble non trivial.

De préférence, la solution couvrirait au moins deux zones de disponibilité.

En réponse aux questions: Non, les sessions ne sont pas collantes. Et oui, nous aurons besoin de SSL, mais cela pourrait en théorie être entièrement géré par une autre configuration - nous pouvons diriger le trafic SSL vers un emplacement différent du trafic non SSL.

OK, je n'ai jamais construit de solution d'équilibrage de charge AWS avec du trafic aux niveaux de SmugMug moi-même, mais juste en pensant à la théorie et aux services AWS, quelques idées me viennent à l'esprit.

La question d'origine manque quelques éléments qui ont tendance à avoir un impact sur la conception de l'équilibrage de charge:

1. Sessions collantes ou pas? Il est très préférable de ne pas utiliser de session persistante et de laisser tous les équilibreurs de charge (LB) utiliser le round robin (RR) ou la sélection de backend aléatoire. Les sélections RR ou backend aléatoires sont simples, évolutives et fournissent une répartition uniforme de la charge en toutes circonstances.
2. SSL ou pas? Que SSL soit utilisé ou non, et sur quel pourcentage de demandes, a généralement un impact sur la conception de l'équilibrage de charge. Il est souvent préférable de mettre fin à SSL le plus tôt possible, pour simplifier la gestion des certificats et garder la charge du processeur SSL à l'écart des serveurs d'applications Web.

Je réponds du point de vue de la façon de maintenir la couche d'équilibrage de charge elle-même hautement disponible. Garder les serveurs d'applications HA se fait simplement avec les contrôles d'intégrité intégrés à vos équilibreurs de charge L7.

OK, quelques idées qui devraient fonctionner:

1) "La manière AWS":

• La première couche, à l'avant, utilise ELB en mode L4 (TCP / IP).
• Deuxième couche, utilisez les instances EC2 avec votre équilibreur de charge L7 de choix (nginx, HAProxy, Apache, etc.).

Avantages / idée: Les équilibreurs de charge L7 peuvent être des AMI EC2 assez simples, tous clonés à partir de la même AMI et utilisant la même configuration. Ainsi, les outils d'Amazon peuvent gérer tous les besoins HA: ELB surveille les équilibreurs de charge L7. Si un L7 LB meurt ou ne répond plus, ELB et Cloudwatch génèrent ensemble une nouvelle instance automatiquement et l'intègrent dans le pool ELB.

2) "Le tournoi à la ronde DNS avec méthode de surveillance:"

• Utilisez le round robin DNS de base pour obtenir une distribution de charge à grain grossier sur quelques adresses IP. Disons simplement que vous publiez 3 adresses IP pour votre site.
• Chacune de ces 3 IP est une adresse IP élastique AWS (EIA), liée à une instance EC2, avec un équilibreur de charge L7 de votre choix.
• Si un EC2 L7 LB meurt, un agent utilisateur conforme (navigateur) doit simplement utiliser l'un des autres IP à la place.
• Configurez un serveur de surveillance externe. Surveillez chacun des 3 EIP. Si l'un ne répond plus, utilisez les outils de ligne de commande d'AWS et certains scripts pour déplacer l'EIP vers une autre instance EC2.

Avantages / idée: les agents utilisateurs conformes doivent automatiquement basculer vers une autre adresse IP si l'un d'eux ne répond plus. Ainsi, en cas d'échec, seulement 1/3 de vos utilisateurs devraient être impactés, et la plupart d'entre eux ne devraient rien remarquer puisque leur UA bascule silencieusement vers une autre IP. Et votre boîtier de surveillance externe remarquera qu'un EIP ne répond pas et rectifiera la situation en quelques minutes.

3) DNS RR vers des paires de serveurs HA:

Fondamentalement, c'est la propre suggestion de Don d'un battement de cœur simple entre une paire de serveurs, mais simplifié pour plusieurs adresses IP.

• À l'aide de DNS RR, publiez un certain nombre d'adresses IP pour le service. En suivant l'exemple ci-dessus, disons simplement que vous publiez 3 adresses IP.
• Chacun de ces IP va à une paire de serveurs EC2, donc 6 instances EC2 au total.
• Chacune de ces paires utilise Heartbeat ou une autre solution HA avec des outils AWS pour conserver 1 adresse IP active, dans une configuration active / passive.
• Chaque instance EC2 a votre équilibreur de charge L7 de choix installé.

Avantages / idée: dans l'environnement complètement virtualisé d'AWS, il n'est en fait pas si facile de raisonner sur les services L4 et les modes de basculement. En simplifiant à une paire de serveurs identiques en gardant une seule adresse IP en vie, il devient plus simple de raisonner et de tester.

Conclusion: Encore une fois, je n'ai en fait rien essayé en production. D'après mon intuition, l'option 1 avec ELB en mode L4 et les instances EC2 autogérées en tant que L7 LB semblent les plus conformes à l'esprit de la plate-forme AWS, et où Amazon est le plus susceptible d'investir et de se développer plus tard. Ce serait probablement mon premier choix.

Si vous ne faites pas de sessions persistantes, ou si vous utilisez le style tomcat / apache (ajoutez l'ID du nœud à l'ID de session, par opposition au stockage de l'état dans le LB), j'utiliserais ELB devant un groupe de haproxies. ELB a un contrôle de santé intégré, vous pouvez donc le faire surveiller les haproxys et en retirer tous ceux de la piscine. Beaucoup moins à configurer que le basculement de pulsation.

En ce qui concerne la propagation des changements, je n'ai pas de bonne réponse. Puppet est idéal pour la configuration initiale et la mise en œuvre des modifications, mais pour ajouter / supprimer des nœuds, vous avez tendance à vouloir une réponse plus rapide que son intervalle d'interrogation de 30 minutes.

Je ne l'ai pas utilisé moi-même mais j'ai vu beaucoup de gens mentionner l'utilisation de marionnettes pour gérer ce genre de problèmes sur EC2