L'équilibrage de charge dans Amazon EC2?

Question

Nous nous disputons avec HAProxy depuis plusieurs jours dans Amazon EC2; L’expérience a jusqu’à présent été excellente, mais nous n’avons pas l’intention de tirer davantage de performances de l’équilibreur de charge logiciel. Nous ne sommes pas exactement des experts en réseautage sous Linux (nous sommes une boutique .NET, normalement), mais nous avons jusqu'ici tenu le nôtre en tentant de définir correctement les limites, en inspectant les messages du noyau et les tcpdumps pour détecter les irrégularités éventuelles. Jusqu'à présent, cependant, nous avons atteint un plateau d'environ 1 700 demandes / s. À ce stade, les délais d'attente des clients ne manquent pas (nous utilisons et modifions httperf à cette fin). Un collègue et moi-même écoutions le dernier podcast Stack Overflow, dans lequel les fondateurs de Reddit notent que l'ensemble de leur site utilise un nœud HAProxy et qu'il n'est pas encore devenu un goulot d'étranglement. Ack! Soit nous ne voyons pas autant de demandes simultanées, nous faisons quelque chose de terriblement faux, soit la nature partagée d’EC2 limite la pile réseau de l’instance Ec2 (nous utilisons un type d’instance volumineux). Compte tenu du fait que Joel et les fondateurs de Reddit sont d’accord sur le fait que le réseau sera probablement le facteur limitant, est-il possible que ce soit la limitation que nous observons?

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

Modifier Il semble que le problème réel ne concerne pas le nœud de l'équilibreur de charge! Le coupable était en fait les nœuds exécutant httperf, dans ce cas. Lorsque httperf construit et détruit un socket pour chaque requête, il consacre une bonne quantité de temps processeur au noyau. Lorsque nous avons augmenté le taux de requête, le TCP FIN TTL (60 secondes par défaut) conservait les sockets trop longtemps et la valeur par défaut de ip_local_port_range était trop basse pour ce scénario d'utilisation. Au bout de quelques minutes, le nœud client (httperf) crée et détruit constamment de nouveaux sockets, le nombre de ports inutilisés s’est épuisé et les "requêtes" suivantes ont été égarées à ce stade, générant un nombre de requêtes bas / s et une grande quantité. des erreurs.

Nous avons également examiné nginx, mais nous travaillons avec RighScale et ils ont des scripts de remplacement pour HAProxy. Oh, et nous avons bien sûr une échéance trop serrée pour échanger des composants, à moins que cela ne s'avère absolument nécessaire. Heureusement, le fait d’être sur AWS nous permet de tester une autre configuration en utilisant nginx en parallèle (si cela est justifié) et d’effectuer le changement du jour au lendemain.

Cette page décrit assez bien chacune des variables sysctl. (ip_local_port_range et tcp_fin_timeout ont été réglés, dans ce cas).

Answer 1

Ce n'est pas vraiment une réponse à votre question, mais nginx et pound ont tous deux une bonne réputation d'équilibreurs de charge. Wordpress est passé à nginx avec de bons résultats.

Mais plus spécifiquement, pour déboguer votre problème. Si vous ne voyez pas une utilisation à 100% de l'unité centrale (y compris une attente d'E / S), vous êtes lié au réseau, oui. En interne, EC2 utilise un réseau gigabit. Essayez d’utiliser une instance XL pour disposer du matériel sous-jacent et ne pas avoir à partager ce port réseau gigabit.

Answer 2

Ne répond pas directement à la question, mais EC2 prend désormais en charge l'équilibrage de charge via Elastic Load Balancing plutôt que de s'exécuter. votre propre équilibreur de charge dans une instance EC2.

EDIT: Le service DNS Route 53 d'Amazon offre désormais un moyen de faire pointer un domaine de niveau supérieur sur un ELB avec un "alias". record. Étant donné qu'Amazon connaît l'adresse IP actuelle de l'ELB, il peut renvoyer un enregistrement A pour cette adresse IP actuelle sans avoir à utiliser un enregistrement CNAME, tout en restant libre de modifier l'adresse IP de temps à autre.

Answer 3

Oui, vous pouvez utiliser un équilibreur de charge hors site .. et sur du bare metal, LVS est un excellent choix, mais votre temps de latence sera terrible! Selon la rumeur, Amazon va régler le problème de CNAME. Cependant, il est peu probable qu’ils ajoutent des contrôles d’état https, complets ou personnalisés, des agents de retour, une correspondance d’URL, l’insertion de cookies (et certaines personnes ayant une bonne architecture diraient également cela aussi). Cependant, c’est pourquoi Scalr, RightScale et d’autres utilisent habituellement HAProxy. les derrière une entrée DNS à tour de rôle. Ici, chez Loadbalancer.org, nous sommes sur le point de lancer notre propre solution d'équilibrage de charge EC2: http: // blog. loadbalancer.org/ec2-load-balancer-appliance-rocks-and-its-free-for-now-anyway/ Nous prévoyons d’utiliser des scripts SSH pour s’intégrer à la mise à l’échelle automatique de la même manière que rightscale, tous les commentaires appréciés sur le blog. Merci

Answer 4

Je souhaiterais basculer vers un équilibreur de charge hors site, et non dans le nuage, et utiliser un système similaire à IPVS. [La raison pour laquelle il serait hors du nuage d'Amazon est à cause du truc du noyau] Si Amazon ne limite pas l'IP source des paquets en sortie, vous pouvez utiliser un mécanisme d'équilibrage de charge unidirectionnel. Nous faisons quelque chose comme cela et cela nous donne environ 800 000 demandes simultanées [bien que nous ne traitions pas la latence]. Je dirais aussi que vous utilisez "ab2". (banc apache), car il est un peu plus convivial et plus facile à utiliser à mon humble avis.

Answer 5

Même si votre problème est résolu. KEMP Technologies dispose désormais d'un équilibreur de charge totalement éclaté pour AWS. Pourrait vous épargner quelques soucis.