Aislamiento temporal entre las máquinas virtuales
Aislamiento temporal o aislamiento de rendimiento entre máquina virtual (VMs) se refiere a la capacidad de aislar el comportamiento temporal (o limitar las interferencias temporales) de múltiples máquinas virtuales entre sí, a pesar de correr en el mismo host físico y compartir un conjunto de recursos físicos tales como procesadores, memoria y discos.
Introducción al problema
Una de las principales ventajas de utilizar Virtualización en consolidación de servidores, es la posibilidad de perfección "pack" múltiples sistemas subutilizados en un único servidor físico, por lo tanto lograr una mejor utilización general de los recursos de hardware disponibles. De hecho, toda una Sistema operativo (OS), junto con las aplicaciones que se ejecutan dentro, se puede ejecutar en un máquina virtual (VM). sin embargo, cuando múltiples máquinas virtuales se ejecutan concurrentemente en el mismo host físico, comparten los recursos físicos disponibles, incluyendo CPU(s), adaptador de red(s), disco(s) y la memoria. Esto añade un grado de imprevisibilidad en el rendimiento que puede ser exhibido por cada VM individual, en comparación con lo que se espera. Por ejemplo, una máquina virtual con un pico de informáticas temporal perturbe las otras corrientes VMs, causando una caída temporal significativa e indeseable en su desempeño. En un mundo de la informática que se está desplazando hacia Computación en la nube paradigmas donde los recursos (informática, almacenamiento, redes) se pueden alquilar remotamente en virtualizados forma bajo los acuerdos de nivel de servicio precisos, sería altamente deseable que el rendimiento de los recursos virtualizados sea tan estable y predecible como sea posible.
Posibles soluciones
Pueden utilizarse varias técnicas para hacer frente al problema ya mencionado. Su objetivo es lograr cierto grado de aislamiento temporal a través de las VMs funcionando simultáneamente, en los distintos niveles críticos de programación:: Programación CPU, red de programación y programación de disco.
Para el CPU, es posible utilizar adecuada programación técnicas a nivel hypervisor para contener la cantidad de computación cada VM podrá imponer a un núcleo o CPU física compartida. Por ejemplo, en el Xen hipervisor, la BVT, basada en el crédito y S-FED programadores han sido propuestos para controlar cómo se distribuye la potencia informática entre competidores VMs.[1] Para obtener un funcionamiento estable de las aplicaciones virtualizadas, es necesario utilizar aquellas configuraciones de programador que no son conservación de trabajo. También, en el KVM hipervisor, se ha propuesto utilizar estrategias de programación basada en la Fed [2] para mantener un funcionamiento estable y predecible de las aplicaciones virtualizadas [3] .[4] Finalmente, con una multi-core o multiprocesador host físico, es posible desplegar cada VM en un procesador independiente o núcleo, con el fin de aislar temporalmente el funcionamiento de varias máquinas virtuales.
Para la red, es posible utilizar tráfico shaping técnicas para limitar la cantidad de tráfico que puede imponer cada VM en el host. Además, es posible instalar a varios adaptadores de red en el mismo host físico, y configurar la capa de virtualización para que cada VM puede otorgar acceso exclusivo a cada uno de ellos. Por ejemplo, esto es posible con los dominios del conductor del hipervisor Xen. Adaptadores de red múltiples colas existen compatibles con múltiples máquinas virtuales a nivel de hardware, tener colas de paquetes separados asociadas a las diferentes VMs alojadas (por medio de las direcciones IP de las VMs), tales como los dispositivos de la cola de dispositivo Virtual Machine (VMDq) por Intel.[5] Finalmente, programación en tiempo real de la CPU puede también utilizarse para mejorar el aislamiento temporal del tráfico de red de múltiples máquinas virtuales desplegados en la misma CPU.[6]
Cuando se utilizan estrategias de programación en tiempo real para controlar la cantidad de CPU reservado a cada VM, un problema desafiante es el de cómo tener en cuenta para el tiempo de CPU en todo el sistema de actividades que podrían no ser fáciles para tener en cuenta que cada VM correctamente. Por ejemplo, en el caso del programador de Xen, el Dom0 y los servicios de dominios controlador pueden ser compartidos a través de múltiples máquinas virtuales accediendo a ellas. Asimismo, en el caso del hipervisor KVM, la carga de trabajo impuesta en el host OS debido a que sirve el tráfico de red para cada cliente individual OS podría no ser fácilmente distinguible, porque involucra principalmente controladores de dispositivo de nivel de núcleo y la infraestructura de red (en el sistema operativo host). Algunas técnicas para mitigar esos problemas han sido propuestos para el caso de Xen.[7]
A lo largo de las líneas de reservas adaptables, es posible aplicar estrategias de control de regeneración para adaptarse dinámicamente la cantidad de recursos reservados para cada máquina virtual, con el fin de mantener un nivel estable de rendimiento para las aplicaciones virtualizadas.[8] Siguiendo la tendencia de adaptación, en aquellos casos en que un sistema virtualizado no está cumpliendo con los niveles de rendimiento esperados (ya sea debido a imprevistos interferencias de otras máquinas virtuales simultáneamente corrientes, o a una estrategia de despliegue mal que simplemente recogió una máquina con recursos de hardware insuficiente), es posible vivir-migrar máquinas virtuales mientras se están ejecutando, para alojarlas en un host físico más capaz (o menos cargada).
Referencias
- ^ Ludmila Cherkasova, Diwaker Gupta, Amin Vahdat (03 de septiembre de 2007), "Comparación de los tres programadores de CPU en Xen", Revisión de la evaluación del desempeño. Vol 35, número 2, obtenido el 30 de junio de 2010
- ^ Fabio Checconi, Tommaso Cucinotta, Dario Faggioli, Giuseppe Lipari, CPU multiprocesador jerárquica reservas para el Kernel de LinuxActas del v taller internacional sobre plataformas de sistemas operativos para aplicaciones en tiempo real embebidas (OSPERT 2009), Dublín, Irlanda, junio de 2009
- ^ Tommaso Cucinotta, Gaetano Anastasi, Luca Abeni, Respetando las restricciones temporales en los servicios virtualizadosActas del II Taller Internacional IEEE en tiempo real arquitectura orientada a servicios y aplicaciones (RTSOAA 2009), Seattle, Washington, julio de 2009
- ^ Tommaso Cucinotta, Gaetano Anastasi, Luca Abeni, Máquinas virtuales en tiempo realProceedings of the 29 sistema en tiempo real Symposium (RTSS 2008)--sesión de trabajo en progreso, Barcelona, diciembre de 2008
- ^ Shefali Chinni, Radhakrishna Hiremane, Máquina virtual dispositivo colasIntel Virtualization Technology White Paper, 2007
- ^ Tommaso Cucinotta, Maria Giani, Dario Faggioli y Fabio Checconi, Garantías de rendimiento para las máquinas virtuales mediante programación en tiempo realActas del quinto taller sobre virtualización y Cloud High-Performance Computing (VHP 2010), Ischia (Nápoles), Italia, agosto de 2010.
- ^ Diwaker Gupta, Lucy Cherkasova, Robert Gardner, Amin Vahdat, Aplicación de aislamiento de rendimiento todas las máquinas virtuales de XenActas de la VII Conferencia Internacional de Middleware (Middleware 2006), Lecture Notes in Computer Science, volumen 4290/2006, pp.342-362, Melbourne, Australia, noviembre de 2006
- ^ Ripal Nathuji, Aman Kansal y Alireza Ghaffarkhah (abril de 2010), "Q-nubes: gestionar rendimiento interferencia efectos de nubes QoS-consciente", In: de la 5ª Conferencia Europea en los sistemas informáticos (EuroSys 2010) (París, Francia)