Est-il possible de mettre 2 HAProxy en maître/esclave ( pour palier à des problèmes de disques par exemple ) ?
Si oui est-il possible de garder les connections ( VRRP ? ) ?
Pour la première question, oui on peut faire ça avec du VRRP. Mais si possible, on évite de mettre des disques dans des machines qui assurent ce genre de fonctions lorsqu'elles sont vitales.
Pour la seconde question, oui et non :
- on ne peut pas garder les connexions TCP vu qu'elles sont établies par une machine et que l'autre ne les a pas dans sa table, et ne connait pas les données, les numéros des séquence TCP, tailles de fenêtres, etc...
- par contre, pour la persistance niveau 7, ça ne pose pas de problème lorsqu'on utilise des algorithmes déterministes comme l'insertion de cookie. Les deux répartiteurs ont la même conf, et lorsque le client présente son cookie désignant le serveur 2, les deux comprennent de quel serveur il s'agit.
Sur du HTTP, d'une manière générale, on ne se soucie pas de la reprise de sessions TCP, les sessions sont bien trop éphémères, et leur contenu rejouable, parfois même par le navigateur lui-même. De plus, le surcoût lié à la synchronisation (p.ex sur des firewalls) est énorme sur des sites à fort trafic.
Si vous voulez expérimenter avec le VRRP, je recommande keepalived ( http://www.keepalived.org/ ) (en particulier la version 1.1.13, à laquelle j'ai ajouté des fonctionnalités de tests de process locaux et de priorités flottantes précisément pour mieux le coupler à haproxy). En plus, son auteur (Alex Cassen) est français également, et bien que peu bavard sur son produit, a créé un excellent framework le rendant très extensible.
[^] # Re: config maitre / esclave
Posté par tarreau willy . En réponse à la dépêche HAProxy, le répartiteur de charge fiable et performant. Évalué à 4.
Pour la première question, oui on peut faire ça avec du VRRP. Mais si possible, on évite de mettre des disques dans des machines qui assurent ce genre de fonctions lorsqu'elles sont vitales.
Pour la seconde question, oui et non :
- on ne peut pas garder les connexions TCP vu qu'elles sont établies par une machine et que l'autre ne les a pas dans sa table, et ne connait pas les données, les numéros des séquence TCP, tailles de fenêtres, etc...
- par contre, pour la persistance niveau 7, ça ne pose pas de problème lorsqu'on utilise des algorithmes déterministes comme l'insertion de cookie. Les deux répartiteurs ont la même conf, et lorsque le client présente son cookie désignant le serveur 2, les deux comprennent de quel serveur il s'agit.
Sur du HTTP, d'une manière générale, on ne se soucie pas de la reprise de sessions TCP, les sessions sont bien trop éphémères, et leur contenu rejouable, parfois même par le navigateur lui-même. De plus, le surcoût lié à la synchronisation (p.ex sur des firewalls) est énorme sur des sites à fort trafic.
Si vous voulez expérimenter avec le VRRP, je recommande keepalived ( http://www.keepalived.org/ ) (en particulier la version 1.1.13, à laquelle j'ai ajouté des fonctionnalités de tests de process locaux et de priorités flottantes précisément pour mieux le coupler à haproxy). En plus, son auteur (Alex Cassen) est français également, et bien que peu bavard sur son produit, a créé un excellent framework le rendant très extensible.
Willy