Bonjour, j'aurais aimé des retours éventuels sur de la répartition de charge en direct routing (DSR) sur le protocole HTTPS. J'imagine qu'il faut que les ports soient configurés en sticky pour éviter des switchs de sessions SSL ... A chaque fois les exemples utilisent un SSL Accelerator pour soulager les serveurs, mais dans mon cas je n'en ai pas besoin comme les serveurs ne font pas grand chose... je veux mettre en place du LB pour faire du failover uniquement (et heartbeat 2 me sort par les yeux)... -- Greg
2010/9/28 Greg <greg-frsag@duchatelet.net>:
Bonjour,
j'aurais aimé des retours éventuels sur de la répartition de charge en direct routing (DSR) sur le protocole HTTPS. J'imagine qu'il faut que les ports soient configurés en sticky pour éviter des switchs de sessions SSL ...
A chaque fois les exemples utilisent un SSL Accelerator pour soulager les serveurs, mais dans mon cas je n'en ai pas besoin comme les serveurs ne font pas grand chose... je veux mettre en place du LB pour faire du failover uniquement (et heartbeat 2 me sort par les yeux)...
Si tu ne sers pas grand chose (est-ce que c'est ce que tu entends par "ne font pas grand chose") alors le DSR ne t'apportera pas grand chose. Tu gagnes un routage et surtout une contrainte : Il y a deux façon de le faire, soit par remplacement de la MAC à l'envoie de la trame, soit en utilisant des interfaces dummy sur tes serveurs. Donc dans le premier cas, ça ne fonctionne qu'en local, et dans le second, ça t'imposes de ré-adresser tes machines. Donc dans le premier cas, tu ne vas gagner que tu as une latence improbable sur ta commutation ou que ton LB est très lent. Dans l'autre cas, il faut en gros refaire l'archi en servant de nouvelles adresses, ou les conserver mais les migrer d'un eth([0-9]+) à un dummy$1 pour ne pas répondre à l'arp de ta gw. Après ça dépend du nombre de connexions, de la quantité de donnée que tu sers, etc...
-- Greg
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
-- Steven Le Roux Jabber-ID : Steven@jabber.fr 0x39494CCB <steven@le-roux.info> 2FF7 226B 552E 4709 03F0 6281 72D7 A010 3949 4CCB
On Tue, 28 Sep 2010 16:51:19 +0200, Steven Le Roux <steven@le-roux.info> wrote:
2010/9/28 Greg <greg-frsag@duchatelet.net>:
Bonjour,
j'aurais aimé des retours éventuels sur de la répartition de charge en direct routing (DSR) sur le protocole HTTPS. J'imagine qu'il faut que les ports soient configurés en sticky pour éviter des switchs de sessions SSL ...
avec un lvs (keepalived) il faut évidemment ajouter le sticky et astuce si tu veux par exemple passer du http au https il faut dans keepalived indiquer comme port 0 (tous quoi).
A chaque fois les exemples utilisent un SSL Accelerator pour soulager les serveurs, mais dans mon cas je n'en ai pas besoin comme les serveurs ne font pas grand chose... je veux mettre en place du LB pour faire du failover uniquement (et heartbeat 2 me sort par les yeux)...
Si tu ne sers pas grand chose (est-ce que c'est ce que tu entends par "ne font pas grand chose") alors le DSR ne t'apportera pas grand chose. Tu gagnes un routage et surtout une contrainte :
Il y a deux façon de le faire, soit par remplacement de la MAC à l'envoie de la trame, soit en utilisant des interfaces dummy sur tes serveurs. Donc dans le premier cas, ça ne fonctionne qu'en local, et dans le second, ça t'imposes de ré-adresser tes machines.
Donc dans le premier cas, tu ne vas gagner que tu as une latence improbable sur ta commutation ou que ton LB est très lent. Dans l'autre cas, il faut en gros refaire l'archi en servant de nouvelles adresses, ou les conserver mais les migrer d'un eth([0-9]+) à un dummy$1 pour ne pas répondre à l'arp de ta gw.
Après ça dépend du nombre de connexions, de la quantité de donnée que tu sers, etc...
le plus simple est de faire un lo:0 avec l'ip du LB et ajouter dans le sysctl.conf : net.ipv4.conf.ethX.arp_ignore = 1 net.ipv4.conf.ethX.arp_announce = 2 Enjoy ;)
Il y a quand même un truc que je ne comprend pas dans ton questionnement, quel est l'intéret pour toi de faire du DSR si tu as très peu de traffic ? ca va juste rendre "compliqué" ton infra pour rien. autant faire du lvs mode nat via keepalived, ca sera bien plus simple et compréhensible par la suite. Et sinon, haproxy fait ca très bien aussi :) mais tu sembles vouloir utiliser du LB L4. Hervé. On Tue, 28 Sep 2010 12:02:29 +0200 Greg <greg-frsag@duchatelet.net> wrote:
Bonjour,
j'aurais aimé des retours éventuels sur de la répartition de charge en direct routing (DSR) sur le protocole HTTPS. J'imagine qu'il faut que les ports soient configurés en sticky pour éviter des switchs de sessions SSL ...
A chaque fois les exemples utilisent un SSL Accelerator pour soulager les serveurs, mais dans mon cas je n'en ai pas besoin comme les serveurs ne font pas grand chose... je veux mettre en place du LB pour faire du failover uniquement (et heartbeat 2 me sort par les yeux)...
-- Hervé COMMOWICK, EXOSEC (http://www.exosec.fr/) ZAC des Metz - 3 Rue du petit robinson - 78350 JOUY EN JOSAS Tel: +33 1 30 67 60 65 - Fax: +33 1 75 43 40 70 mailto:hcommowick@exosec.fr
Le 29/09/2010 10:05, Hervé COMMOWICK a écrit :
Il y a quand même un truc que je ne comprend pas dans ton questionnement, quel est l'intéret pour toi de faire du DSR si tu as très peu de traffic ?
La latence par exemple. C'est pour une page de paiement, chaque ms compte.
ca va juste rendre "compliqué" ton infra pour rien.
Toute mon infra est en DSR pour le reste, je trouve pas très compliqué d'ajouté une vip sur lo et 3 lignes dans sysctl.conf ... Le NAT peut apporter d'autres problèmes, et je veux que ce soit le plus simple possible au niveau du réseau (pas forcément de l'infra), parce que même s'il n'y a pas énormément de traffic, les tables de NAT peuvent être vite pleines par exemple... La question que je me posais, c'est surtout "est-ce que ça marche le https en DSR ?" et si non, pourquoi ? -- Greg
Yop, On Wed, Sep 29, 2010 at 10:56:44AM +0200, Greg wrote:
Le 29/09/2010 10:05, Hervé COMMOWICK a écrit :
Il y a quand même un truc que je ne comprend pas dans ton questionnement, quel est l'intéret pour toi de faire du DSR si tu as très peu de traffic ?
La latence par exemple. C'est pour une page de paiement, chaque ms compte.
ca va juste rendre "compliqué" ton infra pour rien.
Toute mon infra est en DSR pour le reste, je trouve pas très compliqué d'ajouté une vip sur lo et 3 lignes dans sysctl.conf ...
+1 Je trouve même le DR plus simple que le NAT. Exemple: sur des LB mutualisés suffit juste de propager la seule VLAN (publique) du client sur les LB.
Le NAT peut apporter d'autres problèmes, et je veux que ce soit le plus simple possible au niveau du réseau (pas forcément de l'infra), parce que même s'il n'y a pas énormément de traffic, les tables de NAT peuvent être vite pleines par exemple...
Il y a du conntrack aussi sur LVS, propre à LVS certes mais c'est pareil que le fonctionnement du NAT, un peu de mémoire par "session". Et tu peux changer la taille de la table de conntrack NAT, avec la mémoire disponible sur les machines aujourd'hui ya de quoi faire :-)
La question que je me posais, c'est surtout "est-ce que ça marche le https en DSR ?" et si non, pourquoi ?
Oui, ça marche, et si tu veux assurer de rester sur la même machine (synchro sessions, etc...), tu peux configurer de la persistance sur LVS. Sylvain
On Tue, 28 Sep 2010 12:02:29 +0200, Greg <greg-frsag@duchatelet.net> wrote:
Bonjour,
Hi, Je reprends ce thread avec un peu de retard.
j'aurais aimé des retours éventuels sur de la répartition de charge en direct routing (DSR) sur le protocole HTTPS. J'imagine qu'il faut que les ports soient configurés en sticky pour éviter des switchs de sessions SSL ...
Tu peux le faire sans soucis ça fonctionne très bien.
A chaque fois les exemples utilisent un SSL Accelerator pour soulager les serveurs, mais dans mon cas je n'en ai pas besoin comme les serveurs ne font pas grand chose... je veux mettre en place du LB pour faire du failover uniquement (et heartbeat 2 me sort par les yeux)...
Et pourquoi ne pas faire un fail over entre les nodes directement, en évitant de passer par un LB? Il n'y a pas que Heartbeat pour cela :). Perso, selon les usages, j'apprécie énormément KeepAlived :). Bien sur, si tu a un LB à disposition, c'est juste un peu plus de traf pour lui, et une meilleure scalabilité :).
A ma connaissance, KeepAlived est un load-balancer...
Keepalived est un petit daemon/script qui se charge de gérer : - du vrrp sous linux , donc des @IP flottantes entre serveurs - lvs, avec différents check (un peu comme ldirector) Il est une bonne alternative a Heartbeart qui est a éviter (du moins en version 2). Sinon un truc simple et qui marche très bien pour juste une @IP flottante + script => ucarp. -- Raphael Mazelier
Hi,
Et pourquoi ne pas faire un fail over entre les nodes directement, en évitant de passer par un LB? Il n'y a pas que Heartbeat pour cela :). Perso, selon les usages, j'apprécie énormément KeepAlived :).
A ma connaissance, KeepAlived est un load-balancer...
Pas que :). Il y a la partie VRRP, qui est de la gestion d'IP flottante pure, et donc de la tolérance à la panne, et une surcouche à LVS, pour en faire en plus un load balanceur. Il est tout à fait possible de l'utiliser sans mettre en place de directive de load balancing, et nous aurons alors un "simple" outil de gestion du fail over. (au niveau serveur et non au niveau applicatif). Couplé à un mon, qui coupe keepalived quand le service est mort, on a donc un système de fail-over pur et dur. My 0.01€ :)
participants (8)
-
Florian Coulmier -
Greg -
Hervé COMMOWICK -
Raphael Mazelier -
Richard DEMONGEOT -
Steven Le Roux -
Sylvain Rochet -
Yann Verry