OpenVZ

OpenVZ
Información general
Tipo de programa	Virtualización nivel SO
Desarrollador	Proyecto comunitario, soportado por SWsoft
Lanzamiento inicial	2005
Licencia	GNU GPL v.2
Información técnica
Plataformas admitidas	x86, x86_64, IA-64
Versiones
Última versión estable	4.86 de octubre de 2014
Enlaces
Sitio web oficial Repositorio de código

OpenVZ es una tecnología de virtualización en el nivel de sistema operativo basada en el núcleo y sistema operativo Linux. OpenVZ permite que un servidor físico ejecute múltiples instancias de sistemas operativos aislados, conocidos como Servidores Privados Virtuales (SPV) o Entornos Virtuales (EV).

Si se lo compara a máquinas virtuales tales como VMware, VirtualBox y las tecnologías de virtualización tales como Xen, OpenVZ ofrece menor flexibilidad en la elección del sistema operativo: tanto los huéspedes como los anfitriones deben ser Linux (aunque las distribuciones de GNU/Linux pueden ser diferentes en diferentes EVs). Sin embargo, la virtualización en el nivel de sistema operativo de OpenVZ proporciona mejor rendimiento, escabilidad, densidad, administración de recursos dinámicos, y facilidad de administración que las alternativas.

OpenVZ es una base de Virtuozzo que es un software comercial desarrollado por SWsoft, Inc., OpenVZ es un producto de software libre y licenciado bajo los términos de la licencia GNU GPL versión 2.

OpenVZ consiste del núcleo y de herramientas en el nivel de usuario.

Núcleo

El núcleo de OpenVZ es un núcleo Linux modificado, que agrega una noción de Entorno Virtual. El núcleo proporciona virtualización, aislamiento, administración de recursos, y Punto de comprobación

Virtualización y aislamiento

Cada EV es una entidad separada, y desde el punto de vista de su dueño se muestra como un servidor físico real. De manera que tiene sus propios:

Archivos

Bibliotecas del sistema, aplicaciones, /proc y /sys virtualizado, locks virtualizados etc.

Usuarios y grupos

Cada EV tiene sus propios usuarios root, así como también otros usuarios y grupos.

Árbol de procesos

Un EV solamente ve sus propios procesos (comenzando a partir de init). Los PIDs son virtualizados, de manera que el PID de init es 1 como debe ser.

Red

Dispositivo de red virtual, que permite a un EV tener sus propias direcciones IP, así como también un conjunto de reglas de netfilter (iptables) y reglas de encaminamiento.

Dispositivos

Si es necesario, solamente al EV puede otorgarse acceso a los dispositivos reales como interfaces de red, puertos seriales, particiones de disco, etc.

Objects IPC

Memoria compartida, semáforos, mensajes

Administración de recursos

Como todos los EVs usan el mismo kernel, la administración de recursos es de suprema importancia. Realmente, cada EV debería permanecer dentro de sus límites y no afectar a otros EVs de ninguna manera - y esto es lo que la administración de recursos hace.

La administración de recursos de OpenVZ consiste de tres componentes: cuota de disco de dos niveles, planificador de CPU razonable, y monitor de usuarios. Debe notarse que todos esos recursos se pueden cambiar durante el tiempo de ejecución de un EV, no hay necesidad de reiniciar el sistema. Es decir, si se desea dar a un EV menos memoria, sencillamente hay que cambiar los parámetros apropiados al vuelo. Esto es o muy difícil de hacer o imposible con otras maneras de virtualización tales como VM o hypervisor.

Cuota de disco de dos niveles

El dueño (root) del sistema anfitrión (OpenVZ) puede configurar cuota de disco por EV, en términos de bloques de disco e inodos (aproximadamente igual al número de archivos). Éste es el primer nivel de cuota de disco. Además de esto, un dueño de EV (root) puede usar las herramientas usuales de cuotas dentro de su propio EV para definir cuotas de disco estándar de UNIX por usuario y por grupo.

Si se desea dar a un EV más espacio, sencillamente hay que incrementar la cuota de disco. No se necesita redimensionar las particiones de disco, etc.

Planificador de CPU razonable

El planificador de CPU en OpenVZ es una implementación de dos niveles de planificación de estrategia de compartición razonable.

Sobre el primer nivel el planificador decide a que EV se le da una porción de tiempo de CPU, basado en valores de unidades de cpu por EV. Sobre el segundo nivel el planificador de Linux estándar decide que procesos ejecutar en ese EV, usando las prioridades de procesos de Linux estándares.

El administrador OpenVZ puede configurar valores diferentes de unidades de cpu para diferentes EVs, y el tiempo de CPU que se darán a ellos de manera proporcional. También hay una manera de limitar el tiempo de CPU, e.g. que un EV sea limitado al 10% del tiempo disponible de CPU.

Monitor de usuarios

El monitor de usuarios es un grupo de contadores por EV, límites, y garantías. Hay un conjunto de alrededor de 20 parámetros que se eligen cuidadosamente para cubrir todos los aspectos de la operación de EV, de manera que ningún EV por sí solo pueda abusar de cualquier recurso el cual es limitado por todo el nodo y así hacer daño a otros EVs.

Los recursos contabilizados y controlados son principalmente memoria y objetos en el kernel tales como los segmentos de memoria compartidos IPC, buffers de red etc. Cada recurso puede verse desde /proc/user_beancounters y tiene cinco valores asociados con este: uso actual, uso máximo (por el tiempo de vida de un EV), contador de barrera, de límite y de falla. El significado de barrera y límite es dependiente del parámetro; en breve, aquellos que se pueden pensar como un límite soft y un límite hard. Si cualquier recurso alcanza el contador de límite o de falla, entonces el dueño del EV puede ver si algo malo está pasando analizando la salida de /proc/user_beancounters en su EV.

Punto de comprobación y migración en vivo

La característica de migración en vivo y punto de comprobación se liberó para OpenVZ a mediados de abril de 2006. Esta permite migrar un EV desde un servidor físico a otro sin necesidad de apagar/reiniciar un EV. El proceso se conoce como punto de comprobación: un EV se congela y todo su estado se guarda al archivo en disco. Este archivo puede transferido a otra máquina y un EV puede descongelarse (restaurado) allí. La demora es alrededor de unos pocos segundos,

Dado que cada pieza de estado de EV, incluyendo conexiones de red abiertas, se guarda, desde la perspectiva del usuario parece una demora en la respuesta: una transacción de base de datos toma más tiempo que el usual, cuando continúa como normal el usuario no nota que su base de datos está ya corriendo en otra máquina. Esta característica hace posible escenarios tales como actualizar un servidor sin necesidad de reiniciarlo: si la base de datos necesita más memoria o recursos de CPU, sencillamente se debe comprar un servidor mejor y más nuevo y migrar en vivo el EV a éste, migrar todos los EVs a otro, apagarlo, agregar memoria, arrancarlo de nuevo y migrar todos los EVs de nuevo.

Herramientas en el nivel del usuario

OpenVZ viene con herramientas de línea de comandos para administrar EVs (vzctl), además de herramientas para administrar software en EVs (vzpkg).

vzctl

Esta es una simple herramienta de línea de comandos de alto nivel para administrar un EV.

vzctl create VEID [--ostemplate <name>] [--config <name>]

Este comando creará un nuevo Entorno Virtual con ID numérico de VEID el cual estará basado en una plantilla de SO específico (una distribución de Linux) y habiendo tomado parámetros de administración de recursos tomados de un ejemplo de configuración especificado. Tanto --ostemplate como --config</tt son parámetros opcionales, los valores preterminados para ellos se dan un archivo de configuración global.

vzctl start VEID

Inicia un EV determinado. Iniciar significa crear un contexto de Entorno Virual en el kernel, configurar todos los parámetros de administración de recursos y ejecutar /sbin/init del EV en ese contexto

vzctl stop VEID

Detiene un EV determinado. Un EV puede también detenerse (o reiniciarse) por su propietario usando los comandos estándares /sbin/halt o /sbin/reboot.

vzctl exec VEID <comando>

Ejecuta un conmando dentro de un EV determinado. Por ejemplo, para ver una lista de procesos dentro del EV 102, usar vzctl exec 102 ps ax,

vzctl enter VEID

Abre una shell de EV. Esto es útil si, por ejemplo, sshd está muerto para este EV y se quiere resolver el problema.

vzctl set VEID --parameter <value> [...] [--save]

Configurar un parámetro para EV. Hay un montón de parámetros diferentes. Tales como, agregar direcciones de IP a un DV, usar vzctl set VEID --ipadd x.x.x.x --save. Para configurar cuota de disco de EV, usar tt>vzctl set VEID --diskspace soft:hard --save. Para definir la barrera y memoria límite del kernel de VE, usar vzctl set VEID --kmemsize barrier:limit --save.

Plantillas y vzpkg

Las plantillas son imágenes precreadas que se usan para crear un nuevo EV. Básicamente, una plantilla es un conjunto de paquetes, y un cache de plantilla es un tarball de un entorno chroot con aquellos paquetes instalados. Durante la fase vzctl create, se desempaqueta un tarball. Usando una técnica de cache de template, un nuevo EV se puede crear en segundos.

Las herramientas vzpkg constituyen un conjunto de herramientas para facilitar la creación de cache en plantillas. Actualmente soporta repositorios basados en yum. Así que, básicament, para crear una plantilla, por ejemplo en la distribución Fedora Core 5, se necesita especificar un conjunto de repositorios yum, repositorios que tienen paquetes FC5, y un conjunto de paquetes a instalarse. Además, los scripts pre- y post- instalaciónse pueden emplearse para modificación/optiomización adicional de un cache de plantilla. Todos los datos de arriba (repositorios, lista de paquetes, scripts, claves GPG etc.) forman los metadatos de las plantillas. Teniendo unos metadatos de plantilla, el cache de plantilla se puede crear automáticamente; basta ejecutar la herramienta< tt>vzpkgcache. Ésta descargará e instalará los paquetes en EV temporario, y empaquetará el resultado como un cache de plantilla.

Caches de plantillas para distribuciones que no se basan en RPM se pueden crear también, aunque esto es más bien un proceso manual. Por ejemplo, este HOWTO da instrucciones detalladas de como crear un cache de plantilla de Debian.

Dado que las caches de plantillas (también plantillas precreadas) cambian constantemente, en este enlace [1] puedes consultar directamente tanto las plantillas oficiales como las contribuidas por la comunidad, así como descargarlas directamente. Existen plantillas precreadas para casi todas las distribuciones mas comunmente utilizadas (Debian, Asianux, Centos, Fedora, Gentoo Mandriva, OpenSuse, AltLinux, SlackWare, Suse y Ubuntu).

---

Características distintivas

Escalabilidad

Ya que OpenVZ emplea un modelo de kernel único, es tan escalable como kernel Linux 2.6, lo que significa que soporta hasta 64 CPUs y hasta 64 GB de RAM. Un entorno virtual único se puede escalar hasta el equipo físico entero, i.e. usar todos las CPUs y toda la RAM.

De hecho, algunas personas están usando OpenVZ con único Entorno Virtual. Esto es extraño a primera vista, pero dado el hecho de que un EV único usa todo los recursos del hardware con rendimiento nativo, y tiene agregados beneficios tales como independencia del hardware, administración de recursos y migración en vivo, esto es una opción obvia en muchos escenarios.

Densidad

Densidad de OpenVZ en un equipo de 768 Mb (¾ Gb) de RAM

OpenVZ es capaz de alojar cientos de Entornos Virtuales en hardware decente (las principales limitaciones son RAM y CPU).

El gráfico muestra la relación del tiempo de respuesta del Servidor Web Apache de EV sobre el número de EVs. Las medidas fueron hechas en una máquina con 768 Mb (¾ Gb) de RAM; cada EV estaba ejecutando el conjunto usual de procesos: init, syslogd, crond, sshd y Apache. Los daemons de apache estaban sirviendo páginas estáticas, que fueron transmitidas por http_load, y se midió el primer tiempo de respuesta. Como se puede ver, según el número de EV crece, el tiempo de respuesta se hace más alto a causa de la disminución de la memoria RAM y el excesivo swappeo.

En este escenario es posible ejecutar hasta 120 VEs en ¾ Gb de RAM. Esto se extrapola linealmente, de manera que es posible ejecutar hasta aproximadamente 320 EVs en un equipo con 2 Gb de RAM.

Administración masiva

Un propietario (root) de un servidor físico OpenVZ (también conocido como Nodo de Hardware) puede ver todos los procesos y archivos de EV. Esto hace la administración masiva de escenarios posible. Considerar que VMware o Xen se usan para consolidación de servidores: para aplicar una actualización de seguridad a unos 10 servidores virtuales se debe iniciar una sesión en cada uno y ejecutar el procedimiento de actualización - el mismo que se haría con diez servidores físicos.

En el caso de OpenVZ, se puede ejecutar un simple script de intérprete de comandos que actualice todo (o sólo algunos seleccionados) EVs a la vez.

Escenarios de uso

Los siguientes escenarios de uso son comunes para todas las tecnologías de virtualización. Sin embargo, una característica única de la virtualización en el nivel de SO como OpenVZ es que no se tiene que gastar gran cantidad de tiempo de procesamiento por la virtualización, esto hace los escenarios más atractivos.

Seguridad

Se pone cada servicio de red (como Apache, Servidor de Correo, Servidor DNS etc.) en un Entorno Virtual separado. En caso de que un cracker encuentre un agujero en la seguridad de uno de las aplicaciones y entre, todo lo que él puede abusar es ese mismo servicio; dado que todos los otros servicios están en EVs separados él no puede acceder a ellos.

Consolidación de Servidores

Actualmente, la mayoría de los servidores están infrautilizados. Usando OpenVZ, tales servidores se pueden consolidar migrándolos a Entornos Virtuales. Se ahorra en espacio de racks, consumo de electricidad, y esfuerzo de administración.

Hosting

Aparentemente, la virtualización en el nivel de SO es el único tipo de virtualización que los hosters pueden pagar y usar para vender VEs baratos a sus clientes. Notar que cada VE tiene acceso completo de root, lo que significa que el dueño del VE pueden reinstalar cualquier cosa, y aun usar cosas tales como iptables (reglas de cortafuego)

Desarrollo y Pruebas

Usualmente los desarrolladores y testers necesitan acceder a un grupo de distribuciones de Linux, y necesitan reinstalarlas desde cero con frecuencia. Con OpenVZ, pueden tener todo en un sólo equipo, sin ninguna necesidad de reiniciar, con rendimiento nativo, y un nuevo EV se puede crear en sólo un minuto. Clonar un VE es también muy simple: solamente se necesita copiar el área del EV y el archivo de configuración.

Educativo

Varios alumnos pueden compartir un EV. Cada uno puede trabajar con una diferente distribución de Linux. Un nuevo EV se puede (re)crear en un minuto.

Tecnologías similares

Otras implementaciones de tecnología virtualización en el nivel de Sistema Operativo son Linux-VServer, FreeBSD Jails, y Solaris Containers.

Desarrollo Futuro

Según mayo de 2006, las grandes modificaciones de OpenVZ no han sido incorporadas al núcleo Linux. Ya que hay tecnologías de virtualización competitivas, no está claro si, cuando, y en qué forma los cambios podrían combinarse. Todavía, hay una discusión en curso en LKML acerca de las diferentes maneras de virtualización en el nivel de SO, posibles implementaciones, e inclusión.

Planes de desarrollo actual para OpenVZ incluyen:

• Estabilizar la división de desarrollo alrededor del kernel 2.6.17
• Agregar soporte para IPv6 y redes puenteadas
• Agregar característica de afinidad de VCPU para EVs
• VE I/O planificación basada en CFQ
• Continuar manteniendo núcleos específicos por distribución (FC5, SUSE10)
• Continuar trabajando en la virtualización del kernel principal

Véase también

• Comparación de máquinas virtuales
• Virtuozzo

Enlaces externos

En inglés

• Sitio de OpenVZ
• OpenVZ Wiki
• Entrevista: Andrey Savochkin