Hello,

HAproxy pourrais te permettre tout cela je pense. 
On l’utilise pas mal chez nous et il fait le café (je ne sais pas pour le chocolat par contre .. )

Par contre, je crois que Nginx permet de faire du sticky session via cookie (je l’ai déjà mis en place mais sans le tester en production je dois l’avouer). 
Avec un configuration de ce genre : 
upstream critiques {

    # Tente de se connecter 3 fois, en cas d’échec down 30sec avant le nouveau test
    server 192.168.0.132:80 max_fails=3 fail_timeout=30s;
    server 192.168.0.133:80 max_fails=3 fail_timeout=30s;

    keepalive 30;
}

map $cookie_backend $sticky_critiques {
    # Test la variable cookie_backend et modifie sticky_backend suivant sa valeur
    pweb2     192.168.0.132:80;
    pweb3     192.168.0.133:80;
    # Par defaut renvoie sur le cluster
    default   critiques;

} 


-- 
Thomas Cheronneau

On 10 June 2016 at 10:27:16, Artur (frsag@pydo.org) wrote:

Bonjour les gens,

J'aurais besoin de vos conseils pour mettre en place un reverse proxy
applicatif devant une application node.js qui utilise des websockets.

J'ai déjà un nginx qui fait ça, mais il y a quelques détails qui me
posent problème (sticky sessions pas en natif, paramétrage incomplet) et
j'aimerais savoir quelles sont les alternatives.

Le proxy doit pouvoir gérer les connexions http et https (terminateur
tls) avec des backends en http et ws, savoir gérer les sticky sessions
avec des cookies (pas par adresse IP d'origine).

Et être tolérant avec ses backends. Par exemple, pouvoir réessayer si
jamais il y a un souci de connexion, ne pas basculer sur d'autres
backends sans qu'on lui demande dans la config (sticky sessions !),
supporter un nombre de connexions ouvertes importantes (dizaine de
milliers de websockets), ne pas être trop gourmand en ressources. Il
peut aussi faire le chocolat chaud... je bois pas de café. :p

Merci pour votre retour d'expériences.

--
Cordialement,
Artur.

_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/