Faites évoluer HAProxy pour plus de 64 000 websockets

8

Nous essayons de concevoir une architecture capable de gérer plus de 64 000 websockets.

Nous avons d'abord essayé avec Amazon ELB, mais sa conception ne permet pas un pic inattendu de trafic ni de websocket. (Le mode TCP expire les websockets de manière inattendue)

Avec HAProxy, ces limites ne s'appliquent pas, mais nous serons limités à environ 64 000 websockets maintenus entre HA et les serveurs principaux.

Plusieurs solutions qui vous sont venues à l'esprit:

  • Plusieurs instances HAProxy, équilibre de charge avec DNS (Route53 a une option pondérée)
  • Deux instances HAProxy avec Keepalived, plusieurs adresses IP internes (je ne sais pas si c'est faisable)

Y a-t-il une meilleure manière de faire cela ?

domain-name-system load-balancing haproxy scalability websocket Bastien974
la source
1
Pourquoi 64k limit? S'agit-il d'un port source? Si tel est le cas, vous pouvez simplement ajouter plus de «serveurs» au backend qui sont liés à différents ports ...
Kyle Brandt
@ Bastien974, le moyen le plus simple, est d'utiliser différentes sources ip pour les backends, pour évoluer vers des connexions 130K, j'ai utilisé deux options ips et tw_reuse sysctl
c4f4t0r

Réponses:

7

Si votre limite de 64 Ko est due aux ports source, vous pouvez faire quelque chose comme ceci (un peu hacky, mais c'est ce que nous faisons actuellement à SE pour les websockets (nous avons quelque chose comme 0,5 million en même temps que HAProxy):

server ny-web01-1 10.0.0.1:8081 check
server ny-web01-2 10.0.0.1:8082 check
server ny-web01-3 10.0.0.1:8083 check

De plus, plusieurs instances sont réalisables avec keepalived. Faites simplement quelque chose comme DNS à tour de rôle sur plusieurs IP. Assurez-vous simplement que les IP sont toujours récupérées par les équilibreurs de charge actifs car le DNS lui-même ne vous donnera pas l'équilibrage de la charge (il y a plus d'options ici aussi, celle-ci est tout simplement simple).

Kyle Brandt
la source
1
Si je comprends bien, car une connexion TCP est définie par srcIP: srcPORT / destIP: destPORT, si je suis capable d'écouter dans les serveurs principaux sur plusieurs ports, cela signifierait entre HAProxy et les serveurs principaux, je serais en mesure d'avoir plusieurs connexions à partir du même 127.0.0.1.112345 -> 10.0.0.1:8081, 127.0.0.1:12345 -> 10.0.0.1:8082, etc.? Est-ce que cela fonctionne vraiment?
Bastien974
@ Bastien974: Vous comprenez bien - cela fonctionne.
Kyle Brandt
@ Bastien974: Vous pouvez utiliser source 0.0.0.0 usesrc clientdans la configuration backend de haproxy pour la transparence de la source tproxy. De cette façon, srcIP: srcPORT va être l'IP / les ports clients réels (pas les IP internes de la machine haproxy) - parfait pour la journalisation aussi.
wqw
0

Vous pouvez configurer plusieurs systèmes HAproxy qui partagent les mêmes IP en utilisant Anycast et BGP ou un autre protocole de routage de frontière. De cette façon, tous les systèmes HAproxy sont actifs; si l'un de ceux-ci tombe en panne, vous arrêtez de faire la publicité de l'itinéraire BGP sur ce système et il cessera en ~ 30 secondes de recevoir du trafic; qui sera redistribué à d'autres systèmes disponibles qui annoncent la même gamme.

Par exemple, vérifiez cette URL pour savoir comment configurer une telle disposition

Hrvoje Špoljar
la source
Je ne suis pas sûr que cela fonctionnerait à l'intérieur d'une infrastructure AWS VPC car j'ai besoin d'utiliser Elastic IP associé à chaque instance. Votre solution serait très proche de celle du DNS, car Amazon Route53 offre la possibilité d'ajouter un bilan de santé. Ma préoccupation est que même avec un TTL bas, nous ne pouvons pas nous permettre d'attendre la propagation vers d'autres pays (nous avons un client dans le monde entier) pour arrêter d'envoyer du trafic vers une instance HA "morte".
Bastien974