Je viens de chercher des équilibreurs de charge élastiques. Si je comprends bien, ils ne font que le round robin, distribuant également les connexions aux serveurs derrière eux. Que se passe-t-il donc si vous avez des instances de tailles différentes derrière un ELB? Envoie-t-il plus de connexions à l'instance plus grande ou continue-t-il de répartir uniformément les connexions, ce qui signifie que vous ne devriez vraiment pas utiliser des instances de tailles différentes.
Réponses:
Si je comprends bien, ils ne font que le round robin, distribuant également les connexions aux serveurs derrière eux.
En quelque sorte, mais pas tout à fait je pense - malheureusement, la documentation de routage Amazon ELB est loin d'être inexistante, il faut donc assembler quelques pièces pour tirer une conclusion. Voici le seul fragment du Guide du développeur d'Elastic Load Balancing que je connaisse, voir la section Sessions persistantes dans Vue d'ensemble d'Elastic Load Balancing :
Par défaut, un équilibreur de charge achemine chaque demande indépendamment vers l'instance d'application avec la plus petite charge . Cependant, vous pouvez utiliser la fonctionnalité de session persistante (également appelée affinité de session), qui permet à l'équilibreur de charge de lier la session d'un utilisateur à une instance d'application spécifique. Cela garantit que toutes les demandes provenant de l'utilisateur pendant la session seront envoyées à la même instance d'application. [c'est moi qui souligne]
Maintenant, que signifie exactement la plus petite charge ? Encore une fois, la seule explication que je connaisse est la réponse quelque peu vague de l'équipe AWS de 2009 à la stratégie ELB :
ELB garde vaguement la trace du nombre de demandes (ou de connexions dans le cas de TCP) en attente à chaque instance. Il ne surveille pas l'utilisation des ressources (comme le processeur ou la mémoire) à chaque instance. ELB effectuera actuellement un tour de table parmi les instances qui, selon elle, contiennent le moins de demandes en suspens. [c'est moi qui souligne]
Cela a beaucoup de sens concernant leur architecture système et les cas d'utilisation traités, mais ne fournit évidemment pas la transparence et / ou le contrôle du routage que vous souhaitez ou dont vous avez besoin pour les scénarios HA avancés.
Veuillez noter que, selon l'interprétation, cela peut ou non être contredit un peu par une réponse plus récente de l'équipe AWS à Elastic Load Balancing - Stratégies de distribution de charge :
Le round-robin entre en jeu, mais les sessions client n'honorent pas toujours les caches TTL ou DNS afin que vous puissiez obtenir des résultats asymétriques et des distributions inégales des demandes. L'ELB ne prend pas en compte ce que les instances de trafic / demandes ont reçu à ce jour dans les décisions d'acheminement du trafic. [c'est moi qui souligne]
Bien sûr, ce qui précède est modifié avec les contrôles de santé correctement documentés, transparents et contrôlables , ce qui vous donne un moyen de supprimer (potentiellement temporairement) les instances de l'inclusion dans le routage en premier lieu, comme résumé dans la réponse de l'équipe AWS susmentionnée à ELB Stratégie également:
L'équilibreur de charge surveille l'intégrité de vos instances enregistrées auprès de votre équilibreur de charge. Lorsque l'équilibreur de charge détecte un problème avec une instance, il arrête de lui distribuer du trafic. Lorsque l'instance est à nouveau saine, l'équilibreur de charge redémarre la distribution du trafic vers elle. Ce processus permet à votre application de réagir automatiquement aux instances ayant échoué sans que vous ayez à être impliqué au-delà de la configuration du bilan de santé.
Bien que certainement inhabituel, je ne vois pas pourquoi ELB ne devrait pas fonctionner avec un pool de différents types d'instances Amazon EC2 également - je n'ai pas essayé cela moi-même cependant et je recommanderais les deux, Surveillance de votre équilibreur de charge à l'aide de CloudWatch ainsi que surveillance vos instances EC2 individuelles et corrélez les résultats afin d'obtenir un aperçu et une confiance respectifs dans une telle configuration à terme.
Sur la base des déclarations faites jusqu'à présent, l'algorithme de distribution est extrêmement simple.
Le front-end d'ELB est généralement plus d'une instance ELB, et la distribution est circulaire.
Le back-end (vos instances) prétend être:
ELB garde vaguement la trace du nombre de demandes (ou de connexions dans le cas de TCP) en attente à chaque instance. Il ne surveille pas l'utilisation des ressources (comme le processeur ou la mémoire) à chaque instance. ELB effectuera actuellement un tour de table parmi les instances qui, selon elle, contiennent le moins de demandes en suspens.
Cela impliquerait que si une instance plus importante a moins de demandes en attente, alors plus de trafic serait acheminé vers elles. Il n'y a aucun moyen de garantir cela.