L'équilibrage de charge dans Amazon EC2?

Question

Nous avons eu des combats avec HAProxy pour quelques jours dans Amazon EC2; l'expérience a été jusqu'à présent très bien, mais nous sommes coincés sur la serrant plus les performances du logiciel d'équilibrage de la charge. Nous ne sommes pas exactement les réseaux Linux génies (nous ne sommes qu'un .NET boutique, normalement), mais nous avons tenu jusqu'à présent notre propre, en essayant de régler correctement les ulimits, en inspectant les messages du noyau et tcpdumps pour toutes les irrégularités. Jusqu'à présent, nous avons atteint un plateau d'environ 1 700 requêtes/s, à quel point le client délais d'attente abondent (nous avons été à l'aide de et de peaufinage httperf à cet effet). Un collègue et moi avons été à l'écoute de la plus récente Débordement de Pile podcast, dans lequel le Reddit fondateurs de noter que la totalité de leur site fonctionne un HAProxy nœud, et qui jusqu'à présent n'est pas devenu un goulot d'étranglement. Ack! Il n'y a de toute façon pas voir que beaucoup de demandes simultanées, nous faisons quelque chose de mal, ou de la nature partagée de l'EC2 est la limitation de la pile réseau de l'instance Ec2 (nous sommes à l'aide d'un grand type d'instance). Compte tenu du fait que Joel et le Reddit fondateurs d'accord que le réseau sera probablement le facteur limitant, est-il possible que la limitation que nous voyons?

Toutes les pensées sont grandement appréciés!

Edit , Il ressemble à la réelle question n'est pas, en fait, avec l'équilibrage de la charge de noeud! Le coupable était en fait les noeuds httperf, dans la présente instance. Comme httperf construit et arrache un socket pour chaque demande, il consacre une bonne quantité de temps CPU dans le noyau. Comme nous avons croisé le taux de demande supérieure, le TCP FIN TTL (années 60 par défaut) a été de garder les sockets autour trop long, et le ip_local_port_range par défaut a été trop faible pour ce scénario d'utilisation. En gros, après quelques minutes de la client (httperf) nœud de constamment créer et de détruire les nouveaux sockets, le nombre de ports non utilisés manqué, et après la "demande" d'erreur à ce stade, rendement faible demande/sec nombre et une grande quantité d'erreurs.

Nous avons également eu regardé nginx, mais Nous avons travaillé avec RighScale, et ils ont déroulant dans des scripts pour HAProxy. Oh, et nous avons trop serré un délai de [bien sûr] pour passer sur les composants, sauf si cela s'avère absolument nécessaire. Heureusement, étant sur AWS nous permet de tester une autre configuration à l'aide de nginx en parallèle (le cas échéant), et de les faire passer une nuit plus tard.

Cette page décrit chacune des variables sysctl assez bien (ip_local_port_range et tcp_fin_timeout ont été à l'écoute, dans ce cas).

Answer 1

Ne pas répondre directement à la question, mais EC2 prend désormais en charge l'équilibrage de charge par le biais de Elastic Load Balancing , plutôt que de courir votre propre programme d'équilibrage de charge dans une instance EC2.

EDIT: Amazon Route 53 DNS service propose désormais un moyen de signaler un domaine de niveau supérieur à un ELB avec un "alias" enregistrement. Depuis Amazon connaît l'adresse IP actuelle de l'ELB, il peut retourner un record pour cette IP actuelle plutôt que d'avoir à utiliser un enregistrement CNAME, tout en restant libre de changer l'IP de temps à autre.

Answer 2

Pas vraiment une réponse à votre question, mais de nginx et livre tous les deux ont bonne réputation load-balancers. Wordpress juste passé à nginx avec de bons résultats.

Mais, plus précisément, de corriger votre problème. Si vous ne voyez pas 100% d'utilisation du processeur (y compris attente d'e/S), alors vous êtes au réseau lié, oui. EC2 utilise en interne un réseau gigabit, essayez d'utiliser un XL exemple, si vous avez le matériel sous-jacent à vous-même, et ne pas avoir à partager et que le port réseau gigabit.

Answer 3

Oui, Vous pouvez utiliser un équilibreur de charge.. et sur métal nu LVS est un excellent choix, mais votre temps de latence sera terrible! La rumeur veut qu'Amazon va résoudre le problème lié à CNAME. Cependant, ils sont peu susceptibles d'ajouter https, de la profondeur ou de la coutume des contrôles de santé, de la rétroaction des agents, l'url correspondant, témoin d'insertion (et certaines personnes avec une bonne architecture dirais tout à fait raison.) Cependant c'est pourquoi Scalr, RightScale et d'autres sont à l'aide de HAProxy généralement de deux d'entre eux derrière un round robin DNS entrée. Ici, à Loadbalancer.org nous sommes sur le point de lancer notre propre EC2 d'équilibrage de la charge appaliance: http://blog.loadbalancer.org/ec2-load-balancer-appliance-rocks-and-its-free-for-now-anyway/ Nous sommes à la planification sur l'utilisation de SSH scripts pour intégrons avec mise à l'échelle automatique de la même façon rightscale est le cas, les commentaires appréciés sur le blog. Merci

Answer 4

Je regarde le passage à un hors-site d'équilibrage de la charge, non pas dans le cloud et exécuter quelque chose comme IPVS sur le dessus de cela. [La raison pour laquelle il serait hors de amazon cloud est à cause de noyau choses] Si Amazon ne limite pas l'adresse IP source des paquets provenant de l', vous pourriez aller avec une unidirectionnel mécanisme d'équilibrage de charge. Nous faisons quelque chose comme ça, et elle nous permet de nous, environ 800 000 demandes simultanées [bien que nous ne traitent pas de latence]. Je voudrais également dire l'utilisation "ab2" (apache bench), comme il est un peu plus convivial et plus facile à utiliser, à mon humble avis.