Avantages d'un dédié virtuel ?
Olivier Masson
Sur un dédié virtuel, quelles sont les ressources en commun au niveau
logiciel ?
S'il y en a aucune, le seul intérêt est-il de payer moins cher pour un
mini-dédié ?
Merci.
Marc Plunian
chaque serveur virtuel comme un serveur dédié classique. Outre le prix
par rapport à un serveur dédié physique, l'hébergeur se charge
d'administrer le serveur hote (maj systèmes sécurité). En général, via
un système de templates, l'hébergeur met à disposition les logiciels à
mettre à jour, à vous de maj ou pas.
Il y a beaucoup d'intérêt à utiliser des serveurs virtuels et notamment
la possibilité via des outils spécifiques de déplacer/dupliquer une
machine virtuelle pour la faire fonctionner sur un autre site. C'est
bien pratique en cas de panne sur un netcenter : panne électrique, panne
serveur.
Olivier Masson
> A part le système hôte pas grand chose. Les logiciels sont installés sur
> chaque serveur virtuel comme un serveur dédié classique. Outre le prix
> par rapport à un serveur dédié physique, l'hébergeur se charge
> d'administrer le serveur hote (maj systèmes sécurité). En général, via
> un système de templates, l'hébergeur met à disposition les logiciels à
> mettre à jour, à vous de maj ou pas.
>
Mais ces maj du serveur, elles concernent quoi ?
Il y a donc une base commune ? On a la même distrib j'imagine, mais quoi
d'autres ? On a la même install de postfix (par exemple), apache, bind,
etc. mais on peut avoir le fichier conf que l'on souhaite, avec en plus
la possibilité d'installer d'autres applis, c'est ça ?
Merci.
Franck
> Mais ces maj du serveur, elles concernent quoi ?
> Il y a donc une base commune ?
La base commune, c'est le système "superviseur", c'est à dire l'OS qui
va gérer le partage de ressources entre les différentes machines virtuelles.
> On a la même distrib j'imagine
Non, chaque machine virtuelle veut faire tourner la distrib. voir l'OS
qu'elle désire. Il peut très bien y avoir sur la même machine physique
une machine virtuelle tournant sous linux, et une autre tournant sous
Windows.
Dans la machine virtuelle, vous faites ce que vous voulez, de votre
point de vue, il n'y a *aucune* différence avec un dédié "réel".
Olivier Masson
> Dans la machine virtuelle, vous faites ce que vous voulez, de votre
> point de vue, il n'y a *aucune* différence avec un dédié "réel".
Donc le système n'est pas mieux protégé, surveillé, etc. comme il me
semblait le comprendre dans certaines offres ?
Franck
Le superviseur surveille évidemment les machines virtuelles et est
capable de remonter des alertes... Chose que l'ont peut aussi faire
aussi avec des dédiés physiques.
L'avantage du dédié virtuel, c'est qu'en cas de panne matérielle on peut
immédiatement redémarrer la machine virtuelle sur un autre serveur
physique sans avoir quoi que ce soit à réinstaller ou reconfigurer.
Emmel
viennent d'où ? génération spontanée ?
A mon avis, le seul avantage, c'est par rapport à un hébergement
mutualisé : l'ensemble des ressources (BP, CPU, RAM, ...) ne peut être
monopolisé par un utilisateur (script merdique, ...)
ML
Franck
> Ah oui ? et l'OS de la machine virtuelle, les fichiers, les données, ils
> viennent d'où ? génération spontanée ?
Sur un SAN évidemment.
Faire de la machine virtuelle sur un simple PC puissant, c'est faisable,
mais quand on veut faire ça professionnellement, on externalise le
stockage des machines virtuelles, on ne se contente pas d'utiliser les
disques internes à la machine...
Là où je bosse, on utilise un bladecenter & un san ibm. Il suffit de
quelques secondes pour déplacer une machine d'une lame vers une autre.
Olivier Masson
> L'avantage du dédié virtuel, c'est qu'en cas de panne matérielle on peut
> immédiatement redémarrer la machine virtuelle sur un autre serveur
> physique sans avoir quoi que ce soit à réinstaller ou reconfigurer.
>
Ok, merci.
Disons simplement qu'on n'est pas censé se soucier des problèmes
matériels. Par contre, intrusions, mises à jour de sécurité, etc. c'est
pareil qu'un dédié.
Franck
> Par contre, intrusions, mises à jour de sécurité, etc. c'est
> pareil qu'un dédié.
Voilà.
Ceci dit, la plupart des hébergeurs proposant du dédié et du dédié
virtuel proposent également de l'infogérance.
nicolas vigier
Ca depend surement des offres. Sur certaines il est possible que
certaines parties du système soient partagées entre toutes les machines
virtuelles.
Christophe Baegert
> Là où je bosse, on utilise un bladecenter & un san ibm. Il suffit de
> quelques secondes pour déplacer une machine d'une lame vers une autre.
Oui, avec un san totalement redondant ca le fait bien. Mais à quel prix...
Christophe Baegert
>
> A mon avis, le seul avantage, c'est par rapport à un hébergement
> mutualisé : l'ensemble des ressources (BP, CPU, RAM, ...) ne peut être
> monopolisé par un utilisateur (script merdique, ...)
Oui, mais vous risquez aussi de pâtir vous-même des limitations en question
les jours de pics sur votre site !!! D'ailleurs sur un hébergement
mutualisé sérieux il y a en principe des dispositifs de surveillance de ce
qui tourne pour éviter les accidents (sans ça un mutu ne peut pas tourner
de manière fiable). Au final, hormis les cas de virtualisation basé sur un
SAN dans un contexte grand compte ou pour faire tourner autre chose que le
classique linux-apache-mysql-php, l'intérêt d'un dédié virtuel est faible
AMHA.
Marc Plunian
> Emmel wrote:
>> A mon avis, le seul avantage, c'est par rapport à un hébergement
>> mutualisé : l'ensemble des ressources (BP, CPU, RAM, ...) ne peut être
>> monopolisé par un utilisateur (script merdique, ...)
>
> Oui, mais vous risquez aussi de pâtir vous-même des limitations en question
> les jours de pics sur votre site !!!
des valeurs minimum garanties. En cas de besoin le système peut allouer
(si l'hébergeur a configuré le serveur virtuel pour ça!)des ressources
supplémentaires si les autres serveurs n'en n'ont pas besoin. Il est
rare que X serveurs virtuels sur la même machine physique
aient des pics en même temps. D'ou l'intérêt de la virtualisation.
D'ailleurs sur un hébergement
> mutualisé sérieux il y a en principe des dispositifs de surveillance de ce
> qui tourne pour éviter les accidents (sans ça un mutu ne peut pas tourner
> de manière fiable).
Au final, hormis les cas de virtualisation basé sur un
> SAN dans un contexte grand compte ou pour faire tourner autre chose que le
> classique linux-apache-mysql-php, l'intérêt d'un dédié virtuel est faible
> AMHA.
applications avec la virtualisation sans passer forcément par des SAN ou
NAS. Par exemple, on duplique (de façon autotmatique)le serveur virtuel
un ou 2 fois par jour sur un autre serveur, si on plante le serveur de
prod, on peut redémarrer en quelques minutes (1/4 d'heure) avec ses
données de la veille sur l'autre serveur. C'est quand même mieux que de
tout réinstaller (système + applis) et de restaurer ses données (quand
on a une sauvegarde !).
Emmel
Tu peux aussi le faire avec des dédiés 'normaux', pas simplement avec
des machines virtuelles qui, à ce niveau n'apportent rien (d'où ma remarque)
ML
Mihamina Rakotomandimby
> Ceci dit, la plupart des hébergeurs proposant du dédié et du dédié
> virtuel proposent également de l'infogérance.
Une infogérance qui coute 3 ou 4 fois le serveur n'est pas
commercialement viable.
Une infogérance qui a le meme cout que le serveur (virtuel),... je me
demande en quoi c'est de l'infogérance.
Je dis ça,...
Olivier Masson
> de manière fiable). Au final, hormis les cas de virtualisation basé sur un
> SAN dans un contexte grand compte ou pour faire tourner autre chose que le
> classique linux-apache-mysql-php, l'intérêt d'un dédié virtuel est faible
> AMHA.
L'intérêt que j'y vois pour mon compte, c'est d'avoir plus puissant
qu'un mutualisé (avoir 20% d'un P4 me semble plus puissant que d'être un
des 20, 50, 100 sites d'un mutualisé), de pouvoir modifier les config de
PHP, installer PostgreSQL si je veux, installer cacti, installer
d'autres appli.
man...@free.fr
>SAN dans un contexte grand compte ou pour faire tourner autre chose que le
>classique linux-apache-mysql-php, l'intérêt d'un dédié virtuel est faible
Sur un dédié virtuel vous pouvez aussi:
- Voir la console système du serveur (pratique si plus de reseau, pb de
fichier manque, etc ...)
-> pas possible sur un vrai dédié sauf reboot sur un OS de virtualisation
- Faire une install depuis le CDROM
-> pas possible sur un vrai dédié car vous n'avez pas accès à la machine
- Et dans certain cas booter sur une disquette (genre freedos, tomsrtbt)
Et comme sur un vrai dédié, vous pouvez:
- Booter en rescue sur un mini OS
- avoir jusqu'à 4 disques dur
- gérer vos propres partition
- faire du RAID soft entre disque dur (même si le serveur hôte est déjà en
RAID hard)
- faire du LVM sur les disques dur
Marc Plunian
Je ne vois pas en quoi le fait que l'infogérance serait 3 à 4 fois le
prix du serveur ne serait pas viable commercialement ?? Et d'abord pour
qui ? Le client ou l'hébergeur ?
L'infogérance sur un serveur dédié aura le même coût que sur le serveur
dédié. Si le client ne sait pas administrer son serveur, c'est le cas de
beaucoup d'agences Web, cela leur coutera moins cher de prendre 1
Serveur Virtuel + Infogérance qu'un Serveur dédié + Infogérance.
Olivier Masson
> Sur un dédié virtuel vous pouvez aussi:
> - Voir la console système du serveur (pratique si plus de reseau, pb de
> fichier manque, etc ...)
> -> pas possible sur un vrai dédié sauf reboot sur un OS de virtualisation
> - Faire une install depuis le CDROM
> -> pas possible sur un vrai dédié car vous n'avez pas accès à la machine
> - Et dans certain cas booter sur une disquette (genre freedos, tomsrtbt)
>
Je suis un peu tarte : en quoi ai-je davantage accès à la machine sur un
dédié virtuel ?
> Et comme sur un vrai dédié, vous pouvez:
> - Booter en rescue sur un mini OS
> - avoir jusqu'à 4 disques dur
> - gérer vos propres partition
> - faire du RAID soft entre disque dur (même si le serveur hôte est déjà
> en RAID hard)
> - faire du LVM sur les disques dur
>
C'est le virtuel haut de gamme ! Jamais vu (donc pas assez cherché) de
dédié virtuel ou je pouvais ajouter des disques durs.
Christophe Baegert
> L'intérêt que j'y vois pour mon compte, c'est d'avoir plus puissant
> qu'un mutualisé (avoir 20% d'un P4 me semble plus puissant que d'être un
> des 20, 50, 100 sites d'un mutualisé)
Pas forcément, puisque par moment vous pourriez avoir 80% d'un bi dual-core,
d'un quad-core, d'un cluster... C'est tout l'intérêt du mutualisé, ça lisse
les courbes de charge puisqu'il est rare que tous les hébergés aient leurs
pics de fréquentation en même temps.
> , de pouvoir modifier les config de
> PHP
possible en mutu (chez nous en tout cas)
> installer PostgreSQL si je veux
possible en mutu (chez nous en tout cas)
> installer cacti
inutile en mutu puisque ce n'est pas à vous de gérer les ressources
> installer
> d'autres appli.
Oui, donc on est d'accord, l'intérêt principal c'est d'installer d'autres
choses que le classique LAMP.
Christophe Baegert
> Sur un dédié virtuel vous pouvez aussi:
> - Voir la console système du serveur (pratique si plus de reseau, pb de
> fichier manque, etc ...)
> -> pas possible sur un vrai dédié sauf reboot sur un OS de virtualisation
> - Faire une install depuis le CDROM
> -> pas possible sur un vrai dédié car vous n'avez pas accès à la machine
> - Et dans certain cas booter sur une disquette (genre freedos, tomsrtbt)
Ca c'est l'intérêt par rapport à un dédié, pas par rapport à un mutualisé
(puisque le but d'un mutualisé c'est de ne pas se casser la tête, ça
tourne, point).
Christophe Baegert
> L'infogérance sur un serveur dédié aura le même coût que sur le serveur
> dédié. Si le client ne sait pas administrer son serveur, c'est le cas de
> beaucoup d'agences Web, cela leur coutera moins cher de prendre 1
> Serveur Virtuel + Infogérance qu'un Serveur dédié + Infogérance.
Et encore moins cher de prendre un mutualisé ;-)
nicolas vigier
>>Au final, hormis les cas de virtualisation basé sur un
>>SAN dans un contexte grand compte ou pour faire tourner autre chose que le
>>classique linux-apache-mysql-php, l'intérêt d'un dédié virtuel est faible
>
> Sur un dédié virtuel vous pouvez aussi:
> - Voir la console système du serveur (pratique si plus de reseau, pb de
> fichier manque, etc ...)
> -> pas possible sur un vrai dédié sauf reboot sur un OS de virtualisation
> - Faire une install depuis le CDROM
> -> pas possible sur un vrai dédié car vous n'avez pas accès à la machine
> - Et dans certain cas booter sur une disquette (genre freedos, tomsrtbt)
Ce genre de choses est possible egalement sur certains dediés.
Olivier Masson
>> , de pouvoir modifier les config de
>> PHP
> possible en mutu (chez nous en tout cas)
>
>> installer PostgreSQL si je veux
> possible en mutu (chez nous en tout cas)
Oui, mais votre mutualisé est au prix de dédiés puissants chez d'autres
(avec, surtout, beaucoup beaucoup plus d'espace disque) !
Je ne doute pas que vous fassiez un très bon travail, mais vos tarifs
sont parfaitement incompatibles avec ce que paient et ce dont ont besoin
mes clients (de l'espace pour leurs mails, un webmail ergonomique, un
site internet peu fréquenté).
Christophe Baegert
> Oui, mais votre mutualisé est au prix de dédiés puissants chez d'autres
> (avec, surtout, beaucoup beaucoup plus d'espace disque) !
Je vous rassure, vous ne m'apprenez rien. Mais tout le monde ne veut pas
s'embêter à gérer un serveur quand il s'agit juste de faire tourner un site
web.
Mihamina Rakotomandimby
> Je ne vois pas en quoi le fait que l'infogérance serait 3 à 4 fois le
> prix du serveur ne serait pas viable commercialement ??
Un client n'est pas pret à payer de l'infogerance à 300EUR/mois pour un
serveur à 59EUR/mois. Si tu as des exemples qui infirment ce que je dis,
alors je suis preneur, parceque sur les données que j'ai, c'est la
conclusion que je peux tirer.
> Et d'abord pour qui ? Le client ou l'hébergeur ?
Le client ne veut pas.
> L'infogérance sur un serveur dédié aura le même coût que sur le serveur
> dédié.
Prenons un serveur milieu de gamme de chez OVH, 80EUR/mois.
Quelles prestations d'infogerance tu veux effectuer pour 80EUR/mois?
> Si le client ne sait pas administrer son serveur, c'est le cas de
> beaucoup d'agences Web, cela leur coutera moins cher de prendre 1
> Serveur Virtuel + Infogérance qu'un Serveur dédié + Infogérance.
Je veux bien que ton affirmation soit vraie pour certains cas, mais pas
plus.
LJVD
> Prenons un serveur milieu de gamme de chez OVH, 80EUR/mois.
> Quelles prestations d'infogerance tu veux effectuer pour 80EUR/mois?
90% des clients ne demandent rien:-)
de l'intérêt d'une bonne distribution et d'outils de monitoring.
D'ailleurs, il existe des boites qui ont compris que la majorité des
dédiés ne sont en fin de compte que des gros mutualisés, avec des config
très standard et duplicables, les couts d'infogérance peuvent chuter.
Passe faire un tour sur Webhostingtalk, tu devrais trouver cela en 2mn
à moins de 30$ par mois.
>> Si le client ne sait pas administrer son serveur, c'est le cas de
>> beaucoup d'agences Web, cela leur coutera moins cher de prendre 1
>> Serveur Virtuel + Infogérance qu'un Serveur dédié + Infogérance.
>
> Je veux bien que ton affirmation soit vraie pour certains cas, mais pas
> plus.
A ma connaissance un VPS nécessite aussi d'être administré,
avec parfois quelques arrachages de cheveux sur du virtuôzozo and co,
à moins que j'ai loupé une marche.
Dans 70% des cas, les hebergeurs poussent au VPS uniquement pour des
questions de ressources. Techniquement, un mutu permet de répondre au
besoin.
Aussi, au lieu de s'embourber dans l'administration d'un VPS,
qui est loin d'être aussi facile qu'il n'y parait,
nombre de webmasters auraient intérêt à prendre un bon fournisseur en
mutualisé.
Un de mes partenaires me fournit cela, et je dois avouer que je serais
bien ennuyé sans cette solution. Et quand j'ai besoin d'une extension
php, d'un truc un peu exotique, je suis servi dans les 8h.
Une certaine idée du bonheur ;-)
Et je prefère savoir que le serveur est indispo en rebbot 3 fois par
mois pour de bonnes raisons, que d'avoir à changer d'hébergeur a chaque
fois qu'il manque un truc.
Laurent
Dominique ROUSSEAU
>> L'infogérance sur un serveur dédié aura le même coût que sur le serveur
>> dédié.
>
> Prenons un serveur milieu de gamme de chez OVH, 80EUR/mois.
> Quelles prestations d'infogerance tu veux effectuer pour 80EUR/mois?
Ca permet d'y consacrer une heure d'admin sys pas trop bradé, ce qui
permet d'assurer les taches courantes (mise à jour de sécurité des
services, relancer le bidule qui a planté suite à un matraquage par un
robot, ...)
Mais il ne faut pas faire la betise de vendre un truc forfaitaire, à
80E/mois.
Frederic G. MARAND
"LJVD" <lj...@freeeeeeeeeeee.fr.invalid> a écrit dans le message de news:
47601ed2$0$30618$426a...@news.free.fr...
Mihamina Rakotomandimby a écrit :
[...]
> Aussi, au lieu de s'embourber dans l'administration d'un VPS,
> qui est loin d'être aussi facile qu'il n'y parait,
> nombre de webmasters auraient intérêt à prendre un bon fournisseur en
> mutualisé.
Le problème, c'est d'en trouver un: dès qu'on fait quelques milliers de
visiteurs/jour, pas moyen... j'ai demandé des avis et des offres voici
quelques semaines ici même et fait le tour de ce que je trouvais sur les
sites de comparaison d'offres, et AUCUN hébergeur n'a répondu à ma demande
avec un mutualisé, alors que j'en ai un jusqu'au 31/12... mais qu'il arrête
justement les mutualisés.
Christophe Baegert
> Le problème, c'est d'en trouver un: dès qu'on fait quelques milliers de
> visiteurs/jour, pas moyen... j'ai demandé des avis et des offres voici
> quelques semaines ici même
Dans quel post ?
Frederic G. MARAND
alias :
"Christophe Baegert" <cbaegert-p...@lixium.fr> a écrit dans le
message de news: 4760580c$0$11658$426a...@news.free.fr...
Manuel Guesdon
Bah, on peut peut être faire.
Un des derniers clients venu chez nous venait d'un serveur virtuel d'amen
qui ramait et il nous dit:
<<
Tout d'abord, pour la rapidité du site, toute l'équipe m'a fait part
de sa grande satisfaction !
C'est clair que ça n'a rien à voir avec Amen et nous sommes vraiment
content...
>>
Au depart on lui avait dit: ca devrait passer chez nous en mutualisé a
tel prix, au cas où le back office necessiterait vraiment beaucoup de
resources, en dédié ca couterait tant et on prendrait en charge la
migration dans ce cas.
Au final, en mutu ca passe bien :-)
Et on a des sites mutualisés qui font 5 a 6000 visites/jours sans pb.
Cela dit, en mutu chez nous c'est quelque fois plus cher qu'en virtuel ou
dédié chez d'autres...
Pour faire court: sales AT oxymium.net avec les requirements et on
verra... :-)
Manuel
Christophe Baegert
vous avoir répondu que c'était possible chez nous ?
Marc Plunian
> Marc Plunian wrote:
>> Je ne vois pas en quoi le fait que l'infogérance serait 3 à 4 fois le
>> prix du serveur ne serait pas viable commercialement ??
>
> Un client n'est pas pret à payer de l'infogerance à 300EUR/mois pour un
> serveur à 59EUR/mois. Si tu as des exemples qui infirment ce que je dis,
> alors je suis preneur, parceque sur les données que j'ai, c'est la
> conclusion que je peux tirer.
Il y a des infogérances à 300,00 €, nous avons une prestation dans ma
boite pour ça mais à ce prix là on a un serveur de spare immédiatement
disponible, les patchs systèmes/sécurité, rotation de logs,supervision
du serveru, reboot du serveur et des services, l'installation de
nouveaux logiciels à la demande du client,la gestion des droits et
permissions ....
Par contre pour beaucoup moins, 120,00 € on peut faire pas mal de choses
. Superision du serveur et des services, gestion des droits,patchs ...
Et même pour 80 € nous fournissons un support hotline de qualité (avec
un vrai admin sys réseau qui répond), la superivision du serveur, nous
on intègre en plus une intervention de 30 minutes sur le serveur par
mois pour une demande particulière du client.
Et nous ne sommes pas les seuls à proposer ce genre de service à ce
tarif voire moins cher, notamment chez les petits/moyens hébergeurs.
>
>> Et d'abord pour qui ? Le client ou l'hébergeur ?
>
> Le client ne veut pas.
>
>> L'infogérance sur un serveur dédié aura le même coût que sur le
>> serveur dédié.
>
> Prenons un serveur milieu de gamme de chez OVH, 80EUR/mois.
> Quelles prestations d'infogerance tu veux effectuer pour 80EUR/mois?
Voir plus haut.
>
>> Si le client ne sait pas administrer son serveur, c'est le cas de
>> beaucoup d'agences Web, cela leur coutera moins cher de prendre 1
>> Serveur Virtuel + Infogérance qu'un Serveur dédié + Infogérance.
>
> Je veux bien que ton affirmation soit vraie pour certains cas, mais pas
> plus.
Bon ben sous somme d'accord.
Marc Plunian
> Mihamina Rakotomandimby a écrit :
>
>> Prenons un serveur milieu de gamme de chez OVH, 80EUR/mois.
>> Quelles prestations d'infogerance tu veux effectuer pour 80EUR/mois?
>
> 90% des clients ne demandent rien:-)
> de l'intérêt d'une bonne distribution et d'outils de monitoring.
>
> D'ailleurs, il existe des boites qui ont compris que la majorité des
> dédiés ne sont en fin de compte que des gros mutualisés, avec des config
> très standard et duplicables, les couts d'infogérance peuvent chuter.
> Passe faire un tour sur Webhostingtalk, tu devrais trouver cela en 2mn
> à moins de 30$ par mois.
>
>>> Si le client ne sait pas administrer son serveur, c'est le cas de
>>> beaucoup d'agences Web, cela leur coutera moins cher de prendre 1
>>> Serveur Virtuel + Infogérance qu'un Serveur dédié + Infogérance.
>>
>> Je veux bien que ton affirmation soit vraie pour certains cas, mais
>> pas plus.
>
> A ma connaissance un VPS nécessite aussi d'être administré,
> avec parfois quelques arrachages de cheveux sur du virtuôzozo and co,
> à moins que j'ai loupé une marche.
administrer pour le quotidien. C'est quand même autre chose que la ligne
de commaned ou Webmin.
>
> Dans 70% des cas, les hebergeurs poussent au VPS uniquement pour des
> questions de ressources. Techniquement, un mutu permet de répondre au
> besoin.
pour unsite déjà développé sur un mutualisé ? Ce ne sera pas possible.
Il y a également les pb de sécurité, sur un mutualisé si un site se fait
piraté le serveur entier rsique d'être compromis.
> Aussi, au lieu de s'embourber dans l'administration d'un VPS,
> qui est loin d'être aussi facile qu'il n'y parait,
> nombre de webmasters auraient intérêt à prendre un bon fournisseur en
> mutualisé.
serveur virtuel pour des raisons de cout et de réactivité.Lorsque qu'ils
sont bloqués, ils nous appellent, on leur donne la solution et ce sont
eux quil'applique sur leur serveur on peut également intervenir sur le
serveur.
Christophe Baegert
> Essaye d'avoir une version de PHP ou de MySQL spécifique par exemple
> pour unsite déjà développé sur un mutualisé ? Ce ne sera pas possible.
Pour PHP je me répète mais c'est possible.
> Il y a également les pb de sécurité, sur un mutualisé si un site se fait
> piraté le serveur entier rsique d'être compromis.
Humm.... faut voir à changer d'hébergeur dans ce cas !
Marc Plunian
> Marc Plunian wrote:
>> Essaye d'avoir une version de PHP ou de MySQL spécifique par exemple
>> pour unsite déjà développé sur un mutualisé ? Ce ne sera pas possible.
>
> Pour PHP je me répète mais c'est possible.
évident que dans un hébergement mutualisé tu ne peux faire du sur
mesure. Biensur qu'en serveru virtuel nous cherchons également à
standardiser nos machines virtuels de façon à les déployer plus
rapidement, d'ailleurs en utisant Plesk sur Virtuozzo, les logiciels et
les versions dépendent de la la version de Plesk. Dans l'ensemble cela
convient, si ce n'est pas le cas onpeut faire du sur mesure sur un
virtuel ce qui est plus difficile à faire sur du mutualisé.
>
>> Il y a également les pb de sécurité, sur un mutualisé si un site se fait
>> piraté le serveur entier rsique d'être compromis.
>
> Humm.... faut voir à changer d'hébergeur dans ce cas !
>
nous avions plusieurs centaines de mutualisés (avec des gens compétents
pour l'admin) et il arrivait qu'un site "bouffe" une bonne partie des
ressources pour x raisons. Avec du virtualisé tu n'as pas cet effet
"tous les oeufs dans le même panier",ya quand même moins de risque, non ?
Christophe Baegert
> C'était un exemple et même si c'est possible avec PHP mais il est
> évident que dans un hébergement mutualisé tu ne peux faire du sur
> mesure.
Ca n'a rien d'évident...
> Biensur qu'en serveru virtuel nous cherchons également à
> standardiser nos machines virtuels de façon à les déployer plus
> rapidement, d'ailleurs en utisant Plesk sur Virtuozzo, les logiciels et
> les versions dépendent de la la version de Plesk. Dans l'ensemble cela
> convient, si ce n'est pas le cas onpeut faire du sur mesure sur un
> virtuel ce qui est plus difficile à faire sur du mutualisé.
Difficile != impossible
>>> Il y a également les pb de sécurité, sur un mutualisé si un site se fait
>>> piraté le serveur entier rsique d'être compromis.
>>
>> Humm.... faut voir à changer d'hébergeur dans ce cas !
>>
> C'est un peut léger comme argument. J'ai travaillé chez un hébergeur ou
> nous avions plusieurs centaines de mutualisés (avec des gens compétents
> pour l'admin) et il arrivait qu'un site "bouffe" une bonne partie des
> ressources pour x raisons. Avec du virtualisé tu n'as pas cet effet
> "tous les oeufs dans le même panier",ya quand même moins de risque, non ?
Je parlais de la sécurité. Pour les problèmes de ressources, c'est justement
le boulot d'un hébergeur en mutu de faire en sorte d'éviter ça, chacun a
ses petites astuces, chez nous on peut même "nicer" un site qui abuse !
nicolas vigier
> Marc Plunian wrote:
>
>> Il y a également les pb de sécurité, sur un mutualisé si un site se fait
>> piraté le serveur entier rsique d'être compromis.
>
> Humm.... faut voir à changer d'hébergeur dans ce cas !
C'est pas une question d'hebergeur, sur n'importe quel mutualisé il y
a un risque.
Marc Plunian
Ok on peut faire des choses mais comme tu le dis "nicer" ça reste des
petites astuces. Tu n'as aucun isolement de contexte comme tu peux
l'avoir avec un serveur virtuel. Franchement pour avoir bossé chez un
hébergeur qui faisait du dédié et du mutualisé et aujourd'hui uniquement
du dédié et du virtualisé, je remarque que l'on a peu ou pas les pb que
l'on rencontrait avec les mutualisés et surtout plus les appels de
clients qui remarquaient des baisses de perf sur leurs mutualisés, ...
LJVD
> LJVD a écrit :
>> Dans 70% des cas, les hebergeurs poussent au VPS uniquement pour des
>> questions de ressources. Techniquement, un mutu permet de répondre au
>> besoin.
> Essaye d'avoir une version de PHP ou de MySQL spécifique par exemple
> pour unsite déjà développé sur un mutualisé ? Ce ne sera pas possible.
Tu peux toujours avoir besoin de spécifique, dans ce cas le vps et le
dédié sont en effet une réponse.
Cela concerne à mon avis 30% max des utilisateurs de VPS ...
Et il faut se méfier des environnements spécifiques,
rien que pour une histoire de portabilité des applis ...
mon admin sait me dire quand je commence à coder avec les pieds,
il est le premier à en mesurer l'impact sur le serveur :-)
Laurent
Mickaël Wolff
> A part le système hôte pas grand chose. Les logiciels sont installés sur
> chaque serveur virtuel comme un serveur dédié classique.
C'est faux, ça dépend de la technologie utilisée. Avec Xen,
effectivement, le système parasite est indépendant de son hôte. Mais
avec une technologie telle que Virtuozzo, le kernel est commun, ainsi
qu'un certain nombre de fichiers. Ensuite, ça dépend de si on est sous
du MS ou autre chose.
Je ne vois aucun intérêt à la virtualisation pour le client. Le
mutualisé peut être mis en place avec les mêmes restrictions qu'avec la
virtualisation. C'est une question de paramétrage et de rigueur. C'est
là qu'est l'intérêt, celui du hosteur en fait : c'est plus simple de
mettre la responsabilité de la gestion d'un sous-système au client
plutôt que de se taper la tête à mettre en place des prisons et des
restrictions dures.
Personnellement, je n'ai jamais vu d'avantages à la virtualisation
autre que les tests. Et autre que le gâchis de ressources.
--
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org
Mickaël Wolff
> Pour PHP je me répète mais c'est possible.
C'est possible, à condition d'utiliser PHP en CGI. C'est d'ailleurs
une voie que j'explore actuellement pour créer mes offres. On verra ce
que ça donne.
Christophe Baegert
> Ok on peut faire des choses mais comme tu le dis "nicer" ça reste des
> petites astuces.
petite astuce très efficace en tout cas !
> Tu n'as aucun isolement de contexte comme tu peux
> l'avoir avec un serveur virtuel. Franchement pour avoir bossé chez un
> hébergeur qui faisait du dédié et du mutualisé et aujourd'hui uniquement
> du dédié et du virtualisé, je remarque que l'on a peu ou pas les pb que
> l'on rencontrait avec les mutualisés et surtout plus les appels de
> clients qui remarquaient des baisses de perf sur leurs mutualisés, ...
on n'a pas ce genre d'appels ;-)
Christophe Baegert
> Christophe Baegert a écrit :
>> Pour PHP je me répète mais c'est possible.
>
> C'est possible, à condition d'utiliser PHP en CGI. C'est d'ailleurs
> une voie que j'explore actuellement pour créer mes offres. On verra ce
> que ça donne.
eh oui ;-)
Marc Plunian
> Marc Plunian a écrit :
>
>> A part le système hôte pas grand chose. Les logiciels sont installés sur
>> chaque serveur virtuel comme un serveur dédié classique.
>
> C'est faux, ça dépend de la technologie utilisée. Avec Xen,
> effectivement, le système parasite est indépendant de son hôte. Mais
> avec une technologie telle que Virtuozzo, le kernel est commun, ainsi
> qu'un certain nombre de fichiers. Ensuite, ça dépend de si on est sous
> du MS ou autre chose.
>
> Je ne vois aucun intérêt à la virtualisation pour le client. Le
> mutualisé peut être mis en place avec les mêmes restrictions qu'avec la
> virtualisation. C'est une question de paramétrage et de rigueur. C'est
> là qu'est l'intérêt, celui du hosteur en fait : c'est plus simple de
> mettre la responsabilité de la gestion d'un sous-système au client
> plutôt que de se taper la tête à mettre en place des prisons et des
> restrictions dures.
Dans le cas de virtuozzo, je suis bien d'accord que l'on ne peut à
proprement parler de virtualisation mais plutot d'isolation de contexte.
Et je pense que lorsque tu parles de "paramétrage, de rigueur, de
prisons et de restrictions dures" tu te rapproches de ce que propose
Virtuozzo.
ALors Ok, zyva propose comme Virtuozzo un accès root à ton serveur
mutualisé afin que les clients puissent comme Virtuozzo installer leurs
applications et faire tous les paramétrages qu'ils veulent ?
Je préfère utiliser une logiciel certe propriétaire (existe aussi OpenVZ
en OS)qui a fait ses preuves et qui continue d'être développé plutot que
de de faire des "astuces" dans mon coin.
>
> Personnellement, je n'ai jamais vu d'avantages à la virtualisation
> autre que les tests. Et autre que le gâchis de ressources.
>
Gachis de ressources ? La virtualisation ? Alors là je ne comprends pas
mais c'est exactement le contraire : possibilité de mutualiser des
services sur un même serveur physique. Lorsque qu'une entreprise ou un
hébergeur a une infra mutualisé il peut réaliser une cartographie de ses
serveurs et applications et les distribuer uniquement en fonction des
besoins et disponibilités des ressources et non plus en fonction des
compatibilités des systèmes et des logiciels.
Par exemple, des services applicatifs qui sont utilisés en journée et
d'autres uniquement la nuit dans des environnements systèmes
imcompatibles et bien c'est possible de les faire fonctionner surle même
serveur physique avec Xen ou ESX.
J'ai des clients dans plusieurs secteurs et je t'assure qu'ils voient
tous un intérêt à virtualiser, particulièrement dans l'administration
souvent à cause d'éditeurs qui ne garantissent pas leurs applis si elles
sont mutualisées sur un même serveur.
Marc Plunian
Oui c'est possible nous avons déjà fait ça pour faire fonctionner 2
versions de PHP sur un même serveur virtuel mais ça reste du bidouillage
avec les problèmes que cela entraine par la suite avec les développeurs
qui ne savent plus quelle version utiliser.
Mihamina Rakotomandimby
> Il y a des infogérances à 300,00 €, nous avons une prestation dans ma
> boite pour ça mais à ce prix là on a un serveur de spare immédiatement
> disponible, les patchs systèmes/sécurité, rotation de logs,supervision
> du serveru, reboot du serveur et des services, l'installation de
> nouveaux logiciels à la demande du client,la gestion des droits et
> permissions ....
Oui, mais est-ce que beaucoup de clients sont demandeur de cela?
>> Prenons un serveur milieu de gamme de chez OVH, 80EUR/mois.
>> Quelles prestations d'infogerance tu veux effectuer pour 80EUR/mois?
> Voir plus haut.
Ouais... tant mieux si tu y arrives.
Frederic G. MARAND
courriel d'offre de votre société.
Si vous souhaitez faire une offre, mieux vaut poursuivre en courrier privé:
ceci concerne relativement peu f.r.i.h.
"Christophe Baegert" <cbaegert-p...@lixium.fr> a écrit dans le
message de news: 4760b8b4$0$20719$426a...@news.free.fr...
Christophe Baegert
> Oui c'est possible nous avons déjà fait ça pour faire fonctionner 2
> versions de PHP sur un même serveur virtuel mais ça reste du bidouillage
> avec les problèmes que cela entraine par la suite avec les développeurs
> qui ne savent plus quelle version utiliser.
A chacun ses responsabilités, on ne peut pas demander une version
personnalisée de PHP et dire ensuite qu'on ne s'y retrouve pas ;-)
Lionel
> Un client n'est pas pret à payer de l'infogerance à 300EUR/mois pour
> un serveur à 59EUR/mois.
Je confirme.
Je paye 100euros/mois d'infogérence pour un dédié à 200euros/mois.
Depuis 3 ans, je n'ai jamais appelé le hotline, personne n'est jamais
intervenu sur mon serveur (hormis moi), et je n'ai jamais eu de coupure de
plus de 5minutes.
Je ne vois pas pourquoi payer plus cher un service que je n'utilise pas.
Et en cas de souci, je ne suis pas sur que cette infogérence me soit d'une
grande utilité...
Sans parler de l'ajout d'application: pour une install de postgresql avec
install par défaut, soit 10min, j'ai reçu un devis de 90euros.
Je préfèrerais largement investir ces 100euros dans du matériel plus
performant.
Quand je vois les offres OVH, pour 2 fois moins cher j'ai un serveur
nettement plus performant....c'est forcément tentant.
Je reste chez mon hébergeur car la tranquillité n'a pas de prix.
Mais si j'avais confiance en OVH et étais certain d'avoir aussi peu de
soucis, je n'hésiterais pas.
> Prenons un serveur milieu de gamme de chez OVH, 80EUR/mois.
> Quelles prestations d'infogerance tu veux effectuer pour 80EUR/mois?
Qu'est-on en droit d'attendre pour 100euros/mois ?
Christophe Baegert
> Je paye 100euros/mois d'infogérence pour un dédié à 200euros/mois.
> Depuis 3 ans, je n'ai jamais appelé le hotline, personne n'est jamais
> intervenu sur mon serveur (hormis moi)
Une vraie infogérance, c'est quand le client n'a pas le mot de passe root.
Cornelia Schneider
news:476670ea$0$2166$426a...@news.free.fr:
> Une vraie infogérance, c'est quand le client n'a pas le mot de passe
> root.
Donc je ne signerai jamais une formule infogérance... Pas confiance à ce
point-là.
Cornelia *per aspera ad astra*
--
Be out and be proud - today is the first day of the rest of your life
Support Transgenre Strasbourg : http://www.sts67.org
BoW : http://www.bownbend.com
GPG key ID 83FF7452, 659C 2B9F 7FD5 5C25 8C30 E723 4423 F8B8 83FF 7452
Stephane Kanschine
> Marc Plunian wrote:
>> Je ne vois pas en quoi le fait que l'infogérance serait 3 à 4 fois le
>> prix du serveur ne serait pas viable commercialement ??
>
> Un client n'est pas pret à payer de l'infogerance à 300EUR/mois pour un
> serveur à 59EUR/mois. Si tu as des exemples qui infirment ce que je dis,
> alors je suis preneur, parceque sur les données que j'ai, c'est la
> conclusion que je peux tirer.
Il est peut être pas prêt à payer les prestations humaines qui vont
avec les prestations techniques. c'est à toi de lui expliquer, de le
convaincre. Le métier de commercial n'existerait pas si on s'arrêtait
à ce que les gens sont prêts à payer :-)
Ceux qui ne veulent toujours pas iront pleurer dans la boîte de
mouchoirs que tu leur as offert le jour où ils ont dit non.
--
Stephane Kanschine
Association APINC : http://www.apinc.org/
Christophe Baegert
> Donc je ne signerai jamais une formule infogérance... Pas confiance à ce
> point-là.
Vous avez bien raison, il vous faut un dédié dans ce cas, parce que si vous
voulez gérer une machine dont vous avez confié la gestion à quelqu'un
d'autre, ça va forcément mal finir ;-)
Cornelia Schneider
> Vous avez bien raison, il vous faut un dédié dans ce cas, parce que si
> vous voulez gérer une machine dont vous avez confié la gestion à
> quelqu'un d'autre, ça va forcément mal finir ;-)
Bé oui. J'ai un VPS avec accès root, justement. (le dédié non-virtuel ne
jsutifie actuellemnt pas son coût dans mo cas, sinon j'en aurais un)
Cornelia
Marc Plunian
Cela représente 1 heure à 1 heure 30 d'intervention par mois
installation, gestion des droits, rotation des fichiers de logs, AMJ
sécurité ..... Soit 3 interventions de 30 minutes (on ne peut pas
décompter à la minute pres) par mois). Et pour ce prix là, tu es en
droit d'attendre que la personne qui intervient soit un administrateur
système et réseau confirmé pas un hotliner de base.
Si tu n'as jamais demandé d'intervention en 3 ans, tu aurais pu négocié
l'installation de PostgrSQL gratos sur ton serveur. Mieux ton hébergeur
aurait du te le proposer.
Marc Plunian
> Christophe Baegert <cbaegert-p...@lixium.fr> wrote in
> news:476670ea$0$2166$426a...@news.free.fr:
>
>> Une vraie infogérance, c'est quand le client n'a pas le mot de passe
>> root.
>
> Donc je ne signerai jamais une formule infogérance... Pas confiance à ce
> point-là.
>
> Cornelia *per aspera ad astra*
>
responsabilité. Si j'infogère le serveur d'un client, je conserve le
compte root et je ne le partage pas avec lui, cela ne l'empêche pas
d'avoir un compte avec des droits élargis qui lui permettent de faire
pas mal de choses mais pas toutes.
Lionel
> 100 € ttc ?
> Cela représente 1 heure à 1 heure 30 d'intervention par mois
> installation, gestion des droits, rotation des fichiers de logs, AMJ
> sécurité ..... Soit 3 interventions de 30 minutes (on ne peut pas
> décompter à la minute pres) par mois). Et pour ce prix là, tu es en
> droit d'attendre que la personne qui intervient soit un administrateur
> système et réseau confirmé pas un hotliner de base.
ok
> Si tu n'as jamais demandé d'intervention en 3 ans, tu aurais pu
> négocié l'installation de PostgrSQL gratos sur ton serveur. Mieux ton
> hébergeur aurait du te le proposer.
J'ai hésité, mais rédiger le mail et attendre la réponse aurait pris plus de
temps que de l'installer moi meme...
Cornelia Schneider
@biggoron.nerim.net:
> Je ne pense pas que ce soit une question de confiance mais plutot de
> responsabilité. Si j'infogère le serveur d'un client, je conserve le
> compte root et je ne le partage pas avec lui, cela ne l'empêche pas
> d'avoir un compte avec des droits élargis qui lui permettent de faire
> pas mal de choses mais pas toutes.
Pour ma part, ce qui m'intéresse dans un VPS ou dédié, c'est justement
d'avoir la main et la responsabilité. Donc infogérance bof pour mes
besoins.
Cornelia
GPLHost (thomas)
> Sur un SAN évidemment.
>
> Faire de la machine virtuelle sur un simple PC puissant, c'est faisable,
> mais quand on veut faire ça professionnellement, on externalise le
> stockage des machines virtuelles, on ne se contente pas d'utiliser les
> disques internes à la machine...
>
> Là où je bosse, on utilise un bladecenter & un san ibm. Il suffit de
> quelques secondes pour déplacer une machine d'une lame vers une autre.
Non. Ce que tu dis s'applique peut-être à une grande entreprise qui ne
sait quoi faire de son argent, mais lorsqu'on fait de l'hébergement, et
vu le marcher actuel, on investi pas dans du IBM, des gros SAN ou autre.
De plus, j'aimerais qu'on me prouve qu'un SAN IBM en RAID5 relié en
Gigabit donne des performances plus attractive qu'un simple accès en
SATA2. A mon avis, on gagne par grand chose, spécialement si beaucoup de
machine accède au meme disque dans le SAN.
Utiliser de petits serveurs indépendants est une très bonne technique
qui a fait ses preuves.
De plus, je ne pense pas que le fait de pouvoir déplacer un VPS d'une
machine a l'autre (migration live) soit le point le plus attractif d'un
VPS. Certe, c'est très pratique, mais en "conditions normal" il n'y a
quand même pas tant de plantage que ça. La plus part des plantages sont
à cause des disques durs, et le problème arrive aussi avec un SAN (oui,
je parle bien de casser PLUSIEURS disques en MEME TEMPS...).
Thomas
GPLHost (thomas)
> Au final, hormis les cas de virtualisation basé sur un
> SAN dans un contexte grand compte ou pour faire tourner autre chose que le
> classique linux-apache-mysql-php, l'intérêt d'un dédié virtuel est faible
> AMHA.
L'intéret est énorme. Il n'y a pas que linux-apache-mysql-php a
héberger. Je te donnes des exemples:
- asterisk (et plus généralement la téléphonie)
- SVN / CVS / Git
- Ruby / Python
Tous ces trucs là demande une configuration que t'aura du mal (si ce
n'est pas impossible) à trouver en mutualisé.
Autre avantage, on se retrouve généralement avec un serveur beaucoup
plus puissant qu'un dédié de base pour moins cher (RAID1, proc
multi-core, carte mère de bonne qualité). Mais bon, ça dépend des
hébergeur ça...
Thomas
GPLHost (thomas)
> Pas forcément, puisque par moment vous pourriez avoir 80% d'un bi dual-core,
> d'un quad-core, d'un cluster... C'est tout l'intérêt du mutualisé, ça lisse
> les courbes de charge puisqu'il est rare que tous les hébergés aient leurs
> pics de fréquentation en même temps.
Sauf que si par exemple, l'un des clients à un site très mal programmé
qui lance une grosse query MySQL. Dans ce cas tout le (presque) serveur
est monopolisé. Presque idem lorsqu'une tache lit un gros fichier sur le
disque.
Ce genre de problèmes sont en général mieux géré sur un VPS (ou tout
doit être normalement bien schédulé).
Thomas
GPLHost (thomas)
> Sur un dédié virtuel vous pouvez aussi:
> - Voir la console système du serveur (pratique si plus de reseau, pb de
> fichier manque, etc ...)
> -> pas possible sur un vrai dédié sauf reboot sur un OS de virtualisation
> - Faire une install depuis le CDROM
> -> pas possible sur un vrai dédié car vous n'avez pas accès à la machine
> - Et dans certain cas booter sur une disquette (genre freedos, tomsrtbt)
Bof... Tous nos nouveaux serveurs dédiés sont maintenant équipé d'une
carte KVM over IP & virtual media over LAN, donc ça compte pas...
> Et comme sur un vrai dédié, vous pouvez:
> - Booter en rescue sur un mini OS
> - avoir jusqu'à 4 disques dur
> - gérer vos propres partition
> - faire du RAID soft entre disque dur (même si le serveur hôte est déjà
> en RAID hard)
> - faire du LVM sur les disques dur
Ca dépend des hébergeurs ça, je dirais. Chez nous c'est pas possible de
booter sur un CD par exemple (mais nos clients peuvent réinstaller l'OS
qu'ils veulent a volonté). Je pense que dans le cadre d'un virtuel,
utiliser 4 disques, faire du RAID ou du LVM (and la machine virtuel) est
totalement inutile car tout ça est déjà fait au niveau du serveur
hébergeant les VPS.
Thomas
GPLHost (thomas)
> avec parfois quelques arrachages de cheveux sur du virtuôzozo and co,
> à moins que j'ai loupé une marche.
Celle de Xen? :)
Thomas
GPLHost (thomas)
> Essaye d'avoir une version de PHP ou de MySQL spécifique par exemple
> pour unsite déjà développé sur un mutualisé ? Ce ne sera pas possible.
C'est possible si tu utilise PHP en cgi-bin, et que tu utilise sbox par
exemple en cgi-wrapper pour faier un chroot des cgi-bin. Ca marche très
bien.
Thomas
GPLHost (thomas)
> C'est possible, à condition d'utiliser PHP en CGI. C'est d'ailleurs
> une voie que j'explore actuellement pour créer mes offres. On verra ce
> que ça donne.
Essaye sbox et dit moi ce que t'en pense alors! (dispo dans la Debian
etch, SID et Lenny, et aussi dans FreeBSD).
Thomas
GPLHost (thomas)
> Je ne vois aucun intérêt à la virtualisation pour le client. Le
> mutualisé peut être mis en place avec les mêmes restrictions qu'avec la
> virtualisation.
Non. En mutualisé, tu n'a pas une iptables par client, un apache avec
des modules spécifique, etc. Il ne s'agit pas uniquement de
"restriction" mais plustot de souplesse que tu n'auras jamais en mutu.
> Personnellement, je n'ai jamais vu d'avantages à la virtualisation
> autre que les tests. Et autre que le gâchis de ressources.
Révise ta copie alors. Tout d'abord, ajouter une "couche xen" ne prend
pas plus de 5% du temps machine en plus dans le pire de cas (cherche des
bench sur google si tu ne me crois pas). Au contraire, lorsqu'on avait
besoin de 5 serveurs dédiés, pour 5 clients, on peut maintenant utiliser
un seule serveur virtualisé. Donc les ressources sont au contraire
économisé. Les serveurs virtualisés sont plus rentable pour l'hébergeur,
pratique (plus que du mutu car on y fait ce qu'on veut) et économique
(moins cher qu'un dédié) pour les clients. Brefs que des avantages.
La virtualisation n'est PLUS le future du hosting, elle EST le hosting.
Les clients en dédié (sauf ceux qui consomme vraiment beaucoup de
ressources) et en mutu, pour ma part, se font de plus en plus rare,
alors que c'est plutot l'inverse pour les clients Xen, au fur et a
mesure que les clients comprennent a quoi ça sert et pourquoi c'est bien...
Thomas Goirand, GPLHost CEO
Christophe Baegert
> La virtualisation n'est PLUS le future du hosting, elle EST le hosting.
> Les clients en dédié (sauf ceux qui consomme vraiment beaucoup de
> ressources) et en mutu, pour ma part, se font de plus en plus rare,
> alors que c'est plutot l'inverse pour les clients Xen, au fur et a
> mesure que les clients comprennent a quoi ça sert et pourquoi c'est
> bien...
C'est peut être que vous êtes plus forts sur le virtuel que sur le mutu. Moi
je n'ai jamais eu UN SEUL client qui m'a demandé un virtualisé. Le client à
qui on ne peut pas répondre avec un mutu, c'est qu'il lui faut un dédié, et
encore un costaud, car un dédié low-cost ne tiendrait pas le coup.
FiLH
Et quel est la perte de perf ? J'ai testé des php en cgi-bin qui m'ont
donné des temps de réponse x5 par rapport à du php en module...
FiLH
--
Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire
une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle.
Roland Barthes.
http://www.filh.org
Christophe Baegert
> Et quel est la perte de perf ? J'ai testé des php en cgi-bin qui m'ont
> donné des temps de réponse x5 par rapport à du php en module...
Notre install de PHP est différenciable pour chaque client, et quelques
pourcents plus rapide que le PHP en module. Quant à la sécurité du PHP en
module... c'est utilisable uniquement en dédié à mon avis tellement c'est
une passoire.
FiLH
> FiLH wrote:
> > Et quel est la perte de perf ? J'ai testé des php en cgi-bin qui m'ont
> > donné des temps de réponse x5 par rapport à du php en module...
>
> Notre install de PHP est différenciable pour chaque client, et quelques
> pourcents plus rapide que le PHP en module.
Hum... moi j'étais 5 fois plus lent, mais bon en mode setuid (oups j'ai
perdu le nom du module qui fait ça): à chaque invocation on rechargeait
le binaire php... et comme on a beaucoup de modules...
>Quant à la sécurité du PHP en
> module... c'est utilisable uniquement en dédié à mon avis tellement c'est
> une passoire.
Il faut la travailler beaucoup effectivement... :)
Et chez nous c'est encore pire que du mutualisé...
Christophe Baegert
> Hum... moi j'étais 5 fois plus lent, mais bon en mode setuid (oups j'ai
> perdu le nom du module qui fait ça): à chaque invocation on rechargeait
> le binaire php... et comme on a beaucoup de modules...
On est en setuid aussi, mais on triche, on est en fait en FastCGI, du coup
c'est à la fois plus rapide, plus pratique et plus sûr qu'en module (bon en
plus d'être super pointu à gérer au début, ça bouffe un peu de RAM... voilà
une partie de l'explication pour ceux qui ne comprennent pas pourquoi on
est 4 fois plus cher que les discounts)
Par contre ce qui m'a très étonné, c'est que le PHP-CGI n'est pas 5 fois
plus lent que le module au lancement, mais à l'exécution, alors que le
FastCGI qui est sensé réduire le temps de lancement permet en réalité
d'exploser les perfs en exécution... Cherchez l'erreur !
FiLH
> FiLH wrote:
> > Hum... moi j'étais 5 fois plus lent, mais bon en mode setuid (oups j'ai
> > perdu le nom du module qui fait ça): à chaque invocation on rechargeait
> > le binaire php... et comme on a beaucoup de modules...
>
> On est en setuid aussi, mais on triche, on est en fait en FastCGI, du coup
> c'est à la fois plus rapide, plus pratique et plus sûr qu'en module (bon en
> plus d'être super pointu à gérer au début, ça bouffe un peu de RAM... voilà
> une partie de l'explication pour ceux qui ne comprennent pas pourquoi on
> est 4 fois plus cher que les discounts)
J'ai retrouvé c'est suphp... hum... le fastCGI c'est le binaire qui
reste chargé et on lui envoit les données si je me souviens bien ?
Le pb est qu'on a 1300 utilisateurs potentiels de la chose, et il me
semblait dans ce cas là qu'il fallait un php par uid. Ce qui n'est pas
raisonnable (bon si on pouvait gérer un truc genre lancer le binaire
pour un utilisateur et le laisser... un certain temps).
> Par contre ce qui m'a très étonné, c'est que le PHP-CGI n'est pas 5 fois
> plus lent que le module au lancement, mais à l'exécution, alors que le
> FastCGI qui est sensé réduire le temps de lancement permet en réalité
> d'exploser les perfs en exécution... Cherchez l'erreur !
Exploser = amméliorer ?
Hum... votre config m'intéresse :) :)... bon nous on est sous Solaris
hein, mais on doit pouvoir jouer...
Ceci dit j'ai noté une énnorme différence de pref suivant qu'on prend un
php avec trois modules ou si on ajoute un peu tout (notamment tous les
modules attaquant divers types de bdd).
ol...@ovh.net
> De plus, j'aimerais qu'on me prouve qu'un SAN IBM en RAID5 relié en
> Gigabit donne des performances plus attractive qu'un simple accès en
> SATA2. A mon avis, on gagne par grand chose, spécialement si beaucoup de
> machine accède au meme disque dans le SAN.
Bonjour,
Bonne Année ;)
Ce n'est pas difficile à prouver. L'avantage d'un SAN par rapport
à un simple disque est le nombre d'IO par seconde. Tu peux faire
énormement d'opérations sur les fichiers et le SAN bats un disque
plusieurs fois. C'est notament très interessant lorsque tu as beaucoup
de fichiers, genre les serveurs d'emails, beaucoup d'écriture, beaucoup
de lectures, des rename, des moves etc. L'avantage de SAN diminue
lorsque tu as beaucoup d'acceder aux peu et gros fichiers. Genre un
serveur de VOD. Et on n'a parlé que des performances. Pour les preuves
il suffit de parler avec ceux qui testent nos RPS et les comparents
aux serveurs dédiés standard. En vitesse de pointe le disque bat un
iSCSI. Lorsque tu fais un tar xf xx.tar avec plein de petits fichiers
iSCSI bat un disque.
Amicalement
Octave
ol...@ovh.net
> On 2008-01-02, ol...@ovh.net <ol...@ovh.net> wrote:
>> En vitesse de pointe le disque bat un
>> iSCSI. Lorsque tu fais un tar xf xx.tar avec plein de petits fichiers
>> iSCSI bat un disque.
>
> chose, chacun sur « leur » disque ?
la question posée était: prouvez moi que le SAN est plus rapide que
le disque dur. comme j'avais dit ça depend de besoins et de l'utilisation.
il y a du pour et du contre. si la question est maintenant: comment se
fait la mutualisation d'un SAN et comment se fait la garantie de
performance sur un SAN, c'est une autre problematique à laquelle je
n'ai pas toutes les reponses (une bonne partie je l'ai déjà mais pas
toutes les reponses). C'est pourquoi on a lancé une beta. en gros,
il faut qu'on teste avec des vrais clients les differents manieres
de mutualisation de resources d'un SAN. En suite, je pourrai eventuellement
repondre à cette question de maniere precise (enfin je prefere que
nos clients repondent à notre place, c'est plus precis comme le feedback).