Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Equilibrage de charge d'une couche
Important
Le AWS OpsWorks Stacks service a atteint sa fin de vie le 26 mai 2024 et a été désactivé pour les nouveaux clients et les clients existants. Nous recommandons vivement aux clients de migrer leurs charges de travail vers d'autres solutions dès que possible. Si vous avez des questions sur la migration, contactez l' AWS Support équipe sur AWS Re:Post
AWS OpsWorks Stacks propose deux options d'équilibrage de charge, Elastic Load Balancing et HAProxy
- Résiliation SSL
-
La couche HAProxy intégrée ne gère pas la terminaison SSL ; vous devez résilier le SSL sur les serveurs. L'avantage de cette approche est que le trafic est chiffré jusqu'à ce qu'il atteigne les serveurs. Toutefois, les serveurs doivent gérer le déchiffrement, ce qui augmente la charge du serveur. En outre, vous devez mettre vos certificats SSL sur les serveurs d'applications, qui sont plus accessibles aux utilisateurs.
Avec Elastic Load Balancing, vous pouvez mettre fin au protocole SSL au niveau de l'équilibreur de charge. Cela réduit la charge sur vos serveurs d'applications, mais le trafic entre l'équilibreur de charge et le serveur n'est pas chiffré. Elastic Load Balancing vous permet également de mettre fin au protocole SSL sur le serveur, mais sa configuration est un peu compliquée.
- Mise à l'échelle
-
Si le trafic entrant dépasse la capacité d'un équilibreur de charge HAProxy, vous devez augmenter sa capacité manuellement.
Elastic Load Balancing s'adapte automatiquement pour gérer le trafic entrant. Pour vous assurer qu'un équilibreur de charge Elastic Load Balancing dispose d'une capacité suffisante pour gérer la charge attendue lors de sa première mise en ligne, vous pouvez le préchauffer
. - Échec de l'équilibreur de charge
-
En cas d'échec de l'instance qui héberge votre serveur HAProxy, tout votre site peut être mis hors ligne jusqu'à ce que vous puissiez redémarrer l'instance.
Elastic Load Balancing est plus résistant aux défaillances que HAProxy. Par exemple, il met en service des nœuds d'équilibrage de charge dans chaque zone de disponibilité ayant des instances EC2 enregistrées. Si le service d'une zone est interrompu, les autres nœuds continuent à gérer le trafic entrant. Pour plus d'informations, consultez Elastic Load Balancing Concepts.
- Délai d'inactivité
-
Les deux équilibreurs de charge mettent une connexion hors service si un serveur est inactif pendant plus d'une valeur de délai d'inactivité spécifiée.
-
HAProxy — La valeur du délai d'inactivité n'a pas de limite supérieure.
-
Elastic Load Balancing — La valeur du délai d'inactivité par défaut est de 60 secondes, avec un maximum de 3 600 secondes (60 minutes).
La limite de temps d'inactivité d'Elastic Load Balancing est suffisante dans la plupart des cas. Nous vous conseillons d'utiliser HAProxy si vous avez besoin d'un délai d'inactivité plus long. Par exemple :
-
Une connexion HTTP de longue durée qui est utilisée pour les notifications push.
-
Une interface d'administration que vous utilisez pour exécuter des tâches susceptibles de durer un maximum de 60 minutes.
-
- Mappage basé sur les URL
-
Vous pouvez avoir besoin qu'un équilibreur de charge transmette une demande entrante à un serveur particulier reposant sur l'URL de la demande. Par exemple, supposons que vous ayez un groupe de dix serveurs d'applications qui prend en charge une application de commerce en ligne. Huit des serveurs gèrent le catalogue et deux gèrent les paiements. Vous voulez transférer toutes les requêtes HTTP liées aux paiements aux serveurs de paiement, en fonction de l'URL de la demande. Dans ce cas, vous devez diriger toutes les URL qui incluent « paiement » vers l'un des serveurs de paiement.
Avec HAProxy, vous pouvez utiliser le mappage basé sur les URL pour diriger les URL contenant une chaîne spécifiée vers certains serveurs. Pour utiliser le mappage basé sur les URL avec AWS OpsWorks Stacks, vous devez créer un fichier de configuration HAProxy personnalisé en remplaçant le
haproxy-default.erbmodèle dans le livre de recettes intégré.haproxyPour plus d'informations, consultez le Manuel de configuration HAProxyet Utilisation de modèles personnalisés. Vous ne pouvez pas utiliser le mappage basé sur les URL pour les requêtes HTTPS. Une demande HTTPS est chiffrée, donc HAProxy n'a aucun moyen d'examiner l'URL de la demande. La prise en charge du mappage d'URL par Elastic Load Balancing est limitée. Pour de plus amples informations, veuillez consulter Écouteurs de votre Classic Load Balancer.
Recommandation : Nous vous recommandons d'utiliser Elastic Load Balancing pour l'équilibrage de charge, sauf si vous avez des exigences qui ne peuvent être traitées que par HAProxy. Dans ce cas, la meilleure approche peut être de combiner les deux en utilisant Elastic Load Balancing comme équilibreur de charge frontal qui distribue le trafic entrant vers un ensemble de serveurs HAProxy. Pour cela :
-
Configurer une instance HAProxy dans chacune des zones de disponibilité de votre pile afin de répartir les demandes entre les serveurs d'applications de la zone.
-
Assignez les instances HAProxy à un équilibreur de charge Elastic Load Balancing, qui distribue ensuite les demandes entrantes aux équilibreurs de charge HAProxy.
Cette approche vous permet d'utiliser le mappage basé sur les URL de HAProxy afin de répartir différents types de demandes entre les serveurs d'applications appropriés. Toutefois, si l'un des serveurs HAProxy est hors ligne, le site continuera à fonctionner car l'équilibreur de charge Elastic Load Balancing distribue automatiquement le trafic entrant aux serveurs HAProxy sains. Notez que vous devez utiliser Elastic Load Balancing comme équilibreur de charge frontal ; un serveur HAProxy ne peut pas distribuer de requêtes à d'autres serveurs HAProxy.
