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 ;)