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.
Bonjour, Haproxy devrait savoir faire tout cela. http://www.haproxy.org/ -- Bruno 2016-06-10 10:26 GMT+02:00 Artur <frsag@pydo.org>:
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/
-- Bruno Cénou - CNRS Administrateur des systèmes d'information Centre pour l'édition électronique ouverte (CNRS - EHESS - Aix-Marseille Université - Université d'Avignon) Cléo / OpenEdition 38 rue Frédéric Joliot-Curie 13451 Marseille Cedex 20 Tél. +33 (0)4 13 55 03 52 Fax +33 (0)4 13 55 03 41 bruno.cenou@openedition.org http://www.openedition.org http://books.openedition.org http://calenda.org http://leo.hypotheses.org http://cleo.openedition.org
Bonjour, Je crois qu'il n'y a pas grand-chose que HAProxy ne sache pas faire. C'est bueno pour : - L'offloading TLS - Le bind en mode http - Les redirections de scheme de http:// vers https:// - La gestion des poids / nombre de try avant de considérer un backend comme décédé - Les perfs (en kernel space de mémoire, c'est tes IOPS / nombre de ports TCP / ulimit qui vont limiter le max du bouzin) Hugo -----Message d'origine----- De : FRsAG [mailto:frsag-bounces@frsag.org] De la part de Artur Envoyé : vendredi 10 juin 2016 10:27 À : frsag@frsag.org Objet : [FRsAG] Un reverse proxy de rêve ? 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/
Le 10/06/2016 à 10:26, Artur a écrit :
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
Hello Artur, A priori, haproxy répond à tous les besoins (je ne suis pas complètement affirmatif pour la partie chocolat chaud, mais café ok). Pour "dizaine de milliers de websockets", suivant le nombre de dizaines, il faudra peut être finasser avec des binds sur des IPs supplémentaires. A+ M -- Michel Blanc { :github => "@leucos", :twitter => "@b9m", :gpg => "0X24B35C22" }
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/
Ben HaProxy sait faire tout ca. Sauf peut-etre le sticky-sticky. Quand ton backend nr 3 est down depuis 10 minutes, tu fais quoi ? Faut tatonner un peu pour les bons reglages, et la gestion des acl est un peu surprenante avec des trucs genre 'scl_inc_gc0' qui ne fait pas que verifier une ACL mais incremente un compteur. Mais un admin moyen en 2-3 semaines peu monter une architecture assez impressionante. En plus couplé a keepalived, tu as une solution tres robuste. Tu gere l'affinité par cookies, donc elle est gardée meme si ton traffic arrive sur un autre haproxy. Cerise sur le Gateau, Willy est tres sympa et la mailing liste tres active. On 2016-06-10 10:26, Artur 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.
Le Fri, Jun 10, 2016 at 10:26:36AM +0200, Artur [frsag@pydo.org] a écrit: [...]
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).
Tout le monde a fait les éloges de haproxy, qui, je pense, remplit ton cahier des charges. Sinon, Apache 2.4 (ouais je sais, c'est has-been :-) sait faire des sticky sessions par cookie et pourrait sans doute faire tout ce que tu veux. Et sinon, par rapport au nombre de connexions simultanées à gérer, si ton proxy applicatif approche les limites du serveur, envisages d'ajouter un load-balancer au niveau ip devant. -- Dominique Rousseau Neuronnexion, Prestataire Internet & Intranet 21 rue Frédéric Petit - 80000 Amiens tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop
Merci à tous pour vos suggestions de HAProxy et pour le paramétrage de nginx, j'ai loupé un ou deux paramètres. Je suis donc "condamné" à découvrir HAProxy. :) Au passage, j'ai effectivement fait quelques tests avec Apache et il fait ce qu'il faut, mais il me semblait plus gourmand en ressources que nginx. Ou alors, ma config de test n'était pas correctement paramétrée. -- Cordialement, Artur.
participants (8)
-
Artur -
Bruno Cénou -
Dominique Rousseau -
Fabien Germain -
Hugo CLARIA -
Michel blanc -
Thomas Cheronneau -
Thomas Pedoussaut