J'ai plusieurs comptes mutualisés chez différents hébergeurs. J'en ai un
peu marre d'avoir 15 codes partout, des scripts de sauvegarde différents
ect...
Ce sont des petits sites qui, pour la plupart, ne dépassent pas le
millier de visiteurs mensuels.
Donc je regardais du côté des VDS et j'ai vu Yellis, offre de base
128Mo/2,3 Go Debian (Trafic maxi théorique 81 Go).
Que pensez vous de ces offres ? Qu'elle charge peux supporter ce genre
de machin/vds ?
Je gère par ailleurs un serveur sous Debian sans problème pour
l'administration.
De plus fait bien attention, tu compare 30 euros HT avec 30 USD (toutes taxes comprises puisqu'il n'y a pas de TVA sur les services internet aux US). 30 euros HT correspondent a 43 USD TTC en gros, ce qui n'es pas le meme prix du coup.
Ah bon ? alors les BRCI seront contentes de l'apprendre. (Vous seriez gerant d'une societe on pourrait etre inquiet.)
De plus fait bien attention, tu compare 30 euros HT avec 30 USD (toutes
taxes comprises puisqu'il n'y a pas de TVA sur les services internet aux
US). 30 euros HT correspondent a 43 USD TTC en gros, ce qui n'es pas le
meme prix du coup.
Ah bon ? alors les BRCI seront contentes de l'apprendre.
(Vous seriez gerant d'une societe on pourrait etre inquiet.)
De plus fait bien attention, tu compare 30 euros HT avec 30 USD (toutes taxes comprises puisqu'il n'y a pas de TVA sur les services internet aux US). 30 euros HT correspondent a 43 USD TTC en gros, ce qui n'es pas le meme prix du coup.
Ah bon ? alors les BRCI seront contentes de l'apprendre. (Vous seriez gerant d'une societe on pourrait etre inquiet.)
GPLHost
manu wrote:
"Frédéric VANNIÈRE" a écrit dans le message de news: 43d497aa$0$24480$
Bonjour,
Yellis utilise UML, cette technologie n'est vraiment pas adaptée à l'hébergement, il y a beaucoup trop de perte de puissance avec la virtualisation.
UML fonctionne très bien (avec le patch SKAS3 et les UMLs ne tourne pas en SKAS0...heureusement), il est aussi évident que sur les serveurs hôtes il n'y a pas du PIII... Actuellement, c'est des P4 630 HT 3.0Ghz EMT64 avec 12 utilisateurs max sur la même machine.
La puissance du processeur ne change rien au problème, les performances de Xen sont meilleurs que celles de UML, virgule, la preuve (point):
La perte de gain dû à UML (exclusivement CPU, pas en HDD) est compensé par le nombres d'utilisateurs simultanés.
Les process d'un serveur virtuel UML sont en fait des process d'un kernel parent. Ca se voit meme dans un top...
Le principale problème n'est en fait PAS la perte de CPU (de 3 à 8% pour xen, et jusqu'a 30 ou 40% pour UML), le plus importance c'est la latence. Rien a faire de transférer à 38,8 GB/s au lieu de 43, non ce qui compte c'est que Xen comprend le fait qu'il faut garder de la bande passante disque dure pour les autres serveur virtuels, et ça UML ne sait pas le faire.
De plus, Xen gère lui-meme un arbre PMMU pour toutes les machines virtuels et est capable de le changer a la voler. Les espaces mémoire sont distinct totalement, et on ne peut pas faire de "burst".
Dès qu'une machine virtuelle UML prend tout le CPU et tout le serveur souffre, avec Xen c'est nettement plus supportable, surtout si on a bien mis les options bvt qu'il faut.
L'offre semble adapté à la plupart des utilisateurs, il n'y a que très peut de "perte".
UML est dépassé quelque soit le client, AMIA...
solution semble au point (il faut aussi noter que le "principe" de fonctionnement "paravirtualisation" est le même que Xen)
Oui et non, Xen apporte quand meme de nouveaux concept, notamment le gestionnaire de mémoire qui n'a rien a voire, et une gestion de la répartition CPU/io/network avancé, pour moi c'est le jour et la nuit.
Xen parallélise avant le kernel, domain0 = machine virtuel, domain1 = machine virtuel., domainX = machine virtuel. UML parallélise (avec le patch SKAS3) après le kernel, domain0= machine réel, domain1 = machine virtuel., domainX = machine virtuel.
Une machine virtuel sous UML est un process dans le kernel principal, alors que sous xen le kernel principale est uniquement responsable de la gestion des drivers physique (le reste étant pris en charge par xen).
Et pour faire tourner du Linux sur du Linux, UML suffit. A moins que vous ne souhaitiez faire tourner du Microsoft sous Xen (via qemu)
Emmanuel.
UML ne suffit plus, il est dépassé par Xen, quelle que soit la situation, et certainement pour tout ce qui est hosting (sauf pour du développement kernel peut-etre). Quand a la possibilité de faire tourner du Microsoft sous Xen, ce n'est pour le moment possible qu'en payant (très) cher car seul les tous nouveaux processeur (les dual core par exemple) sont équipé du jeux d'instruction VT nécessaire, et c'est a mon avis encore trop cher pour de la revente pour les gens qui écrive ici...
Thomas
manu wrote:
"Frédéric VANNIÈRE" <f.vanniere@planet-work.com> a écrit dans le message de
news: 43d497aa$0$24480$636a15ce@news.free.fr...
Bonjour,
Yellis utilise UML, cette technologie n'est vraiment pas adaptée
à l'hébergement, il y a beaucoup trop de perte de puissance avec la
virtualisation.
UML fonctionne très bien (avec le patch SKAS3 et les UMLs ne tourne pas en
SKAS0...heureusement), il est aussi évident que sur les serveurs hôtes il
n'y a pas du PIII...
Actuellement, c'est des P4 630 HT 3.0Ghz EMT64 avec 12 utilisateurs max sur
la même machine.
La puissance du processeur ne change rien au problème, les performances
de Xen sont meilleurs que celles de UML, virgule, la preuve (point):
La perte de gain dû à UML (exclusivement CPU, pas en HDD) est compensé par
le nombres d'utilisateurs simultanés.
Les process d'un serveur virtuel UML sont en fait des process d'un
kernel parent. Ca se voit meme dans un top...
Le principale problème n'est en fait PAS la perte de CPU (de 3 à 8% pour
xen, et jusqu'a 30 ou 40% pour UML), le plus importance c'est la
latence. Rien a faire de transférer à 38,8 GB/s au lieu de 43, non ce
qui compte c'est que Xen comprend le fait qu'il faut garder de la bande
passante disque dure pour les autres serveur virtuels, et ça UML ne sait
pas le faire.
De plus, Xen gère lui-meme un arbre PMMU pour toutes les machines
virtuels et est capable de le changer a la voler. Les espaces mémoire
sont distinct totalement, et on ne peut pas faire de "burst".
Dès qu'une machine virtuelle UML prend tout le CPU et tout le serveur
souffre, avec Xen c'est nettement plus supportable, surtout si on a bien
mis les options bvt qu'il faut.
L'offre semble adapté à la plupart des utilisateurs, il n'y a que très peut
de "perte".
UML est dépassé quelque soit le client, AMIA...
solution semble au point (il faut aussi noter que le "principe" de
fonctionnement "paravirtualisation" est le même que Xen)
Oui et non, Xen apporte quand meme de nouveaux concept, notamment le
gestionnaire de mémoire qui n'a rien a voire, et une gestion de la
répartition CPU/io/network avancé, pour moi c'est le jour et la nuit.
Xen parallélise avant le kernel, domain0 = machine virtuel, domain1 =
machine virtuel., domainX = machine virtuel.
UML parallélise (avec le patch SKAS3) après le kernel, domain0= machine
réel, domain1 = machine virtuel., domainX = machine virtuel.
Une machine virtuel sous UML est un process dans le kernel principal,
alors que sous xen le kernel principale est uniquement responsable de la
gestion des drivers physique (le reste étant pris en charge par xen).
Et pour faire tourner du Linux sur du Linux, UML suffit.
A moins que vous ne souhaitiez faire tourner du Microsoft sous Xen (via
qemu)
Emmanuel.
UML ne suffit plus, il est dépassé par Xen, quelle que soit la
situation, et certainement pour tout ce qui est hosting (sauf pour du
développement kernel peut-etre). Quand a la possibilité de faire tourner
du Microsoft sous Xen, ce n'est pour le moment possible qu'en payant
(très) cher car seul les tous nouveaux processeur (les dual core par
exemple) sont équipé du jeux d'instruction VT nécessaire, et c'est a mon
avis encore trop cher pour de la revente pour les gens qui écrive ici...
"Frédéric VANNIÈRE" a écrit dans le message de news: 43d497aa$0$24480$
Bonjour,
Yellis utilise UML, cette technologie n'est vraiment pas adaptée à l'hébergement, il y a beaucoup trop de perte de puissance avec la virtualisation.
UML fonctionne très bien (avec le patch SKAS3 et les UMLs ne tourne pas en SKAS0...heureusement), il est aussi évident que sur les serveurs hôtes il n'y a pas du PIII... Actuellement, c'est des P4 630 HT 3.0Ghz EMT64 avec 12 utilisateurs max sur la même machine.
La puissance du processeur ne change rien au problème, les performances de Xen sont meilleurs que celles de UML, virgule, la preuve (point):
La perte de gain dû à UML (exclusivement CPU, pas en HDD) est compensé par le nombres d'utilisateurs simultanés.
Les process d'un serveur virtuel UML sont en fait des process d'un kernel parent. Ca se voit meme dans un top...
Le principale problème n'est en fait PAS la perte de CPU (de 3 à 8% pour xen, et jusqu'a 30 ou 40% pour UML), le plus importance c'est la latence. Rien a faire de transférer à 38,8 GB/s au lieu de 43, non ce qui compte c'est que Xen comprend le fait qu'il faut garder de la bande passante disque dure pour les autres serveur virtuels, et ça UML ne sait pas le faire.
De plus, Xen gère lui-meme un arbre PMMU pour toutes les machines virtuels et est capable de le changer a la voler. Les espaces mémoire sont distinct totalement, et on ne peut pas faire de "burst".
Dès qu'une machine virtuelle UML prend tout le CPU et tout le serveur souffre, avec Xen c'est nettement plus supportable, surtout si on a bien mis les options bvt qu'il faut.
L'offre semble adapté à la plupart des utilisateurs, il n'y a que très peut de "perte".
UML est dépassé quelque soit le client, AMIA...
solution semble au point (il faut aussi noter que le "principe" de fonctionnement "paravirtualisation" est le même que Xen)
Oui et non, Xen apporte quand meme de nouveaux concept, notamment le gestionnaire de mémoire qui n'a rien a voire, et une gestion de la répartition CPU/io/network avancé, pour moi c'est le jour et la nuit.
Xen parallélise avant le kernel, domain0 = machine virtuel, domain1 = machine virtuel., domainX = machine virtuel. UML parallélise (avec le patch SKAS3) après le kernel, domain0= machine réel, domain1 = machine virtuel., domainX = machine virtuel.
Une machine virtuel sous UML est un process dans le kernel principal, alors que sous xen le kernel principale est uniquement responsable de la gestion des drivers physique (le reste étant pris en charge par xen).
Et pour faire tourner du Linux sur du Linux, UML suffit. A moins que vous ne souhaitiez faire tourner du Microsoft sous Xen (via qemu)
Emmanuel.
UML ne suffit plus, il est dépassé par Xen, quelle que soit la situation, et certainement pour tout ce qui est hosting (sauf pour du développement kernel peut-etre). Quand a la possibilité de faire tourner du Microsoft sous Xen, ce n'est pour le moment possible qu'en payant (très) cher car seul les tous nouveaux processeur (les dual core par exemple) sont équipé du jeux d'instruction VT nécessaire, et c'est a mon avis encore trop cher pour de la revente pour les gens qui écrive ici...
Thomas
manu
"GPLHost" a écrit dans le message de news: 43d59311$0$25042$
La puissance du processeur ne change rien au problème, les performances de Xen sont meilleurs que celles de UML, virgule, la preuve (point):
http://www.cl.cam.ac.uk/Research/SRG/netos/xen/performance.html Prendre des stats fournies par Xen pour comparer Xen... il y a le même type
de stats pour Virtuozzo fournie par Virtuozzo et même pour Vserver, chacun tire la converture à soit pour dire qu'il est le meilheur. C'est vrai, Xen est un très bon produit, mais pour l'utilisation qui en est faite UML suffit
Les process d'un serveur virtuel UML sont en fait des process d'un kernel parent. Ca se voit meme dans un top... C'est même bien, cela permet de faire du Qos sur les VDS
ce qui compte c'est que Xen comprend le fait qu'il faut garder de la bande passante disque dure pour les autres serveur virtuels, et ça UML ne sait pas le faire. C'est vrai UML ne fait pas cela seul, il suffit donc de mettre un système
d'auto-priorité sur le serveur hôte qui gère cela.
Les espaces mémoire sont distinct totalement, et on ne peut pas faire de "burst". Idem avec UML (SKAS)
la possibiliter de changer la capaciter en dynamique UML n'offre pas cela, mais le quota mémoire n'est pas changé tous les jours
sur un serveur virtuel Changer 1 ligne dans un fichier et faire un reboot du VDS n'est quant même pas la mort.
Dès qu'une machine virtuelle UML prend tout le CPU et tout le serveur souffre, Vous avez dit "perte de CPU: jusqu'a 30 ou 40% pour UML" dans le pire des
cas (sans Qos) l'UML prendra 40% du CPU)
avec Xen c'est nettement plus supportable, surtout si on a bien mis les options bvt qu'il faut. Qos sur serveur hôte.
UML est dépassé quelque soit le client, AMIA... Ce n'est pas vserver ou virtuozzo
Oui et non, Xen apporte quand meme de nouveaux concept, notamment le gestionnaire de mémoire qui n'a rien a voire, et une gestion de la répartition CPU/io/network avancé, pour moi c'est le jour et la nuit. Ce qui n'est pas directement géré par UML, l'est fait par des scripts: il
n'y a que le résultat qui compte.
UML ne suffit plus, il est dépassé par Xen, UML est arrivé à maturitée après des années de develloppment, celui-ci est
même intégré au source du kernel.
Les deux technos sont bonne pour l'utilisation qui en est faite (web)
Emmanuel.
"GPLHost" <nospam@nospam.gplhost.com> a écrit dans le message de news:
43d59311$0$25042$79c14f64@nan-newsreader-07.noos.net...
La puissance du processeur ne change rien au problème, les performances de
Xen sont meilleurs que celles de UML, virgule, la preuve (point):
http://www.cl.cam.ac.uk/Research/SRG/netos/xen/performance.html
Prendre des stats fournies par Xen pour comparer Xen... il y a le même type
de stats pour Virtuozzo fournie par Virtuozzo et même pour Vserver, chacun
tire la converture à soit pour dire qu'il est le meilheur.
C'est vrai, Xen est un très bon produit, mais pour l'utilisation qui en est
faite UML suffit
Les process d'un serveur virtuel UML sont en fait des process d'un kernel
parent. Ca se voit meme dans un top...
C'est même bien, cela permet de faire du Qos sur les VDS
ce qui compte c'est que Xen comprend le fait qu'il faut garder de la bande
passante disque dure pour les autres serveur virtuels, et ça UML ne sait
pas le faire.
C'est vrai UML ne fait pas cela seul, il suffit donc de mettre un système
d'auto-priorité sur le serveur hôte qui gère cela.
Les espaces mémoire sont distinct totalement, et on ne peut pas faire de
"burst".
Idem avec UML (SKAS)
la possibiliter de changer la capaciter en dynamique
UML n'offre pas cela, mais le quota mémoire n'est pas changé tous les jours
sur un serveur virtuel
Changer 1 ligne dans un fichier et faire un reboot du VDS n'est quant même
pas la mort.
Dès qu'une machine virtuelle UML prend tout le CPU et tout le serveur
souffre,
Vous avez dit "perte de CPU: jusqu'a 30 ou 40% pour UML" dans le pire des
cas (sans Qos) l'UML prendra 40% du CPU)
avec Xen c'est nettement plus supportable, surtout si on a bien mis les
options bvt qu'il faut.
Qos sur serveur hôte.
UML est dépassé quelque soit le client, AMIA...
Ce n'est pas vserver ou virtuozzo
Oui et non, Xen apporte quand meme de nouveaux concept, notamment le
gestionnaire de mémoire qui n'a rien a voire, et une gestion de la
répartition CPU/io/network avancé, pour moi c'est le jour et la nuit.
Ce qui n'est pas directement géré par UML, l'est fait par des scripts: il
n'y a que le résultat qui compte.
UML ne suffit plus, il est dépassé par Xen,
UML est arrivé à maturitée après des années de develloppment, celui-ci est
même intégré au source du kernel.
Les deux technos sont bonne pour l'utilisation qui en est faite (web)
"GPLHost" a écrit dans le message de news: 43d59311$0$25042$
La puissance du processeur ne change rien au problème, les performances de Xen sont meilleurs que celles de UML, virgule, la preuve (point):
http://www.cl.cam.ac.uk/Research/SRG/netos/xen/performance.html Prendre des stats fournies par Xen pour comparer Xen... il y a le même type
de stats pour Virtuozzo fournie par Virtuozzo et même pour Vserver, chacun tire la converture à soit pour dire qu'il est le meilheur. C'est vrai, Xen est un très bon produit, mais pour l'utilisation qui en est faite UML suffit
Les process d'un serveur virtuel UML sont en fait des process d'un kernel parent. Ca se voit meme dans un top... C'est même bien, cela permet de faire du Qos sur les VDS
ce qui compte c'est que Xen comprend le fait qu'il faut garder de la bande passante disque dure pour les autres serveur virtuels, et ça UML ne sait pas le faire. C'est vrai UML ne fait pas cela seul, il suffit donc de mettre un système
d'auto-priorité sur le serveur hôte qui gère cela.
Les espaces mémoire sont distinct totalement, et on ne peut pas faire de "burst". Idem avec UML (SKAS)
la possibiliter de changer la capaciter en dynamique UML n'offre pas cela, mais le quota mémoire n'est pas changé tous les jours
sur un serveur virtuel Changer 1 ligne dans un fichier et faire un reboot du VDS n'est quant même pas la mort.
Dès qu'une machine virtuelle UML prend tout le CPU et tout le serveur souffre, Vous avez dit "perte de CPU: jusqu'a 30 ou 40% pour UML" dans le pire des
cas (sans Qos) l'UML prendra 40% du CPU)
avec Xen c'est nettement plus supportable, surtout si on a bien mis les options bvt qu'il faut. Qos sur serveur hôte.
UML est dépassé quelque soit le client, AMIA... Ce n'est pas vserver ou virtuozzo
Oui et non, Xen apporte quand meme de nouveaux concept, notamment le gestionnaire de mémoire qui n'a rien a voire, et une gestion de la répartition CPU/io/network avancé, pour moi c'est le jour et la nuit. Ce qui n'est pas directement géré par UML, l'est fait par des scripts: il
n'y a que le résultat qui compte.
UML ne suffit plus, il est dépassé par Xen, UML est arrivé à maturitée après des années de develloppment, celui-ci est
même intégré au source du kernel.
Les deux technos sont bonne pour l'utilisation qui en est faite (web)
Emmanuel.
manu
"Dominique ROUSSEAU" a écrit dans le message de news:
Vu l'utilisation qui est faite (qui me semble très raisonnable, 12 virtuels par machine telle que décrit), pourquoi ne pas utiliser Xen ? Et pourquoi pas ?
Les deux technos sont bonne pour l'utilisation qui en est faite, il faut bien faire un choix.
Emmanuel.
"Dominique ROUSSEAU" <usenet@leeloo.fdn.fr> a écrit dans le message de news:
slrndtak4o.2ms.usenet@pacoli.in.lee-loo.net...
Vu l'utilisation qui est faite (qui me semble très raisonnable, 12
virtuels par machine telle que décrit), pourquoi ne pas utiliser Xen ?
Et pourquoi pas ?
Les deux technos sont bonne pour l'utilisation qui en est faite, il faut
bien faire un choix.
"Dominique ROUSSEAU" a écrit dans le message de news:
Vu l'utilisation qui est faite (qui me semble très raisonnable, 12 virtuels par machine telle que décrit), pourquoi ne pas utiliser Xen ? Et pourquoi pas ?
Les deux technos sont bonne pour l'utilisation qui en est faite, il faut bien faire un choix.
Emmanuel.
GPLHost
manu wrote:
[ ... ]
Je ne vais pas re cut/past encore et encore, simplement je ne suis pas d'accord.
En effet, on peut faire tout ce que tu dis (script & co, le bridging qu'il faut faire a la main (ou faire du nat), etc.) mais franchement c'est vraiment se faire ch... pour arriver a un résultat approchant.
Dès le début de UML, j'ai testé, re-testé mais certains trucs reste quand meme pas pratique a l'usage. En 2 heures d'utilisation de Xen j'avais totalement oublié UML sans regret, pour moi Xen est un projet tout nouveau qui supplante totalement UML qui du coup prend un sacré coup de vieux.
Thomas
manu wrote:
[ ... ]
Je ne vais pas re cut/past encore et encore, simplement je ne suis pas
d'accord.
En effet, on peut faire tout ce que tu dis (script & co, le bridging
qu'il faut faire a la main (ou faire du nat), etc.) mais franchement
c'est vraiment se faire ch... pour arriver a un résultat approchant.
Dès le début de UML, j'ai testé, re-testé mais certains trucs reste
quand meme pas pratique a l'usage. En 2 heures d'utilisation de Xen
j'avais totalement oublié UML sans regret, pour moi Xen est un projet
tout nouveau qui supplante totalement UML qui du coup prend un sacré
coup de vieux.
Je ne vais pas re cut/past encore et encore, simplement je ne suis pas d'accord.
En effet, on peut faire tout ce que tu dis (script & co, le bridging qu'il faut faire a la main (ou faire du nat), etc.) mais franchement c'est vraiment se faire ch... pour arriver a un résultat approchant.
Dès le début de UML, j'ai testé, re-testé mais certains trucs reste quand meme pas pratique a l'usage. En 2 heures d'utilisation de Xen j'avais totalement oublié UML sans regret, pour moi Xen est un projet tout nouveau qui supplante totalement UML qui du coup prend un sacré coup de vieux.
