Load balancing et solutions à explorer...

[Julia41]

Voilà, ayant un gros site qui grossi et de moins en moins d'utilisateur français mais de plus en plus francophone, j'envisage une solution de load balancing pour papache en fonction des pays avec plusieurs serveurs de petites tailles, le but étant d'en rajouter très simplement et de manière transparente...
J'ai déjà testé le load balancing par champs A (à la Google) mais j'ai eu un problème de session PHP...

Avez vous des retours d'expériences, pour l'instant, l'une des meilleurs solutions que j'ai trouvé est décrit ici : -http://howtoforge.com/load_balancing_apache_mod_proxy_balancer
D'après ce que j'ai compris, apache donne une session à chaque user pour qu'il tombe sur tel ou tel serveur en permanence jusqu'à la fin de la session...
Cette solution demande donc 3 serveurs (1 load balanceur + 2 papaches) pour les tests, le top étant 2 load balanceur...

Voilà, et si quelques-uns d'entre vous on un serveur qui ne sert à rien et qui ont envi de faire mumuse ce weekend, n'hésitez pas à me contacter sur l'IRC de WRI, on pourrait essayer voir ce que ça donne, je compte louer 3 RPS pour faire les tests, mais bon...

Aussi, je n'ai aucune idée de ce que prends (en terme de charge) le load balanceur, donc là dessus, j'aimerais bien avoir votre avis, car à part attribuer des sessions, il n'a pas l'air de beaucoup travailler (bien qu'il se prenne toutes les requetes directes)...

 

[Bool]

Hello,

avec ce système de "reverse proxy", le load balancer bouffe quand même tout le trafic réseau, et ce dans les deux sens ; ça peut être problématique selon ton trafic.

Si tu en es à vouloir "localiser" les serveurs, je suppose que tu n'es pas à une ou deux machines près. Dans ce cas j'aurais tendance à faire le premier aiguillage au niveau DNS (surtout pas en round robin donc), puis sur chaque site à mettre en place un petit cluster (au niveau TCP/IP, pas HTTP) avec stockage des sessions centralisé (via memcache par exemple).
Mais je ne suis pas certain que ce soit vraiment ce que tu cherches...

 

[Julia41]

Le but principale est avant tout de "geekser" car un gros serveur et séparation des images sur un lighty, de la bdd sur un serveur et de papache sur un autre serait une solution largement satisfesante...
En ce moment, le nombre de visiteur sur le site en question double tous les mois, 500 en janvier, 1000 en février, 2000 début mars, 2500 ce matin même...

En tout cas, ta remarque sur le "reverse proxy" m'intéresse, c'était vraiment mon gros point d'intérogation sur le sujet et je trouve ça presque bizarre, car je pensais que ce système mettait lui-même en cache et qu'il indiquait un serveur à utiliser au client et que ce client récupérait un "cookie" ou une session qui lui disait d'utiliser tel ou tel serveur...

Sinon, en ce qui concerne au load balancing, j'ai pensé à quelquechose de "simple" mais brutal... Suffirait d'iptable orange, free, neuf (les plages IP des FAI français) du serveur Canadien, de faire l'inverse pour le serveur Français, ensuite deux champs A sur bind, les FAI résolveraient ainsi la même IP (enfin bon, c'est pas assez pro), le but est surtout de faire le geeks et de prévoir l'avenir...

 

[Bool]

Pour le reverse proxy, s'il gère une session elle est probablement par cookie oui, ou au pire par IP.
Mais ça ne change rien au fait que ce sera le proxy qui recevra toutes les requêtes HTTP, et ce sera également lui qui enverra le contenu aux clients. Donc au moins deux conséquences : il peut être un facteur de ralentissement s'il n'a pas suffisamment de bande passante, et deuxième si l'idée est d'avoir des serveurs "proches" des clients alors le schémas sera inverse : c'est le reverse proxy qu'il faut rapprocher, et il ira probablement chercher ses infos vers un seul serveur/cluster.

Enfin je ne suis pas certain d'être très clair : mais pour le rapprochement "physique" le load balancer ne me semble pas l'idéal. Même basé sur LVS via Tunneling, tu auras toujours le trafic entrant qui parcourra la moitié du globe.

Je n'ai pas encore mis ce genre de solutions en place, mais à mon avis c'est au niveau DNS qu'il faut faire la répartition "géographique" (via LVS aussi par exemple) ; ensuite sur chaque site "physique" tu mets juste un petit reverse proxy (on m'a récemment parlé de lighttpd + mod_cache pour cela).
Le site en lui même peut conserver son hébergement actuel, quitte à migrer sur un cluster plus tard...

Bon courage en tous cas

 

[tofm2]

.
En ce moment, le nombre de visiteur sur le site en question double tous les mois, 500 en janvier, 1000 en février, 2000 début mars, 2500 ce matin même...

tu parles de connexions simultanées ?

 

[Julia41]

Non, je parle de "visiteur unique" (je crois que vous appellez ça comme ça) par jour tracké par Analytics... Mais le traffic de mon site n'est pas dû tout proportionnel... Enfin en clair je ne suis pas là pour discuter de ça...

Bon, pour infos, pour l'instant, j'en serais avec 2 "gros" load balanceur (deux superplans chez OVH en terme de puissance), pas forcément très gros, car leur "mirroring" est sensé permettre de changer un serveur complet avec l'autre prenant le relai... Donc cela permet : arf 2 SP ne suffisent pas, on va remplacer un SP par un HG, dès que c'est fini, on change le deuxième SP, aucune intéruption de traffic...
Les load balanceur seraient gérés avec heartbeat... Ptit tuto sympa pour voir ce que ça fait : -http://doc.ubuntu-fr.org/heartbeat
Et le top pour les tests :

Maintenant, retirez fermement le cordon d'alimentation de Twin 1.

Donc je pense tester au moins la solution pour le serveur SSHd sur des machines virtuelles @home...

Pour le clustering papache, je pense prendre le premier lien que j'ai fourni dans ce tuto.
Si cela intéresse certains, n'hésites pas à me le dire, je vous tiendrais au courant...

Edit : Si vous connaissez un hébergeur de dédié, bon marché au Canada et/ou en Hollande que je commence mes recherches...

 

[pedrolopez]

Hello,
je rebondis sur la remarque de bool sur le fait que le reverse proxy est le point central par lequel tout le trafic passe en retour vers le client.
J'ai un serveur qui fait du contenu statique, disons static.acme.com qui sature (bande passante à 100 Mb/s) et j'aimerais balancer les requêtes qui arrivent sur cette adresse sur plusieurs serveurs physiques pour désengorger ce serveur unique, mais que chaque serveur balancé réponde directement au client pour pouvoir utiliser la bande passante de chaque dédié ( et ne pas repasser par le reverse proxy qui est engorgé)

Je cherche une solution soft et si possible pas basée sur du DNS round robin.
J'utilise Lighttpd comme reverse proxy, et j'ai été surpris de ne pas trouver de méthode pour faire ce que je veux avec Lighttpd 8O. Qqu'un a-t-il mis en place une telle solution ?
merci !

 

[fandecine]

J'ai lu un excellent article à ce sujet sur un LINUX MAGAZINE, le n°92 (il date un peu, mais doit pouvoir être commandé quand même)

Le titre de l'article "Cluster haute-disponibilité avec equilibrage de charge".

 

[Bool]

pedrolopez : il y a de nombreuses combinaisons possibles.

Pour répartir le trafic sur plusieurs machines, le round robin DNS est quand même le plus simple. Et pour éviter les problèmes de faible tolérance aux pannes, tu peux faire du round robin sur des IP "flottantes" (voir te rabattre sur la solution "ip failover" d'OVH).

Dans le cas où c'est le flux sortant qui sature (c'est le cas de la plupart des sites web), une autre solution est d'utiliser LVS-TUN : le trafic entrant est concentré sur le load balancer, qui ré-aiguille les paquets vers d'autres machines qui se chargent de répondre directement au client (sans repasser par le load balancer quoi) (cf : joulie dessin).

Il y en a probablement d'autres, mais ce n'est à ma connaissance pas possible au niveau du reverse proxy.

 

[pedrolopez]

merci à tous les 2, je crois qu'on va investiguer cette technique d'IPVS avec tunneling.
Ca peut-être valable pour des service un peu plus malins que du simple download de contenu statique (genre du streaming video) ?

 

[Bool]

IPVS intervient à une couche bien inférieure du HTTP, et est donc en théorie transparent (contrairement aux reverses proxy).