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 pris fin le 26 mai 2024 et a été désactivé tant pour les nouveaux clients que pour 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 Elastic Load Balancing HAProxy
- Résiliation SSL
-
La HAProxy couche 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 HAProxy charge, 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
-
Si l'instance hébergeant votre HAProxy serveur tombe en panne, l'ensemble de 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 fournit des nœuds d'équilibrage de charge dans chaque zone de disponibilité contenant EC2 des instances 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 recommandons de l'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 dirigerez tout ce URLs qui inclut le « paiement » ou le « paiement » vers l'un des serveurs de paiement.
Avec HAProxy, vous pouvez utiliser le mappage basé sur les URL pour diriger le contenu d' URLs une chaîne spécifiée vers des serveurs particuliers. Pour utiliser le mappage basé sur des URL avec AWS OpsWorks Stacks, vous devez créer un fichier de HAProxy configuration personnalisé en remplaçant le
haproxy-default.erbmodèle dans le livre de recettes intégré.haproxyPour plus d'informations, consultez le manuel HAProxy de configurationetUtilisation de modèles personnalisés. Vous ne pouvez pas utiliser le mappage basé sur les URL pour les requêtes HTTPS. Une requête HTTPS est cryptée et n' HAProxya donc 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 consiste peut-être à combiner les deux en utilisant Elastic Load Balancing comme équilibreur de charge frontal qui distribue le trafic entrant vers un ensemble de HAProxy serveurs. Pour cela :
-
Configurez une HAProxy instance dans chacune des zones de disponibilité de votre stack pour distribuer les demandes aux serveurs d'applications de la zone.
-
Assignez les HAProxy instances à un équilibreur de charge Elastic Load Balancing, qui distribue ensuite les demandes entrantes aux équilibreurs de HAProxy charge.
Cette approche vous permet d'utiliser HAProxy le mappage basé sur les URL pour distribuer différents types de demandes aux serveurs d'applications appropriés. Toutefois, si l'un des HAProxy serveurs est hors ligne, le site continuera de fonctionner car l'équilibreur de charge Elastic Load Balancing distribue automatiquement le trafic entrant aux HAProxy serveurs sains. Notez que vous devez utiliser Elastic Load Balancing comme équilibreur de charge frontal ; un HAProxy serveur ne peut pas distribuer de demandes à d'autres HAProxy serveurs.
