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.
Modifier les attributs du groupe cible pour votre Application Load Balancer
Après avoir créé un groupe cible pour votre Application Load Balancer, vous pouvez modifier ses attributs.
Attributs de groupe cible
Délai d'annulation d'enregistrement
Elastic Load Balancing cesse d'envoyer des demandes aux cibles dont l'enregistrement est annulé. Par défaut, Elastic Load Balancing attend 300 secondes avant de terminer le processus d'annulation d'enregistrement, ce qui peut aider les demandes en cours vers la cible à se terminer. Pour modifier le temps d'attente d'Elastic Load Balancing, mettez à jour la valeur du retard d'annulation d'enregistrement.
L'état initial d'une cible dont l'enregistrement est en cours d'annulation est draining. Une fois le délai d'annulation d'enregistrement écoulé, le processus d'annulation d'enregistrement se termine et l'état de la cible est unused. Si la cible fait partie d'un groupe Auto Scaling, elle peut être résiliée et remplacée.
Si une cible d'annulation d'enregistrement n'a pas de demandes en cours et pas de connexions actives, Elastic Load Balancing exécute immédiatement le processus d'annulation d'enregistrement, sans attendre que le délai correspondant soit écoulé. Cependant, même si le désenregistrement de la cible est terminé, le statut de la cible est affiché comme draining jusqu'à ce que le délai de désenregistrement expire. Une fois le délai expiré, la cible passe à un état unused.
Si une annulation d'enregistrement de cible met fin à la connexion avant que le délai d'annulation d'enregistrement soit écoulé, le client reçoit une réponse d'erreur de niveau 500.
Mode Démarrage lent
Par défaut, une cible commence à recevoir la totalité de sa part de demandes dès qu'elle est enregistrée auprès d'un groupe cible et qu'elle transmet une vérification de l'état initiale. L'utilisation du mode Démarrage lent permet de donner aux cibles le temps de se mettre en route avant que l'équilibreur de charge ne leur envoie la totalité de leur part de demandes.
Une fois que vous avez activé le démarrage lent pour un groupe cible, ses cibles entrent en mode Démarrage lent lorsqu'elles sont considérées comme saines par le groupe cible. Une cible quitte le mode Démarrage lent une fois que la durée configurée du démarrage lent s'est écoulée ou lorsqu'elle n'est plus saine. L'équilibreur de charge augmente de façon linéaire le nombre de demandes qu'il peut envoyer à une cible en mode Démarrage lent. Une fois qu'une cible saine a quitté le mode Démarrage lent, l'équilibreur de charge peut lui envoyer la totalité de sa part de demandes.
Considérations
-
Lorsque vous activez le démarrage lent pour un groupe cible, les cibles saines enregistrées auprès du groupe cible ne passent pas en mode Démarrage lent.
-
Lorsque vous activez le démarrage lent pour un groupe cible vide, puis que vous enregistrez des cibles à l'aide d'une opération d'enregistrement unique, ces cibles ne passent pas en mode Démarrage lent. Les cibles nouvellement enregistrées passent en mode Démarrage lent si au moins une cible saine n'est pas en mode Démarrage lent.
-
Si vous annulez l'enregistrement d'une cible en mode Démarrage lent, la cible quitte ce mode. Si vous enregistrez à nouveau la même cible, elle entre en mode Démarrage lent si elle est considérée comme saine par le groupe cible.
-
Si une cible n'est plus saine, elle quitte le mode Démarrage lent. Si la cible redevient saine, elle entre à nouveau en mode Démarrage lent.
-
Vous ne pouvez pas activer le mode de démarrage lent lorsque vous utilisez les demandes les moins importantes ou les algorithmes de routage aléatoire pondéré.
Équilibrage de charge entre zones pour les groupes cibles d'Application Load Balancer
Les nœuds de votre équilibreur de charge distribuent les requêtes des clients à des cibles enregistrées. Lorsque la répartition de charge entre zones est activée, chaque nœud d'équilibreur de charge distribue le trafic entre les cibles enregistrées dans toutes les zones de disponibilité enregistrées. Lorsque la répartition de charge entre zones est désactivée, chaque nœud d'équilibreur de charge distribue le trafic entre les cibles enregistrées dans sa zone de disponibilité uniquement. Cela peut être le cas si les domaines de défaillance zonaux sont préférés aux domaines régionaux, afin de garantir qu'une zone saine n'est pas affectée par une zone défectueuse, ou pour améliorer la latence globale.
Avec les Application Load Balancers, la répartition de charge entre zones est toujours activé au niveau de l'équilibreur de charge et ne peut pas être désactivé. Pour les groupes cibles, le paramètre par défaut est d'utiliser le paramètre d'équilibreur de charge, mais vous pouvez le remplacer en désactivant explicitement la répartition de charge entre zones au niveau du groupe cible.
Considérations
-
La permanence de la cible n'est pas prise en charge lorsque la répartition de charge entre les zones est désactivée.
-
Les fonctions lambda en tant que cibles ne sont pas prises en charge lorsque l'équilibreur de charge entre zones est désactivé.
-
Si vous tentez de désactiver la répartition de charge entre zones via l'API
ModifyTargetGroupAttributeset que le paramètreAvailabilityZoned'une cible est défini surall, une erreur se produit. -
Lors de l'enregistrement des cibles, le paramètre
AvailabilityZoneest obligatoire. Les valeurs des zones de disponibilité spécifiques ne sont autorisées que lorsque la répartition de charge entre zones est désactivée. Sinon, le paramètre est ignoré et traité commeall.
Bonnes pratiques
-
Prévoyez une capacité cible suffisante dans toutes les zones de disponibilité que vous comptez utiliser, par groupe cible. Si vous ne parvenez pas à prévoir une capacité suffisante dans toutes les zones de disponibilité participantes, nous vous recommandons de maintenir la répartition de charge entre zones activé.
-
Lorsque vous configurez votre Application Load Balancer avec plusieurs groupes cibles, assurez-vous que tous les groupes cibles participent aux mêmes zones de disponibilité, au sein de la région configurée. Cela permet d'éviter qu'une zone de disponibilité ne soit vide lorsque la répartition de charge entre zones est désactivé, car cela déclenche une erreur 503 pour toutes les demandes HTTP qui entrent dans la zone de disponibilité vide.
-
Évitez de créer des sous-réseaux vides. Application Load Balancers exposent les adresses IP zonales via le DNS pour les sous-réseaux vides, ce qui déclenche les erreurs 503 pour les demandes HTTP.
-
Il peut arriver qu'un groupe cible dont la répartition de charge entre zones est désactivé dispose d'une capacité cible planifiée suffisante par zone de disponibilité, mais que toutes les cibles d'une zone de disponibilité ne fonctionnent pas correctement. Lorsqu'au moins un groupe cible contient toutes des cibles défectueuses, les adresses IP des nœuds d'équilibreur de charge sont supprimées du DNS. Une fois que le groupe cible possède au moins une cible saine, les adresses IP sont restaurées dans le DNS.
Désactiver la répartition de charge entre zones
Vous pouvez activer la répartition de charge entre zones à tout moment pour votre Application Load Balancer.
Activer la répartition de charge entre zones
Vous pouvez activer la répartition de charge entre zones à tout moment pour votre Application Load Balancer. Le paramètre de répartition de charge entre zones au niveau du groupe cible remplace le paramètre au niveau de l'équilibreur de charge.
Poids cibles automatiques (ATW)
Les poids cibles automatiques (ATW) surveillent en permanence les cibles exécutant vos applications, en détectant les écarts de performance significatifs, appelés anomalies. L'ATW permet d'ajuster dynamiquement le volume de trafic acheminé vers les cibles, grâce à la détection des anomalies de données en temps réel.
Automatic Target Weights (ATW) détecte automatiquement les anomalies sur chaque Application Load Balancer de votre compte. Lorsque des cibles anormales sont identifiées, ATW peut automatiquement tenter de les stabiliser en réduisant le volume de trafic qu'elles acheminent, ce que l'on appelle l'atténuation des anomalies. ATW optimise en permanence la distribution du trafic afin de maximiser les taux de réussite par cible tout en minimisant les taux d'échec du groupe cible.
Considérations :
-
La détection des anomalies surveille actuellement les codes de réponse HTTP 5xx provenant de vos cibles et les échecs de connexion à ces derniers. La détection des anomalies est toujours activée et ne peut pas être désactivée.
-
L'ATW n'est pas pris en charge lors de l'utilisation de Lambda comme cible.
Table des matières
Détection des anomalies
La détection des anomalies ATW surveille toutes les cibles présentant un écart de comportement significatif par rapport aux autres cibles de leur groupe cible. Ces écarts, appelés anomalies, sont déterminés en comparant le pourcentage d'erreurs d'une cible avec le pourcentage d'erreurs des autres cibles du groupe cible. Ces erreurs peuvent être à la fois des erreurs de connexion et des codes d'erreur HTTP. Les cibles présentant un taux nettement supérieur à celui de leurs pairs sont alors considérées comme anormales.
La détection d'anomalies nécessite un minimum de trois cibles saines dans le groupe cible. Lorsqu'une cible est enregistrée auprès d'un groupe cible, elle doit passer les tests de santé avant de recevoir du trafic. Une fois que la cible commence à recevoir du trafic, ATW commence à surveiller la cible et publie en permanence le résultat de l'anomalie. Pour les cibles sans anomalies, le résultat de l'anomalie estnormal. Pour les cibles présentant des anomalies, le résultat de l'anomalie estanomalous.
La détection des anomalies ATW fonctionne indépendamment des bilans de santé du groupe cible. Une cible peut réussir tous les tests de santé du groupe cible, mais être tout de même marquée comme anormale en raison d'un taux d'erreur élevé. Le fait que les cibles deviennent anormales n'affecte pas l'état du bilan de santé de leur groupe cible.
État de détection des anomalies
Vous pouvez consulter l'état actuel de détection des anomalies. Les valeurs possibles sont les suivantes :
-
normal— Aucune anomalie n'a été détectée. -
anomalous— Des anomalies ont été détectées.
Atténuation des anomalies
L'atténuation des anomalies ATW éloigne automatiquement le trafic des cibles anormales, leur donnant ainsi la possibilité de se rétablir.
Exigence
La fonction d'atténuation des anomalies d'ATW n'est disponible que lors de l'utilisation de l'algorithme de routage aléatoire pondéré.
Pendant l'atténuation :
-
ATW ajuste périodiquement le volume de trafic acheminé vers des cibles anormales. Actuellement, les règles sont toutes les cinq secondes.
-
L'ATW réduit le volume de trafic acheminé vers des cibles anormales au minimum requis pour atténuer les anomalies.
-
Les cibles qui ne sont plus détectées comme anormales verront progressivement davantage de trafic acheminé vers elles jusqu'à ce qu'elles atteignent la parité avec les autres cibles normales du groupe cible.
État des mesures d'atténuation
Vous pouvez vérifier si ATW effectue des mesures d'atténuation sur une cible. Les valeurs possibles sont les suivantes :
yes— L'atténuation est en cours.no— L'atténuation n'est pas en cours.
Sessions permanentes pour votre Application Load Balancer
Par défaut, un Application Load Balancer achemine chaque demande de façon indépendante vers une cible enregistrée en fonction de l'algorithme de répartition de charge choisi. Toutefois, vous pouvez utiliser la fonctionnalité de session permanente (également appelée affinité de session) pour permettre à l'équilibreur de charge de lier la session d'un utilisateur à une cible spécifique. Il est ainsi possible de garantir que toutes les demandes de l'utilisateur pendant la session soient adressées à la même cible. Cette fonctionnalité est utile pour les serveurs qui conservent des informations d'état afin d'offrir une expérience continue aux clients. Pour utiliser les sessions permanentes, le client doit accepter les cookies.
Application Load Balancers prennent en charge à la fois les cookies basés sur la durée et les cookies basés sur les applications. Les sessions permanentes sont activées au niveau du groupe cible. Vous pouvez combiner une adhérence basée sur la durée, une permanence basée sur l'application et une absence de permanence entre vos groupes cibles.
La clé de la gestion des sessions permanentes consiste à déterminer la durée pendant laquelle votre équilibreur de charge doit acheminer la demande de l'utilisateur vers la même cible. Si votre application dispose de son propre cookie de session, vous pouvez utiliser une session permanente basée sur l'application et le cookie de session de l'équilibreur de charge suit la durée spécifiée par le cookie de session de l'application. Si votre application n'a pas son propre cookie de session, vous pouvez utiliser la permanence basée sur la durée pour générer un cookie de session d'équilibreur de charge d'une durée que vous spécifiez.
Le contenu des cookies générés par l'équilibreur de charge est chiffré à l'aide d'une clé tournante. Vous ne pouvez pas déchiffrer ou modifier les cookies générés par l'équilibreur de charge.
Pour les deux types de viscosité, l'Application Load Balancer réinitialise l'expiration des cookies qu'il génère après chaque demande. Si un cookie expire, la session n'est plus permanente et le client doit supprimer le cookie de son magasin de cookies.
Prérequis
-
Un équilibreur de HTTP/HTTPS charge.
-
Au moins une instance saine dans chaque zone de disponibilité.
Considérations
-
Les sessions permanentes ne sont pas prises en charge si la répartition de charge entre zones est désactivé. Toute tentative d'activation de sessions permanentes alors que la répartition de charge entre zones est désactivé échouera.
-
Pour les cookies basés sur des applications, les noms des cookies doivent être spécifiés individuellement pour chaque groupe cible. Toutefois, pour les cookies basés sur la durée,
AWSALBest le seul nom utilisé pour tous les groupes cibles. -
Si vous utilisez plusieurs couches d'Application Load Balancers, vous pouvez activer des sessions permanentes sur toutes les couches à l'aide de cookies basés sur les applications. Cependant, avec les cookies basés sur la durée, vous ne pouvez activer les sessions permanentes que sur une seule couche, car
AWSALBest le seul nom disponible. -
Si l'Application Load Balancer reçoit à la fois un cookie d'adhérence
AWSALBbasé sur la duréeAWSALBCORSet un cookie permanent, la valeur in sera prioritaire.AWSALBCORS -
La permanence basée sur les applications ne fonctionne pas avec les groupes cibles pondérés.
-
Si vous avez une action de transfert avec plusieurs groupes cibles et que les sessions permanentes sont activées pour un ou plusieurs groupes cibles, vous devez activer la permanence au niveau du groupe cible.
-
WebSocket les connexions sont intrinsèquement collantes. Si le client demande une mise à niveau de connexion vers WebSockets, la cible qui renvoie un code d'état HTTP 101 pour accepter la mise à niveau de connexion est la cible utilisée dans la WebSockets connexion. Une fois la WebSockets mise à niveau terminée, le caractère collant basé sur les cookies n'est pas utilisé.
-
Application Load Balancers utilisent l'attribut
Expiresdans l'en-tête du cookie au lieu de l'attributMax-Age. -
Les Application Load Balancers ne prennent pas en charge les valeurs de cookie codées par URL.
-
Si l'Application Load Balancer reçoit une nouvelle demande alors que la cible est épuisée en raison de la désinscription, la demande est acheminée vers une cible saine.
Types de viscosité
Permanence basée sur la durée
La permanence basée sur la durée achemine les demandes vers la même cible dans un groupe cible à l'aide d'un cookie généré par un équilibreur de charge (AWSALB). Le cookie est utilisé pour mapper la session à la cible. Si votre application n'a pas son propre cookie de session, vous pouvez spécifier votre propre durée de permanence et gérer la durée pendant laquelle votre équilibreur de charge doit systématiquement acheminer la demande de l'utilisateur vers la même cible.
Lorsqu'un équilibreur de charge reçoit pour la première fois une demande d'un client, il achemine la demande vers une cible (en fonction de l'algorithme choisi) et génère un cookie nommé AWSALB. Il code les informations relatives à la cible sélectionnée, chiffre le cookie et inclut le cookie dans la réponse au client. Le cookie généré par l'équilibreur de charge a son propre délai d'expiration de 7 jours, ce qui n'est pas configurable.
Dans les demandes ultérieures, le client doit inclure le cookie AWSALB. Lorsque l'équilibreur de charge reçoit une demande d'un client contenant le cookie, il le détecte et achemine la demande vers la même cible. Si le cookie est présent mais ne peut pas être décodé, ou s'il fait référence à une cible qui a été désenregistrée ou qui n'est pas saine, l'équilibreur de charge sélectionne une nouvelle cible et met à jour le cookie avec les informations relatives à la nouvelle cible.
Pour les demandes de partage de ressources d'origine croisée (CORS), certains navigateurs nécessitent d'SameSite=None; Secureactiver le caractère collant. Pour prendre en charge ces navigateurs, l'équilibreur de charge génère toujours un deuxième cookie de viscositéAWSALBCORS, qui inclut les mêmes informations que le cookie d'adhérence d'origine, ainsi que l'attribut. SameSite Les clients reçoivent les deux cookies, y compris les demandes non CORS.
Permanence basée sur les applications
La permanence basée sur les applications vous donne la flexibilité de définir vos propres critères de permanence par rapport au client cible. Lorsque vous activez la permanence basée sur les applications, l'équilibreur de charge achemine la première demande vers une cible au sein du groupe cible en fonction de l'algorithme choisi. La cible est censée définir un cookie d'application personnalisé correspondant au cookie configuré sur l'équilibreur de charge pour permettre la permanence. Ce cookie personnalisé peut inclure n'importe quel attribut de cookie requis par l'application.
Lorsque Application Load Balancer reçoit le cookie d'application personnalisé de la cible, il génère automatiquement un nouveau cookie d'application chiffré pour capturer les informations relatives à la permanence. Ce cookie d'application généré par l'équilibreur de charge capture les informations de permanence pour chaque groupe cible pour lequel la permanence basée sur les applications est activée.
Le cookie d'application généré par l'équilibreur de charge ne copie pas les attributs du cookie personnalisé défini par la cible. Il a son propre délai d'expiration de 7 jours, ce qui n'est pas configurable. Dans la réponse au client, Application Load Balancer valide uniquement le nom sous lequel le cookie personnalisé a été configuré au niveau du groupe cible et non la valeur ou l'attribut d'expiration du cookie personnalisé. Tant que le nom correspond, l'équilibreur de charge envoie les deux cookies, le cookie personnalisé défini par la cible et le cookie d'application généré par l'équilibreur de charge, en réponse au client.
Lors de demandes ultérieures, les clients doivent renvoyer les deux cookies pour conserver la permanence. L'équilibreur de charge déchiffre le cookie de l'application et vérifie si la durée de la permanence configurée est toujours valide. Il utilise ensuite les informations contenues dans le cookie pour envoyer la demande à la même cible au sein du groupe cible afin de maintenir la permanence. L'équilibreur de charge transmet également le cookie d'application personnalisé par proxy à la cible sans l'inspecter ni le modifier. Dans les réponses suivantes, l'expiration du cookie d'application généré par l'équilibreur de charge et la durée de la permanence configurée sur l'équilibreur de charge sont réinitialisées. Pour maintenir la permanence entre le client et la cible, l'expiration du cookie et la durée de la permanence ne doivent pas s'écouler.
Si une cible est défaillante ou devient défectueuse, l'équilibreur de charge cesse d'acheminer les demandes vers cette cible et choisit une nouvelle cible saine en fonction de l'algorithme de répartition de charge choisi. L'équilibreur de charge considère que la session est désormais « liée » à la nouvelle cible saine et continue d'acheminer les demandes vers cette dernière, même si la cible défaillante réapparaît.
Dans le cas des demandes de partage de ressources d'origine croisée (CORS), pour permettre la permanence, l'équilibreur de charge ajoute les attributs SameSite=None; Secure au cookie d'application généré par l'équilibreur de charge uniquement si la version de l'agent utilisateur est Chromium80 ou supérieure.
Comme la plupart des navigateurs limitent les cookies à une taille de 4 Ko, l'équilibreur de charge divise les cookies d'application supérieurs à 4 Ko en plusieurs cookies. Application Load Balancers prennent en charge les cookies d'une taille maximale de 16 K et peuvent donc créer jusqu'à 4 partitions qu'ils envoient au client. Le nom du cookie d'application que le client voit commence par « AWSALBAPP - » et inclut un numéro de fragment. Par exemple, si la taille du cookie est comprise entre 0 et 4 Ko, le client voit AWSALBAPP -0. Si la taille du cookie est comprise entre 4 et 8 ko, le client voit AWSALBAPP -0 et AWSALBAPP -1, et ainsi de suite.
Répartition manuelle
Lors de la mise à l'échelle, si le nombre de cibles augmente considérablement, il existe un risque de répartition inégale de la charge en raison de la permanence. Dans ce scénario, vous pouvez rééquilibrer la charge sur vos cibles à l'aide des deux options suivantes :
-
Définissez une date d'expiration pour le cookie généré par l'application qui est antérieure à la date et à l'heure actuelles. Cela empêche les clients d'envoyer le cookie à l'Application Load Balancer, qui relancera le processus d'établissement du caractère collant.
-
Définissez une courte durée pour la configuration de rigidité basée sur les applications de l'équilibreur de charge, par exemple 1 seconde. Cela oblige l'Application Load Balancer à rétablir l'adhérence même si le cookie défini par la cible n'a pas expiré.
