We currently migrate to MediaWiki from our old installation, but not all content has been migrated yet. Take a look at the Wiki Team page for instructions how to help or browse through our new wiki at wiki.linux-vserver.org to find the information already migrated.

Primero para aquellos que no han escuchado del proyecto VServer: Éste le permite ejecutar Linux dentro de Linux: cualquier distribución dentro de cualquier distribución. Cada servidor virtual tiene sus propios paquetres, sus propios servicios, sus proprios usuarios y está confinado a usar alguno número de IP solamente y algunas áreas del sistema de archivos. Puede pensar en ellos como máquinas virtuales.

Para mucha gente, un servidor virtual puede parecer un lindo sensacional: Alto componente de geek. Parece interesante, pero probablemente no para todos. ¡Están equivocados!

Muchos puntos

  1. Los Vservers se ejecutan en el mismo kernel que el equipo anfitrión A diferencia de otras soluciones de VM, los vservers no requieren memoria adicional o potencia de procesamiento para el equipo anfitrión.
  2. No hay daemons especiales ejecutándose: Un vserver ejecutando crond, sshd, httpd y sendmail usa los mismos recursos que un servidor normal Linux ejecutando estos servicios.
  3. No se necesita asignar espacio al disco previamente: Vservers generalmente comparten el espacio en disco con el anfitrión, de manera que no hay necesidad de asignar de antemano espacio en disco para cada servidor solamente para encontrar más tarde que su disco está lleno, aun cada vserver usa solamente de una pequeña porción de su espacio asignado.
  4. Uso común de recursos: Dado que los vservers pueden compartir binarios y librerías sin interferirse, un segundo vserver generalmente requiere 40-100 mb solamente. Gran parte del espacio es una copia de la base de datos de los paquetes.
  5. Actualizaciones independientes: Los vservers se actualizan independientemente aun si los binarios se comparten con otros vservers.
  6. Independencia 32-/64-bit: La distribución de vservers de 32 bits se ejecutan normalmente en un equipo de 64 bits, pero más rápido, a veces mucho más.
  7. Mezcla y coincidencia: Puede mezclar varias distribuciones en el mismo servidor todos ejecutándose a la vez. http://www.solucorp.qc.ca por ejemplo es un servidor rh7.3 ejecutándose en un servidor rh7.3, junto con varios servidores FC3 así como también vservers Debian en el mismo equipo (un Celeron con 500 MHz).
  8. Las herramientas de administración trabajan dentro de un vserver como de costumbre
  9. Un vserver crackeado no puede alcanzar el server del anfitrión: El server del anfitrión se puede usar de manera segura para investigar el servidor crackeado (y arreglarlo), algo casi imposible con una instalación de Linux común.

¿Por qué necesita vservers?

Créame esto cambiará un montón, pero una vez que capte la idea nuncará volverá atrás. Aquí hay algunas ideas

A) Muchas tareas en el mismo equipo

Como el hardware evoluciona, es tentador poner más y más tareas en un servidor. Linux puede manejarlas. Linux es confiable y todo eso. En algún momento, termina con tantas cosas y tanta gente metiendo mano en el mismo equipo que se preocupa acerca de actualizar las cosas.

Vservers trata con esto. El mismo equipo ejecuta múltiples vservers y cada uno hace el trabajo que se supone tiene que hacer. Si necesita actualizar a php5 para un proyecto dado haga lo mismo y solamente se afecta el proeycto.

Además, puede dar la contraseña de root de un vserver a un administrador y el será capaz de realizar las actualizaciones, reiniciar los servicios y cosas así sin tener que saber acerca de cada proyecto alojado en un servidor.

B) Resource Independance: Moving vservers

Dado que los vserver son solamente invitados para el hardware que está usando, no se enteran de los tales: No contienen configuraciones de disco, configuraciones de kernels o de redes.

Una vez que ha encontrado que un proyecto usa más recursos que lo esperado, puede moverlo a otro equipo sin tener que meter mano aquí y allá. Un vserver es solamente un directorio dentro del servidor del anfitrión. Lo empaqueta con tar y lo copia a otro equipo y lo reinicia allí.

Un administrador puede mover vservers sin que sus usuarios sepan que lo hace.

C) Experimenting and Upgrading.

You have this typical problem. You intend to upgrade a site either with new package (new PHP5) or new features (new version of the Web applications). After having tested all this on the development machine, you are ready to update the production server. Having some experience you do it properly

  • First a good backup of the server
  • Then you perform all the upgrades and install the new applications
  • Fire: the new server is online and kicking.
  • 2 hours later, you realise that something does not work as expected.
  • 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.

Using vserver, all this is very easy

  • You stop the production vserver
  • You clone it (Cloning a vserver takes 1 minute unless it has a lot of data).
  • You perform the upgrades in the new vserver and give it life.

Later you find it does not work as expected and you can't immediately fix it.

  • You turn off the new vserver and assign it a new IP number.
  • You start both the old and new. Now the old is still online and you can fiddle with the new (on a different IP address) to fix the problem.

D) Development

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.

Later once we know how popular the new service is, we can move it again to a more powerful server, as needed, without any fiddling (moving accounts, installing packages, and so on)

As a good example, Herbert has 33 vservers on his notebook allowing him to test various projects and various distributions from rh6.2 to FC3 and Debian.

E) Distribution Independence

We are often talking about our preferred distribution. Should we use FC, Debian or something else ? Should we give a spin to the latest and greatest ?

With vservers, the choice of a distribution is less important. When you select a distribution, you expect it will do the following

  • Good hardware support/detection
  • Good package technology/updates
  • Good package selection
  • Reliable packages

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 flaws. 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.

Takes few hours to investigate vservers, you will never look back.