Virtualización de hardware

La virtualización de hardware es la virtualización de computadoras como plataformas de hardware completas, ciertas abstracciones lógicas de sus componentes o solo la funcionalidad requerida para ejecutar varios sistemas operativos . La virtualización emula el entorno de hardware de su arquitectura anfitriona, lo que permite que varios sistemas operativos se ejecuten sin modificaciones y de forma aislada. En sus orígenes, el software que controlaba la virtualización se denominaba "programa de control", pero con el tiempo se empezaron a preferir los términos " hipervisor " o "monitor de máquina virtual". ^[1]

Concepto

El término "virtualización" fue acuñado en la década de 1960 para referirse a una máquina virtual (a veces llamada "pseudomáquina"), un término que data del sistema experimental IBM M44/44X . ^[1] La creación y gestión de máquinas virtuales también se ha denominado "virtualización de plataforma" o, más recientemente, "virtualización de servidor". ^[2]^[3]

La virtualización de plataformas se realiza en una plataforma de hardware determinada mediante un software host (un programa de control ), que crea un entorno informático simulado, una máquina virtual (VM), para su software invitado . El software invitado no se limita a las aplicaciones de usuario; muchos hosts permiten la ejecución de sistemas operativos completos. El software invitado se ejecuta como si se estuviera ejecutando directamente en el hardware físico, con varias advertencias notables. El acceso a los recursos físicos del sistema (como el acceso a la red , la pantalla, el teclado y el almacenamiento en disco ) generalmente se administra a un nivel más restrictivo que el procesador host y la memoria del sistema. A menudo, se restringe el acceso de los invitados a dispositivos periféricos específicos , o pueden estar limitados a un subconjunto de las capacidades nativas del dispositivo, según la política de acceso al hardware implementada por el host de virtualización. ^[4]^{: 5,13}

La virtualización a menudo implica penalizaciones en el rendimiento, tanto en los recursos necesarios para ejecutar el hipervisor como en un rendimiento reducido en la máquina virtual en comparación con la ejecución nativa en la máquina física. ^[4]^{: 35,67-68}

Razones para la virtualización

En el caso de la consolidación de servidores , muchos servidores físicos pequeños pueden reemplazarse por un servidor físico más grande para disminuir la necesidad de más recursos de hardware (costosos), como CPU y discos duros. Aunque el hardware se consolida en entornos virtuales, normalmente los sistemas operativos no lo hacen. En cambio, cada sistema operativo que se ejecuta en un servidor físico se convierte en un sistema operativo distinto que se ejecuta dentro de una máquina virtual. De ese modo, el servidor grande puede "albergar" muchas de esas máquinas virtuales "invitadas". Esto se conoce como transformación de físico a virtual (P2V). La utilización promedio de un servidor a principios de la década de 2000 era del 5 al 15 %, pero con la adopción de la virtualización, esta cifra comenzó a aumentar para reducir la cantidad de servidores necesarios. ^[5]
Además de reducir los costos de equipo y mano de obra asociados con el mantenimiento de los equipos, la consolidación de servidores también puede tener el beneficio adicional de reducir el consumo de energía y la huella global en sectores ambientales y ecológicos de la tecnología. Por ejemplo, un servidor típico funciona a 425 W ^[6] y VMware estima una relación de reducción de hardware de hasta 15:1. ^[7]
Una máquina virtual (VM) se puede controlar e inspeccionar más fácilmente desde un sitio remoto que una máquina física, y la configuración de una VM es más flexible. Esto es muy útil en el desarrollo del núcleo y para la enseñanza de cursos sobre sistemas operativos, incluida la ejecución de sistemas operativos heredados que no admiten hardware moderno. ^[8]
Se puede aprovisionar una nueva máquina virtual según sea necesario sin necesidad de realizar una compra de hardware por adelantado.
Una máquina virtual se puede trasladar fácilmente de una máquina física a otra según sea necesario. Por ejemplo, un vendedor que visita a un cliente puede copiar una máquina virtual con el software de demostración a su computadora portátil, sin necesidad de transportar la computadora física. Asimismo, un error dentro de una máquina virtual no daña el sistema anfitrión, por lo que no existe el riesgo de que el sistema operativo falle en la computadora portátil.
Debido a esta facilidad de reubicación, las máquinas virtuales se pueden usar fácilmente en escenarios de recuperación ante desastres sin preocupaciones por el impacto de fuentes de energía renovadas y defectuosas.

Sin embargo, cuando varias máquinas virtuales se ejecutan simultáneamente en el mismo host físico, cada una de ellas puede presentar un rendimiento variable e inestable que depende en gran medida de la carga de trabajo impuesta al sistema por otras máquinas virtuales. Este problema se puede solucionar mediante técnicas de instalación adecuadas para el aislamiento temporal entre máquinas virtuales .

Existen varios enfoques para la virtualización de plataformas.

Ejemplos de casos de uso de virtualización:

Ejecutar una o más aplicaciones que no son compatibles con el sistema operativo host: una máquina virtual que ejecuta el sistema operativo invitado requerido podría permitir que se ejecuten las aplicaciones deseadas, sin alterar el sistema operativo host.
Evaluación de un sistema operativo alternativo: el nuevo sistema operativo podría ejecutarse dentro de una máquina virtual, sin alterar el sistema operativo host.
Virtualización de servidores: se podrían ejecutar varios servidores virtuales en un solo servidor físico, para aprovechar al máximo los recursos de hardware del servidor físico.
Duplicación de entornos específicos: una máquina virtual podría, dependiendo del software de virtualización utilizado, duplicarse e instalarse en múltiples hosts o restaurarse a un estado de sistema previamente respaldado.
Creación de un entorno protegido: si un sistema operativo invitado que se ejecuta en una máquina virtual se daña de una manera que no es rentable reparar, como puede ocurrir al estudiar malware o instalar software con mal comportamiento, la máquina virtual puede simplemente descartarse sin dañar el sistema host y se puede usar una copia limpia al reiniciar el invitado.

Virtualización completa

En la virtualización completa, la máquina virtual simula suficiente hardware para permitir que un sistema operativo "invitado" sin modificar, diseñado para el mismo conjunto de instrucciones, se ejecute de forma aislada. Este enfoque se inició en 1966 con los IBM CP-40 y CP-67 , predecesores de la familia VM .

Paravirtualización

En la paravirtualización, la máquina virtual no simula necesariamente el hardware, sino que en su lugar (o además) ofrece una API especial que sólo se puede utilizar modificando ^{[ aclaración necesaria ]} el sistema operativo "invitado". Para que esto sea posible, el código fuente del sistema operativo "invitado" debe estar disponible. Si el código fuente está disponible, es suficiente reemplazar las instrucciones sensibles con llamadas a las API de VMM (por ejemplo: "cli" con "vm_handle_cli()"), luego volver a compilar el sistema operativo y utilizar los nuevos binarios. Esta llamada del sistema al hipervisor se denomina "hiperllamada" en TRANGO y Xen ; se implementa a través de una instrucción de hardware DIAG ("diagnosticar") en el CMS de IBM bajo VM ^{[ aclaración necesaria ]} (que fue el origen del término hipervisor ).

Virtualización asistida por hardware

En la virtualización asistida por hardware, el hardware proporciona soporte arquitectónico que facilita la creación de un monitor de máquina virtual y permite que los sistemas operativos invitados se ejecuten de forma aislada. ^[9] Esto se puede utilizar para ayudar a la virtualización completa o a la paravirtualización. La virtualización asistida por hardware se introdujo por primera vez en los procesadores IBM 308X en 1980, con la instrucción Start Interpretive Execution (SIE). ^[10]

En 2005 y 2006, Intel y AMD desarrollaron hardware adicional para soportar la virtualización ejecutada en sus plataformas. Sun Microsystems (ahora Oracle Corporation ) agregó características similares en sus procesadores UltraSPARC T-Series en 2005.

En 2006, se descubrió que el soporte de hardware x86 de 32 y 64 bits de primera generación rara vez ofrecía ventajas de rendimiento sobre la virtualización de software. ^[11]

Virtualización a nivel de sistema operativo

En la virtualización a nivel de sistema operativo, un servidor físico se virtualiza a nivel de sistema operativo, lo que permite que varios servidores virtualizados aislados y seguros se ejecuten en un único servidor físico. Los entornos de sistema operativo "invitados" comparten la misma instancia de ejecución del sistema operativo que el sistema host. Por lo tanto, también se utiliza el mismo núcleo del sistema operativo para implementar los entornos "invitados", y las aplicaciones que se ejecutan en un entorno "invitado" determinado lo ven como un sistema independiente.

Recuperación ante desastres de virtualización de hardware

Un plan de recuperación ante desastres (DR) suele considerarse una buena práctica para una plataforma de virtualización de hardware. La recuperación ante desastres de un entorno de virtualización puede garantizar una alta tasa de disponibilidad durante una amplia gama de situaciones que alteran las operaciones comerciales normales. En situaciones en las que es importante que las plataformas de virtualización de hardware sigan funcionando, un plan de recuperación ante desastres puede garantizar que se cumplan los requisitos de rendimiento y mantenimiento del hardware. Un plan de recuperación ante desastres de virtualización de hardware implica la protección tanto del hardware como del software mediante diversos métodos, incluidos los que se describen a continuación. ^[12]^[13]

Copia de seguridad en cinta para necesidades de archivo a largo plazo de datos de software: Este método común se puede utilizar para almacenar datos fuera del sitio, pero la recuperación de datos puede ser un proceso difícil y prolongado. Los datos de respaldo en cinta son tan buenos como la última copia almacenada. Los métodos de respaldo en cinta requieren un dispositivo de respaldo y material de almacenamiento permanente.
Replicación de archivos completos y de aplicaciones: La implementación de este método requerirá software de control y capacidad de almacenamiento para la replicación de aplicaciones y archivos de datos, generalmente en el mismo sitio. Los datos se replican en una partición de disco diferente o en un dispositivo de disco separado y puede ser una actividad programada para la mayoría de los servidores y se implementa más para aplicaciones de tipo base de datos.
Redundancia de hardware y software: Este método garantiza el más alto nivel de protección de recuperación ante desastres para una solución de virtualización de hardware, al proporcionar replicación duplicada de hardware y software en dos áreas geográficas distintas. ^[14]

Véase también

Referencias

^ ab Creasy, RJ (1981). "El origen del sistema de tiempo compartido VM/370" (PDF) . IBM . Consultado el 26 de febrero de 2013 .
^ Thomson, Julian (23 de mayo de 2018). «Máquinas virtuales: una introducción a la virtualización de plataformas». Performance Software . Consultado el 8 de julio de 2023 .
^ "¿Qué es la virtualización de servidores?".
^ ab Bugnion, Edouard; Nieh, Jason; Tsafrir, Dan (2017). Soporte de hardware y software para virtualización . San Rafael, CA: Morgan & Claypool Publishers. ISBN 9781627056939.
^ "El envejecimiento de los chips se acelera". 14 de febrero de 2018.
^ Rajesh Chheda; Dan Shookowsky; Steve Stefanovich; Joe Toscano (14 de enero de 2009). "Perfiles de uso de energía para un consumo eficiente".
^ "Descripción general de la consolidación de servidores de VMware". Archivado desde el original el 8 de enero de 2022.
^ Jason Nieh ; Ozgur Can Leonard (agosto de 2000). "Examinando VMware". Diario del Dr. Dobb . Archivado desde el original el 22 de noviembre de 2019.
^ Smith, L.; Kägi, A.; Martins, FM; Neiger, G.; Leung, FH; Rodgers, D.; Santoni, AL; Bennett, SM; Uhlig, R.; Anderson, AV (mayo de 2005). "Tecnología de virtualización de Intel". Computer . 38 (5): 48–56. doi :10.1109/MC.2005.163.
^ IBM System/370 Extended Architecture Interpretive Execution (PDF) (Primera edición). IBM. Enero de 1984. SA22-7095-0 . Consultado el 27 de octubre de 2022 .
^ Keith Adams; Ole Agesen (21–25 de octubre de 2006). A Comparison of Software and Hardware Techniques for x86 Virtualization (PDF) (Una comparación de técnicas de software y hardware para la virtualización x86) (PDF) . ASPLOS'06. San José, California, EE. UU. Archivado desde el original (PDF) el 8 de enero de 2022. Sorprendentemente, descubrimos que el soporte de hardware de primera generación rara vez ofrece ventajas de rendimiento sobre las técnicas de software existentes. Atribuimos esta situación a los altos costos de transición de VMM/guest y a un modelo de programación rígido que deja poco espacio para la flexibilidad del software a la hora de gestionar la frecuencia o el costo de estas transiciones.
^ "La guía esencial para la recuperación ante desastres: cómo garantizar la continuidad de las TI y de los negocios" (PDF) . Vision Solutions, Inc. 2010. Archivado desde el original (PDF) el 16 de mayo de 2011.
^ Wold, G (2008). "Proceso de planificación de recuperación ante desastres". Archivado desde el original el 15 de agosto de 2012.
^ "Virtualización de recuperación ante desastres: protección de los sistemas de producción mediante VMware Virtual Infrastructure y Double-Take" (PDF) . VMware. 2010. Archivado desde el original (PDF) el 23 de septiembre de 2010.

Enlaces externos

Introducción a la virtualización Archivado el 22 de octubre de 2020 en Wayback Machine , por Amit Singh
Xen y el arte de la virtualización, ACM, 2003, por un grupo de autores
Software de virtualización de Linux
Zoppis, Bruno (27 de agosto de 2007) [1.ª publicación: LinuxDevices:2007]. "Uso de un hipervisor para reconciliar la GPL y el código propietario embebido". Linux Gizmos . Archivado desde el original el 24 de diciembre de 2013.