Software">
Stallings Chapter 14.en - Es
Stallings Chapter 14.en - Es
Stallings Chapter 14.en - Es
com
Capítulo
Maquinas virtuales
14,1 Conceptos de máquinas virtuales
14,2 Hipervisores
Hipervisores
Paravirtualización
Dispositivo virtual de virtualización
asistida por hardware
Microservicios
Estibador
14,6 Gestión de E / S
14,7 VMware ESXi
14,8 Microsoft Hyper-V y Xen Variants
14,9 Java VM
14.10 Arquitectura de máquina virtual Linux Vserver
Arquitectura
Programación de procesos
14.11 Resumen
627
628 Capítulo 14 / Máquinas virtuales
Lganador Oobjetivos
Después de estudiar este capítulo, debería poder:
• Analice la virtualización de tipo 1 y tipo 2.
• Explique la virtualización de contenedores y compárela con el enfoque del hipervisor.
• Comprender los problemas del procesador relacionados con la implementación de una máquina virtual.
• Comprender los problemas de gestión de la memoria relacionados con la implementación de
una máquina virtual.
Las primeras tres secciones de este capítulo tratan los dos enfoques principales de
la virtualización: máquinas virtuales y contenedores. El resto del capítulo analiza algunos
sistemas específicos.
Tradicionalmente, las aplicaciones se han ejecutado directamente en un sistema operativo (SO) en una
computadora personal (PC) o en un servidor, con la PC o el servidor ejecutando solo un SO a la vez. Por lo
tanto, el proveedor de aplicaciones tuvo que reescribir partes de sus aplicaciones para cada sistema
operativo / plataforma en el que se ejecutarían y admitirían, lo que aumentó el tiempo de comercialización de
nuevas características / funciones, aumentó la probabilidad de defectos, aumentó los esfuerzos de prueba de
calidad y, por lo general, condujo a aumento de precio. Para admitir varios sistemas operativos, los
proveedores de aplicaciones necesitaban crear, administrar y admitir varias infraestructuras de hardware y
sistemas operativos, un proceso costoso y que requiere muchos recursos. Una estrategia eficaz para hacer
frente a este problema se conoce comovirtualización de hardware. La tecnología de virtualización permite
que una sola PC o servidor ejecute simultáneamente múltiples sistemas operativos o múltiples sesiones de un
solo sistema operativo. Una máquina con software de virtualización puede alojar numerosas aplicaciones,
incluidas las que se ejecutan en diferentes sistemas operativos, en una única plataforma. En esencia, el
sistema operativo host puede admitir una serie demáquinas virtuales (VM), cada uno de los cuales tiene las
características de un sistema operativo en particular y, en algunas versiones de virtualización, las
características de una plataforma de hardware en particular. máquina virtual del sistema, destacando que es
el hardware del sistema el que se está virtualizando.
14.1 / CONCEPTOS DE MÁQUINA VIRTUAL 629
sistema operativo host o uno diferente. Por ejemplo, un sistema operativo Windows invitado podría ejecutarse en una máquina virtual
630 Capítulo 14 / Máquinas virtuales
sobre un sistema operativo de host Linux. El sistema operativo invitado, a su vez, admite un
conjunto de funciones de biblioteca estándar y otros archivos y aplicaciones binarios. Desde el
punto de vista de las aplicaciones y del usuario, esta pila aparece como una máquina real, con
hardware y un SO; así, el términomáquina virtual es apropiado. En otras palabras, es el
hardware el que se virtualiza.
La cantidad de invitados que pueden existir en un solo host se mide por ratio de
consolidación. Por ejemplo, se dice que un host que admite 4 VM tiene un índice de
consolidación de 4 a 1, también escrito como 4: 1 (consulte la Figura 14.1). Los hipervisores
iniciales disponibles comercialmente proporcionaron relaciones de consolidación de entre 4: 1 y
12: 1, pero incluso en el extremo inferior, si una empresa virtualizara todos sus servidores,
podría eliminar el 75% de los servidores de sus centros de datos. Más importante aún, también
podrían eliminar el costo, que a menudo asciende a millones o decenas de millones de dólares
anuales. Con menos servidores físicos, se necesitaba menos energía y menos refrigeración.
Además, esto conduce a menos cables, menos conmutadores de red y menos espacio en el piso.
La consolidación de servidores se convirtió, y sigue siendo, una forma tremendamente valiosa
de resolver un problema costoso y derrochador. Hoy en día, se implementan más servidores
virtuales en el mundo que servidores físicos,
Podemos resumir las razones clave por las que las organizaciones utilizan la virtualización de la siguiente
manera:
• Hardware heredado: Las aplicaciones creadas para hardware heredado aún se pueden
ejecutar virtualizando (emulando) el hardware heredado, lo que permite la retirada del
hardware antiguo.
• Despliegue rápido: Como se explica más adelante, mientras que la implementación de nuevos
servidores en una infraestructura puede llevar semanas o más, una nueva VM puede
implementarse en cuestión de minutos. Como se explica a continuación, una máquina virtual
consta de archivos. Al duplicar esos archivos, en un entorno virtual hay una copia perfecta del
servidor disponible.
14.2 HIPERVISORES
No existe una clasificación definitiva de los diversos enfoques que se han adoptado
para el desarrollo de máquinas virtuales. En [UHLI05], [PEAR13], [RPSE04], [ROSE05],
[NAND05] y [GOLD11 se describen varios métodos de clasificación. ]. Esta sección
examina el concepto de hipervisor, que es la base más común para clasificar los
enfoques de máquinas virtuales.
Hipervisores
La virtualización es una forma de abstracción. Al igual que un sistema operativo abstrae los
comandos de E / S del disco de un usuario mediante el uso de capas de programa e interfaces,
la virtualización abstrae el hardware físico de las máquinas virtuales que admite. El monitor o
hipervisor de la máquina virtual es el software que proporciona esta abstracción. Actúa como un
intermediario o policía de tráfico, actuando como un proxy para los invitados (VM) cuando
solicitan y consumen recursos del host físico.
Una máquina virtual es una construcción de software que imita las características de un
servidor físico. Está configurado con cierto número de procesadores, cierta cantidad de RAM,
recursos de almacenamiento y conectividad a través de los puertos de red. Una vez que se crea
la máquina virtual, se puede encender como un servidor físico, cargar con un sistema operativo
y soluciones de software, y utilizar como un servidor físico. A diferencia de un servidor físico,
este servidor virtual solo ve los recursos con los que se ha configurado, no todos los recursos
del host físico en sí. Este aislamiento permite que una máquina host ejecute muchas máquinas
virtuales, cada una de las cuales ejecuta la misma o diferentes copias de un sistema operativo,
compartiendo RAM, almacenamiento y ancho de banda de red, sin problemas. Un sistema
operativo en una máquina virtual accede al recurso que le presenta el hipervisor. El hipervisor
facilita la traducción y la E / S de la máquina virtual a los dispositivos del servidor físico y de
regreso a la máquina virtual correcta. De esta manera, ciertas instrucciones privilegiadas que un
SO "nativo" estaría ejecutando en el hardware de su host quedan atrapadas y ejecutadas por el
hipervisor como un proxy para la máquina virtual. Esto crea cierta degradación del rendimiento
en el proceso de virtualización, aunque con el tiempo tanto el hardware y las mejoras de
software han minimizado esta sobrecarga.
632 Capítulo 14 / Máquinas virtuales
Una instancia de VM se define en archivos. Una máquina virtual típica puede constar de unos pocos
archivos. Hay un archivo de configuración que describe los atributos de la máquina virtual. Contiene la
definición del servidor, cuántos procesadores virtuales (vCPU) se asignan a esta máquina virtual, cuánta RAM
está asignada, a qué dispositivos de E / S tiene acceso la VM, cuántas tarjetas de interfaz de red (NIC) hay en el
servidor virtual , y más. También describe el almacenamiento al que puede acceder la VM. A menudo, ese
almacenamiento se presenta como discos virtuales que existen como archivos adicionales en el sistema de
archivos físico. Cuando se enciende una máquina virtual o se crea una instancia, se crean archivos adicionales
para el registro, la paginación de la memoria y otras funciones. Dado que una máquina virtual se compone
esencialmente de archivos, determinadas funciones en un entorno virtual se pueden definir de forma más
sencilla y rápida que en un entorno físico. Desde los primeros días de las computadoras, hacer copias de
seguridad de los datos ha sido una función fundamental. Dado que las máquinas virtuales ya son archivos,
copiarlos produce no solo una copia de seguridad de los datos, sino también una copia de todo el servidor,
incluido el sistema operativo, las aplicaciones y la configuración del hardware en sí.
Un método común para implementar rápidamente nuevas máquinas virtuales es mediante el uso de plantillas.
Una plantilla proporciona un grupo estandarizado de configuraciones de hardware y software que se pueden usar
para crear nuevas máquinas virtuales configuradas con esas configuraciones. La creación de una nueva VM a partir de
una plantilla consiste en proporcionar identificadores únicos para la nueva VM y hacer que el software de
aprovisionamiento cree una VM a partir de la plantilla y agregue los cambios de configuración como parte de la
implementación.
Hypervisor Funciones Las principales funciones que realiza un hipervisor son las
siguientes:
• Gestión de ejecución de máquinas virtuales: Incluye programación de VM para ejecución,
administración de memoria virtual para asegurar el aislamiento de VM de otras VM, cambio de
contexto entre varios estados del procesador. También incluye aislamiento de VM para evitar
conflictos en el uso de recursos y emulación de temporizadores e interrupciones.
• Ejecución de operaciones privilegiadas por hipervisor para máquinas virtuales invitadas: Ciertas
operaciones invocadas por los sistemas operativos invitados, en lugar de ser ejecutadas directamente por el
hardware del host, pueden tener que ser ejecutadas en su nombre por el hipervisor, debido a su naturaleza
privilegiada.
• Gestión de máquinas virtuales (también denominada gestión del ciclo de vida de las máquinas virtuales): Configuración de máquinas
virtuales invitadas y control de los estados de las máquinas virtuales (p. Ej., Inicio, Pausa y Detención).
type 1 horaypervisor Hay dos tipos de hipervisores, que se distinguen por si hay un sistema operativo
entre el hipervisor y el host. Un hipervisor de tipo 1 (consulte la Figura 14.2a) se carga como una capa
de software directamente en un servidor físico, de forma muy similar a como se carga un sistema
operativo. El hipervisor de tipo 1 puede controlar directamente los recursos físicos de
14.2 / HIPERVISORES 633
Virtual Virtual
Máquina 1 Máquina 2
Virtual Virtual
Máquina 1 Máquina 2
Aplicaciones Aplicaciones
el anfitrión. Una vez que está instalado y configurado, el servidor es capaz de admitir máquinas
virtuales como invitados. En entornos maduros, donde los hosts de virtualización se agrupan
para aumentar la disponibilidad y el equilibrio de carga, se puede instalar un hipervisor en un
nuevo host. Luego, ese nuevo host se une a un clúster existente y las máquinas virtuales se
pueden mover al nuevo host sin ningún problema. interrupción del servicio. Algunos ejemplos
de hipervisores de tipo 1 son VMware ESXi, Microsoft Hyper-V y las diversas variantes de Xen.
type 2 Hypervisor Un hipervisor de tipo 2 explota los recursos y las funciones de un sistema operativo host y se
ejecuta como un módulo de software en la parte superior del sistema operativo (consulte la Figura 14.2b).
Depende del sistema operativo para manejar todas las interacciones de hardware en nombre del hipervisor.
Algunos ejemplos de hipervisores de tipo 2 son VMwareWorkstation y Oracle VMVirtual Box.
Las diferencias clave entre los dos tipos de hipervisor son las siguientes:
• Normalmente, los hipervisores de tipo 1 funcionan mejor que los hipervisores de tipo 2. Debido
a que un hipervisor de tipo 1 no compite por recursos con un sistema operativo, hay más
recursos disponibles en el host y, por extensión, se pueden alojar más máquinas virtuales en un
servidor de virtualización mediante un hipervisor de tipo 1.
• Los hipervisores de tipo 1 también se consideran más seguros que los hipervisores de tipo 2.
Las máquinas virtuales en un hipervisor de tipo 1 realizan solicitudes de recursos que se
manejan de manera externa a ese invitado y no pueden afectar a otras máquinas virtuales o al
hipervisor que los soporta. Esto no es necesariamente cierto para las máquinas virtuales en un
hipervisor de tipo 2, y un invitado malintencionado podría afectar más que a sí mismo.
Paravirtualización
A medida que la virtualización se hizo más frecuente en las corporaciones, tanto los proveedores de
hardware como de software buscaron formas de proporcionar aún más eficiencias. Como era de
esperar, estos caminos llevaron tanto a la virtualización asistida por software como a la virtualización
asistida por hardware.Paravirtualización es una técnica de virtualización asistida por software que
utiliza API especializadas para vincular máquinas virtuales con el hipervisor para optimizar su
rendimiento. El sistema operativo en la máquina virtual, Linux o Microsoft Windows, tiene soporte de
paravirtualización especializado como parte del kernel, así como controladores de paravirtualización
específicos que permiten que el sistema operativo y el hipervisor trabajen juntos de manera más
eficiente con la sobrecarga de las traducciones del hipervisor. Este software asistido ofrece soporte de
virtualización optimizado en servidores con o sin procesadores que brindan extensiones de
virtualización. El soporte de paravirtualización se ha ofrecido como parte de muchas de las
distribuciones generales de Linux desde 2008.
Aunque los detalles de este enfoque difieren entre las distintas ofertas, a continuación se ofrece
una descripción general (consulte la Figura 14.3). Sin paravirtualización, el sistema operativo invitado
puede ejecutarse sin modificaciones si el hipervisor emula el hardware. En este caso, las llamadas de
los controladores del sistema operativo invitado al hardware son interceptadas por el hipervisor, que
realiza cualquier traducción necesaria para el hardware nativo y redirige la llamada al controlador real.
Con la paravirtualización, el código fuente de un sistema operativo se modifica para ejecutarse como
un SO invitado en un entorno de máquina virtual específico. Las llamadas al hardware se reemplazan
por llamadas al hipervisor, que puede aceptar estas llamadas y redirigirlas sin
VM VM VM VM VM VM
SO SO SO SO SO SO
Verdadero Verdadero Verdadero Modificado Modificado Modificado
Conductores Conductores Conductores Conductores Conductores Conductores
Hipervisor Hipervisor
Modelos de dispositivos Hipervisor
(hardware emulado) Interfaz del conductor
Verdadero Verdadero
Conductores Conductores
Hardware Hardware
modificación de los controladores reales. Esta disposición es más rápida con menos gastos generales que una
configuración no paravirtualizada.
Dispositivo virtual
Un dispositivo virtual es un software independiente que se puede distribuir como una imagen de máquina
virtual. Por lo tanto, consta de un conjunto empaquetado de aplicaciones y SO huésped. Es independiente de
la arquitectura del hipervisor o del procesador y puede ejecutarse en un hipervisor de tipo 1 o de tipo 2.
VM basadas en hipervisor, los contenedores no tienen como objetivo emular servidores físicos. En cambio, todas las
aplicaciones en contenedores en un host comparten un kernel de sistema operativo común. Esto elimina los recursos
necesarios para ejecutar un sistema operativo independiente para cada aplicación y puede reducir en gran medida los gastos
generales.
Gran parte de la tecnología para contenedores que se utiliza hoy en día se desarrolló para Linux y los
contenedores basados en Linux son, con mucho, los más utilizados. Antes de pasar a una discusión
sobre contenedores, es útil presentar el concepto de grupo de control del kernel de Linux. En 2007
[MENA07], la API de proceso estándar de Linux se amplió para incorporar la contenedorización del
entorno de usuario a fin de permitir la agrupación de múltiples procesos, permisos de seguridad de
usuario y gestión de recursos del sistema. Inicialmente referido comocontenedores de proceso, a
finales de 2007, la nomenclatura cambió a grupos de control (cgroups) para evitar confusiones
causadas por múltiples significados del término envase en el contexto del kernel de Linux, y la
funcionalidad de los grupos de control se fusionó con la línea principal del kernel de Linux en la
versión 2.6.24 del kernel, lanzada en enero de 2008.
El espacio de nombres de procesos de Linux es jerárquico, en el que todos los procesos son hijos del
proceso de arranque común llamado init. Esto forma una única jerarquía de procesos. El grupo de control del
kernel permite que coexistan múltiples jerarquías de procesos en un solo sistema operativo. Cada jerarquía
se adjunta a los recursos del sistema en el momento de la configuración.
Cgroups proporciona:
• Limitación de recursos: Los grupos se pueden configurar para que no excedan un límite de memoria configurado.
• Priorización: Algunos grupos pueden obtener una mayor proporción de uso de CPU o rendimiento de
E / S de disco.
• Contabilidad: Mide el uso de recursos de un grupo, que se puede utilizar, como ejemplo,
con fines de facturación.
• Control: Congelación de grupos de procesos, su checkpointing y reinicio.
Conceptos de contenedor
La figura 14.4 compara las pilas de software de hipervisor y contenedor. Para los contenedores, solo
se requiere un motor de contenedor pequeño como soporte para los contenedores. El motor de
contenedores configura cada contenedor como una instancia aislada al solicitar recursos dedicados
del sistema operativo para cada contenedor. Luego, cada aplicación de contenedor utiliza
directamente los recursos del sistema operativo host. Aunque los detalles difieren de un producto de
contenedor a otro, las siguientes son tareas típicas realizadas por un motor de contenedor:
• Mantenga un entorno de ejecución ligero y una cadena de herramientas que gestione contenedores,
imágenes y compilaciones.
Máquina virtual
Aplicación Aplicación Aplicación Aplicación
Bibliotecas Bibliotecas
Máquina virtual
Aplicación Aplicación Aplicación Aplicación
SO invitado SO invitado
Bibliotecas Bibliotecas
Hipervisor
SO invitado SO invitado
SO del host
Hipervisor
Hardware Hardware
Envase
Aplicación Aplicación Aplicación Aplicación
Envase
Bibliotecas Bibliotecas
Motor de contenedor
SO del host
Hardware
(c) Contenedor
• Configuración: La fase de configuración incluye el entorno para crear e iniciar los contenedores de
Linux. Un ejemplo típico de la fase de configuración es el kernel de Linux habilitado con banderas o
paquetes instalados para permitir la partición del espacio de usuario. La configuración también incluye
la instalación de herramientas y utilidades (por ejemplo, lxc, bridge utils) para crear una instancia del
entorno del contenedor y la configuración de red en el sistema operativo host.
• Gestión: Una vez que un contenedor está configurado y configurado, debe administrarse para
permitir un arranque (inicio) y apagado del contenedor sin problemas. Por lo general, las operaciones
administradas para un entorno basado en contenedores incluyen iniciar, detener, congelar y migrar.
Además, existen metacomandos y cadenas de herramientas que permiten la asignación controlada y
administrada de contenedores en un solo nodo para el acceso del usuario final.
Debido a que todos los contenedores en una máquina se ejecutan en el mismo kernel, compartiendo así la
mayor parte del sistema operativo base, una configuración con contenedores es mucho más pequeña y liviana en
comparación con una disposición de máquina virtual hipervisor / sistema operativo invitado. En consecuencia, un
sistema operativo puede tener muchos contenedores ejecutándose sobre él, en comparación con el número limitado
de hipervisores y sistemas operativos invitados que se pueden admitir.
638 Capítulo 14 / Máquinas virtuales
Los contenedores virtuales son factibles debido al control de recursos y los aislamientos de procesos,
como se explica utilizando técnicas como el grupo de control del kernel. Este enfoque permite que los
recursos del sistema se compartan entre varias instancias de contenedores aislados. Cgroups proporciona un
mecanismo para administrar y monitorear los recursos del sistema. El rendimiento de la aplicación está cerca
del rendimiento del sistema nativo debido al kernel único compartido entre todas las instancias de
contenedor de espacio de usuario, y la sobrecarga es solo para proporcionar un mecanismo para aislar los
contenedores a través de cgroups. Los subsistemas Linux particionados usando primitivas de grupo de
control incluyen sistema de archivos, espacio de nombres de proceso, pila de red, nombre de host, IPC y
usuarios.
Para comparar máquinas virtuales con contenedores, considere la operación de E / S durante una
aplicación con el proceso P en un entorno virtualizado. En un entorno de virtualización de sistema clásico (sin
soporte de hardware), el proceso P se ejecutaría dentro de una máquina virtual invitada. La operación de E / S
se enruta a través de la pila del sistema operativo invitado al dispositivo de E / S invitado emulado. La llamada
de E / S es interceptada por el hipervisor que la reenvía a través de la pila del sistema operativo host al
dispositivo físico. En comparación, el contenedor se basa principalmente en un mecanismo de
direccionamiento indirecto proporcionado por las extensiones del marco del contenedor que se han
incorporado al núcleo del flujo principal. Aquí, un solo kernel se comparte entre varios contenedores (en
comparación con el kernel del sistema operativo individual en las máquinas virtuales del sistema). La figura
14.5 ofrece una descripción general del flujo de datos de las máquinas virtuales y los contenedores.
Solicitud
1. No es necesario un sistema operativo invitado en el entorno del contenedor. Por lo tanto, los contenedores son
livianos y tienen menos gastos generales en comparación con las máquinas virtuales.
Debido a que son livianos, los contenedores son una alternativa atractiva a las máquinas
virtuales. Una característica atractiva adicional de los contenedores es que brindan portabilidad de las
aplicaciones. Las aplicaciones en contenedores se pueden mover rápidamente de un sistema a otro.
Estos beneficios de los contenedores no significan que los contenedores sean siempre una alternativa
preferida a las máquinas virtuales, como muestran las siguientes consideraciones:
• Las aplicaciones de contenedor solo son portables entre sistemas que admiten el mismo kernel del sistema
operativo con las mismas características de soporte de virtualización, lo que generalmente significa Linux. Por
lo tanto, una aplicación de Windows en contenedores solo se ejecutaría en máquinas con Windows.
• Una máquina virtual puede requerir una configuración de kernel única que no es aplicable a otras
máquinas virtuales en el host; este requisito se aborda mediante el uso del sistema operativo invitado.
Un caso de uso potencial, citado en [KERN16], gira en torno a Kubernetes, una tecnología
de orquestación de contenedores de código abierto creada por Google pero ahora administrada
por Cloud Native Computing Foundation (CNCF). La fundación en sí opera como un proyecto
colaborativo de la Fundación Linux. Por ejemplo, si un administrador dedica 500 Mbps a una
aplicación en particular que se ejecuta en Kubernetes, entonces el plano de control de red
puede participar en la programación de esta aplicación para encontrar el mejor lugar para
garantizar ese ancho de banda. O, al trabajar con la API de Kubernetes, un plano de control de
red puede comenzar a crear reglas de firewall de entrada que sean conscientes de las
aplicaciones de contenedor.
Como parte del aislamiento de un contenedor, cada contenedor debe mantener su propio sistema de
archivos aislado. Las características específicas varían de un producto contenedor a otro, pero los
principios esenciales son los mismos.
Como ejemplo, observamos el sistema de archivos contenedor utilizado en OpenVZ. Esto se muestra
en la Figura 14.6. El programador init se ejecuta para programar aplicaciones de usuario y cada contenedor
tiene su propio proceso de inicio, que desde la perspectiva de los nodos de hardware es simplemente otro
proceso en ejecución.
Lo más probable es que los múltiples contenedores en un host ejecuten los mismos procesos, pero
cada uno de ellos no tiene una copia individual aunque el comando ls muestra que el directorio / bin del
contenedor está lleno de programas. En cambio, los contenedores comparten una plantilla, una característica
de diseño en la que todas las aplicaciones que vienen con el sistema operativo y muchas de las
640 Capítulo 14 / Máquinas virtuales
/ vz / root
1x 2 años 3z
abrasador rjones
Las aplicaciones más comunes se empaquetan juntas como grupos de archivos alojados por el sistema
operativo de la plataforma y vinculados simbólicamente en cada contenedor. Esto también incluye archivos
de configuración, a menos que el contenedor los modifique; cuando eso sucede, el sistema operativo copia el
archivo de plantilla (llamado copia al escribir), elimina el enlace simbólico virtual y coloca el archivo
modificado en el sistema de archivos del contenedor. Al utilizar este esquema de intercambio de archivos
virtual, se logra un ahorro de espacio considerable, con solo los archivos creados localmente que realmente
existen en el sistema de archivos del contenedor.
A nivel de disco, un contenedor es un archivo y se puede escalar hacia arriba o hacia abajo fácilmente. Desde
el punto de vista de la verificación de virus, el sistema de archivos del contenedor se monta bajo un punto de montaje
especial en el nodo de hardware para que las herramientas del sistema en el nivel del nodo de hardware puedan
verificar de forma segura todos los archivos si es necesario.
14.3 / CONTENEDOR VIRTUALIZACIÓN 641
Microservicios
Un concepto relacionado con los contenedores es el de microservicio. NIST SP 800-180 (
Definición de NIST de microservicios, contenedores de aplicaciones y máquinas virtuales del
sistema, Febrero de 2016) define un microservicio como un elemento básico que resulta de la
descomposición arquitectónica de los componentes de una aplicación en patrones poco
acoplados que consisten en servicios autónomos que se comunican entre sí mediante un
protocolo de comunicaciones estándar 219 y un conjunto de API bien definidas , independiente
de cualquier proveedor, producto o tecnología.
La idea básica detrás de los microservicios es que, en lugar de tener una pila de
aplicaciones monolítica, cada servicio específico en una cadena de entrega de aplicaciones se
divide en partes individuales. Al utilizar contenedores, las personas están haciendo un esfuerzo
consciente para dividir su infraestructura en unidades más comprensibles, lo que abre una
oportunidad para que las tecnologías de redes tomen decisiones en nombre del usuario que
antes no podían tomar en un mundo centrado en las máquinas.
Dos ventajas clave de los microservicios son las siguientes:
• Los microservicios implementan unidades desplegables mucho más pequeñas, lo que luego
permite al usuario enviar actualizaciones o realizar funciones y capacidades mucho más
rápidamente. Esto coincide con las prácticas de entrega continua, donde el objetivo es expulsar
unidades pequeñas sin tener que crear un sistema monolítico.
• Los microservicios también admiten una escalabilidad precisa. Debido a que un microservicio
es una sección de una aplicación mucho más grande, se puede replicar fácilmente para crear
múltiples instancias y distribuir la carga solo para esa pequeña parte de la aplicación en lugar
de tener que hacerlo para toda la aplicación.
Estibador
Históricamente, los contenedores surgieron como una forma de ejecutar aplicaciones de una manera más
flexible y ágil. Los contenedores de Linux permitieron ejecutar aplicaciones ligeras, directamente dentro del
sistema operativo Linux. Sin la necesidad del hipervisor y las máquinas virtuales, las aplicaciones se pueden
ejecutar de forma aislada en el mismo sistema operativo. Google ha estado utilizando contenedores de Linux
en sus centros de datos desde 2006. Pero el enfoque de contenedores se hizo más popular con la llegada de
los contenedores de Docker en 2013. Docker proporciona una forma más simple y estandarizada de ejecutar
contenedores en comparación con la versión anterior de contenedores. El contenedor Docker también se
ejecuta en Linux. Pero Docker no es la única forma de ejecutar contenedores. Linux Containers (LXC) es otra
forma de ejecutar contenedores. Tanto LXC como Docker tienen raíces en Linux. Una de las razones por las
que el contenedor Docker es más popular en comparación con los contenedores de la competencia, como
LXC, es su capacidad para cargar una imagen de contenedor en un sistema operativo host de una manera
simple y rápida. Los contenedores de Docker se almacenan en la nube como imágenes y los usuarios solicitan
su ejecución cuando los necesitan de una manera sencilla.
Docker consta de los siguientes componentes principales:
• Imagen de Docker: Las imágenes de Docker son plantillas de solo lectura desde las que se crean instancias
de contenedores de Docker.
• Cliente de Docker: Un cliente de Docker solicita que se utilice una imagen para crear un nuevo
contenedor. El cliente puede estar en la misma plataforma que un host de Docker o una máquina de
Docker.
642 Capítulo 14 / Máquinas virtuales
• Host de Docker: Una plataforma con su propio sistema operativo host que ejecuta aplicaciones en
contenedores.
• Motor de Docker: Este es el paquete de tiempo de ejecución ligero que crea y ejecuta los
contenedores de Docker en un sistema host.
• Máquina Docker: La máquina Docker puede ejecutarse en un sistema separado de los hosts de
Docker, que se utilizan para configurar los motores de Docker. La máquina Docker instala el
motor Docker en un host y configura el cliente Docker para comunicarse con el motor Docker.
La máquina Docker también se puede usar localmente para configurar una imagen de Docker
en el mismo host que ejecuta la máquina Docker.
• Registro de Docker: Un registro de Docker almacena imágenes de Docker. Después de crear
una imagen de Docker, puede enviarla a un registro público, como un concentrador de Docker,
oa un registro privado que se ejecuta detrás de su firewall. También puede buscar imágenes
existentes y extraerlas del registro a un host.
En un entorno virtual, existen dos estrategias principales para proporcionar recursos de procesador. La primera es emular un chip como
software y proporcionar acceso a ese recurso. Ejemplos de este método son QEMU y el emulador de Android en el SDK de Android. Tienen
la ventaja de ser fácilmente transportables ya que no dependen de la plataforma, pero no son muy eficientes desde el punto de vista del
rendimiento, ya que el proceso de emulación consume muchos recursos. El segundo modelo en realidad no virtualiza procesadores, pero
proporciona segmentos de tiempo de procesamiento en los procesadores físicos (pCPU) del host de virtualización a los procesadores
virtuales de las máquinas virtuales alojadas en el servidor físico. Así es como la mayoría de los hipervisores de virtualización ofrecen
procesador recursos a sus invitados. Cuando el sistema operativo de una máquina virtual pasa instrucciones al procesador, el hipervisor
intercepta la solicitud. Luego, programa el tiempo en los procesadores físicos del host, envía la solicitud de ejecución y devuelve los
resultados al sistema operativo de la VM. Esto asegura el uso más eficiente de los recursos del procesador disponibles en el servidor físico.
Para agregar algo de complejidad, cuando varias VM compiten por el procesador, el hipervisor actúa como controlador de tráfico,
programando el tiempo del procesador para cada solicitud de VM y dirigiendo las solicitudes y los datos hacia y desde las máquinas
virtuales. Esto asegura el uso más eficiente de los recursos del procesador disponibles en el servidor físico. Para agregar algo de
complejidad, cuando varias VM compiten por el procesador, el hipervisor actúa como controlador de tráfico, programando el tiempo del
procesador para cada solicitud de VM y dirigiendo las solicitudes y los datos hacia y desde las máquinas virtuales. Esto asegura el uso más
eficiente de los recursos del procesador disponibles en el servidor físico. Para agregar algo de complejidad, cuando varias VM compiten por
el procesador, el hipervisor actúa como controlador de tráfico, programando el tiempo del procesador para cada solicitud de VM y
dirigiendo las solicitudes y los datos hacia y desde las máquinas virtuales.
Junto con la memoria, la cantidad de procesadores que tiene un servidor es una de las
métricas más importantes al dimensionar un servidor. Esto es especialmente cierto, y de alguna
manera más crítico, en un entorno virtual que en uno físico. En un servidor físico, normalmente
la aplicación tiene uso exclusivo de todos los recursos informáticos configurados en el sistema.
Por ejemplo, en un servidor con cuatro procesadores de cuatro núcleos, la aplicación puede
utilizar dieciséis núcleos de procesador. Por lo general, los requisitos de la aplicación son mucho
menores. Esto se debe a que el servidor físico se ha dimensionado para un posible estado
futuro de la aplicación que incluye un crecimiento de tres a cinco años y también incorpora
algún grado de picos de rendimiento de alto nivel de agua. En realidad, de un procesador
14.4 / PROBLEMAS DE PROCESO 643
Desde el punto de vista, la mayoría de los servidores están muy subutilizados, lo que es un fuerte impulsor de la consolidación a
Cuando las aplicaciones se migran a entornos virtuales, uno de los temas más importantes de
discusión es cuántos procesadores virtuales deben asignarse a sus máquinas virtuales. Dado que el
servidor físico que están desocupando tenía dieciséis núcleos, a menudo la solicitud del equipo de
aplicaciones es duplicar eso en el entorno virtual, independientemente de cuál fue su uso real. Además
de ignorar el uso en el servidor físico, otro elemento que se pasa por alto son las capacidades
mejoradas de los procesadores en el servidor de virtualización más nuevo. Si la aplicación se migró en
el límite inferior de cuando finalizó la vida útil o el arrendamiento de su servidor, sería de tres a cinco
años. Incluso a los tres años, la ley de Moore proporciona procesadores que serían cuatro veces más
rápidos que los del servidor físico original. Para ayudar a "dimensionar correctamente" las
configuraciones de la máquina virtual, hay herramientas disponibles que monitorearán el uso de
recursos (procesador, memoria, red y E / S de almacenamiento) en los servidores físicos y luego harán
recomendaciones para el tamaño óptimo de la máquina virtual. Si esa utilidad de estimación de
consolidación no se puede ejecutar, existen varias buenas prácticas. Una regla básica durante la
creación de una máquina virtual es comenzar con una vCPU y monitorear el rendimiento de la
aplicación. Agregar vCPU adicionales en una máquina virtual es simple y requiere un ajuste en la
configuración de la máquina virtual. La mayoría de los sistemas operativos modernos ni siquiera
requieren un reinicio antes de poder reconocer y utilizar la vCPU adicional. Otra buena práctica es no
sobreasignar la cantidad de vCPU en una VM. Es necesario programar una cantidad coincidente de
pCPU para las vCPU en una máquina virtual. VM. Si tiene cuatro vCPU en su VM, el hipervisor debe
programar simultáneamente cuatro pCPU en el host de virtualización en nombre de la máquina
virtual. En un host de virtualización muy ocupado, tener demasiadas vCPU configuradas para una VM
puede afectar negativamente el rendimiento de la aplicación de la VM, ya que es más rápido
programar una sola pCPU. Esto no significa que no haya aplicaciones que requieran varias CPU
virtuales. Los hay, y deben configurarse adecuadamente, pero la mayoría no lo hace.
Los sistemas operativos nativos administran el hardware actuando como intermediarios entre las solicitudes de código de la
aplicación y el hardware. A medida que se realizan solicitudes de datos o procesamiento, el sistema operativo los pasa a los controladores
de dispositivo correctos, a través de los controladores físicos, a los dispositivos de almacenamiento o de E / S, y viceversa. El sistema
operativo es el enrutador central de información y controla el acceso a todos los recursos físicos del hardware. Una función clave del
sistema operativo es ayudar a evitar que las llamadas al sistema malintencionadas o accidentales interrumpan las aplicaciones o el sistema
operativo en sí. Los anillos de protección describen el nivel de acceso o privilegio dentro de un sistema informático, y muchos sistemas
operativos y arquitecturas de procesadores aprovechan este modelo de seguridad. La capa más confiable a menudo se llama Ring 0 (cero) y
es donde funciona el kernel del sistema operativo y puede interactuar directamente con el hardware. Los anillos 1 y 2 son donde se
ejecutan los controladores de dispositivos mientras que las aplicaciones de usuario se ejecutan en el área menos confiable, el anillo 3. En la
práctica, sin embargo, los anillos 1 y 2 no se usan con frecuencia, lo que simplifica el modelo a espacios de ejecución confiables y no
confiables. El código de la aplicación no puede interactuar directamente con el hardware, ya que se ejecuta en Ring 3 y necesita que el
sistema operativo ejecute el código en su nombre en Ring 0. un disco o una conexión de red. Anillo 3. En la práctica, sin embargo, los anillos
1 y 2 no se usan con frecuencia, lo que simplifica el modelo a espacios de ejecución confiables y no confiables. El código de la aplicación no
puede interactuar directamente con el hardware, ya que se ejecuta en Ring 3 y necesita que el sistema operativo ejecute el código en su
nombre en Ring 0. un disco o una conexión de red. Anillo 3. En la práctica, sin embargo, los anillos 1 y 2 no se usan con frecuencia, lo que
simplifica el modelo a espacios de ejecución confiables y no confiables. El código de la aplicación no puede interactuar directamente con el
hardware, ya que se ejecuta en Ring 3 y necesita que el sistema operativo ejecute el código en su nombre en Ring 0. un disco o una
conexión de red.
Los hipervisores se ejecutan en Ring 0 controlando el acceso al hardware de las máquinas virtuales
que alojan. Los sistemas operativos de esas máquinas virtuales también creen que se ejecutan
644 Capítulo 14 / Máquinas virtuales
en Ring 0, y de alguna manera lo hacen, pero solo en el hardware virtual que se crea como
parte de la máquina virtual. En el caso de un apagado del sistema, el sistema operativo del
invitado solicitaría un comando de apagado en el anillo 0. El hipervisor intercepta la
solicitud; de lo contrario, el servidor físico se apagaría, lo que causaría estragos en el
hipervisor y en cualquier otra máquina virtual alojada. En cambio, el hipervisor responde
al sistema operativo invitado que el apagado se está produciendo según lo solicitado, lo
que permite que el sistema operativo invitado complete los procesos de apagado del
software necesarios.
Al igual que la cantidad de CPU virtuales, la cantidad de memoria asignada a una máquina virtual es
una de las opciones de configuración más cruciales; de hecho, los recursos de memoria suelen ser el
primer cuello de botella al que llegan las infraestructuras virtuales a medida que crecen. Además, al
igual que la virtualización de procesadores, el uso de la memoria en entornos virtuales tiene más que
ver con la gestión del recurso físico que con la creación de una entidad virtual. Al igual que con un
servidor físico, una máquina virtual debe configurarse con suficiente memoria para funcionar de
manera eficiente al proporcionar espacio para el sistema operativo y las aplicaciones. Nuevamente, la
máquina virtual está configurada con menos recursos que los que contiene el host físico. Un ejemplo
sencillo sería un servidor físico con 8 GB de RAM. Una máquina virtual aprovisionada con 1 GB de
memoria solo vería 1 GB de memoria, aunque el servidor físico en el que está alojado tiene más.
Cuando la máquina virtual usa recursos de memoria, el hipervisor administra las solicitudes de
memoria mediante el uso de tablas de traducción para que el sistema operativo invitado (VM) dirija el
espacio de memoria en las direcciones que Este es un buen primer paso, pero persisten los
problemas. Al igual que con el procesador, los propietarios de aplicaciones solicitan asignaciones de
memoria que reflejen las infraestructuras físicas desde las que migraron, independientemente de si el
tamaño de la asignación está garantizado o no, lo que genera máquinas virtuales sobreaprovisionadas
y recursos de memoria desperdiciados. En el caso de nuestro servidor de 8 GB, solo se podían alojar
siete máquinas virtuales de 1 GB, y el 1 GB restante se necesitaba para el hipervisor. Además de
"dimensionar correctamente" las máquinas virtuales en función de sus características de rendimiento
reales, hay funciones integradas en los hipervisores que ayudan a optimizar el uso de la memoria. Uno
de estos escompartir página(ver Figura 14.7). El uso compartido de páginas es similar a la
deduplicación de datos, una técnica de almacenamiento que reduce la cantidad de bloques de
almacenamiento que se utilizan. Cuando se crea una instancia de una máquina virtual, el sistema
operativo y las páginas de la aplicación se cargan en la memoria. Si varias máquinas virtuales están
cargando la misma versión del sistema operativo o ejecutando las mismas aplicaciones, muchos de
estos bloques de memoria están duplicados. El hipervisor ya está administrando las transferencias de
memoria virtual a física y puede determinar si una página ya está cargada en la memoria. En lugar de
cargar una página duplicada en la memoria física, el hipervisor proporciona un enlace a la página
compartida en la tabla de traducción de la máquina virtual. En los hosts donde los invitados ejecutan el
mismo sistema operativo y las mismas aplicaciones, se puede recuperar entre el 10 y el 40% de la
memoria física real. Al 25%,
Dado que el hipervisor gestiona el uso compartido de páginas, los sistemas operativos de la
máquina virtual desconocen lo que sucede en el sistema físico. Otra estrategia para el uso eficiente de
la memoria es similar al aprovisionamiento ligero en la gestión del almacenamiento.
14.6 / GESTIÓN DE E / S 645
Memoria física
un administrador para asignar más almacenamiento a un usuario del que realmente está
presente en el sistema. La razón es proporcionar una marca de agua alta que a menudo nunca
se alcanza. Lo mismo se puede hacer con la memoria de la máquina virtual. Asignamos 1 GB de
memoria, pero eso es lo que ve el sistema operativo de la VM. El hipervisor puede usar una
parte de esa memoria asignada para otra VM recuperando páginas más antiguas que no se
están usando. El proceso de recuperación se realiza medianteglobo. El hipervisor activa un
controlador de globo que (virtualmente) infla y presiona el sistema operativo invitado para
descargar páginas en el disco. Una vez que se borran las páginas, el controlador de globo se
desinfla y el hipervisor puede usar la memoria física para otras VM. Este proceso ocurre durante
momentos de contención de memoria. Si nuestras VM de 1GB usaran la mitad de su memoria
en promedio, nueve VM requerirían solo 4.5GB y el resto como grupo compartido administrado
por el hipervisor y algunas para la sobrecarga del hipervisor. Incluso si alojamos tres máquinas
virtuales de 1 GB adicionales, todavía hay una reserva compartida. Esta capacidad de asignar
más memoria de la que existe físicamente en un host se denominasobreasignación de
memoria. No es raro que los entornos virtualizados tengan entre 1,2 y 1,5 veces la memoria
asignada y, en casos extremos, muchas veces más.
Existen técnicas de administración de memoria adicionales que proporcionan una mejor
utilización de los recursos. En todos los casos, los sistemas operativos de las máquinas virtuales
ven y tienen acceso a la cantidad de memoria que se les ha asignado. El hipervisor gestiona ese
acceso a la memoria física para garantizar frente a asegurar que todas las solicitudes se
atiendan de manera oportuna sin afectar a las máquinas virtuales. En los casos en que se
requiera más memoria física de la disponible, el hipervisor se verá obligado a recurrir a la
paginación en el disco. En entornos de clústeres de hosts múltiples, las máquinas virtuales se
pueden migrar automáticamente en vivo a otros hosts cuando ciertos recursos escasean.
14.6 GESTIÓN DE E / S
El rendimiento de la aplicación a menudo está directamente relacionado con el ancho de banda que se
le ha asignado a un servidor. Ya sea el acceso al almacenamiento que se ha bloqueado o el tráfico
restringido a la red, cualquiera de los casos hará que una aplicación se perciba como de bajo
rendimiento. De esta manera, durante la virtualización de cargas de trabajo, la virtualización de E / S
es un elemento crítico. La arquitectura de cómo se gestiona la E / S en un entorno virtual
646 Capítulo 14 / Máquinas virtuales
Aplicaciones
Máquina virtual
Sistema operativo
Controlador NIC
Hipervisor
Dispositivo emulado
Servidor físico
Controlador NIC
NIC
La red
es sencillo (ver Figura 14.8). En la máquina virtual, el sistema operativo realiza una llamada al
controlador del dispositivo como lo haría en un servidor físico. A continuación, el controlador del
dispositivo se conecta con el dispositivo; aunque en el caso del servidor virtual, el dispositivo es un
dispositivo emulado que es organizado y administrado por el hipervisor. Estos dispositivos emulados
suelen ser un dispositivo real común, como una tarjeta de interfaz de red Intel e1000 o controladores
SGVA o IDE genéricos simples. Este dispositivo virtual se conecta a la pila de E / S del hipervisor que se
comunica con el controlador de dispositivo que está asignado a un dispositivo físico en el servidor
host, traduciendo las direcciones de E / S de invitado a las direcciones de E / S del host físico. El
hipervisor controla y monitorea las solicitudes del controlador de dispositivo de la máquina virtual, a
través de la pila de E / S, fuera del dispositivo físico y viceversa. enrutar las llamadas de E / S a los
dispositivos correctos en las máquinas virtuales correctas. Existen algunas diferencias arquitectónicas
entre los proveedores, pero el modelo básico es similar.
Las ventajas de virtualizar la ruta de E / S de la carga de trabajo son muchas. Permite la
independencia del hardware al abstraer los controladores específicos del proveedor a versiones más
generalizadas que se ejecutan en el hipervisor. Una máquina virtual que se ejecuta en un servidor IBM
como host se puede migrar en vivo a un host de servidor blade HP sin preocuparse por
incompatibilidades de hardware o desajustes de versiones. Esta abstracción permite una de las
mayores fortalezas de disponibilidad de la virtualización: la migración en vivo. El intercambio de
recursos agregados, rutas de red, por ejemplo, también se debe a esta abstracción. En soluciones más
maduras, existen capacidades para controlar de forma granular los tipos de tráfico de red y el ancho
de banda que se otorga a máquinas virtuales individuales o grupos de máquinas virtuales para
asegurar un rendimiento adecuado en un entorno compartido para garantizar un nivel de calidad de
servicio elegido. Además de estos, hay otras características que mejoran la seguridad y la
disponibilidad. La compensación es que el hipervisor está administrando todo el tráfico, para el cual
fue diseñado, pero requiere una sobrecarga del procesador. En los primeros días de la virtualización,
este era un problema que podría ser un factor limitante, pero los procesadores multinúcleo más
rápidos y los hipervisores sofisticados prácticamente han eliminado esta preocupación.
14.7 / VMware esXi 647
Además del modelo descrito anteriormente, algunas aplicaciones o usuarios exigirán una ruta
dedicada. En este caso, existen opciones para evitar la supervisión y la pila de E / S del hipervisor, y
conectarse directamente desde el controlador de dispositivo de la máquina virtual al dispositivo físico
en el host de virtualización. Esto proporciona la virtud de tener un recurso dedicado sin gastos
generales que brindan el mayor rendimiento posible. Además de un mejor rendimiento, dado que el
hipervisor tiene una participación mínima, hay menos impacto en el procesador del servidor host. La
desventaja de un dispositivo de E / S conectado directamente es que la máquina virtual está vinculada
al servidor físico en el que se ejecuta. Sin la abstracción del dispositivo, la migración en vivo no es
posible fácilmente, lo que puede reducir potencialmente la disponibilidad. Funciones proporcionadas
por el hipervisor, como la sobreasignación de memoria o el control de E / S, no están disponibles, lo
que podría desperdiciar recursos infrautilizados y mitigar la necesidad de virtualización. Aunque un
modelo de dispositivo dedicado proporciona un mejor rendimiento, hoy en día rara vez se utiliza, ya
que los centros de datos optan por la flexibilidad que proporciona la E / S virtualizada.
Soporte de VM y
recurso
administración
VMkernel
(a) ESX
Comandos CLI
para la configuración
y apoyo
(b) ESXi
Este tamaño pequeño permite a los proveedores de servidores entregar hardware con ESXi ya
disponible en la memoria flash del servidor. La gestión de la configuración, la supervisión y la creación
de scripts ahora están disponibles a través de las utilidades de la interfaz de línea de comandos. Los
agentes de terceros también se ejecutan en VMkernel después de ser certificados y firmados
digitalmente. Esto permite, por ejemplo, que un proveedor de servidores que brinde monitoreo de
hardware incluya un agente en VMkernel que pueda devolver sin problemas métricas de hardware,
como la temperatura interna o el estado de los componentes, a las herramientas de administración de
VMware u otras herramientas de administración.
Las máquinas virtuales se alojan a través de los servicios de infraestructura en VMkernel.
Cuando las máquinas virtuales solicitan recursos, el hipervisor cumple esas solicitudes,
trabajando a través de los controladores de dispositivo adecuados. Como se describió
anteriormente, el hipervisor coordina todas las transacciones entre las múltiples máquinas
virtuales y los recursos de hardware en el servidor físico.
Aunque los ejemplos analizados hasta ahora son muy básicos, VMware ESXi proporciona
funciones avanzadas y sofisticadas de disponibilidad, escalabilidad, seguridad, capacidad de
gestión y rendimiento. Se introducen capacidades adicionales con cada versión, mejorando las
capacidades de la plataforma. Algunos ejemplos son los siguientes:
• Almacenamiento VMotion: Permite la reubicación de los archivos de datos que componen una
máquina virtual, mientras esa máquina virtual está en uso.
• Tolerancia a fallos: Crea una copia bloqueada de una máquina virtual en un host
diferente. Si el host original sufre una falla, las conexiones de la máquina virtual se
trasladan a la copia, sin interrumpir a los usuarios ni a la aplicación que están
usando, a diferencia de la Alta Disponibilidad, que requeriría reiniciar la máquina
virtual en otro servidor.
• Administrador de recuperación del sitio: Utiliza varias tecnologías de replicación para copiar
máquinas virtuales seleccionadas a un sitio secundario en el caso de un desastre en el centro de
datos. El sitio secundario se puede levantar en cuestión de minutos; las máquinas virtuales se
encienden automáticamente de una manera seleccionada y escalonada para asegurar una transición
suave y precisa.
• Programador de recursos distribuidos (DRS): Coloca de forma inteligente las máquinas virtuales en
los hosts para el inicio y puede equilibrar automáticamente las cargas de trabajo a través de VMotion
según las políticas comerciales y el uso de recursos. Un aspecto de esto, la Administración de energía
distribuida (DPM), puede apagar (y encender) hosts físicos según sea necesario. Storage DRS puede
migrar activamente archivos de máquinas virtuales en función de la capacidad de almacenamiento y la
latencia de E / S, nuevamente según las reglas comerciales y la utilización de recursos.
Estas son solo algunas de las características que extienden la solución ESXi de VMware más allá
de ser un simple hipervisor que puede admitir máquinas virtuales, a una plataforma para el nuevo
centro de datos y la base de la computación en la nube.
650 Capítulo 14 / Máquinas virtuales
conductores
KernelU KernelU
Kernel0
Hipervisor Xen
Hardware
Partición principal
Partición secundaria Partición secundaria
VM
WMI trabajadores
Hardware
los controladores de dispositivos. Al igual que los controladores FrontEnd y BackEnd en Xen, la partición
principal en Hyper-V utiliza un proveedor de servicios de virtualización (VSP) para proporcionar servicios de
dispositivo a las particiones secundarias. Las particiones secundarias se comunican con los VSP mediante un
cliente de servicio de virtualización (o consumidor). (VSC) para sus necesidades de E / S.
Microsoft Hyper-V tiene desafíos de disponibilidad similares a los de Xen debido a las necesidades del
sistema operativo en la partición principal, la contención de recursos que requiere una copia adicional de
Windows en el servidor y el conducto de E / S único. Desde el punto de vista de las características, Hyper-V es
muy robusto, aunque no tan ampliamente utilizado como ESXi, ya que todavía es relativamente nuevo en el
mercado. A medida que pase el tiempo y aparezcan nuevas funciones, la adopción probablemente
aumentará.
14,9 Java VM
Aunque Java Virtual Machine (JVM) tiene el término máquina virtual como parte de su nombre, su
implementación y usos son diferentes a los modelos que hemos cubierto. Los hipervisores admiten
una o más máquinas virtuales en un host. Estas máquinas virtuales son cargas de trabajo autónomas,
cada una de las cuales admite un sistema operativo y aplicaciones y, desde su perspectiva, tienen
acceso a un conjunto de dispositivos de hardware que proporcionan recursos informáticos, de
almacenamiento y de E / S. El objetivo de una máquina virtual Java es proporcionar un espacio de
tiempo de ejecución para que un conjunto de código Java se ejecute en cualquier sistema operativo
instalado en cualquier plataforma de hardware, sin necesidad de realizar cambios de código para
adaptarse a los diferentes sistemas operativos o hardware. Ambos modelos tienen como objetivo ser
independientes de la plataforma mediante el uso de cierto grado de abstracción.
La JVM se describe como una máquina de computación abstracta, que consta de un conjunto
de instrucciones, una pc (contador de programa) Registrarse, a apilar para contener variables y
resultados, un montón para datos en tiempo de ejecución y recolección de basura, y un método área
para código y constantes. La JVM puede admitir varios subprocesos y cada subproceso tiene su propio
registro y áreas de pila, aunque las áreas de montón y método se comparten entre todos los
subprocesos. Cuando se crea una instancia de la JVM, se inicia el entorno de ejecución, las estructuras
de memoria se asignan y se completan con el método (código) y las variables seleccionados, y el
programa comienza. El código que se ejecuta en la JVM se interpreta en tiempo real desde el lenguaje
Java en el código binario apropiado. Si ese código es válido y se adhiere a los estándares esperados,
comenzará a procesarse. Si no es válido,
652 Capítulo 14 / Máquinas virtuales
Linux VServer es un enfoque de contenedor virtualizado, rápido y de código abierto para implementar
máquinas virtuales en un servidor Linux [SOLT07, LIGN05]. Solo se trata de una copia del kernel de
Linux. VServer consiste en una modificación relativamente modesta del kernel más un pequeño
conjunto de áreas de usuario del sistema operativo1 instrumentos. El kernel de VServer Linux admite
variosServidores virtuales. El kernel administra todos los recursos y tareas del sistema, incluida la
programación de procesos, la memoria, el espacio en disco y el tiempo del procesador.
Arquitectura
Cada servidor virtual está aislado de los demás mediante las capacidades del kernel de Linux.
Esto proporciona seguridad y facilita la configuración de varias máquinas virtuales en una única
plataforma. El aislamiento involucra cuatro elementos: chroot, chcontext, chbind y capacidades.
los chroot El comando es un comando de UNIX o Linux para hacer que el directorio raíz (/) se
convierta en algo diferente al predeterminado durante la vida útil del proceso actual. Solo lo pueden
ejecutar usuarios privilegiados y se utiliza para dar acceso a un proceso (comúnmente un servidor de
red como FTP o HTTP) a una parte restringida del sistema de archivos. Este comando proporciona
aislamiento del sistema de archivos. Todos los comandos ejecutados por el servidor virtual solo
pueden afectar los archivos que comienzan con la raíz definida para ese servidor.
los chcontext La utilidad de Linux asigna un nuevo contexto de seguridad y ejecuta
comandos en ese contexto. El habitual oalojado El contexto de seguridad es el contexto 0. Este
contexto tiene los mismos privilegios que el usuario raíz (UID 0): este contexto puede ver y
eliminar otras tareas en los otros contextos. El contexto número 1 se utiliza para ver otros
contextos pero no puede afectarlos. Todos los demás contextos proporcionan un aislamiento
completo: los procesos de un contexto no pueden ver ni interactuar con procesos de otro
contexto. Esto proporciona la capacidad de ejecutar contextos similares en la misma
computadora sin ninguna interacción posible en el nivel de la aplicación. Por tanto, cada
servidor virtual tiene su propio contexto de ejecución que proporcionaaislamiento del proceso.
loschbind La utilidad ejecuta un comando y bloquea el proceso resultante y sus hijos para
que usen una dirección IP específica. Una vez llamados, a todos los paquetes enviados por este
servidor virtual a través de la interfaz de red del sistema se les asigna la dirección IP de envío
derivada del argumento dado a chbind.la red
1 El término userland se refiere a todo el software de aplicación que se ejecuta en el espacio del usuario en lugar del espacio del kernel.
Área de usuario del SO generalmente se refiere a los diversos programas y bibliotecas que utiliza el sistema operativo para interactuar con
el kernel: software que realiza entrada / salida, manipula objetos del sistema de archivos, etc.
14.10 / linuX VserVer Virtual MaChine arChiteCture 653
Servidor Servidor
aplicaciones aplicaciones
Plataforma virtual
Plataforma de hospedaje
Administrador de VM.
Administrador remoto.
Servicios principales
/hogar
/hogar
/hogar
/ proc
/ proc
/ proc
/ dev
/ dev
/ dev
/ usr
/ usr
/ usr
Imagen de SO estándar
aislamiento: Cada servidor virtual utiliza una dirección IP distinta y separada. Otros servidores
virtuales no pueden acceder al tráfico entrante destinado a un servidor virtual.
Finalmente, a cada servidor virtual se le asigna un conjunto de capacidades.El concepto de capacidad
bilidades, como se usa en Linux, se refiere a una partición de los privilegios disponibles para un usuario root,
como la capacidad de leer archivos o rastrear procesos propiedad de otro usuario. Por lo tanto, a cada
servidor virtual se le puede asignar un subconjunto limitado de privilegios del usuario raíz. Esto proporciona
aislamiento de raíz.VServer también puede establecer límites de recursos, como límites a la cantidad de
memoria virtual que puede usar un proceso.
La figura 14.12 muestra la arquitectura general de Linux VServer. VServer proporciona una
imagen de SO virtualizada compartida, que consta de un sistema de archivos raíz y un conjunto
compartido de bibliotecas del sistema y servicios del kernel. Cada máquina virtual se puede iniciar,
apagar y reiniciar de forma independiente. La figura 14.12 muestra tres grupos de software que se
ejecutan en el sistema informático.plataforma de alojamiento incluye la imagen del sistema
operativo compartido y una VM host privilegiada, cuya función es monitorear y administrar las otras
VM. losplataforma virtual crea máquinas virtuales y es la vista del sistema vista por el aplicaciones
ejecutándose en las máquinas virtuales individuales.
Programación de procesos
La instalación de la máquina virtual Linux VServer proporciona una forma de controlar el uso del
tiempo del procesador por parte de la VM. VServer superpone un filtro de depósito de tokens (TBF)
sobre la programación estándar de Linux. El propósito del TBF es determinar cuánto tiempo de
ejecución del procesador (procesador único, multiprocesador o multinúcleo) se asigna a cada VM. Si
solo se usa el programador de Linux subyacente para programar procesos globalmente en todas las
VM, los procesos de escasez de recursos en una VM desplazan a los procesos en otras VM.
La figura 14.13 ilustra el concepto TBF. Para cada VM, se define un depósito con una capacidad
deS tokens. Los tokens se agregan al depósito a una tasa deR tokens durante cada intervalo de tiempo
de duración T. Cuando el depósito está lleno, los tokens entrantes adicionales simplemente se
descartan. Cuando un proceso se ejecuta en esta VM, consume un token por cada tic del reloj del
temporizador. Si el balde se vacía, el proceso se pone en espera y no se puede reiniciar hasta que el
balde se vuelva a llenar a un valor de umbral mínimo deMETRO tokens.En ese punto, el proceso se
reprograma.Una consecuencia significativa del enfoque TBF
654 Capítulo 14 / Máquinas virtuales
es que una máquina virtual puede acumular tokens durante un período de inactividad y luego usar los tokens
en una ráfaga cuando sea necesario.
Ajustando los valores de R y T permite regular el porcentaje de capacidad que puede reclamar
una VM. Para un solo procesador, podemos definir la asignación de capacidad de la siguiente manera:
R
= fracción de la asignación del procesador
T
Esta ecuación denota la fracción de un solo procesador en un sistema. Así, por ejemplo, si un sistema
es multinúcleo con cuatro núcleos y deseamos proporcionar una VM en promedio de un procesador
dedicado, entonces establecemos R = 1 y T = 4. El sistema general está limitado de la siguiente
manera. Si haynorte VM, luego:
norte RI
a ... 1
I= 1 TI
Los parametros S y METRO están configurados para penalizar a una VM después de una cierta
cantidad de tiempo de ráfaga. Los siguientes parámetros deben configurarse o asignarse para una VM:
Después de un tiempo de ráfaga deB, la máquina virtual sufre un tiempo de espera de H.Con estos
parámetros, es posible calcular los valores deseados de S y METRO como sigue:
R
METRO = W * H *
T
R
S = W * B * a1 - B
T
dónde W es la velocidad a la que se ejecuta el programa (toma decisiones). Por ejemplo,
considere una máquina virtual con un límite de 1/2 del tiempo del procesador, y deseamos decir
que después de usar el procesador durante 30 segundos, habrá un tiempo de espera de 5
segundos. El programador se ejecuta a 1000 Hz. Este requisito se cumple con los siguientes
valores:METRO = 1,000 * 5 * 0.5 = 2500 fichas; S = 1000 * 30 * (1 - 0,5) = 15.000 fichas.
14.12 / TÉRMINOS CLAVE, PREGUNTAS DE REVISIÓN Y PROBLEMAS 655
14.11 RESUMEN
La tecnología de virtualización permite que una sola PC o servidor ejecute simultáneamente múltiples
sistemas operativos o múltiples sesiones de un solo sistema operativo. En esencia, el sistema
operativo host puede admitir varias máquinas virtuales (VM), cada una de las cuales tiene las
características de un sistema operativo en particular y, en algunas versiones de virtualización, las
características de una plataforma de hardware en particular.
Una tecnología de máquina virtual común hace uso de un monitor de máquina
virtual (VMM) o hipervisor, que se encuentra en un nivel más bajo que la VM y admite
VM. Hay dos tipos de hipervisores, que se distinguen por si hay otro sistema
operativo entre el hipervisor y el host. Un hipervisor de tipo 1 se ejecuta directamente
en el hardware de la máquina y un hipervisor de tipo 2 opera sobre el sistema
operativo host.
Java VM ejemplifica un enfoque muy diferente para implementar un entorno de VM. El objetivo de una
VM de Java es proporcionar un espacio de tiempo de ejecución para que un conjunto de código Java se
ejecute en cualquier sistema operativo instalado en cualquier plataforma de hardware, sin necesidad de
realizar cambios de código para adaptarse a los diferentes sistemas operativos o hardware.
Términos clave
Preguntas de revisión
Problemas
14.1. Técnicas como la sobreasignación de memoria y el uso compartido de páginas permiten que a las máquinas
virtuales se les asignen más recursos de los que se encuentran físicamente en un solo host de virtualización.
¿Esto permite que el agregado de las máquinas virtuales realice más trabajo real del que sería capaz de
realizar una carga de trabajo física en el mismo hardware?