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) Experimentación y actualización

Ud. tiene este típico problema. Pretende actualizar un sitio o bien con un nuevo paquete (nuevo PHP5) o con nuevas características (nueva versión de las aplicaciones Web). Después de haber probado todo esto sobre la máquina de desarrollo, está listo para actualizar el srvidor de producción. Teniendo alguna experiencia lo hace apropiadamente

  • Primero un buen backup del servidor
  • Luego realiza todas las actualizaciones e instala las nuevas aplicaciones
  • Fuego: el nuevo servidor está vivito y coleando
  • 2 horas más tarde, se da cuenta que algo no funciona como esperaba.
  • Para peor, funciona bien en la máquina de desarrollo.
  • Ahora son las 2 am y esto tiene que funcionar a las 8am. (Una famosa canción francesa: Je m'arrete ou je continue) Debería detener y restaurar la cinta o esperar y desear que se encuentre el problema...

Todos hemos experimentado esto. Otra solución a este problema sería instalar el nuevo servidor en producción sobre nuevo hardware, pero esto no es fácil, ya que tiene que clonar el primer servidor (la mayoría de la gente no se siente cómoda haciendo eso) o no tiene el hardware.

Al usar vserver, todo esto es es muy fácil

  • Detiene el vserver de producción
  • Lo clona (Clonar un vserver lleva 1 minuto a menos que tenga un montón de datos).
  • Realiza las actualizaciones en el nuevo vserver y lo pone a andar.

Más tarde encuentra que no funciona como esperaba y no puede solucionarlo inmediatamente.

  • Detiene el nuevo servidor y le asigna una nueva IP.
  • Arranca tanto el viejo como el nuevo. Ahora el viejo está aun online y puede meter mano con el nuevo (en una dirección IP diferente) para solucionar el problema.

D) Desarrollo

Está trabajando en nuevo proyecto. En este momento no tiene idea acerca de los recursos que necesitará (cargar). En general, tiene un encuentro y toma una decisión acerca del nuevo hardware. Pero en este caso no tiene idea. Así que en cambio, ponemos el nuevo proyecto en un vserver en el primer equipo linux disponible, incluyendo la estación de trabajo del desarrollador. Y desarrollamos. Una vez que la cosa está lista, clonamos el vserver sobre algún servidor de producción y lo ponemos a funcionar.

Más tarde sabemos cuan popular el servicio es, podemos migrarlo de nuevo a un servidor más potente, según sea necesario, sin necesidad de meter mano (migrar cuentas, instalar paquetes, etc.)

Como un buen ejemplo, Herbert tiene 33 vservers en su hotebook permiéndole probar varios proyectos y varuas distribuciones desde rh6.2 hacia FC3 y Debian.

E) Indipendencia de la distribución

Con frecuencia discutimos acerca de nuestra distribución preferida. ¿Deberíamos usar FC, Debian o alguna otra? ¿Deberíamos dar un giro a la última y más importante?

Con vservers, la opción de una distribución es menos importante. Cuando selecciona una distribución, espera que haga los siguiente

  • Buen soporte y descubrimiento de hardware
  • Buenas actualizaciones y tecnología de paquetes
  • Buena selección de paquetes
  • Paquetes confiables

La opción es importante porque cada servicio en un equipo estará usando la misma distribución. La mayoría de las distribuciones que existen son buenas y confiables. Pero tienen defectos. Por ejemplo, una distribución - digamos XXX - es excelente pero no está trayendo el PHP reciente y superior. Ahora ya que ha decidido usar XXX para algunos proyectos, esto no impide de usar XXY para otros proyectos. Así que en lugar de migrar XXY para todo, lo migra como quiera, proyecto por proyecto.

Toma una pocas horas investigar vservers, nunca volverá atrás.