Lors de l'utilisation de l'équilibrage de charge TCP avec HAProxy, tout le trafic sortant passe-t-il par le LB?

Je configure une application à héberger à l'aide de machines virtuelles (probablement Amazon, mais ce n'est pas figé) qui nécessitera à la fois l'équilibrage de charge HTTP et l'équilibrage de charge un grand nombre (50k environ si possible) de connexions TCP persistantes. La quantité de données n'est pas si élevée, mais les mises à jour sont fréquentes.

En ce moment, j'évalue les équilibreurs de charge et je suis un peu confus quant à l'architecture de HAProxy. Si j'utilise HAProxy pour équilibrer les connexions TCP, tout le trafic résultant devra-t-il transiter par l'équilibreur de charge? Dans l'affirmative, une autre solution (comme LVS ou même nginx_tcp_proxy_module) serait-elle mieux adaptée?

HAProxy (comme de nombreux équilibreurs de charge) entretient généralement deux conversations. Le proxy a une session (tcp dans ce cas) avec le client et une autre session avec le serveur. Par conséquent, avec les proxys, vous finissez par voir 2x les connexions sur l'équilibreur de charge. Par conséquent, tout le trafic passe par l'équilibreur de charge.

En ce qui concerne la mise à l'échelle sur plusieurs équilibreurs de charge, je ne pense pas que vous en ayez besoin. Mais un moyen pratique et assez facile de le faire est d'utiliser quelque chose comme keepalived avec deux IP flottantes et un DNS à tour de rôle entre ces deux IP. Avec keepalived, si l'un des équilibreurs de charge tombe en panne, l'autre détiendrait les deux adresses IP, vous obtenez ainsi une haute disponibilité de cette façon. Cela étant dit, je pense que vous irez bien avec une instance haproxy active avec votre charge.

HAProxy évolue très bien. Par exemple, le réseau Stack Exchange utilise des sockets Web qui maintiennent des connexions TCP ouvertes. Pendant que je publie ceci, nous avons 143 000 sockets TCP établis sur une machine virtuelle VMware sans aucun problème. L'utilisation du processeur sur la machine virtuelle est d'environ 7%.

Avec ce type de configuration avec HAProxy, assurez-vous de régler maxconnsuffisamment haut. Voici un exemple de configuration HAProxy pour vous aider à démarrer:

frontend fe_websockets
        bind 123.123.123.123:80
        mode tcp
        log global
        option tcplog
        timeout client 3600s
        backlog 4096
        maxconn 50000
        default_backend be_nywebsockets

backend be_nywebsockets
        mode  tcp
        option log-health-checks
        option redispatch
        option tcplog
        balance roundrobin
        server web1 10.0.0.1:1234
        server web2 10.0.0.2:1234
        timeout connect 1s
        timeout queue 5s
        timeout server 3600s

Oui, tout le trafic doit normalement passer par l'équilibreur de charge. Les demandes sont reçues par l'équilibreur de charge et les réponses sont renvoyées à l'équilibreur de charge qui les renvoie aux clients.

Pour choisir le bon outil, je n'ai pas beaucoup d'expérience sur les autres options. J'utilise haproxy et il est vraiment bon et stable et peut gérer une grande quantité de trafic. De plus, ses capacités ACL sont excellentes.

Il existe une possibilité d'utiliser et de configurer DSR (Direct Server Return) mais cela n'a rien à voir avec le Loadbalancer mais est configuré dans la pile tcp (tables de routage). Nous l'avons utilisé pour un grand portail vidéo streaaming. Bien que cela fonctionne, cela vous donnera beaucoup de maux de tête concernant la complexité du routage nécessaire.

Ainsi, je ne recommanderais pas d'utiliser cette technique sans considérer très attentivement l'utilisation et les inconvénients.

Il y a peut-être quelques astuces pour commencer:

• http://www.remsys.com/blog/configuring-dsr-on-the-alteon-load-balancers
• http://community.brocade.com/docs/DOC-1650

S'amuser!