Je me prépare à la certification AWS et suis tombé sur une question sur ELB avec la session permanente activée pour les instances dans 2 zones de disponibilité. Le problème est que les demandes d'un testeur de charge logiciel dans l'une des zones de disponibilité se retrouvent dans les instances de cette zone de disponibilité uniquement au lieu d'être réparties entre les zones de disponibilité. Dans le même temps, les demandes régulières des clients sont uniformément réparties entre les zones de disponibilité. Les bonnes réponses pour résoudre le problème du testeur de charge sont:
Je ne suis pas sûr de comprendre ce scénario. Quel est le comportement par défaut de Route 53 en ce qui concerne la résolution des adresses IP ELB? Dans tous les cas, ces enregistrements DNS ont 60 secondes de TTL. N'est-il pas redondant de re-résoudre le DNS à chaque demande? En outre, la résolution DNS est une responsabilité du service DNS lui-même, pas du logiciel de test de charge, n'est-ce pas? Je peux comprendre que les demandes provenant de la même instance, avec un logiciel de test de charge, iront au même LBed EC2, mais pourquoi doit-il s'agir d'une instance de la même zone de disponibilité? Cela ne peut être réalisé que par un routage basé sur la géolocalisation ou la latence, mais je ne trouve rien dans les spécifications si ce sont celles par défaut.
3 Réponses :
Le problème est le problème, voir ici: https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-sticky-sessions.html
L'équilibreur de charge utilise un cookie spécial pour associer la session à l'instance qui a traité la demande initiale, mais qui suit le durée de vie du cookie d'application spécifié dans la politique configuration. L'équilibreur de charge insère uniquement un nouveau cookie de persistance si la réponse de l'application comprend un nouveau cookie d'application. le Le cookie de persistance de l'équilibreur de charge ne se met pas à jour à chaque demande. Si le cookie d'application est explicitement supprimé ou expire, la session cesse d'être collant jusqu'à ce qu'un nouveau cookie d'application soit émis.
La première solution, pour re-résoudre le DNS, créera de nouvelles sessions et avec cela brisera la rigidité de l'ELB. La deuxième solution consiste à utiliser plusieurs clients, la rigidité n'est pas un problème si le nombre de clients répartis globalement est important.
PARTIE 2: n'a pas pu ajouter comme commentaire, est trop long:
Oui, ma réponse était simple et incomplète.
Ce que nous savons, c'est que ELB fait 2 AZ et aura 2 nœuds avec des IP différentes. Pas clair combien IP, dépend du nombre de demandes et du nombre de serveurs sur chaque AZ. Route 53 fait tourner l'IP à chaque nouvelle demande, la première fois dans NodeA-IP, NodeB-IP, la deuxième fois dans NodeB-IP, NodeA-IP. L'application de test de charge prendra à chaque nouvelle demande la première adresse IP, en équilibrant les 2 AZ. Parce qu'un Node ne peut acheminer que dans son AZ, si le cookie collant est pour NodeA et que la demande arrive à NodeB, NodeB l'enverra à l'un de ses serveurs dans AZ2 en ignorant le cookie pour un serveur dans AZ 1.
J'ai besoin d'exécuter quelques tests, rapidement testé avec Route53 avec ELB classique et 2 AZ et tourne à chaque fois les IP. Ce que je veux tester si j'ai un cookie collant pour AZ 1 et j'atteins le nœud 2 ne me transmettra pas au nœud 1 (en cas d'absence de serveurs disponibles, est décrit dans la doc ce flux intéressant). J'espère avoir des mises à jour dans peu de temps.
Il est clair que le problème concerne la viscosité (même à partir de la question du test lui-même), mais ce n'est pas un cookie du côté de l'application dans ce cas; La résolution DNS en elle-même n'a rien à voir avec les sessions. La session est ajoutée en tant que cookies (niveau HTTP), DNS est pour le mappage de domaine à IP et n'a rien à voir avec les cookies. S'il vous plaît, fournissez plus de détails / liens ou je devrai décliner votre réponse. Désolé.
Veuillez vérifier la version 2 de mon commentaire, désolé d'être en retard
Merci! Cela répond maintenant à certaines questions. Donc, vous dites que par défaut Route 53 retournera toutes les adresses IP ELB (jusqu'à 8 je suppose en fonction des limitations de Route 53), mais les fera-t-il tourner tout le temps? "Node ne peut acheminer que dans son AZ" - ceci est basé sur l'hypothèse que la fonction cross-AZ n'est pas activée sur le LB.
Lorsqu'un ELB se trouve dans plus d'une zone de disponibilité, il a toujours plus d'une adresse IP publique - au moins une par zone.
Lorsque vous demandez ces enregistrements dans une recherche DNS, vous obtenez tous ces enregistrements (en supposant qu'il n'y en ait pas beaucoup) ou un sous-ensemble d'entre eux (s'il y en a un grand nombre, ce qui serait le cas dans un cluster actif avec trafic important) mais ils ne sont pas ordonnés.
Si le logiciel de test de charge résout l'adresse IP du point de terminaison et conserve exactement l'une des adresses IP - ce qui est probable - alors tout le trafic ira à un nœud de l'équilibreur, qui est dans une zone, et enverra du trafic aux instances de cette zone.
Mais qu'en est-il de ...
Équilibrage de charge entre zones
Les nœuds de votre équilibreur de charge distribuent les requêtes des clients aux cibles enregistrées. Lorsque l'équilibrage de charge entre zones est activé, chaque nœud d'équilibrage de charge distribue le trafic entre les cibles enregistrées dans toutes les zones de disponibilité activées. Lorsque l'équilibrage de charge entre zones est désactivé, chaque nœud d'équilibrage de charge distribue le trafic entre les cibles enregistrées dans sa zone de disponibilité uniquement.
Si la persistance est configurée, ces sessions atterriront initialement dans une zone de disponibilité, puis resteront dans cette zone de disponibilité car elles s'en tiennent à l'instance initiale où elles ont atterri. Si la zone croisée est activée, le résultat n'est pas aussi clair, mais soit les nœuds d'équilibrage peuvent préférer des instances dans leur propre zone dans ce scénario (lors de la première mise en place de la rigidité), soit ce n'était pas vraiment le but de la question. La rigidité nécessite une coordination et le trafic inter-AZ prend un temps non nul en raison de la distance (généralement <10 ms), mais il serait logique qu'un équilibreur préfère sélectionner les instances de sa zone locale pour les sessions sans affinité établie. < / p>
En fait, la configuration du logiciel de test de charge pour résoudre à nouveau le point de terminaison pour chaque requête n'est pas vraiment au cœur de la solution - le but est de s'assurer que (1) le logiciel de test de charge les utilise toutes et ne se verrouille pas sur exactement une et (2) que si plus d'adresses deviennent disponibles en raison de la mise à l'échelle de l'équilibreur sous charge, le logiciel de test de charge étend son pool de cibles.
Dans tous les cas, ces enregistrements DNS ont une durée de vie de 60 secondes. N'est-il pas redondant de résoudre à nouveau le DNS à chaque demande?
Le logiciel peut ne pas voir le TTL, ne pas respecter le TTL et, comme indiqué ci-dessus, s'en tenir à une seule réponse même si plusieurs sont disponibles, car il n'en a besoin que d'une pour établir la connexion. Chaque requête n'est pas strictement nécessaire, mais elle résout le problème.
De plus, la résolution DNS est une responsabilité du service DNS lui-même, pas du logiciel de test de charge, n'est-ce pas?
Dans ce contexte, «résoudre DNS» signifie simplement faire une recherche DNS, quoi que cela signifie dans l'instance spécifique, que ce soit en utilisant le résolveur DNS du système d'exploitation ou en effectuant une requête directe vers un serveur DNS récursif. Lorsque le logiciel établit une connexion à un nom d'hôte, il "résout" (recherche) l'adresse IP associée.
L'autre solution, "utiliser un service de test de charge tiers pour envoyer des requêtes à partir de clients distribués globalement", résout le problème par accident, puisque les clients distribués - même s'ils s'en tiennent au premier adresse qu'ils voient - sont plus susceptibles de voir toutes les adresses disponibles. L'aspect de distribution «globale» est une distraction.
ELB s'appuie sur l'arrivée aléatoire de requêtes sur ses nœuds externes dans le cadre de la stratégie d'équilibrage. Un logiciel de test de charge dont la conception néglige cela ne teste pas correctement l'ELB. Les deux solutions atténuent le problème de différentes manières.
Merci Michael. "mais il serait logique pour un équilibreur de préférer sélectionner les instances de sa zone locale pour les sessions sans affinité établie" - d'une part, oui, mais d'autre part - cela peut entraîner une distribution vraiment déséquilibrée s'il y a du trafic provient principalement d'une AZ spécifique.
À propos de l'équilibrage entre zones - Je suis sûr que c'est ce qui est sous-entendu, car la question indique également qu'un trafic régulier d'un segment d'utilisateurs est réparti uniformément sur deux zones de disponibilité. Et il semble que ce ne soit pas tout à fait clair pourquoi et comment Route53 + ELB sont configurés par défaut pour AutoScaling. Comme vous l'avez mentionné: "Si la zone croisée est activée, le résultat n'est pas aussi clair"
Non ... le trafic normal a tendance à être uniformément réparti même sans équilibrage entre zones car les requêtes arrivent au hasard aux différents nœuds d'équilibrage en raison de la nature désordonnée des réponses DNS de Route 53. Navigateurs individuels ont tendance à faire exactement la même chose que celle décrite dans la question - résoudre une fois et s'en tenir à une seule adresse IP - mais comme il existe de nombreux navigateurs, l'effet d'équilibrage se produit naturellement. ELB dépend en partie de l'effet d'équilibrage des enregistrements DNS non ordonnés / round robin, c'est pourquoi un outil de test de charge qui ne répète pas la recherche DNS se comporte de cette manière.
Eh bien, si le nombre d'instances est le même dans toutes les zones de disponibilité ( docs.aws.amazon.com/elasticloadbalancing/latest/userguid e /… ) ... ce qui était le cas dans la question.
En tout cas, je pense que c'est clair maintenant. La stratégie Route 53 par défaut est probablement Single qui est basée sur le round robin. Cette adresse IP peut être mise en cache dans le cache DNS du système d'exploitation ou dans le logiciel lui-même (la JVM semble également utiliser la mise en cache DNS, par exemple).
Cela dit, il serait plus logique pour Route 53 d'utiliser la politique de routage de réponse à valeurs multiples qui renverra les adresses IP des 6 instances (le maximum est de 8), puis ce serait au système d'exploitation de les faire un tour de rôle. aws.amazon.com/premiumsupport/knowledge-center/…
Route 53 renvoie déjà plusieurs réponses, comme je l'ai déjà souligné ... mais il est extrêmement courant pour une application de résoudre le nom, une fois, de prendre une adresse et de l'exécuter, en fonction de la vieille hypothèse selon laquelle il n'était pas nécessaire d'actualiser la recherche DNS - ce qui prend bien sûr du temps et des ressources. J'ai vu d'anciens services de back-end Java de production qui passeront des appels d'API à la seule adresse IP qu'ils ont trouvée la première fois qu'ils ont résolu un point de terminaison d'API et s'y tenir pour toujours jusqu'au redémarrage.
Apparemment, la JVM peut avoir sa propre notion indépendante des TTL DNS. "Sur certaines configurations Java, le TTL par défaut de la JVM est défini de sorte qu'il n'actualise jamais les entrées DNS tant que la JVM n'est pas redémarrée. Ainsi, si l'adresse IP d'une ressource AWS change alors que votre application est toujours en cours d'exécution, elle ne sera pas t pouvoir utiliser cette ressource jusqu'à ce que vous redémarriez manuellement la JVM et que les informations IP mises en cache soient actualisées. Dans ce cas, il est essentiel de définir le TTL de la JVM afin qu'elle actualise périodiquement ses informations IP mises en cache. " docs.aws.amazon. com / sdk-for-java / v1 / developer-guide /…
Je viens de trouver une autre preuve que Route 53 renvoie plusieurs adresses IP et les fait pivoter pour les scénarios de mise à l'échelle ELB:
Par défaut, Elastic Load Balancing renvoie plusieurs adresses IP lorsque les clients effectuent une résolution DNS, les enregistrements étant classés de manière aléatoire sur chaque demande de résolution DNS. Au fur et à mesure que le profil de trafic change, le service de contrôleur met à l'échelle les équilibreurs de charge pour gérer davantage de demandes, en évoluant de manière égale dans toutes les zones de disponibilité.
Et puis:
Pour garantir que les clients profitent de l'augmentation de la capacité, Elastic Load Balancing utilise un paramètre TTL sur l'enregistrement DNS de 60 secondes. Il est essentiel que vous teniez compte de ce changement d'enregistrement DNS dans vos tests. Si vous ne vous assurez pas que DNS est re-résolu ou si vous utilisez plusieurs clients de test pour simuler une charge accrue, le test peut continuer à atteindre une seule adresse IP lorsque Elastic Load Balancing a en fait alloué beaucoup plus d'adresses IP.
Ce que je n'avais pas réalisé au début, c'est que même si le trafic régulier est réparti uniformément entre les zones de disponibilité, cela ne signifie pas que l'équilibrage de charge entre zones est activé. Comme Michael l'a souligné, le trafic régulier passera naturellement par divers endroits et aboutira dans différentes zones de disponibilité. Et comme cela n'a pas été explicitement mentionné dans le test, l'équilibrage Cross-AZ n'a peut-être pas été en place.
https://aws.amazon. com / articles / best-practices-in-evaluation-elastic-load-balancing /