Stallings Chapter 14.en - Es

Traducido del inglés al español - www.onlinedoctranslator.
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
14.3 Virtualización de contenedores

Grupos de control del kernel
Conceptos de contenedor
Sistema de archivos contenedor
Microservicios
Estibador
14,4 Problemas con el procesador
14,5 Gestión de la memoria
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
14.12 Términos clave, preguntas de revisión y problemas
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.
• Comprender los problemas de administración de E / S relacionados con la implementación de una

máquina virtual.
• Compare y contraste VMware ESXi, Hyper-V, Xen y Java VM.

• Explique el funcionamiento de la máquina virtual Linux.
Este capítulo se centra en la aplicación de la virtualización al diseño de sistemas operativos. La

virtualización abarca una variedad de tecnologías para administrar los recursos informáticos al
proporcionar una capa de traducción de software, conocida como capa de abstracción, entre el
software y el hardware físico. La virtualización convierte los recursos físicos en recursos lógicos
o virtuales. La virtualización permite a los usuarios, las aplicaciones y el software de
administración que operan por encima de la capa de abstracción administrar y usar los recursos
sin necesidad de conocer los detalles físicos de los recursos subyacentes.
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.
14.1 CONCEPTOS DE MÁQUINA VIRTUAL
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
Figura 14.1 Concepto de máquina virtual
La virtualización no es una tecnología nueva. Durante la década de 1970, los sistemas

mainframe de IBM ofrecieron las primeras capacidades que permitirían a los programas usar solo una
parte de los recursos de un sistema. Varias formas de esa habilidad han estado disponibles en
plataformas desde ese momento. La virtualización se incorporó a la informática convencional a
principios de la década de 2000, cuando la tecnología estaba disponible comercialmente en servidores
x86. Las organizaciones sufrían un exceso de servidores debido a la estrategia de "una aplicación, un
servidor" impulsada por Microsoft Windows. La Ley de Moore impulsó mejoras rápidas de hardware
que superaron la capacidad del software, y la mayoría de estos servidores estaban muy subutilizados,
a menudo consumiendo menos del 5% de los recursos disponibles en cada servidor. Además, esta
sobreabundancia de servidores llenó los centros de datos y consumió grandes cantidades de energía y
refrigeración, presionar la capacidad de una corporación para administrar y mantener su
infraestructura. La virtualización ayudó a aliviar este estrés.
La solución que permite la virtualización es una monitor de máquina virtual (VMM),
o comúnmente conocido hoy como hipervisor. Este software se encuentra entre el hardware y las máquinas
virtuales y actúa como un intermediario de recursos. En pocas palabras, permite que varias máquinas
virtuales coexistan de forma segura en un único host de servidor físico y compartan los recursos de ese host.
La Figura 14.1 ilustra este tipo de virtualización en términos generales. En la parte superior de la plataforma
de hardware se encuentra algún tipo de software de virtualización, que puede consistir en el sistema
operativo host más software de virtualización especializado o simplemente un paquete de software que
incluye funciones del sistema operativo host y funciones de virtualización, como se explica a continuación. El
software de virtualización proporciona la abstracción de todos los recursos físicos (como el procesador, la
memoria, la red y el almacenamiento) y, por lo tanto, permite que se ejecuten varias pilas de computación,
llamadas máquinas virtuales, en un solo host físico.
Cada máquina virtual incluye un sistema operativo, llamado sistema operativo invitado. Este sistema operativo puede ser el mismo que el
sistema operativo host o uno diferente. Por ejemplo, un sistema operativo Windows invitado podría ejecutarse en una máquina virtual
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.
• Versatilidad: El uso del hardware se puede optimizar maximizando el número de tipos de

aplicaciones que puede manejar una sola computadora.
• Consolidación: Un recurso de gran capacidad o alta velocidad, tal servidor se puede
utilizar de manera más eficiente al compartir el recurso entre múltiples aplicaciones
simultáneamente.
• Agregando: La virtualización facilita la combinación de varios recursos en un
recurso virtual, como en el caso de la virtualización del almacenamiento.
• Dinámica: Con el uso de máquinas virtuales, los recursos de hardware se pueden asignar
fácilmente de manera dinámica, lo que mejora el equilibrio de carga y la tolerancia a fallas.
• Facilidad de manejo: Las máquinas virtuales facilitan la implementación y la prueba de

software.
• Mayor disponibilidad: Los hosts de máquinas virtuales se agrupan para formar grupos de recursos
informáticos. Varias máquinas virtuales están alojadas en cada uno de estos servidores y, en el caso de
una falla del servidor físico, las máquinas virtuales en el host fallido se pueden reiniciar rápida y
automáticamente en otro host del clúster. En comparación con proporcionar este tipo de
disponibilidad para un servidor físico, los entornos virtuales pueden proporcionar una mayor
disponibilidad a un costo significativamente menor y con menos complejidad.
14.2 / HIPERVISORES 631
Las ofertas de máquinas virtuales comerciales de empresas como VMware y Microsoft se

utilizan ampliamente en servidores, y se han vendido millones de copias. Un aspecto clave de la
virtualización de servidores es que, además de la capacidad de ejecutar múltiples VM en una máquina,
las VM pueden verse como recursos de red. La virtualización del servidor enmascara los recursos del
servidor, incluido el número y la identidad de los servidores físicos, procesadores y sistemas
operativos individuales, de los usuarios del servidor. Esto hace posible la partición de un solo host en
varios servidores independientes, conservando los recursos de hardware. También hace posible
migrar rápidamente un servidor de una máquina a otra para el equilibrio de carga o para la
conmutación dinámica en caso de falla de la máquina. La virtualización de servidores se ha convertido
en un elemento central en el manejo de aplicaciones de “big data” y en la implementación de
infraestructuras de computación en la nube.
Además de su uso en entornos de servidor, estas tecnologías de VM también se utilizan en
entornos de escritorio para ejecutar varios sistemas operativos, normalmente Windows y Linux.
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.
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.
• Emulación de dispositivos y control de acceso: Emulando todos los dispositivos de red y

almacenamiento (bloque) que esperan diferentes controladores nativos en VM, mediando el
acceso a dispositivos físicos por diferentes VM.
• 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).
• Administración de plataforma de hipervisor y software de hipervisor: Implica la configuración de

parámetros para las interacciones del usuario con el host del hipervisor, así como con el software del
hipervisor.
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
Aplicaciones Aplicaciones bibliotecas bibliotecas
bibliotecas bibliotecas SO invitado SO invitado
SO invitado SO invitado Hipervisor tipo 2
Hipervisor tipo 1 Sistema operativo host
Hardware compartido Hardware compartido
(a) Hipervisor de tipo 1 (b) Hipervisor de tipo 2
Figura 14.2 Hipervisores tipo 1 y tipo 2
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.
• Los hipervisores de tipo 2 permiten al usuario aprovechar la virtualización sin necesidad

de dedicar un servidor solo a esa función. Los desarrolladores que necesitan ejecutar
múltiples entornos como parte de su proceso, además de aprovechar el espacio de
trabajo productivo personal que proporciona un sistema operativo de PC, pueden hacer
ambas cosas con un hipervisor tipo 2 instalado como una aplicación en su escritorio
LINUX o Windows. Las máquinas virtuales que se crean y utilizan se pueden migrar o
copiado de un entorno de hipervisor a otro, lo que reduce el tiempo de implementación y

aumenta la precisión de lo que se implementa, lo que reduce el tiempo de comercialización de
un proyecto.
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
Aplicación Aplicación Aplicación Aplicación Aplicación Aplicación
Huésped Huésped Huésped Huésped Huésped Huésped
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
(a) Hipervisor de tipo 1 (b) Hipervisor tipo 1 paravirtualizado

con SO invitados paravirtualizados
Figura 14.3 Paravirtualización

14.3 / CONTENEDOR VIRTUALIZACIÓN 635
modificación de los controladores reales. Esta disposición es más rápida con menos gastos generales que una
configuración no paravirtualizada.
Virtualización asistida por hardware

De manera similar, los fabricantes de procesadores AMD e Intel agregaron funcionalidad a sus
procesadores para mejorar el rendimiento con hipervisores. AMD-V y VT-x de Intel designan las
extensiones de virtualización asistida por hardware que los hipervisores pueden aprovechar durante
el procesamiento. Los procesadores Intel ofrecen un conjunto de instrucciones adicional llamado
Extensiones de máquina virtual (VMX). Al tener algunas de estas instrucciones como parte del
procesador, los hipervisores ya no necesitan mantener estas funciones como parte de su código base,
el código en sí puede ser más pequeño y más eficiente, y las operaciones que soportan son mucho
más rápidas ya que ocurren completamente en el procesador. Este soporte asistido por hardware no
requiere un sistema operativo invitado modificado a diferencia de la paravirtualización.
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.
Implementar un dispositivo de aplicación preinstalado y preconfigurado es mucho más fácil

que preparar un sistema, instalar la aplicación y configurarlo y configurarlo. Los dispositivos virtuales
se están convirtiendo en un medio de facto de distribución de software y han dado lugar a un nuevo
tipo de negocio: el proveedor de dispositivos virtuales.
Además de muchos dispositivos virtuales útiles orientados a aplicaciones, un desarrollo
relativamente reciente e importante es el dispositivo virtual de seguridad (SVA). El SVA es una
herramienta de seguridad que realiza la función de monitorear y proteger las otras VM (VM de
usuario), y se ejecuta fuera de esas VM en una VM especialmente reforzada con seguridad. El SVA
obtiene su visibilidad del estado de una máquina virtual (incluido el estado del procesador, los
registros y el estado de la memoria y los dispositivos de E / S), así como el tráfico de red entre las
máquinas virtuales y entre las máquinas virtuales y el hipervisor, a través delintrospección de la
máquina virtualAPI del hipervisor. NIST SP 800-125 (Recomendaciones de seguridad para la
implementación del hipervisor, Octubre de 2014) señala las ventajas de esta solución. Específicamente,
el SVA es:
• No vulnerable a una falla en el sistema operativo invitado
• Independiente de la configuración de la red virtual y no es necesario volver a configurarla

cada vez que la configuración de la red virtual cambia debido a la migración de las VM o al
cambio en la conectividad entre las VM residentes en el host del hipervisor.
14.3 VIRTUALIZACIÓN DE CONTENEDORES
Un enfoque relativamente reciente de la virtualización se conoce como virtualización de contenedores. En este

enfoque, el software, conocido comocontenedor de virtualización, se ejecuta en la parte superior del kernel del
sistema operativo host y proporciona un entorno de ejecución aislado para las aplicaciones. diferente a
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.
Grupos de control del kernel
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.
• Crea un proceso para el contenedor.

• Administre los puntos de montaje del sistema de archivos.
• Solicite recursos del kernel, como memoria, dispositivos de E / S y direcciones IP.
Un ciclo de vida típico de los contenedores basados en Linux se puede entender a través de
diferentes fases de los contenedores de Linux:
Máquina virtual
Aplicación Aplicación Aplicación Aplicación
Bibliotecas Bibliotecas
Máquina virtual
SO invitado SO invitado
Hipervisor
SO invitado SO invitado
SO del host
Hipervisor
Hardware Hardware
(a) Hipervisor de tipo 1 (b) Hipervisor de tipo 2
Envase
Envase
Motor de contenedor
SO del host
Hardware
(c) Contenedor
Figura 14.4 Comparación de máquinas virtuales y contenedores
• 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.
• Configuración: Los contenedores están configurados para ejecutar aplicaciones o comandos

específicos. La configuración del contenedor de Linux incluye parámetros de red (p. Ej., Dirección IP),
sistemas de archivos raíz, operaciones de montaje y dispositivos a los que se permite el acceso a
través del entorno del contenedor. En general, los contenedores están configurados para permitir la
ejecución de una aplicación en los recursos del sistema controlados (como el límite superior en el
acceso a la memoria de la aplicación).
• 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.
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
Controlador de dispositivo de SO invitado
Dispositivo de E / S virtual Solicitud
Intercepción de hipervisor Indirección a través de grupos de control del kernel
Controlador de dispositivo físico Controlador de dispositivo físico
Dispositivo de E / S físico Dispositivo de E / S físico
(a) Hipervisor (b) Contenedor
Figura 14.5 Flujo de datos para la operación de E / S a través del hipervisor y

Envase
Las dos características destacables de los envases son las siguientes:
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.
2. El software de gestión de contenedores simplifica el procedimiento de creación y

gestión de contenedores.
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.
• La virtualización de VM funciona en la frontera del hardware y el sistema operativo. Es capaz de

proporcionar un sólido aislamiento de rendimiento y garantías de seguridad con la interfaz estrecha
entre las máquinas virtuales y los hipervisores. La contenedorización, que se encuentra entre el
sistema operativo y las aplicaciones, incurre en una menor sobrecarga, pero potencialmente introduce
mayores vulnerabilidades de seguridad.
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.
Sistema de archivos 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
/ vz / root
1x 2 años 3z
compartimiento dev etc sistema usuarios var
abrasador rjones
escritorio docs Biblioteca
Figura 14.6 Esquema de archivo OpenVZ
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.
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.
• 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.
• Concentrador de Docker: Esta es la plataforma de colaboración, un repositorio público de imágenes de

contenedores de Docker. Los usuarios pueden usar imágenes almacenadas en un centro que son aportadas
por otros y contribuir con sus propias imágenes personalizadas.
14.4 PROBLEMAS DEL PROCESADOR
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
través de la virtualización, como se discutió anteriormente.
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
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.
14.5 GESTIÓN DE LA MEMORIA
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 virtual Memoria virtual Memoria virtual
Memoria física
Figura 14.7 Compartir página
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
Aplicaciones
Máquina virtual
Sistema operativo
Controlador NIC
Hipervisor
Dispositivo emulado
Servidor físico
Controlador NIC
NIC
La red
Figura 14.8 E / S en un entorno virtual
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
Un procesador más rápido permite que el hipervisor realice sus funciones

de administración de E / S más rápidamente y también acelera la velocidad a la
que se realiza el procesamiento del procesador invitado. Los cambios explícitos
de hardware para la compatibilidad con la virtualización también mejoran el
rendimiento. Intel ofrece tecnología de aceleración de E / S (I / OAT), un
subsistema físico que mueve copias de memoria a través del acceso directo a
memoria (DMA) desde el procesador principal a esta parte especializada de la
placa base. Aunque está diseñado para mejorar el rendimiento de la red, el DMA
remoto también mejora las velocidades de migración en vivo. Descargar el
trabajo del procesador a dispositivos inteligentes es otro camino para mejorar el
rendimiento. Las tarjetas de interfaz de red inteligentes admiten una serie de
tecnologías en este espacio. El motor de descarga de TCP (TOE) elimina el
procesamiento de TCP / IP del procesador del servidor por completo a la NIC.
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.
14,7 VMmercancía ESXI
ESXi es un hipervisor disponible comercialmente de VMware que proporciona a los usuarios un

hipervisor de tipo 1, o bare-metal, para alojar máquinas virtuales en sus servidores. VMware
desarrolló sus soluciones iniciales basadas en x86 a finales de la década de 1990 y fue el
primero en ofrecer un producto comercial al mercado. Este primer momento en el mercado,
junto con las innovaciones continuas, ha mantenido a VMware firmemente en la cima de la
cuota de mercado, pero lo que es más importante, a la cabeza desde el punto de vista de la
amplitud de las características y la madurez de la solución. El crecimiento del mercado de la
virtualización y los cambios en las soluciones de VMware se han descrito en otra parte, pero
existen ciertas diferencias fundamentales en la arquitectura ESXi en comparación con las otras
soluciones disponibles.
El kernel de virtualización (VMkernel) es el núcleo del hipervisor y realiza todas las funciones de
virtualización. En versiones anteriores de ESX (consulte la Figura 14.9a), el hipervisor se implementó
junto con una instalación de Linux que sirvió como capa de administración. Ciertas funciones de
administración como registro, servicios de nombres y, a menudo,
Hardware VMware Sistema

vigilancia administración administración
agentes agentes agentes
Infraestructura Comandos CLI

agentes para la configuración
VM VM
(NTP, Syslog) y apoyo
Soporte de VM y
recurso
administración
VMkernel
(a) ESX
Comandos CLI
para la configuración
y apoyo
Sin agente Sin agente

sistemas hardware
administración vigilancia
VM VM
VMware Común Infraestructura Soporte de VM y

administración información agentes recurso
estructura modelo (NTP, Syslog) administración
Consolas de soporte local

VMkernel
(b) ESXi
Figura 14.9 ESX y ESXi
En esta consola de servicio se instalaron agentes de terceros para respaldo o monitoreo de

hardware. También era un excelente lugar para que los administradores ejecutaran otros
scripts y programas. La consola de servicio tenía dos problemas. El primero era que era
considerablemente más grande que el hipervisor; una instalación típica requería unos 32 MB
para el hipervisor y unos 900 MB para la consola de servicio. La segunda fue que la consola de
servicio basada en Linux era una interfaz y un sistema bien entendidos, y era vulnerable a
ataques de malware o personas. Luego, VMware rediseñó ESX para instalarlo y administrarlo sin
la consola de servicio.
Esta nueva arquitectura, denominada ESXi (la "i" de integrado) tiene todos los servicios de
administración como parte del VMkernel (consulte la Figura 14.9b). Esto proporciona un paquete más
pequeño y mucho más seguro que antes. Las versiones actuales están en el vecindario
14.7 / VMware esXi 649
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.
• Control de E / S de red y almacenamiento: Permite a un administrador asignar ancho de

banda de red en una red virtual de una manera muy granular. Estas políticas se activan cuando
hay contención en la red y pueden garantizar que las máquinas virtuales específicas, los grupos
de máquinas virtuales que componen una aplicación en particular o las clases de tráfico de
datos o almacenamiento tengan la prioridad y el ancho de banda requeridos para operar como
se desee.
• 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.
14,8 millonesicrosoft Hyper-VY Xen VARIANTES
A principios de la década de 2000, un esfuerzo basado en la Universidad de Cambridge condujo

al desarrollo de Xen, un hipervisor de código abierto. Con el tiempo, y a medida que aumentaba
la necesidad de virtualización, muchas variantes de hipervisor han surgido de la rama principal
de Xen. En la actualidad, además del hipervisor de código abierto, hay una serie de ofertas de
hipervisor comercial basadas en Xen de Citrix, Oracle y otros. Con una arquitectura diferente al
modelo de VMware, Xen requiere un sistema operativo o dominio dedicado para trabajar con el
hipervisor, similar a la consola de servicio de VMware (consulte la Figura 14.10). Este dominio
inicial se conoce como dominio cero (Dom0), ejecuta la pila de herramientas Xen y, como área
privilegiada, tiene acceso directo al hardware. Muchas versiones de Linux contienen un
hipervisor Xen que es capaz de crear un entorno virtual. Algunos de estos son CentOS, Debian,
Fedora, Ubuntu, OracleVM, Red Hat (RHEL), SUSE y XenServer. Las empresas que utilizan
soluciones de virtualización basadas en Xen lo hacen debido al costo más bajo (o nulo) del
software, o debido a su propia experiencia interna en Linux.
Los invitados en Xen son dominios sin privilegios o, a veces, dominios de usuario, a los que se hace
referencia como DomU. Dom0 proporciona acceso a los recursos de red y almacenamiento a los invitados a
través de controladores BackEnd que se comunican con los controladores FrontEnd en DomU. A menos que
haya dispositivos de transferencia configurados (generalmente USB), todas las E / S de red y almacenamiento
se manejan a través de Dom0. Dado que Dom0 es en sí mismo una instancia de Linux, si le sucede algo
inesperado, todas las máquinas virtuales que admite se verán afectadas. El mantenimiento estándar del
sistema operativo, como la aplicación de parches, también puede afectar potencialmente la disponibilidad
general.
Como la mayoría de las ofertas de código abierto, Xen no contiene muchas de las capacidades
avanzadas que ofrece VMware ESXi, aunque con cada versión aparecen características adicionales y se
mejoran las características existentes.
Microsoft ha tenido una serie de tecnologías de virtualización, incluido Virtual Server, una
oferta de hipervisor de tipo 2 que se adquirió en 2005 y todavía está disponible hoy sin costo.
Microsoft Hyper-V, un hipervisor de tipo 1, se lanzó por primera vez en 2008 como parte de la
versión del sistema operativo Windows Server 2008. Similar a la arquitectura Xen, Hyper-V tiene
una partición principal que sirve como un complemento administrativo del hipervisor Tipo 1
(consulte la Figura 14.11). Las máquinas virtuales invitadas se designan como particiones
secundarias. La partición principal ejecuta el sistema operativo Windows Server además de sus
funciones, como administrar el hipervisor, las particiones invitadas y
Dom0 DomU DomU
conductores
KernelU KernelU
Kernel0
Hipervisor Xen
Hardware
Figura 14.10 Xen

14.9 / Java VM 651
Partición principal
Partición secundaria Partición secundaria
VM
WMI trabajadores
conductores VSP VSC VSC

Núcleo Núcleo
Núcleo
Microsoft Hyper-V VMBus
Hardware
Figura 14.11 Hyper-V
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,
y el proceso falla, se genera una condición de error y se devuelve a la JVM y al

usuario.
Java y JVM se utilizan en una amplia variedad de áreas, incluidas aplicaciones web, dispositivos móviles
y dispositivos inteligentes, desde decodificadores de televisión hasta dispositivos de juegos, reproductores de
Blu-ray y otros elementos que utilizan tarjetas inteligentes. La promesa de Java de "Escribir una vez, ejecutar
en cualquier lugar" proporciona un modelo de implementación ágil y simple, lo que permite que las
aplicaciones se desarrollen independientemente de la plataforma de ejecución.
14.10 ARQUITECTURA DE MÁQUINA VIRTUAL LINUX VSERVER
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
VManfitrión VM1 VMnorte
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
Figura 14.12 Arquitectura VServer de Linux
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
Tasa de entrada del token =
R/T tokens por segundo Los tokens se pueden acumular

hasta el tamaño del balde; exceso
de fichas descartadas
Tamaño del cubo =

Cubo actual S tokens
ocupación Mínimo
umbral =
S tokens
El proceso en ejecución consume 1
token / tic del temporizador
Figura 14.13 Esquema de depósito de token de Linux VServer
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.
14.12 TÉRMINOS CLAVE, PREGUNTAS DE REVISIÓN Y PROBLEMAS
Términos clave
envase hipervisor hipervisor tipo 1

índice de consolidación de la máquina virtual de Java hipervisor tipo 2
virtualización de contenedores (JVM) dispositivo virtual
Estibador grupo de control del kernel virtualización de contenedores
SO invitado aumento de la memoria de virtualización
virtualización de hardware sobreasignación de memoria máquina virtual (VM)
asistida por hardware microservicio monitor de máquina virtual
virtualización compartir página (VMM)
SO anfitrión paravirtualización
Preguntas de revisión
14.1. Describa brevemente la virtualización de Tipo 1 y Tipo 2.

14.2. Describa brevemente la virtualización de contenedores.
14.3. Explica el concepto de globos aerostáticos.
14.4. Proporcione una breve descripción de Java VM.
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?

Stallings Chapter 14.en - Es

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Stallings Chapter 14.en - Es

Cargado por

Copyright:

Formatos disponibles

Traducido del inglés al español - www.onlinedoctranslator.

14.3 Virtualización de contenedores

14,4 Problemas con el procesador

14,5 Gestión de la memoria

14.12 Términos clave, preguntas de revisión y problemas

• Comprender los problemas de administración de E / S relacionados con la implementación de una

• Compare y contraste VMware ESXi, Hyper-V, Xen y Java VM.

Este capítulo se centra en la aplicación de la virtualización al diseño de sistemas operativos. La

14.1 CONCEPTOS DE MÁQUINA VIRTUAL

Figura 14.1 Concepto de máquina virtual

La virtualización no es una tecnología nueva. Durante la década de 1970, los sistemas

• Versatilidad: El uso del hardware se puede optimizar maximizando el número de tipos de

• Facilidad de manejo: Las máquinas virtuales facilitan la implementación y la prueba de

Las ofertas de máquinas virtuales comerciales de empresas como VMware y Microsoft se

• Emulación de dispositivos y control de acceso: Emulando todos los dispositivos de red y

• Administración de plataforma de hipervisor y software de hipervisor: Implica la configuración de

Aplicaciones Aplicaciones bibliotecas bibliotecas

bibliotecas bibliotecas SO invitado SO invitado

SO invitado SO invitado Hipervisor tipo 2

Hipervisor tipo 1 Sistema operativo host

Hardware compartido Hardware compartido

(a) Hipervisor de tipo 1 (b) Hipervisor de tipo 2

Figura 14.2 Hipervisores tipo 1 y tipo 2

• Los hipervisores de tipo 2 permiten al usuario aprovechar la virtualización sin necesidad

copiado de un entorno de hipervisor a otro, lo que reduce el tiempo de implementación y

Aplicación Aplicación Aplicación Aplicación Aplicación Aplicación

Huésped Huésped Huésped Huésped Huésped Huésped

(a) Hipervisor de tipo 1 (b) Hipervisor tipo 1 paravirtualizado

Figura 14.3 Paravirtualización

Virtualización asistida por hardware

Implementar un dispositivo de aplicación preinstalado y preconfigurado es mucho más fácil

• No vulnerable a una falla en el sistema operativo invitado

• Independiente de la configuración de la red virtual y no es necesario volver a configurarla

14.3 VIRTUALIZACIÓN DE CONTENEDORES

Un enfoque relativamente reciente de la virtualización se conoce como virtualización de contenedores. En este

Grupos de control del kernel

• Crea un proceso para el contenedor.

(a) Hipervisor de tipo 1 (b) Hipervisor de tipo 2

Figura 14.4 Comparación de máquinas virtuales y contenedores

• Configuración: Los contenedores están configurados para ejecutar aplicaciones o comandos

Controlador de dispositivo de SO invitado

Dispositivo de E / S virtual Solicitud

Intercepción de hipervisor Indirección a través de grupos de control del kernel

Controlador de dispositivo físico Controlador de dispositivo físico

Dispositivo de E / S físico Dispositivo de E / S físico

(a) Hipervisor (b) Contenedor

Figura 14.5 Flujo de datos para la operación de E / S a través del hipervisor y

Las dos características destacables de los envases son las siguientes:

2. El software de gestión de contenedores simplifica el procedimiento de creación y

• La virtualización de VM funciona en la frontera del hardware y el sistema operativo. Es capaz de

Sistema de archivos contenedor

compartimiento dev etc sistema usuarios var

escritorio docs Biblioteca

Figura 14.6 Esquema de archivo OpenVZ

• Concentrador de Docker: Esta es la plataforma de colaboración, un repositorio público de imágenes de

14.4 PROBLEMAS DEL PROCESADOR

través de la virtualización, como se discutió anteriormente.

14.5 GESTIÓN DE LA MEMORIA

Memoria virtual Memoria virtual Memoria virtual

Figura 14.7 Compartir página

Figura 14.8 E / S en un entorno virtual

Un procesador más rápido permite que el hipervisor realice sus funciones