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é ?
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...
Marc Plunian wrote:
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...
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
Marc Plunian wrote in news:fk8qlp$2cuq$1 @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
-- 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 <marc.plunian@netensia.fr> wrote in news:fk8qlp$2cuq$1
@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
--
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 in news:fk8qlp$2cuq$1 @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
-- 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
GPLHost (thomas)
Franck wrote:
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
Franck wrote:
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...).
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)
Christophe Baegert wrote:
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
Christophe Baegert wrote:
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...
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)
Christophe Baegert wrote:
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
Christophe Baegert wrote:
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é).
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)
wrote:
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
manu157@free.fr wrote:
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.
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)
LJVD wrote:
avec parfois quelques arrachages de cheveux sur du virtuôzozo and co, à moins que j'ai loupé une marche.
Celle de Xen? :)
Thomas
LJVD wrote:
avec parfois quelques arrachages de cheveux sur du virtuôzozo and co,
à moins que j'ai loupé une marche.
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)
Mickaël Wolff wrote:
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
Mickaël Wolff wrote:
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).
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)
Mickaël Wolff wrote:
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
Mickaël Wolff wrote:
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...
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...
