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/