Hébergement

atmaniak wrote:

Bonjour,
je m'appelle Frédéric, et je me suis dit que j'allais exposer, comme
d'habitude, l'etendu de mon savoir sur f.r.i.h.

J'ai donné deux solutions, une simple qui permet de décharger le MySQL
sur une machine plus adaptée. Ce qui prend le plus de resources
c'est toujours MySQL, les disques doivent être rapides (36Go WD raptor)
et il faut beaucoup de mémoire.

Pour cela je donne donc des conseils sur les serveurs MySQL a utiliser
alors que je ne connais pas le type de requetes qui seront faites sur ce
serveur. C'est à dire que je conseille de prendre des disques 10krpm
mini, mais je ne précise pas qu'il pourrait etre interessant de faire du
RAID.

Le RAID c'est trivial et ça coûte que dalle, il faut être cinglé
aujourd'hui pour ne en mettre. Les besoins sont ceux d'un gros site qui
rapporte de l'argent et qui va se développer et avoir toujours plus
de visiteurs.

Quand au serveur Web, apres tout il ne sert a rien, alors je ne précise
pas quelle sera sa configuration.

Un bon P4 ou AMD64 avec 1 ou 2 Go de RAM fera l'affaire, pour augmenter
la capacité on peut en ajouter un second facilement sans aucune
coupure. Parfois il est même plus intéressant de mettre 2/3 petites
machines plutôt qu'une grosse.

Une solution puissante et pas trop coûteuse :
- un serveur MySQL qui fera aussi NFS et DNS local
- 2-3 serveurs frontaux, synchronisés avec du subversion,
les sessions en NFS
- 1 load balancer (LVS), une petite machine convient parfaitement

*Cette solution n'est pas a mettre dans les mains d'un débutant*

Ca dépend si l'hébergeur aide le débutant ou pas. Une personne
expérimentée peut configurer tout le système en quelques heures et une
fois que ça tourne on n'a plus besoin d'y toucher.

Et ensuite, je me suis dit que j'allais proposer une solution tout a
fait intelligente techniquement, ou je multiplie les possibilités de
pannes sans prendre de mesures afin de les eviter.
Mais bon, cette solution est tout sauf simple a mettre en
place/maintenir, notamment pour les problèmes de logs, d'heures (et oui,
un ntp local ne fait pas de mal), de monitoring, ...
(et le atmaniak qui sommeille en moi a la fleme de faire la liste
totales des problèmes a gérer sur ce type de solutions)

Ca diminue les pannes, un load balancer est une machine de qualité
peu puissante qui a peu de chances de griller (pour les DD on met
du RAID et on choisi une bonne alime type supermicro).

La plupart des pannes que je rencontre sont des pannes logicielles,
c'est surtout surtout Apache qui a tendance à planter pour rien.

Le tout relié en gigabit.

Ou juste a bien découper le traffic entre plusieurs cartes réseaux sur
du 100 Mb/s. Mais bon, je m'appelle Frédéric, et je fais toujours tout
mieux que les autres, alors il faut du Giga (c'est moi qu'ai la plus
grosseuh !)

Comme le RAID, ça coûte que dalle, toutes les cartes mères pro ont 2
ports GbE ou alors on peut rajouter une 3Com. Un switch 3com de 5 ports
en GbE ne coûte rien.

Pour avoir une meilleur dispo on peut ajouter un second serveur MySQL
et utiliser la réplication et aussi un second load balancer.

Enfin un peu de raison. Surtout penser au deuxième LoadBalancer, on a
deja vu trop de personnes (y compris des grands groupes) avoir des
problèmes simplement parce qu'ils n'avaient pas de second LB.

Les load balancers des grands groupes ne sont pas des serveurs
supermicro. Comme je l'ai dit avec du LVS le risque de panne est
très faible mais un second LB ajouté par la suite c'est mieux.

Comme je n'ai pas assez de clients, j'en profite discretement pour
glisser mes tarifs sur la coloc et le transit IP. Apres tout, j'ai
déballé ma culture, le client potentiel me recontactera peut etre pour
obtenir un devis plus précis :)

J'ai assez de clients et ce ne sont pas nos tarifs mais les tarifs
constatés chez autre chose que des discounters.

PS par atmaniak :
Bon, alors on va tout reprendre depuis le début :
Non, ce n'est pas la peine de passer tout de suite d'une solution a 200
euros / mois a une solution a plusieurs milliers d'euros d'investissements.
Comme dit par d'autres personnes, il est d'abord essentiel sur ce genre
de sites a forte croissance de bien auditer/vérifier le code, ainsi que
la configuration des machines (oui, un serveur ca s'optimise).
Ensuite, et cela pour etre a l'aise, une premiere étape dans la
repartition des services (et par conséquent de la charge) peut etre
envisagée. De nombreux hébergeurs proposent des serveurs dédiés en
location tout a fait adaptés/adaptables pour ce genre de problematiques.

On peut aussi prendre plusieurs dedibox :)


Il existe des solutions pour tous les budgets, reste à déterminer
combien on peut investir par rapport aux revenus générés par le
site et au coût d'une panne.


--
Frédéric VANNIÈRE 231 rue Saint-Honoré
Directeur Technique 75001 PARIS - FRANCE
PLANET-WORK Tél : 0891 024 424
http://www.planet-work.fr/ Fax : 0143 461 199

Frédéric VANNIÈRE wrote:

La plupart des pannes que je rencontre sont des pannes logicielles,
c'est surtout surtout Apache qui a tendance à planter pour rien.

Et donc on peut souvent les résoudre de manière logicielle sans passer par
un cluster...

Là encore ca dépend de ce que tu va mettre en cache, et de la
qualité de tes disques. Il vaut mieux parfois mettre ca en base de
données (bien configurée, donc tchao le MyISAM) que sur un disque qui
gratte peut-être déjà trop avec le reste du site.
Repenser le site me semble être la bonne solution, en générant un
maximum de fichiers statiques (et avant de saturer une machine avec du
fichier statique - fichier HTML ou image- tu as une très très grande
marge de maneuvre ;)
Enfin, vu la fréquentation en terme de visiteurs, je pense que tu es +
que large en bande passante, donc le problème vient assurément de la
machine. Sans doute aussi une configuration imparfaite (on peut
quadrupler des perfs de Apache+PHP avec le bon réglage, etc. mais à
chaque situation sa solution propre).

atmaniak wrote:

Frédéric VANNIÈRE wrote:

Une première évolution simple :
- un serveur pour MySQL (AMD64X2 2 à 4 Go RAM, disques 10krpm mini)
- un serveur pour le web

Bonjour,
je m'appelle Frédéric, et je me suis dit que j'allais exposer, comme
d'habitude, l'etendu de mon savoir sur f.r.i.h.

Toi t'es vraiment le roi des cons. Le genre de trucs qu'a expliqué
Frédéric, c'est justement vachement classique, j'ai un pote qui
développe "commeaucinema.com" (hop, un peu de pub :) par exemple, et
c'est exactement le type d'architecture qu'il a développé. Note que
cette personne n'est qu'un "simple" developpeur web, assez fort il est
vrai, mais en tout cas pas un professionnel de l'hébergement.

C'est à dire que je conseille de prendre des disques 10krpm
mini, mais je ne précise pas qu'il pourrait etre interessant de faire du
RAID.

PAN ! Perdu, il a parlé du RAID dans son poste. Il t'as fait quoi pour
que tu lui en veuille autant ?

*Cette solution n'est pas a mettre dans les mains d'un débutant*

Qui a dit que juju2mars allait tout faire tout seul ? Qui te dis qu'il
est un débutant ?

Et ensuite, je me suis dit que j'allais proposer une solution tout a
fait intelligente techniquement, ou je multiplie les possibilités de
pannes sans prendre de mesures afin de les eviter.

Ha, parce que pour toi, la redondance augmente le risque de panne...

Le tout relié en gigabit.

Ou juste a bien découper le traffic entre plusieurs cartes réseaux sur
du 100 Mb/s. Mais bon, je m'appelle Frédéric, et je fais toujours tout
mieux que les autres, alors il faut du Giga (c'est moi qu'ai la plus
grosseuh !)

Excuse moi, mais si tu relis 2 serveurs MySQL en slave-master sans
mettre du giga-bit, t'es vraiment a l'ouest... Avec tes économies a 2
balles, le site rame toujours autant qu'avant, bravo ! :)

PS par atmaniak :
Bon, alors on va tout reprendre depuis le début :
Non, ce n'est pas la peine de passer tout de suite d'une solution a 200
euros / mois a une solution a plusieurs milliers d'euros d'investissements.
Comme dit par d'autres personnes, il est d'abord essentiel sur ce genre
de sites a forte croissance de bien auditer/vérifier le code, ainsi que
la configuration des machines (oui, un serveur ca s'optimise).

Ha... D'après toi le code est pourri... Et une fois le code tout clean
et que ça suffit pas, tu fais quoi ?

Ensuite, et cela pour etre a l'aise, une premiere étape dans la
repartition des services (et par conséquent de la charge) peut etre
envisagée.

Oui, c'est ce que Frédérique à tenter d'expliquer, mais visiblement tu
n'as pas lu.

De nombreux hébergeurs proposent des serveurs dédiés en
location tout a fait adaptés/adaptables pour ce genre de problematiques.

Tu apporte une bonne solution au problème, merci...

Moi je trouve perso que Frédérique a 100% bon dans son post, on il
explique toutes les solutions possible, c'est exhaustif, mais peut-etre
un peu trop compliquer a comprendre pour un débutant.

Thomas

raphael mazelier wrote:

GPLHost (thomas) wrote:

Plusieurs solutions:
1- Prendre un serveur encore plus puissant (si c'est possible dans
une limite de prix raisonable)
2- Prendre plusieurs serveur, avec par exemple un des serveurs qui ne
fera que la base de donnée (et si ça suffit pas, prendre encore plus
de serveurs)

3- Vérifier le code pour voir si y a pas des requêtes SQL moisies ou
des indexes qui manquent dans la base.

+1

Ouai. Et aussi ajouter "jp-cache" si le site est en php et que ça fait
des requettes en bases qui n'ont pas besoin d'une trop grande réactivité
(moins de 5 minutes par exp). Je sais pas si vous connaissez, mais moi
je trouve que c'est TRES efficace ! :)

Thomas

Toi t'es vraiment le roi des cons. Le genre de trucs qu'a expliqué
Frédéric, c'est justement vachement classique, j'ai un pote qui développe
"commeaucinema.com" (hop, un peu de pub :) par exemple, et c'est
exactement le type d'architecture qu'il a développé. Note que cette
personne n'est qu'un "simple" developpeur web, assez fort il est vrai,
mais en tout cas pas un professionnel de l'hébergement.

l'ambiance est a la courtoisie.

PAN ! Perdu, il a parlé du RAID dans son poste. Il t'as fait quoi pour que
tu lui en veuille autant ?


Qui a dit que juju2mars allait tout faire tout seul ? Qui te dis qu'il est
un débutant ?

Peut etre parce qu'il poste ça sur FRIH, donc il est soit debutant soit naif
sur l'eventualité d'une reponse vu le peu d'element qu'il fournit et
ceux qui se baladent par ici.

Ha, parce que pour toi, la redondance augmente le risque de panne...

ça depend c'est la meme qu'a RedBus ? (j'ai pas pu me retenir).

Excuse moi, mais si tu relis 2 serveurs MySQL en slave-master sans mettre
du giga-bit, t'es vraiment a l'ouest... Avec tes économies a 2 balles, le
site rame toujours autant qu'avant, bravo ! :)

On ne connait strictement rien sur le site en question, donc sa solution
vaut largment la votre au vu des elements qu'on a
pour le moment.

Ha... D'après toi le code est pourri... Et une fois le code tout clean et
que ça suffit pas, tu fais quoi ?

Re , On ne connait strictement rien sur le site en question,
C'est donc une possibilité a envisager, cela dit pour un eventuel
fournisseur c'est mieux que cela ne vienne pas de la
si il veut lui louer des serveurs.

Moi je trouve perso que Frédérique a 100% bon dans son post, on il
explique toutes les solutions possible, c'est exhaustif, mais peut-etre un
peu trop compliquer a comprendre pour un débutant.

on se croirait dans une cour d'ecole....
La question est plutot : un hebergeur n'a t'il pas une infrastructure de ce
type deja en production pour ses formules en mutualisé ? Et cela ne me
suffira t'il pas ?
Cela evite de penser a l'architecture, de la faire evoluer, de remplacer le
materiel, etc... et d'avoir des competances dans plusieurs domaines.

Thomas

Bonsoir à tous !

Je vous remercie pour vos réactions !

Je réfléchis à toutes les propositions possibles, c'est un peu
compliqué malgré tout...

Quand je parle de membres, je parle bien de membres et non pas de
visiteurs ! Les membres sont les abonnés au site. Pour 10 membres qui
se connectent, c'est 1 visiteur qui vient jetter un oeil...

Frédéric VANNIÈRE wrote:

Une solution puissante et pas trop coûteuse :
- un serveur MySQL qui fera aussi NFS et DNS local
- 2-3 serveurs frontaux, synchronisés avec du subversion,
les sessions en NFS

Tant qu'à faire, autant mettre les sessions en mcache/msession.

--
@+
Calimero

Frédéric VANNIÈRE wrote:

Une solution puissante et pas trop coûteuse :
- un serveur MySQL qui fera aussi NFS et DNS local
- 2-3 serveurs frontaux, synchronisés avec du subversion,
les sessions en NFS

Tant qu'à faire, autant mettre les sessions en mcache/msession.

J'ai déjà utilisé et ça a merdé à fond. En théorie c'est u ne bonne
solution mais il faut faire un essai.


--
Frédéric VANNIERE 231 rue Saint-Honoré
Directeur Technique 75001 PARIS - FRANCE
PLANET-WORK Tél : 0891 024 424
http://www.planet-work.fr/ Fax : 0143 461 199

GPLHost (thomas) wrote:

Ouai. Et aussi ajouter "jp-cache" si le site est en php et que ça fait
des requettes en bases qui n'ont pas besoin d'une trop grande réactivité
(moins de 5 minutes par exp). Je sais pas si vous connaissez, mais moi
je trouve que c'est TRES efficace ! :)

Y Smarty qui a aussi un système de cache pas vilain (même si j'ai pas
expérimenté à grande échelle, les trucs auxquels j'ai participés étant
toujours très dynamique, donc incachable).

Sinon, il a aussi les compilateurs+caches PHP (genre eAccelerator) qui
peuvent aider si on a des sites lourds (genre CMS usine-à-gazesque) où
chaque requête implique le parsing de plusieurs dizaines de Ko de code
PHP.
J'ai souvenance d'un petit benchmark d'ADODB PHP (une implémentation
en PHP pur qui essaie d'imiter les objets ADODB de chez MS) où ils
comparaient les performances entre le code parsé en temps réel et le
code précompilé/caché. En terme de requêtes HTTP/seconde pour une page
moyenne, ca donnait un rapport de 1 à 3 je crois.

--
@+
Calimero