load balancing

[pouf1809]

Bonjour,
Je suis en train de creer un site d'annonces. Pour l'instant j'ai un serveur dedie mais lorsque le trafic va augmenter je vais rajouter 1 ou 2 serveurs supplementaires pour amortir la charge.
Comment faire pour gerer le load balancing ? Est ce que mon site doit gerer des synchro entre les differentes databases pour les mettre a jour ?
Merci pour votre aide mais je suis un peu perdu !

 

[polweb]

Salut,

il y a différentes solutions à ton problême. Je crois bien qu'il a pound qui fait cela. Chez ovh ipfaillover permet de faire du load balancing, tu peux aussi faire cela par les DNS, tu attribue aléatoirment deux ip différentes pour la même résolution.

http://www.ovh.com/fr/items/ip_load_balancing.xml



A plus.

 

[pouf1809]

dois je avoir une synchronisation entre mes databases ? Ou peut on eviter cette synchro ?

 

[Julia41]

Tout dépends ce que tu veux comme load balancing et ce qui risque de "craindre".
Si c'est le HTTP qui risque de craindre, je te conseil un truc style HAProxy pour faire du load balancing "soft". Mais tu dois quand même synchroniser tes fichiers.
Généralement on utilise ce système là pour distribuer la charge entre 2 serveurs mais ça n'a pas de tolérance de panne.

Pour le MySQL, si tu veux faire du "load balancing" (Balance de charge, ne pas confondre avec High Avability => haute dispo) il te faudra passer sous un système master/slave : tu fais tes SELECT sur les esclaves, tes UPDATE/INSERT/DELETE sur le master.

Généralement, pour des systèmes qui prennent juste des fortes charges (beaucoup de visites) mais qui n'ont que peu de risques de plantage, je mets un gros serveur SQL et une dizaine de kimsufi avec un Mix de round robin DNS + Haproxy.
Si le codeur a bien fait son boulot, je rajoute généralement 2 Slaves derrière.
Tu peux aussi regarder du côté du cache distribué qui pourrait remplacer les bases de données SQL très rapidement (c'est ce que fait twitter) les bases de données ne sont utilisés que pour les "vieux" trucs.

-http://highscalability.com/scaling-twitter-making-twitter-10000-percent-faster ce site donne énormément d'informations sur le load balancing et la haute disponibilité.

Généralement le load balancing/haute disponibilité s'apprends "sur le tas" car tant qu'on a pas les mains dans le panier on ne sait jamais trop comment aborder le problème. Il m'a fallu avoir un site avec 8 millions de hit/jours pour commencer à bien voir comment aborder le truc.

Bon, voilà pour un retour en vrac, le plus dur/chiant reste la synchro des fichiers en général, si tu utilises une infra Master/Slave au niveau de MySQL, tu pourras voir pour stocker tes fichiers dans MySQL en FILE.

 

[Mountain Magazin]

Salut,

Est ce qu'il peut être intéressant d'avoir un gros serveur pour les bases MySQL avec juste les bases dessus, et les fichiers php sur un autre ?

Je parle pour un site avec une forte audience en SELECT, mais pas de gros volumes d'insert/update/delete ?

Avec bien sur l'utilisation de Memcache et d'un cache d'opcode APC (stockage du framework dans un filesystem séparé avec l'option noatime).

A savoir qu'avec cette configuration si elle est viable, l'objectif serait de s'épargner la synchronisation des données, au moins jusqu'à ce qu'un tel processus ne soit plus suffisant.

Merci

 

[Julia41]

Toujours intéressant de séparer les deux MySQL fait des grosses lectures disques pour les SELECT, donc si pendant ce temps PHP à "toute la machine" pour s'amuser, il ira forcément plus vite. Généralement ça tourne quand même très bien sans cette méthode, en revanche si tu as un site PHP qui fait des SELECT/UPDATE/INSERT SQL en même temps que PHP écrit sur des fichiers, par exemple un site d'upload d'image, là tu peux gagner énormément.
Enfin bon, si ton load ne dépasse pas les 0.6 ça ne vaut peut-être pas la peine de prendre une nouvelle machine.

Avant de prendre un nouveau dédié il faut voir ce qui bloque beaucoup/peu.
C'est des conseils en vrac, rien ne se ressemble forcément

 

[Mountain Magazin]

Ok,

Merci de ta réponse. Pour l'instant j'ai pas de souci sur mes sites existants, avec l'utilisation du cache, ça roule sans problème.

Par contre, je bosse sur un projet de CMS hébergé qui va tirer pas mal de ressources, avec des montées en charge assez importantes et très ponctuelles. Je réfléchis donc au meilleur choix pour l'héberger et le concevoir, à savoir que pendant plusieurs mois, mon dédié actuel suffira amplement. Par contre ensuite... si ça se passe comme prévu, il faudra accompagner la montée en charge progressivement, et je profite de la discussion pour proposer ce que j'avais imaginé.

Je souhaite rester simple les premiers mois, et si les résultats sont au rendez vous, alors investir dans une structure plus conséquente.

Merci

 

[Julia41]

Généralement pour les sites qui "grossissent" la stratégie est "souvent" la même.
PHP + SQL sur le même serveur
PHP et SQL sur 2 serveurs
PHP et SQL et contenu statique sur un autre serveur
Si le SQL tient parfaitement et que c'est PHP qui ramme (rarement le statique) on rajoute des serveurs PHP et on load balance le tout.

Si ça bloque au niveau du SQL j'ai tendance à dire que le site est mal codé (après ça dépends de "ce à quoi il sert").
On peut aussi gagner énormément en faisant travailler les "clients" (ceux qui surfent sur le site) en effectuant eux même des calculs lourds grâce au javascript/ajax Facebook en abuse un peu mais résultat ça tourne.

 

[Mountain Magazin]

C'est un peu l'idée que je m'en fait, reste à trouver les bonnes limites et à anticiper correctement.
Merci