Question Échelle HAProxy pour plus de 64 000 websockets


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

Nous avons d’abord essayé avec Amazon ELB, mais sa conception ne permet pas une augmentation inattendue du trafic ni des prises Web. (Mode TCP expirant les websockets de manière inattendue)

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

Les solutions multiples qui me sont venues à l’esprit:

  • Plusieurs instances HAProxy, répartition de charge avec DNS (Route53 possède une option pondérée)
  • Deux instances HAProxy avec Keepalived, plusieurs adresses IP internes (ne sait pas si c'est faisable)

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


8
2017-11-05 16:21


origine


Pourquoi 64k limite? Est-ce une chose de 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, consiste à utiliser différentes sources IP pour les backends, pour passer à 130K connexions, j’ai utilisé deux options sipsct ips et tw_reuse - c4f4t0r


Réponses:


Si votre limite de 64k est due à des ports source, vous pouvez faire quelque chose comme ceci (un peu hacky, mais c'était ce que nous faisons actuellement chez SE pour les websockets (nous avons quelque chose comme .5 millions simultanés habituellement avec 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

Plusieurs instances sont également possibles avec keepalived. Il suffit de faire quelque chose comme un DNS à tour de rôle sur plusieurs adresses 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, celle-ci est simplement simple).


7
2017-11-05 17:17



Si je comprends bien, puisqu’une connexion TCP est définie par srcIP: srcPORT / destIP: destPORT, si je suis capable d’écouter les serveurs principaux sur plusieurs ports, cela signifie entre HAProxy et les serveurs principaux, je pourrais avoir plusieurs connexions du même 127.0.0.1:12345 -> 10.0.0.1:8081, 127.0.0.1:12345 -> 10.0.0.1:8082, etc? Est-ce que ça marche vraiment? - Bastien974
@ Bastien974: Vous comprenez bien - cela fonctionne. - Kyle Brandt♦
@ Bastien974: Vous pouvez utiliser source 0.0.0.0 usesrc client dans la configuration dorsale de haproxy pour la transparence de la source tproxy. De cette façon, srcIP: srcPORT seront l'adresse IP / les ports du client (et non les adresses IP internes de la machine haproxy), ce qui est également pratique pour la journalisation. - wqw


Vous pouvez configurer plusieurs systèmes HAproxy partageant les mêmes adresses IP en utilisant Anycast et BGP ou un autre protocole de routage à la frontière. Ainsi, tous les systèmes HAproxy sont actifs. si l'un de ces événements tombe en panne, vous arrêtez d'annoncer la route BGP sur ce système et cela arrêtera dans 30 secondes la réception du trafic; qui seront redistribués aux autres systèmes disponibles qui annoncent la même gamme.

Par exemple vérifier ce URL sur la façon de configurer une telle disposition


0
2017-11-05 16:29



Je ne suis pas tout à fait sûr que cela fonctionnerait dans une infrastructure AWS VPC car je dois 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é. Mon problème 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