Quel CPU choisir pour un dédié ?
- Auteur de la discussion dorian53
- Date de début
C'est comme tout tout depand la necessité en ressource de ton ou tes site(s) web hebergé(s).
Si tu fais beaucoup de requette sur une base SQL un CPU puissant est conseiller, s'il s'ait que du transfert de donnée sans reels requettes SQl un CPU moins puissant fera l'affaire...
Après Duron, Athlon, Celeron ils se valent tous... Ce qui compte c'est la frequence et la ram derrière 8)
Si tu fais beaucoup de requette sur une base SQL un CPU puissant est conseiller, s'il s'ait que du transfert de donnée sans reels requettes SQl un CPU moins puissant fera l'affaire...
Après Duron, Athlon, Celeron ils se valent tous... Ce qui compte c'est la frequence et la ram derrière 8)
dorian53 a dit:
Qu'est cencé faire ton serveur dedié ?
Serveur web ou serveur de base de données ?
Pour des raisons de securité, et de performance, il convient de ne PAS mettre les deux serveurs sur la même machine.
Combein de sites "dynamiques" vas tu heberger dessus ?
Quel OS vas tu utiliser ?
Perso, j'attache beaucoup d'importance à la RAM, et je pense qu'un Celeron avec 2 Giga de ram sera plus polivalent qu'un Core2Duo avec 512 Mo...
Tout depend aussi de la techno que tu veux utiliser : Php demandera moins de ressource que .Net ou Java.
Le gros du boulot d'un serveur de page (donc, serveur web), se passe à la compilation/précompilation des script/executables. Je ne suis pas certain qu'une bete de course soit nécessaire, sauf si tu comptes heberger un/plusieurs très gros sites.
Si c'est le cas, ta problématique serait plutot de te dire "quel type de load balancing dois je utiliser, sur combien de machine" ^^.
Mon conseil : le meilleurs compromis Puissance CPU/Memoire pour debuter, et monitore bien ton serveur, pour voir s'il sature.
J'aimerais bien voir un Kimsufi (OVH) avec 2 Go de Ram, executant un Apache/PHP/Postgres (mais à eviter de melanger les torchont et les serviettes - Base + Web).
Sur ces trois processeurs, pour un PC de bureau, la meilleure à toujours été l'Athlon, donc j'pense que pour un serv ça doit être pareil, ça chauffe mais ça c'est pas ton problème...
Juste niveau compatibilité, si tu veux faire des choses ne rentrant pas dans les trucs de base, le Celeron aura peut-être plus de compatibilité (noyau et tout le tralala)...
Enfin sur ces trois, je prendrais l'Athlon.
Edit : Pour des raisons de securité, et de performance, il convient de ne PAS mettre les deux serveurs sur la même machine
A mon avis, il en est pas encore à prendre 2 serveurs...
Juste niveau compatibilité, si tu veux faire des choses ne rentrant pas dans les trucs de base, le Celeron aura peut-être plus de compatibilité (noyau et tout le tralala)...
Enfin sur ces trois, je prendrais l'Athlon.
Edit : Pour des raisons de securité, et de performance, il convient de ne PAS mettre les deux serveurs sur la même machine
A mon avis, il en est pas encore à prendre 2 serveurs...
Bien-sure ^^ C'est pour cela Qu'AMD et Intel ont decliné leurs offres processeur en desktop ET Serveur.Julia41 a dit:
Un serveur a des contraintes differentes d'une machine de bureau.
Et le critère de chaleur a aussi son influence (perte d'energie pas dissipation thermique, necessitant une alimentation plus grosse, donc plus chere, qui se repercutera sur la facture finale).
Je n'ai pas verifié cette affirmation, mais il semble que les incompatibilités sont plus souvent liées à la qualité du bios de la carte mère, qu'au proc lui même.Julia41 a dit:
Il est interressant de prendre en compte, par contre, le nombre de coeur en fonction de l'OS utilisé, et des applications qui vont tourner dessus.
Il n'est jamais trop tard pour prendre les bonnes habitudes ^^.Julia41 a dit:
Car qui dit "dedié", dit plus autonome. Il faut alors penser à certains domaines tels que la sécurité, les sauvegardes, etc ...
Avoir une application buziness implique quelques precautions à prendre en compte.
Et il y a des palliatifs très interressants, plutôt que de prendre deux serveurs dedié.
Dans le cas d'un site qui sollicite fortement une base de données, mais qui a des ressources limités (photos, videos ...), il peut etre interressant de prendre un serveur Web mutualisé (peu chere) + un serveur dedié pour la base de données. Ce qui fait que pour un surcout minim par mois, tu as une solution plus secure, mieux répartie, donc plus performante : Service rendu de meilleur qualité.
Mais bon, ce n'est que mon avis, je ne fais que répondre à la question.
Et mettre un moteur de 2 C dans une porshe, mais quel est l'interet ?rog a dit:
Ca se disctute :rog a dit:
J'ai un site avec bcp de page generées dynamiquement, qui necessite une grosse base de données.
Je prends un mutu chez OVH pour la partie serveur WEB, avec peu d'espace disque, mais avec une BP par mois honorable.
Par contre, je prend un Dedié pour la base de données, que je vais pouvoir tuner à mon envie.
C'est une solution propre, et moins honnereuse ...
Mais effectivement, on peut prendre deux dedié, si on a un budget no limit
(C'est presque jamais le cas)Je ne travaille pas avec l'architecture que propose nico92 mais je trouve l'idée interessante (pour la bp en particulier) le seul probleme de cette infra c'est que si tu partages ton mutu avec des boulets qui font des boucles infinies a tout va ca va pas etre bon non plus.
Donc 2 solutions :
Soit ton budget te le permet et tu prends 2 dédiés (1 de base pour le web) et l'Athlon avec au minimum 1Go pour la base (mais alors tu supprimes TOUT module inutile) ou 2Go. Soit pour un début (j'ai commencé comme ca) 1 seul bon dédié (dans ton cas Athlon + 2 voire 4 Go RAM) web+mysql ... ton chemin faisant et dès que tes revenus te le permettront tu prendras 1 dédié en sup pour mysql ...
Ah j'oublié ... tes scripts tu optimiseras ...
Donc 2 solutions :
Soit ton budget te le permet et tu prends 2 dédiés (1 de base pour le web) et l'Athlon avec au minimum 1Go pour la base (mais alors tu supprimes TOUT module inutile) ou 2Go. Soit pour un début (j'ai commencé comme ca) 1 seul bon dédié (dans ton cas Athlon + 2 voire 4 Go RAM) web+mysql ... ton chemin faisant et dès que tes revenus te le permettront tu prendras 1 dédié en sup pour mysql ...
Ah j'oublié ... tes scripts tu optimiseras ...
@Nico92
ça fait déjà un paquet d'années que je touche aux servers web, mon premier etait un pII400 et je voudrai te signaler que des pIII soutenaient déjà très correctement les vhosts
ta bp honorable sur un mutu est directement liée aux autres sites hébergés
et pour les noyaux, j'ai été très déçu par les kernel amd64
rog
ça fait déjà un paquet d'années que je touche aux servers web, mon premier etait un pII400 et je voudrai te signaler que des pIII soutenaient déjà très correctement les vhosts
ta bp honorable sur un mutu est directement liée aux autres sites hébergés
et pour les noyaux, j'ai été très déçu par les kernel amd64
rog
rog a dit:
Mais ca n'a rien à voir avec les virtuals Hosts !!
Tu dis qu'il ne sert à rien de prendre un mutualisé qd tu as un dedié.
Je te reponds que ca depend de ton besoin, et de ton budget.
Exemple : Tu geres un super gros forum. (Oui, je sais, c'est abusé comme exemple, mais un forum, ca comporte peu d'images, et peu de pages statiques, c'est que du dynamique, et ca bouffe pas mal de ressources en base (espace et CPU).
Fais un tour du coté de OVH, par exemple, et quelle solution prends tu ?
Tu as le choix, mais perso, je prends un mutu 90 plan, avec 600 Go par moi, espace disque de 900 Mo (suffisant). Par contre, je colle ma base de données sur un mutualisé. Quel est l'interet de prendre un dedié pour ton PHP ? A moins que ton application soit ultra complexe, full objet, avec des tas de worklow à gerer, du XSL à parser, etc ^^ ... Non, je ne vois pas l'interet. (le seul interet que je peux encore trouver, c'est la config exotique d'apache et de PHP, mais là, il faut vraiment chercher la petite bete).
Par contre, ta base de donnée, oui, elle va tourner, mais surtout, tu es maitre de la taille de tes bases, des ressources à lui allouer.
Car une base de 40 Mo, ca part très vite (taille recommandé pour un 90 plan). Sans oublier que si ton script PHP est rapide, mais que ca base rame ... c'est encore plus dommage.
Apres, decider de separer le Httpd de mysql, ou de postgres est une regle de base en sécurité informatique.
Si un prestataire pretend mon pondre un site web (sur lequel je vais baser mon business), et qu'il ne prend pas en compte les criteres de securité et de backup, moi, je pense que c'est un charlot (C'est mon avis, et du vecu aussi
)Peu importe de savoir si c'est du mutu ou du dedié, ce qui compte, c'est le rapport qualité/performance au meilleurs cout.
Comme le dit raljx, le mieux est de prendre une petit proc, mais avec pas mal de Ram. On augmente la Ram Avant le proc
Et oui, il serait interressant de savoir ce qu'il veut y mettre sur son serveur (j'ai posé la question au debut
PS : j'ai tjr pas capté le rapport avec le vhost ^^
ça veut dire que en l'an 2000 on hébergeait plusieurs centaines de sites avec un PIII
ta solution httpd sur un mutu et mysql sur un dédié ne peut pas convenir car tu depend de la frequentation de plusieurs de sites sur celui-ci pour trouver la ressource et bande passante pour faire interpréter tes pages php
et niveau secu je ne vois pas d'amelioration vu que tu vas devoir faire accepter les requêtes distantes au server mysql
et la backup n'a rien à voir dans l'histoire vu que tu as un acces root sur le dedié
rog
ta solution httpd sur un mutu et mysql sur un dédié ne peut pas convenir car tu depend de la frequentation de plusieurs de sites sur celui-ci pour trouver la ressource et bande passante pour faire interpréter tes pages php
et niveau secu je ne vois pas d'amelioration vu que tu vas devoir faire accepter les requêtes distantes au server mysql
et la backup n'a rien à voir dans l'histoire vu que tu as un acces root sur le dedié
rog
Oulala ...
Bon, ok, je n'insiste pas
PS : Pour Mysql, dans ce cas, tu ouvres un flux non pas vers l'exterieur, mais vers l'ip de la machine de ton serveur de page. Ce qui fait que tout ce qui vient de l'exterieur ne peux pas attaquer directement la base.
PS2 : tu as les mêmes contraintes de bande passante avec un dedié qu'avec un mutu
Pour le reste, je ne suis decidement pas convaincu. ^^
(c'est quoi le nom de ta boite ?)
Bon, ok, je n'insiste pas
PS : Pour Mysql, dans ce cas, tu ouvres un flux non pas vers l'exterieur, mais vers l'ip de la machine de ton serveur de page. Ce qui fait que tout ce qui vient de l'exterieur ne peux pas attaquer directement la base.
PS2 : tu as les mêmes contraintes de bande passante avec un dedié qu'avec un mutu
Pour le reste, je ne suis decidement pas convaincu. ^^
(c'est quoi le nom de ta boite ?)
Nico92 a dit:
C'est à dire ?
Car il y a le serveur apache, mysql, dns, webmin, etc...
Tout le monde ne peut pas se permettre de louer un serveur alors deux...
Par contre j'ai quelqu'un qui ne m'a pas dit du bien sur le principe de mettre apache sur un serveur et mysql sur un autre pour atteindre un niveau de performances supplémentaire sans passer à un bi-xeon par exemple...
Mais ce n'est pas toi qui parlait de plusieurs centaines de sites sur un serveur ?
Si c'est pas de la mutualisation ca ?
Ecoute, globalement, je suis assez d'accord avec toi lorsque tu parles de contrainte de bande passante.
Il faut juste voir si ton site est vraiment ralenti de manière frequente.
Car des goulots d'etranglement, tu peux en avoir un peu partout. Surtout si tu mutualises des centaines de sites sur ton serveur dédié.
Perso, je suis chez OVH, et j'ai rarement des problemes à ce niveau là (90 plan). Là ou j'ai un probleme, c'est avec la base, qui grandie à vue d'oeil.
J'ai pensé à prendre un dedié pour tout mettre dessus. Et là, il va fallori que je gere apache/mysql/php, plus autres services (backup, mail, etc ...).
Au lieu de tout mettre sur un dedié, j'envisage un dedié pour la base, et resté en mutu pour le serveur de page. Car quand mon site ralenti, il ralenti à cause des accès en base. Et je suis limité par le nombre de connections à cette meme base.
Bon, en plus, je voudrais mettre du postgres
La plupart du temps, il est plus facile de merdouiller avec la base qu'avec ton code PHP. Si ton code merdouille, tu arrives vite à un timeout, et dans ce cas, rien n'est plus utilisable.
Alors que ta base de donnée mais en oeuvre plusieurs notions :
Taille, Type de base, requete (voir procedures stockés, nombre de connection simultanée, shema de base (il y a malheureusement bcp de gens qui ne savent pas optimiser des bases). Et ca, je prefere etre seul maitre à bord.
Alors oui, tu peux avoir du sale code PHP, mais bien souvent, c'ets la base qui traine. Et je prefere passer par ma solution, plutot que de tout coller sur un seul serveur dedié. Question d'habitude
Si c'est pas de la mutualisation ca ?
Ecoute, globalement, je suis assez d'accord avec toi lorsque tu parles de contrainte de bande passante.
Il faut juste voir si ton site est vraiment ralenti de manière frequente.
Car des goulots d'etranglement, tu peux en avoir un peu partout. Surtout si tu mutualises des centaines de sites sur ton serveur dédié.
Perso, je suis chez OVH, et j'ai rarement des problemes à ce niveau là (90 plan). Là ou j'ai un probleme, c'est avec la base, qui grandie à vue d'oeil.
J'ai pensé à prendre un dedié pour tout mettre dessus. Et là, il va fallori que je gere apache/mysql/php, plus autres services (backup, mail, etc ...).
Au lieu de tout mettre sur un dedié, j'envisage un dedié pour la base, et resté en mutu pour le serveur de page. Car quand mon site ralenti, il ralenti à cause des accès en base. Et je suis limité par le nombre de connections à cette meme base.
Bon, en plus, je voudrais mettre du postgres
La plupart du temps, il est plus facile de merdouiller avec la base qu'avec ton code PHP. Si ton code merdouille, tu arrives vite à un timeout, et dans ce cas, rien n'est plus utilisable.
Alors que ta base de donnée mais en oeuvre plusieurs notions :
Taille, Type de base, requete (voir procedures stockés, nombre de connection simultanée, shema de base (il y a malheureusement bcp de gens qui ne savent pas optimiser des bases). Et ca, je prefere etre seul maitre à bord.
Alors oui, tu peux avoir du sale code PHP, mais bien souvent, c'ets la base qui traine. Et je prefere passer par ma solution, plutot que de tout coller sur un seul serveur dedié. Question d'habitude
Ohax a dit:
On parle bien d'un serveur de page (apache) et un SGBD.
Evidement, il faut penser au reste (donc, ca ne fait que conforter ma position).
C'est justement parce que tout le monde ne peux pas louer deux serveur que je propose de passer sur une archi mi didiée/mi mutualisée.
mutu : apache/php
dedié : SGBD.
Sinon, trouve moins un hebergeur qui va te coller un SGBD sur la meme machine physique qu'apache ^^ Je suis curieux de voir ca
La repatition c'est pourtant super simple à comprendre
Si tout est sur la meme machine : fait tourner l'un des serveur à bloc, et observe le comportement de l'autre ... et on a pas parlé de securité là ...
en es tu bien sur ?
ne pourrait il pas venir aussi de la bande passante ?
pour verifier c'est simple, tu colles un fichier de 100mo et lors du ralentissement tu le telecharges et tu verra à quelle vitesse il descend
tu peux aussi faire une requête mysql très legere avec une page de 5ko de resultat en y collant la fonction qui calcule les temps d'execution
sans polemiquer, le ralentissement vient du pic d'activité du server et les responsables sont les 200 ou 300 sites hébergés et il est clair que tu peux coller ton site sur nimporte quelle machine sans avoir de problème de cohabitation LAMP
ensuite tu pourras demander à ceux qui t'on dit que la séparation apache/mysql etait meilleur de t'expliquer pourquoi (les requêtes style into out file etant maintenant bloquées par les grant user)
pas evident
rog
rog a dit:
Il y a 2 semaines, un le système de load balancing de chez OVH causait un peu de perte, pas beaucoup 0.4%
BDD hébergés chez Redbus et Papache hébergé à Rbx...
C'est une solution bien, quand elle marche et est plus couteuse que de correctement dimensionner ses usages... (Avis PERSO)...
On est pas encore dans le housing...
rog a dit:
J'ai une solution plus pro : tu monitor tes serveurs.
Bah oui, pour savoir si ton serveur est en train de ramer, tu regarde sa charge processeur. C'est valable aussi bien pour le SGBD, mais aussi pour apache.
Pour la séparation des serveur sur les machines, je ne vais même pas chercher à argumenter plus : C'est un critère élémentaire de sécurité.
Trouves moi juste une boite serieuse qui colle ces deux serveur sur la meme machine ^^ Mais dis moi le nom, que je n'y aille surtout pas.
Julia, c'est pas une question de housing : ce qu'il y a dans ton serveur, tu le paies ... Y compris le surdimensioneement.
PS : OVH est encore chez Redbus ? je croyais qu'ils avaient arreté ?
OVH ne loue pas des dédiés chez Redbus, juste ses offres Housing...
Alors là, question de sécurité, je vois pas trop où elle est...
Tu parles d'une boite qui ferait ça, ceux qui souhaitent louer du Mutu, c'est un peu normal... Ils peuvent choisir la BP, les servs les plus adaptés...
Tu sépares les 2, si Apache crash sur machine 1, machine 2 sert à rien...
Si MySQL crash sur machine 2, machine 1 qui sert à rien...
Pour parler de charge oui, mais pas pour parler de sécurité...
Alors là, question de sécurité, je vois pas trop où elle est...
Tu parles d'une boite qui ferait ça, ceux qui souhaitent louer du Mutu, c'est un peu normal... Ils peuvent choisir la BP, les servs les plus adaptés...
Tu sépares les 2, si Apache crash sur machine 1, machine 2 sert à rien...
Si MySQL crash sur machine 2, machine 1 qui sert à rien...
Pour parler de charge oui, mais pas pour parler de sécurité...
Julia41 a dit:
Wé ok, j'ai du me tromper de forum alors...
Chez nous, on gere plus de 400 serveurs avec applicatifs metier, ce qui comprend en outre les serveur oracle, sybase, serveur web et d'application. Et il n'y a pas un seul serveur de base données qui soit mutualisé avec un serveur de page, ou autre...
On a même du mysql, et une postgres.
Mais vous avez raisons, ca ne sert à rien. C'est juste une recommandation impérative dans les grands groupes. On se demande bien pourquoi d'ailleurs.
Julia, si une machine crash, elle crash, tu n'as plus qu'a la remonter (si bakcup correctement fait). Si tu as tout tes oeufs dans le même panier, ah moins de repliquer tes données, tu es dans la merde.
Ta base de données ne doit JAMAIS etre accessible depuis le web (meme machien que le serveur web). Renseignes toi ...
excuses moi mais pour eviter les floods et discussions stériles, tu devrais lire plus attentivement ce que l'on ecris
tu parles d'un probleme de surcharge sur un server mutualisé et tu demandes notre avis sur une migration shématisée par un server apache en mutualisé et un server mysql dédié
tu incrimines en surcharge le server mysql et je te donne un conseil sur une methode pour verifier d'ou vient la surcharge
tu me repond que ma solution est du bricolage et que tu préferes monitorer ton server (jusq'à present il me semble qu'il s'agit du mutu ovh)
je te pose la question si tu peux effectuer un monitoring sur un mutualisé ovh
et tu me demandes si je parles d'un dédié ??
ça fait la 3° fois que tu le dis mais tu ne fournis aucun argument
et le couplage ou non des deux servers n'a rien à voir avec les systèmes de backup
rog
Il est clair que la separation des machines est un element clé de la sécurité. Par contre tu peux eviter les backup si crash avec une soluce fail-over c'est ce que j'ai sur ma plateforme. 2 (ou plus ) frontaux avec un rsync maitre/esclave sur l'une et l'autre des machines + un systeme de Load balancing en soft style LVS (pas de round robin) . Si la machine 1 crashe la 2 est toujours dispo et replique sur la 1 quand celle-ci est remontée ... idem dans l'autre sens ... idem pour mysql maitre/esclave avec replic + ip flottante... la base est toujours disponible ... c'est une soluce tip top, je n'ai plus jamais fait tomber mon site grace a ca depuis maintenant plusieurs mois ... a conseiller surtout que le rapport qualité / prix reste assez abordable puisque'a part les serveurs on travaille avec du soft qui plus est en libre.
OVH n'a pas arreté ses services de Housing par contre il ne monte plus de plateforme du style de celle du dessus ...
) frontaux avec un rsync maitre/esclave sur l'une et l'autre des machines + un systeme de Load balancing en soft style LVS (pas de round robin) . Si la machine 1 crashe la 2 est toujours dispo et replique sur la 1 quand celle-ci est remontée ... idem dans l'autre sens ... idem pour mysql maitre/esclave avec replic + ip flottante... la base est toujours disponible ... c'est une soluce tip top, je n'ai plus jamais fait tomber mon site grace a ca depuis maintenant plusieurs mois ... a conseiller surtout que le rapport qualité / prix reste assez abordable puisque'a part les serveurs on travaille avec du soft qui plus est en libre.OVH n'a pas arreté ses services de Housing par contre il ne monte plus de plateforme du style de celle du dessus ...
raljx a dit:Il est clair que la separation des machines est un element clé de la sécurité. Par contre tu peux eviter les backup si crash avec une soluce fail-over c'est ce que j'ai sur ma plateforme. 2 (ou plus
OVH n'a pas arreté ses services de Housing par contre il ne monte plus de plateforme du style de celle du dessus ...
Enfin qqch d'interressant
On avait mis en place cette solution pour un portail :
3 Apache en load balancing, plus deux mysql repliqués.
Ca marcahit plutot bien
)) (On bossait avec alink.. (no pub)Pour le housing, ce n'etait pas de l'ironie, je pensais vraiment qu'ils avaient arreté de bosser avec redbus suite à quelques petits problemes (de sous sous aussi
, j'ai du voir passer ca dans la ML ...Bon, sinon, pour en finir avec le faux troll à deux roubles :
@ rog :
Branches tes yeux, VOUS avez parlé de surcharge sur un mutu.
Et je n'ai absolument pas demandé votre avis sur quoi que ce soit :
J'ai juste specifié, à la base, qu'il fallait séparer les bases de données des serveurs web. T'as vu autre chose ? relis bien, et si tu ne vois pas, relis encore.
J'affirme que dans mes experiences, les moteurs de bases de donnes sont plus sollicité que les moteurs PHP, et d'apache. Là ou je bosse, les dev ne sont pas tjr calé en optimisation de base (ce qui est une science à part entiere, qui devrait revenir à des DBM, pas uniquement aux dev ..)
Je veux bien que tu me donnes des conseils, mais comment peux tu etre crédible lorsque tu remes en cause des regles elementaires de securité, d'architecture, et autre, et de ma parler de virtual host alors que ca n'a rien à voir...
Mais je rêve ... Je te parle de surcharge de base de données, et non pas de savoir pourquoi mon serveur ralenti. (d'ailleurs, je ne parle pas que de surcharge, mais aussi de tailles de bases ... mais bon, c'est pas grave ...).
La cause est déjà trouvée, et dans le cas d'un serveur dedié, je prefere le dedié à la base, quit à deleguer la brique serveur http à un mutu (dans le cas d'un site dynamique s'appuyant sur une grosse base, relis, c'est ecrit !!). A part me dire que qd on a un dedié, on n'utilise pas un mutu, j'ai rien vu d'autre (enfin si, mais c'etait pas non plus très puissant, désolé).
Mais tu melanges tout, decidement ...
Le fait de separer les sgbd des httpd est une pratique fortement recommandée, pour des raisons de sécurité, de maintenance, de modularité, de répartition de charge ... Ce ne sont pas des arguments ca ?
Après, je peux bien essayer de t'expliquer comment, mais tu reste tellement ancré sur ta position que ca me parait vain ...
Donc, fais ce que tu veux, mais ce que tu me proposes est effectivement assimible à du bricolage.
Fin du post pour moi.
Pour en revenir au sujet initial :
Tout depend de la taille de ton application, du nombre de site (dans le cas d'un serveur web), de la taille des bases, de la charge estimée si c'est le cas d'une base de donnée.
Le choix du processeur doit aussi se faire (et surtout), en relation avec le prix auquel tu vas le toucher, et à la memoire que tu vas lui allouer.
Le meilleurs des procs couplé à 256 Mo de ram te coutera la peau du fion, mais serait "castré" par la faible quantité de memoire.
Prix, Memoire, frequence, utilisation ... ce sont les critères importants.
La chaleurs aussi, mais il y a des palliatifs ...
dommage on commençait à s'amuser
moi je vais donner deux arguments contre ton architecture
1) en multipliant les machines tu multipies les incidences de panne matériel
2) tu ne peux pas maitriser la disponibilité des ressources allouées à tes scripts sur un server mutualisé
pour la securité :
ta solution entraine obligatoirement une disponibilité du server mysql pour au moins une connection externe
et je n'ai pas vu chez ovh la possiblité de pouvoir créer des régles sur leurs routers/firewall pour bloquer les requêtes
- on augmenterait donc les possibilités d'attaque directes sur le server mysql
rog
si tu veux continuer la discussion, essaies d'être precis et concis et surtout evites les arguments du style "dans ma boite ils font ceci ou cela"
merci
WRInaute passionné
Quel débat d'experts !?
Pauvre internaute qui lit ce post ! Il ne doit rien comprendre...
Pour éclaircir vos propos vis à vis des néophytes, on appellera "serveur" une machine et "service" une application qui fonctionne sur le serveur. (c'est un choix tout a fait arbitraire mais j'utilisais ce vocabulaire auprès de mes étudiants lorsque j'enseignais :wink: )
Donc, il y à ceux qui disent qu'il ne faut pas faire fonctionner plusieurs "services" sur un même "serveur", et ceux qui disent le contraire.
Bon, maintenant, je donne mon avis, fini la neutralité. :mrgreen:
Je ne fais personnellement jamais fonctionner les "services" http, mail et sql (quelque soit le soft choisi) sur le même serveur dans un souci de performances (et vous pouvez me dire ce que vous voulez, j'ai fait des tests et il n'y a pas photo!) Je vais même plus loin, j'ai tendance à "fabriquer" un "service" http différent selon le type de pages à servir (statiques, dynamiques, fichiers images etc ...) avec un "service" http en proxy inverse. Je n'installe pas non plus de "service" ftp sur un "serveur" dédié aux mails ou aux bases de données etc ... Ce sont des règles de bon sens.
Maintenant l'argumentation ! :wink:
1 la performance.
Par exemple, un "service" mail avec un bon antispam style spamassassin et tout plein de règles de filtrage te génère des processus de 30 ou 40 mo, de quoi mettre tes autres "services" à plat.
2 la sécurité.
Si un "serveur" est hacké ou en panne, cela coupe un "service", mais pas les autres. il y a des esprits chagrins qui vont me dire que si le "serveur" qui héberge le "service" sql est planté, le(s) site(s) installées sur le "serveur" qui héberge le(s) service(s) http seront inaccessibles. Et bien, je leur réponds que non si le service http possède un cache de pages efficace et même dans le cas d'un forum, il serait accessible en lecture mais on ne pourrait pas poster.
3 La question d'origine
Hé oui, faut bien y revenir :wink:
Pour répondre à cette question, je ferais l'analogie suivante : Le processeur est le moteur, la mémoire le carburant. Avec un gros moteur et peu d'essence on va vite mais pas loin !
Je conseille donc à l'auteur du post de mettre ses sous dans la mémoire plus que dans le processeur
Voilà!
Aië ! Je vais m'attirer des ennuis moi :mrgreen:
Pauvre internaute qui lit ce post ! Il ne doit rien comprendre...
Pour éclaircir vos propos vis à vis des néophytes, on appellera "serveur" une machine et "service" une application qui fonctionne sur le serveur. (c'est un choix tout a fait arbitraire mais j'utilisais ce vocabulaire auprès de mes étudiants lorsque j'enseignais :wink: )
Donc, il y à ceux qui disent qu'il ne faut pas faire fonctionner plusieurs "services" sur un même "serveur", et ceux qui disent le contraire.
Bon, maintenant, je donne mon avis, fini la neutralité. :mrgreen:
Je ne fais personnellement jamais fonctionner les "services" http, mail et sql (quelque soit le soft choisi) sur le même serveur dans un souci de performances (et vous pouvez me dire ce que vous voulez, j'ai fait des tests et il n'y a pas photo!) Je vais même plus loin, j'ai tendance à "fabriquer" un "service" http différent selon le type de pages à servir (statiques, dynamiques, fichiers images etc ...) avec un "service" http en proxy inverse. Je n'installe pas non plus de "service" ftp sur un "serveur" dédié aux mails ou aux bases de données etc ... Ce sont des règles de bon sens.
Maintenant l'argumentation ! :wink:
1 la performance.
Par exemple, un "service" mail avec un bon antispam style spamassassin et tout plein de règles de filtrage te génère des processus de 30 ou 40 mo, de quoi mettre tes autres "services" à plat.
2 la sécurité.
Si un "serveur" est hacké ou en panne, cela coupe un "service", mais pas les autres. il y a des esprits chagrins qui vont me dire que si le "serveur" qui héberge le "service" sql est planté, le(s) site(s) installées sur le "serveur" qui héberge le(s) service(s) http seront inaccessibles. Et bien, je leur réponds que non si le service http possède un cache de pages efficace et même dans le cas d'un forum, il serait accessible en lecture mais on ne pourrait pas poster.
3 La question d'origine
Hé oui, faut bien y revenir :wink:
Pour répondre à cette question, je ferais l'analogie suivante : Le processeur est le moteur, la mémoire le carburant. Avec un gros moteur et peu d'essence on va vite mais pas loin !
Je conseille donc à l'auteur du post de mettre ses sous dans la mémoire plus que dans le processeur
Voilà!
Aië ! Je vais m'attirer des ennuis moi :mrgreen:
Duron, disparu depuis au moins trois ans. Athlon (on suppose 64) utilisé par quasiment tous les utilisateurs du monde dans le mode 32 bits (connait pas grand monde qui utilise XP 64 ou Vista 64 bits, notamment au niveau compatilité des logiciels). Cette solution est envisageabel uniquement sous Linux (à condition d'avoir version compilée adéquate).
Celeron, la 2 CV des processurs PC.
Mais poiur une simple site, pas la peine de chercher la performance, ils fonctionneront tous (et effectivement privilégie la RAM)
Celeron, la 2 CV des processurs PC.
Mais poiur une simple site, pas la peine de chercher la performance, ils fonctionneront tous (et effectivement privilégie la RAM)
WRInaute occasionnel
Rog...
Les mutualisés ovh sont architecturés en cluster a tolerance de panne, load balancing, et disposent d'une BP bien superieure a 10 mega.
On est plus en 2000, et les serveurs a base de PII 400 sont a la cave ou dans les musees.
Pour info, le seul goulot d'etranglement chez ovh en mutu c'est la vitesse du fond de panier des load balancers cisco ( 4 GB/s ).
http://www.exceliance.fr/art-2006-wta-lb.pdf
Les mutualisés ovh sont architecturés en cluster a tolerance de panne, load balancing, et disposent d'une BP bien superieure a 10 mega.
On est plus en 2000, et les serveurs a base de PII 400 sont a la cave ou dans les musees.
Pour info, le seul goulot d'etranglement chez ovh en mutu c'est la vitesse du fond de panier des load balancers cisco ( 4 GB/s ).
http://www.exceliance.fr/art-2006-wta-lb.pdf
WRInaute occasionnel
Moi aussi je viens applaudir le dernier post de fandecine.
Je passe mon temps à les bookmarquer et à les recommander ...
(et on attend toujours ton blog fandecine)
Je passe mon temps à les bookmarquer et à les recommander ...
(et on attend toujours ton blog fandecine)
WRInaute occasionnel
amokk a dit:
no :wink:
La fréquence ?
Il y a des gens qui osent encore parler de fréquence ?
Vient donc comparer un Celeron 2GZ face à un Core2Duo de la même fréquence...
Même si tu désactive un coeur tu va défoncer le Celeron... Et je pèse mes mots...
La fréquence c'est quelque chose de dépassé...
Allez expliquer aux gens que leur vieux Pentium IV à 4 GZ est complètement périmé...
Il y a des gens qui osent encore parler de fréquence ?
Vient donc comparer un Celeron 2GZ face à un Core2Duo de la même fréquence...
Même si tu désactive un coeur tu va défoncer le Celeron... Et je pèse mes mots...
La fréquence c'est quelque chose de dépassé...
Allez expliquer aux gens que leur vieux Pentium IV à 4 GZ est complètement périmé...
WRInaute passionné
titiplanti a dit:
ça avance, j'ai le domaine, j'ai le serveur et j'ai choisi l'architecture...Manque juste un peu de temp :mrgreen:
Pour l'heure, je termine le montage d'un serveur de streaming vidéos autour de lighttpd (génial ce serveur http !).
Comme on parle de puissance CPU, de ram et de choix de serveur, je pourrais presque vous en parler dans ce topic, mais je préfère attendre d'avoir fini et je vous posterais un petit tutorial sur WRI :wink:
WRInaute impliqué
raljx a dit:Il est clair que la separation des machines est un element clé de la sécurité. Par contre tu peux eviter les backup si crash avec une soluce fail-over c'est ce que j'ai sur ma plateforme. 2 (ou plus
OVH n'a pas arreté ses services de Housing par contre il ne monte plus de plateforme du style de celle du dessus ...
Merci pour cette discussion très intéressante,
Pour avoir une telle structure, faut-il mettre tous les serveurs dans un 1/4 de baie ?
Excuser moi :roll: je vois que vous conseiller beaucoup de ram ,
1) Est ce que vous conseiller beaucoup de ram pour un serveur qui heberge pleins de sites ,
Ou est ce que vous conseiller également beaucoup de ram pour un serveur qui hébérge un seul site avec pas mal de traffic ?
2) Dans le cas du serveur qui heberge un seul site , est ce que cette config est confortable :
Intel Pentium 4 , : 3.00 GHz
Architecture 32 bits
Mémoire vive 1 Go DDR
Dernière question , 1Go de ram c'est déja bien ou c'est tres light ?
Merci beaucoup :wink:
1) Est ce que vous conseiller beaucoup de ram pour un serveur qui heberge pleins de sites ,
Ou est ce que vous conseiller également beaucoup de ram pour un serveur qui hébérge un seul site avec pas mal de traffic ?
2) Dans le cas du serveur qui heberge un seul site , est ce que cette config est confortable :
Intel Pentium 4 , : 3.00 GHz
Architecture 32 bits
Mémoire vive 1 Go DDR
Dernière question , 1Go de ram c'est déja bien ou c'est tres light ?
Merci beaucoup :wink:
untictac a dit:
Bah tout dépends de ton traffic et de ton site ^^
Héberger le site WRI, ou le site d'une ptite team Counter-Strike par exemple, ce n'est pas la même chose...
1go de ram, si c'est que pour du Web et que tu n'as pas un traffic énorme, j'pense que c'est bien...
WRInaute occasionnel
Ca dépend aussi de comment est optimisé ton site, du nombre de requêtes SQL que peut générer un seul visiteur.untictac a dit:
untictac a dit:
Quels sont les services present sur ton serveur ?
Httpd, mails, base de données, etc ...
Si ton site est bien pensé, et qu'il utilise intensément des systèmes de cache, 1 Go peux carrément faire l'affaire.
Pour info, je fais tourner un trombinoscope utilisé intensément chaque jour en interne (5000 personnes d'enregistrés) en full ASP.NET sur une petite machine, avec 1 Go de ram. Ca tourne sans aucun souci.
Le truc, c'est que sur ce serveur, il n'y a que IIS avec le framework .Net. Pas de base de données sur la machine.
Comme le dit Titiplanti, tout dépend de la façon dont est optimisé ton site.
1Go me semble malgré tout plutôt confortable (surtout sur un linux/bsd)
Discussions similaires
