[Serveur dédié] Un gros serveur ou plusieurs 'petits' ?

[miss34]

Actuellement, mon site est hébergé sur un serveur dédié Pentium 4+ chez OVH ( P4 3GHz, 1 GO Ram, DD 40 Go IDE ), et montre actuellement très clairement ses limites.

Voici quelques éléments qui pourraient vous permettre de juger du traffic :
- Pointes de 1000 connectés simultanés chaque soir
- 700.000 pages par jour
- 10.000 visites uniques par jour
- 1100 GO de données par mois

Il s'agit d'un site utilisant PHP et MySQL. Les accès à la base sont fréquents (en lecture mais aussi écriture), et globalement les scripts sont relativement optimisés (c'est subjectif bien sûr)

Ces chiffres de traffic vous semblent-ils cohérents ? Ou je devrais pouvoir en tirer plus d'un serveur comme celui-ci ?

Afin d'adapter le matériel, j'hésite entre les possibilités suivantes :
- Conserver ce serveur, et en prendre un autre identique (dans ce cas, la base de données SQL serait transférée sur le 2e)
- Passer à un serveur plus gros, comme par exemple l'offre P4 SSCI (P4 3GHz, 2 GO Ram, DD 36 Go SCSI)

Je pense qu'il la première solution est préférable. J'ai aussi pensé à une architecture 3 serveurs ( l'un pour les images (apache), l'autre pour la génération des pages PHP (apache+php), et le 3e pour la base de données ).

Le fait d'installer la base de données et le traitement des pages php sur deux serveurs différents (mais chez le même hébergeur) ne risquent-ils pas de rallonger les connexions à la base (vu qu'on ajoute du 'ping') ?

Pour ceux qui auraient des conseils et quelques jugements, merci de bien vouloir m'aider.

[Nitou]

2 serveurs valent mieux qu'un, avec répartition des services.

Si jamais vous mettiez SQL sur une machine différente de PHP, il suffit de raccorder les deux machines en réseau via les ports eth1 de chaque machine (si biensûr les deux cartes mères en possèdent, ce qui ne devrait pas poser problème sur des cartes mères pour serveur).

[fredsoft]

Salut

effectivement plusieurs machines c'est mieux...séparer la base du ou des frontaux web aussi
un lien ethernet dédié pour la base ne sert a rien meme avec des grosse base..il faut se lever tot pour saturer un 10 mb..
le pb que tu vas avoir c'est mysql..car tu auras beau mettre 2 serveurs apache..avec 1 seul msql ça risque de couincer..
du mysql en load balancing est une solution, de l'éclatement de base avec plusieurs instances bases de données aussi...le passage a un autre sgbd aussi.
dans tous les cas change d'hébergeur, ovh n'est pas fait pour les archis complexes, notamment si tu as besion load balancing ils sauront pas faire tu te retrouveras avec du round rubing dns (une ip sur 2 sur un serveur meme si il est down)

[miss34]

Merci pour vos conseils (ça reflète ce que je pensais).

Pour le moment, j'envisage un serveur pour l'apache+php, et un autre pour la base de données (en effet elle consomme pas mal de ressources, car le type de site que j'ai m'empêche de faire beaucoup de cache statique, de plus les insert & update sont fréquents).

J'ai vu que mysql est en train de faire pas mal d'efforts sur la réplication des bases de données d'un serveur maître à un autre, ce qui pourra être sympa pour l'avenir si tout cela venait à grossir encore.

Mais si vous avez qques expériences de répartition des services et de charge (load balancing), je suis preneur d'infos

[xx]

Il y a une technique que j'utilise et qui marche bien, mais assez complexe à mettre en place, c'est la génération du site en html...

En effet, il s'avère qu'un site est à 95% statiques : peu de pages bougent en permanence (je ne parle pas de forum). Tu modifies ton site en DB, une fois les modifs validées, tu généres les pages équivalentes en html. Cette technique est utilisée par tous les très gros sites, ce qui leur permet d'éviter d'installer des serveurs onéreux pour tenir le coup avec un site dynamique.

Sinon, les techniques de clustering, ou de load balancing sont très bien, mais complexes à mettre en œuvre. Ca ne se fait pas sur un coup de tête et ça doit être bien réfléchi. Cependant, avant tout, ne pas oublier de faire de la réplication et de prévoir des techniques (style heart beat) afin de pallier à un pétage du serveur, et de prévoir une bascule en temps réél. loi des 99,999 de dispo.

[rebirth]

Il vaut mieux avoir deux serveurs....avec chacun possedant une copie des donnees de l'autre.
Ainsi tout est gere plus simplement en cas de panne...

C'est pas forcement une mauvaise idee de separer frontal de BDD....
Le serveur qui a le plus de CPU / RAM devra servir la BDD.

Oui tu perdras en perf entre les deux serveurs, une socket locale UNIX c'est toujours plus rapide qu'une socket en reseau...
C'est de l'ordre de 10-15% de perte.
Le debit entre les deux importe peu (c'est sur que tu as 56k et 100000km entre les deux on oublie...mais si c'est dans le meme datacenter / meme hebergeur...grande chance que tu t'en rendes pas compte)

Sinon l'ideal est d'avoir 2/3 serveurs et de faire du reel load-balancing / HA.

Tu peux egalement essayer de limiter les access a ta base en utilisant memcached, c'est assez radical.
Si tu fais beaucoup de SELECT et autres, tu peux quasiment ne plus jamais devoir taper dans la base.

Seul de la RAM est necessaire, plus besoin de CPU ou d'acces au disque (et donc moins de casse)

Bien sur, rien de magique contre les INSERT

[rituel]

1 serveur pour Apache, et deux en cluster pour la BDD me paraît une bonne alternative.

[rebirth]

1 serveur pour Apache, et deux en cluster pour la BDD me paraît une bonne alternative.

Quitte a en avoir 3, autant tout mettre en cluster
Non seulement on repartit la charge, mais en plus on commence a obtenir de la Haute-Dispo

[fredsoft]

Merci pour vos conseils (ça reflète ce que je pensais).

Pour le moment, j'envisage un serveur pour l'apache+php, et un autre pour la base de données (en effet elle consomme pas mal de ressources, car le type de site que j'ai m'empêche de faire beaucoup de cache statique, de plus les insert & update sont fréquents).

J'ai vu que mysql est en train de faire pas mal d'efforts sur la réplication des bases de données d'un serveur maître à un autre, ce qui pourra être sympa pour l'avenir si tout cela venait à grossir encore.

Mais si vous avez qques expériences de répartition des services et de charge (load balancing), je suis preneur d'infos

tu peux me contacter en privé...j'ai travaillé dans le hosting pro avec des archis distribuées et load balancées....
si tu migres vers quelque chose comme cela...imagine toi que le prix que tu pays chez ovh ça correspond meme pas au prix du service de load balancing (mutualisé)...un SLB mutualisé ça tourne dans les 300E par mois...en dédié 10KE a amortir..donc.
les réplications mysql bof bod..tu vas charger a mort pendant ce temps
je suis partisant de l'explosion sur plusieurs instances.
pour finir est tu sure de tes devs ? optimisations ? mode persistance mysql avec un tunign mysql qui va bien..? tu peux aussi convertir certaines requette en générant des fichiers txt toutes les X heures...un genre de cache pour éviter les requettes et passer en statique..bref tout cela s'étudie..

[krikrizzz]

Bonjour à tous !!!

Désolé de remonter ce sujet mais je recherche des documents sur du load balancing avec mysql.
Voila si vous pouviez m'aiguiller cela m'aiderait beaucoup merci parvance.

[sietjp]

Au ca où miss34 repasse dans le coin, je serais bien curieux de savoir ce qu'il a mis en place finalement.

C'est vrai que le load balancing pour apache je comrpends à peu près comment ça pourrait marcher, il suffit de mettre les même fichiers php et images sur chaque serveur. Mais le load balancing pour une base de donnée... Je veux bien qu'on réplique la base mais quand tu fais un insert dans un des 2 bases, il faut bien le faire dans la base répliquée aussi, ça parait trés complexe...

[Robinson]

Moi aussi, je up de nouveau ce sujet qui m'intéresse.

J'ai à près le même traffic (un peu plus de visiteurs).

Pas grand chose à mettre en static... beaucoup d'update et d'insert...