![[Home]](http://wiki.linux-vserver.org/skins/common/images/wiki.png)
| For many people, virtual server may look like a great toy: Very high geek coolness factor, but not much. It looks cool, but probably not for everyone. Wroonnnngggggg!!!! |
| Aux yeux de certains, vserver ressemble peut etre a un tres beau jouet: Excellent pour les geek, tres sympa, mais sans doute pas pour tout le monde. Faux! |
| Few specs and some explanations |
| Quelques specifications et explications |
|
1-Virtual servers are running with the same kernel as the host. Performance are exactly the same as a non virtual server (unlike other VM solutions).
2-Virtual servers have no overhead. There is no special daemons running. A vserver running crond,sshd,httpd and sendmail uses the same resources as a normal linux server. 3-Virtual servers generally share the disk space with the host, so there is no need to pre-allocate disk space for each vserver only to find out later that your disk is full, yet each vserver is only using of tiny portion of their allocated space. 4-A second vserver generally cost 40-100 megs of disk space only. It shares most of the binaries and libraries with the first one. Most of this space is a copy of the RPM database. 5-Vservers are updated independantly even if they share binaries with other vservers. 6-32 bits distributions vservers runs normally on a 64bits linux host, but faster, sometime a lot. 7-You can mix various distributions on the same server all runing at once. http://www.solucorp.qc.ca is a rh7.3 vserver running on a rh7.3 server. We also run FC3 vservers as well as Debian vservers on the same box (A Celeron 500mhz btw). 8-Admin tools work inside a vserver as usual. 9-A cracked vserver can't reach the host server. The host server may be used to investigate safely the cracked server (and fix it), something almost impossible with a typical linux installation. |
|
1-Un ensemble de vservers travaillent a l'aide un seul et meme noyau, celui de l'hote. Les performances sont exactement identiques a celles d'un hote traditionnel. (contrairement aux autres solutions a base de Machines Virtuelles (VM) ).
2-Les vserver n'engendrent pas de cout de traitement supplementaire. Aucun demon ne tourne. Un vserver fait tourner par exemple crond, sshd, httpd et utilise les memes ressources qu'un serveur linux traditionnel. 3-Les vserver partagent en general le meme espace disque que la machine hote, il n'y a donc aucun besoin d'allouer de l'espace a chacun d'entre eux, pour s'apercevoir ensuite que votre disque est plein. Chaque vserver utilise la portion d'espace qui lui est alloue. 4-Un vserver supplementaire coute seulement 40 a 100Mo d'espace disque supplementaire. Il partage les binaires et les bibliotheques du premier vserver. Une grande partie de l'espace occupe est constitue par la copie de la base de paquets RPM. 5-Les vservers sont mis a jour independemment meme s'ils partagent leurs binaires avec d'autres vservers. 6-Les vservers sur distributions 32bits tournent normalement sur un hote en 64bits, parfois plus rapidement, voire meme extremement. 7-Vous pouvez melanger plusieurs distributions de linux sur un meme serveur hote, et les faire fonctionner en parallele. http://www.solucorp.qc.ca est un serveur rh7.3 tournant dans un hote rh7.3 . Nous avons aussi des vserver en FC3, tout autant que des Debian sur la meme machine physique (Pour info, ce n'est qu'un Celeron 500MHz). 8- Vos outils d'administration tournent dans un vserver tout a fait comme d'habitude. 9-A cracked vserver can't reach the host server. The host server may be used to safely investigate the cracked server (and fix it), something almost impossible with a typical linux installation. |
| Believe me this will change a lot and you will never look back. Here are some ideas |
| Believe me this will change a lot, but once you figure it out you will never look back. Here are some ideas |
| As the hardware evolves, it is tempting to put more and more tasks on a server. Linux can handle it. Linux is reliable and so on. At some point, you end up with so much stuff and so much people fiddling in the same box that you start fearing whenever you wish to update something. |
| As the hardware evolves, it is tempting to put more and more tasks on a server. Linux can handle it. Linux is reliable and so on. At some point, you end up with so much stuff and so much people fiddling in the same box that you worry about updating things. |
| Vservers are fixing this. The same box runs multiple vservers and each one does the job it is supposed to do. If you need to upgrade to php5 for a given project you do so and only this project is affected. |
| Vservers address this. The same box runs multiple vservers and each one does the job it is supposed to do. If you need to upgrade to php5 for a given project you do so and only this project is affected. |
|
**To make it worst, it works fine on the development machine.
**Now it is 2 am and this has to work by 8am. Hum. (A famous french song: Je m'arrete ou je continue) Should I stop and restore the tape or I hang on and hope to find the problem... |
|
**To make it worse, it works fine on the development machine.
**Now it is 2 am and this has to work by 8am. Hum. (A famous french song: Je m'arrete ou je continue) Should I stop and restore the tape or hang on and hope to find the problem... |
| We have all experienced this. Another solution to this problem would be to install the new production server on new hardware, but this is not as easy as you have to clone the first server (most people are not confortable doing this) or you do not have the hardware. |
| We have all experienced this. Another solution to this problem would be to install the new production server on new hardware, but this is not as easy, as you have to clone the first server (most people are not confortable doing this) or you do not have the hardware. |
| **You clone it (Cloning a vserver takes 1 minutes unless it has a lot of data). |
| **You clone it (Cloning a vserver takes 1 minute unless it has a lot of data). |
| Later you find it does not work as expected and you can't fixed it (this night). |
| Later you find it does not work as expected and you can't immediately fix it. |
| You are working on a new project. At this point you have no idea of the resource it will need (load). In general, we do a meeting and decide about the new hardware. But we have no idea. So instead, we put the new project on a vserver on the first available linux box, including the workstation of the developper. And we develop. Once the thing is ready, we clone the vserver on some production server and give it a go. |
| You are working on a new project. At this point you have no idea of the resources it will need (load). In general, you have a meeting and make a decision about the new hardware. But in this case we have no idea. So instead, we put the new project on a vserver on the first available linux box, including the workstation of the developer. And we develop. Once the thing is ready, we clone the vserver on some production server and give it a go. |
|
The choice is important because every service running on a box will be using the same distribution. Most distributions out there are good and reliable. But they have flaw. For example, a distribution say XXX is great but is not delivering the latest and greatest PHP. Now because you have decided to use XXX for some projects, it does not prevent you from
using XXY for other projects. So instead of moving to XXY for everything, you move to it as you see fit, project per project. |
| The choice is important because every service running on a box will be using the same distribution. Most distributions out there are good and reliable. But they have flaw. For example, a distribution say XXX is great but is not delivering the latest and greatest PHP. Now because you have decided to use XXX for some projects, it does not prevent you from using XXY for other projects. So instead of moving to XXY for everything, you move to it as you see fit, project per project. |