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
[editar datos en Wikidata]

OpenVZ es una tecnología de virtualización en el nivel de sistema operativo para Linux. OpenVZ permite que un servidor físico ejecute múltiples instancias de sistemas operativos aislados, conocidos como Servidores Privados Virtuales (SPV o VPS en inglés) 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, escalabilidad, 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.

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

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

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.

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.

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.

La característica de la 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 ser transferido a otra máquina y un EV puede descongelarse (restaurarse) allí. La demora es 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.

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

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 set VEID --parameter <9-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.

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 caché 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 caché de template, un nuevo EV se puede crear en segundos.

Las herramientas vzpkg constituyen un conjunto de herramientas para facilitar la creación de caché en plantillas. Actualmente admite repositorios basados en yum. Así que, básicamente, 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 posinstalación pueden emplearse para modificación u optimización adicional de un caché 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 caché 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 caché de plantilla.

Cachés 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 caché de plantilla de Debian.

Dado que las cachés 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 más comúnmente utilizadas (Debian, Asianux, Centos, Fedora, Gentoo, Mandriva, OpenSuse, AltLinux, SlackWare, Suse y Ubuntu).

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

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 MiB (¾ GiB) 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 swapping.

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

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.

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 puede hacer es en ese mismo servicio; dado que todos los otros servicios están en EVs separados no puede acceder a ellos.

Consolidación de Servidores

Actualmente, la mayoría de los servidores están infra-utilizados. 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 las empresas de hosting pueden pagar y usar para vender Entornos Virtuales 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 aún 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 solo 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.

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

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

• Comparación de máquinas virtuales
• Virtuozzo
• Proxmox Virtual Environment

• Sitio de OpenVZ (inglés)
• Entrevista: Andrey Savochkin (inglés)