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.
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.
> 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.
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".
> 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 ?
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.
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
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.
> 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é.
Voilà.
Ceci dit, la plupart des hébergeurs proposant du dédié et du dédié
virtuel proposent également de l'infogérance.
Ca depend surement des offres. Sur certaines il est possible que
certaines parties du système soient partagées entre toutes les machines
virtuelles.
Oui, avec un san totalement redondant ca le fait bien. Mais à quel prix...
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.
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
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,...
> 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.
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
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.
> 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.
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.
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).
Et encore moins cher de prendre un mutualisé ;-)
Ce genre de choses est possible egalement sur certains dediés.
>> , 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é).
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.
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.
> 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
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.
[...]
> 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.
Dans quel post ?
alias :
"Christophe Baegert" <cbaegert-p...@lixium.fr> a écrit dans le
message de news: 4760580c$0$11658$426a...@news.free.fr...
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
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.
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 !
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 !
C'est pas une question d'hebergeur, sur n'importe quel mutualisé il y
a un risque.
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, ...
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
> 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
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.
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 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 ;-)
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.
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.
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.
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...
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 ;-)
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 ?
Une vraie infogérance, c'est quand le client n'a pas le mot de passe root.
> 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
> 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/
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 ;-)
> 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
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.
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...
> 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
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
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
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
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
Celle de Xen? :)
Thomas
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
Essaye sbox et dit moi ce que t'en pense alors! (dispo dans la Debian
etch, SID et Lenny, et aussi dans FreeBSD).
Thomas
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
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.
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
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 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é...
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 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).
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
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).