¿La máquina virtual es más lenta que la máquina física subyacente?

Esta pregunta es bastante general, pero más específicamente me interesa saber si la máquina virtual que ejecuta Ubuntu Enterprise Cloud será más lenta que la misma máquina física sin ninguna virtualización. ¿Cuánto (1%, 5%, 10%)?

¿Alguien midió la diferencia de rendimiento del servidor web o el servidor db (virtual VS físico)?

Si depende de la configuración, imaginemos dos procesadores de cuatro núcleos, 12 GB de memoria y un montón de discos SSD, que ejecutan el servidor empresarial ubuntu de 64 bits. Además de eso, solo 1 máquina virtual puede usar todos los recursos disponibles.

La experiencia típica para una carga de trabajo de servidor de uso general en un hipervisor de tipo básico \ Tipo 1 es de alrededor del 1-5% de la sobrecarga de la CPU y del 5-10% de sobrecarga de la memoria, con alguna sobrecarga adicional que varía según la carga general de E / S. Eso es bastante consistente en mi experiencia para los sistemas operativos invitados modernos que se ejecutan en VMware ESX \ ESXi, Microsoft Hyper-V y Xen, donde el hardware subyacente se ha diseñado adecuadamente. Para los sistemas operativos de servidor de 64 bits que se ejecutan en hardware que admite las extensiones de virtualización de hardware de CPU más actuales, esperaría que todos los hipervisores Tipo 1 se dirijan a ese número de sobrecarga del 1%. La madurez de KVM no depende de Xen (o VMware) en este momento, pero no veo ninguna razón para pensar que sería notablemente peor que ellos para el ejemplo que describe.

Para casos de uso específicos, aunque el "rendimiento" global \ agregado de un entorno virtual puede exceder los servidores básicos \ discretos. Aquí hay un ejemplo de una discusión sobre cómo una implementación de VMware Clustered puede ser más rápida \ mejor \ más barata que un Oracle RAC simple. Las técnicas de administración de memoria de VMware (especialmente el uso compartido de páginas transparente) pueden eliminar la sobrecarga de memoria casi por completo si tiene suficientes máquinas virtuales que sean lo suficientemente similares. Lo importante en todos estos casos es que los beneficios de rendimiento / eficiencia que puede ofrecer la virtualización solo se lograrán si está consolidando varias máquinas virtuales en hosts, su ejemplo (1 VM en el host) siempre será más lento que el metal desnudo en algún grado .

Si bien todo esto es útil, los problemas reales en términos de virtualización del servidor tienden a centrarse en la administración, las técnicas de alta disponibilidad y la escalabilidad. Un margen de rendimiento de CPU del 2-5% no es tan importante como poder escalar eficientemente a 20, 40 o la cantidad de VM que necesite en cada host. Puede lidiar con el impacto en el rendimiento seleccionando una CPU un poco más rápida como línea de base, o agregando más nodos en sus clústeres, pero si el host no puede escalar el número de máquinas virtuales, puede ejecutarse, o el entorno es difícil de administrar o poco confiable, entonces no tiene valor desde la perspectiva de la virtualización del servidor.

El "rendimiento" tiene muchos aspectos. Los n00bs miden el tiempo de arranque de un sistema operativo y dicen, por ejemplo, que Windows 2012 es taaaaaaaaaaaaaaaan porque arranca en 12 segundos en HD real, quizás 1 segundo en SSD.
Pero este tipo de medida no es muy útil: el rendimiento es igual al tiempo de arranque del sistema operativo, pero el sistema operativo se inicia una vez al mes, por lo que la optimización no tiene mucho sentido.

Debido a que es mi negocio diario, podría señalar las siguientes 4 partes que componen el "rendimiento"

1. Carga de la CPU
   Esto debería ser comparable, lo que significa que una tarea de 1000 ms en metal desnudo se ejecutará en 1000 ms de tiempo de proceso y probablemente 1050 ms de tiempo de reloj en un entorno de VM inactivo en el mismo hardware (algunos detalles más adelante). Google MSDN para procesar y consultar el contador de rendimiento y puede hacer algo que puede mostrar cuánto consume la VM su tiempo de CPU.

2. Rendimiento SQL
   El rendimiento de SQL depende en gran medida de IO para el almacén de datos donde se almacenan los datos de SQL. He visto una diferencia del 300% entre el ISCSI de primera generación que puede encontrar en el NAS doméstico de Buffalo, luego el ISCSI con DCE y un verdadero entorno FC de la vieja escuela, en todos los niveles. El FC todavía gana hoy en día, porque la latencia FC es la más baja archivable, lo que lleva a una "copia" del protocolo FC para mejoras del centro de datos TCP / IP. Aquí IOps y la latencia son vitales, pero también el ancho de banda de IO desde el proceso del servidor a los medios depende de si la aplicación tiende a No-SQL o Datawarehousing o está en el medio de eso, como los sistemas ERP ... Sage KHK para pequeñas empresas, SAP para los grandes

3. Acceso al sistema de archivos
   Algunas aplicaciones, como la transmisión de video, se basa en un ancho de banda mínimo garantizado, otras confían en el rendimiento máximo de E / S, como abrir archivos grandes en un editor hexadecimal y cargar un proyecto de video en su programa de creación de películas favorito. No es una situación típica en una máquina virtual ... los IOps también pueden ser importantes para los desarrolladores. Los desarrolladores a menudo utilizan máquinas virtuales porque los entornos de desarrollo son muy sensibles y, por lo tanto, la tentación de hacerlo en una máquina virtual es alta. Compilar un proyecto grande a menudo significa leer toneladas de archivos pequeños, hacer el compilador y construir un EXE y los componentes que lo acompañan.

4. Latencia de red para el cliente
   Aquí, la usabilidad de los programas WYSIWIG, como Word 2010, Openoffice Writer, LaTEX, GSView y otros, depende en gran medida de la velocidad: la rapidez con la que una acción del mouse pasa del cliente al servidor. Especialmente en aplicaciones CAD esto es importante ... pero tampoco es un problema de LAN, es el acceso remoto a través de WAN donde esto es importante.

Pero, y hablo desde la perspectiva de años de consultoría, hay usuarios que tienen la contraseña de administrador (y a menudo son empleados de una gran empresa con un gran presupuesto y un gran bolsillo) quejándose de esto y aquello, pero debe aclararse. qué componente de rendimiento es importante para ellos y cuál es importante desde la perspectiva de la aplicación que utilizan.
Lo más probable es que no sea un bloc de notas, sino una aplicación altamente sofisticada para diseñar esto y aquello, que también era muy costosa y debía moverse en VMware, HyperV o Xenapp y no funciona como se esperaba.

Pero no tienen en cuenta que podría ejecutarse en Xeons de 1.5 GHz en blades que no están hechos para el rendimiento puro de la CPU, están diseñados para un promedio, digamos "optimizados para $ por ciclo de CPU" o "ciclos de CPU por vatio" .

Y cuando hablamos de compensaciones y economizaciones, eso conduce principalmente a compromisos excesivos. Los compromisos excesivos conducen a la falta de recursos donde la CPU se puede manejar bastante bien, pero la falta de memoria conduce a la paginación, la falta de E / S en los enrutadores principales conduce a un mayor tiempo de respuesta en todo, y la sobrecarga transaccional en cualquier tipo de almacenamiento puede detener todas las aplicaciones útiles de responder demasiado rápido Aquí se requiere monitoreo, pero muchos proveedores de software no pueden proporcionar dicha información ... por otro lado, un host con recursos de 3 servidores físicos probablemente pueda manejar 8 máquinas virtuales del mismo diseño como las físicas ...

Las compensaciones de la CPU en los sistemas inactivos a menudo conducen a que los sistemas funcionen un 50% más lento que los sistemas físicos, por otro lado, nadie puede instalar el sistema operativo del "mundo real" y la aplicación del "mundo real" que los técnicos de TI del cliente quieren pasar a la VM caja. Y lleva días (tal vez semanas, pero seguramente 42 reuniones) para dejar en claro que la tecnología VM puede ofrecer flexibilidad mediante el intercambio de velocidad de CPU pura. Esto está integrado en las CPU de estos sistemas blade que actualmente albergan entornos VM más grandes. Además, la memoria no será comparable, también se aplican algunas compensaciones. DDR3 1600 CL10 tendrá un mayor ancho de banda de memoria que DDR2 800 ECC LLR, y todos saben que las CPU de Intel se benefician de esto de una manera diferente que AMD cpus. Pero rara vez se usan en entornos productivos, más en cajas blancas o en centros de datos alojados en países del tercer mundo que ofrecen servicio de centro de datos por el 10% del precio que un centro de datos en su propia patria puede facturar a yu. Gracias a Citrx, un centro de datos puede estar en todas partes si hay menos de 150 ms de latencia entre el usuario final y el centro de datos.

Y la perspectiva de los usuarios domésticos ...

Por último, pero no menos importante, algunas personas quieren tirar Win7 o XP y cambiarlo por un Linux, y luego surge la pregunta del juego porque en realidad solo hay pocos juegos disponibles para Linux y Windows. El juego se basa en gran medida en la aceleración 3D. VMWare 6.5 Workstation y el reproductor gratuito conectado pueden manejar DirectX 9, lo que significa que un Doom3 en una VM puede ejecutarse en la tarjeta gráfica del host en pantalla completa. Los juegos son en su mayoría aplicaciones de 32 bits, por lo que no consumirán más de 3 GB y en su mayoría no más de 3 CPU (visto en Crysis). Los jugadores VM más nuevos y WS pueden manejar versiones DirectX más altas y probablemente también OpenGL ... Jugué UT y UT2004 en VMware 6.5, el host tenía un móvil ATI Radeon 2600 y una CPU T5440. Era estable a 1280x800 y jugable incluso en juegos de red ...

Si. Pero esa no es la pregunta. La diferencia es normalmente despreciable (1% a 5%).

Señalaría que la virtualización puede superar el rendimiento físico en ciertas situaciones. Dado que la capa de red no está limitada a la velocidad de gigabits (aunque la emulación de hardware es de una tarjeta LAN específica), las máquinas virtuales en el mismo servidor pueden comunicarse entre sí a velocidades superiores a la de los servidores físicos múltiples con equipos de red promedio.

He estado haciendo algunas comparaciones de prueba del mismo software que ejecuta la misma prueba (aplicación web basada en .NET con altos volúmenes de tráfico web y acceso considerable a SQL Server). Esto es lo que he visto:

• La máquina física es mejor para crear instancias de clases (lo que se traduce en asignar memoria a nivel del sistema); esto tiene sentido para mí porque las máquinas físicas hacen esto a través del hardware de administración de memoria y las máquinas virtuales lo hacen a través de software (con asistencia parcial de hardware) (en la máquina virtual , la aplicación pasó una cantidad significativa de tiempo en sus constructores (donde se asigna la memoria (y no se hace nada más), en la máquina física, los constructores ni siquiera se incluyeron en el top 1000)
• Cuando se encuentra en medio de un método, los dos son casi equivalentes; esta es probablemente la forma en que se construyen la mayoría de los puntos de referencia que muestran que los dos "son iguales"
• Cuando accede a un controlador de red, el físico supera un poco a la máquina virtual; nuevamente, el físico no tiene mucho espacio entre el proceso .NET y el hardware. VM agrega agrega otras "cosas" por las que cada transacción necesita viajar.
• Realmente, lo mismo se aplica al acceso al disco (el SQL Server estaba en otra máquina): la diferencia es muy pequeña, pero cuando los agrega a todos, es notable. Esto podría haber sido causado por un acceso de red más lento o por un acceso de disco más lento.

Puedo ver fácilmente cómo alguien podría construir puntos de referencia que demuestren que son 1% diferentes o iguales o donde las máquinas virtuales son más rápidas. No incluya nada donde su proceso aproveche los beneficios del soporte de hardware local donde la VM necesita simularlo en software.

Está intentando comparar un sistema operativo, software y datos instalados en un determinado hardware físico con el mismo sistema operativo, software y datos instalados por sí mismos dentro de un hipervisor en el mismo hardware original. Esta comparación simplemente no es válida, porque casi nadie hace esto (al menos al principio). Por supuesto, eso probablemente sería más lento. Afortunadamente, se pierde por completo el punto más común de por qué virtualizar servidores.

Un mejor ejemplo aquí es mirar dos (¡o más!) Servidores más antiguos en su centro de datos. Busque servidores que tengan un rendimiento razonablemente bueno, pero que ya estén viejos y que estén llegando a su ciclo de actualización. Estos servidores ya funcionan bien en hardware antiguo, por lo que, gracias a la ley de Moore, todo lo nuevo que obtenga se sobre-especificará.

Entonces, ¿Qué haces? Es sencillo. En lugar de comprar dos servidores nuevos, compra solo uno y luego migra ambos servidores antiguos al mismo dispositivo físico nuevo. Cuando se prepare para comprar su nuevo servidor, planifique de manera que tenga la capacidad suficiente para manejar no solo la carga de ambos servidores más antiguos, sino también cualquier carga del hipervisor (y tal vez un poco más, para que aún pueda obtener un aumento de rendimiento y puede permitir el crecimiento).

En resumen: las máquinas virtuales proporcionan un rendimiento "lo suficientemente bueno" para la mayoría de las situaciones y lo ayudan a hacer un mejor uso de sus servidores para evitar el desperdicio de potencia informática.

Ahora vamos a estirar esto un poco más. Como se trata de servidores antiguos, quizás estaba buscando un par de servidores simples de $ 1500 para reemplazarlos. Lo más probable es que incluso una de estas cajas de pizza aún pueda manejar fácilmente la carga de ambas máquinas hipotéticas más antiguas ... pero supongamos que decide gastar $ 7500 o más en algún hardware real. Ahora tiene un dispositivo que puede manejar fácilmente hasta una docena de sus servidores existentes (dependiendo de cómo maneje el almacenamiento y las redes), con un costo inicial de solo 5. También tiene los beneficios de administrar solo un servidor físico, desacoplando su software de su hardware (es decir: la actualización del hardware ahora es menos probable que necesite una nueva licencia de Windows o cause un tiempo de inactividad), ahorra una tonelada de energía y su hipervisor puede brindarle mejor información sobre el rendimiento que usted ' he tenido en el pasado. Obtenga dos de estos y, dependiendo de qué tan grande sea, tal vez todo su centro de datos se reduzca a solo dos máquinas, o tal vez desee usar el segundo servidor como un modo de espera activo para contar una mejor historia de alta disponibilidad.

Mi punto aquí es que no se trata solo de rendimiento. Nunca tomaría un servidor de producción perfectamente bueno y lo virtualizaría solo en hardware equivalente solo porque sí. Se trata más de ahorros de costos y otros beneficios que puede obtener de la consolidación, como la alta disponibilidad. Darse cuenta de estos beneficios significa que está moviendo servidores a un hardware diferente, y eso a su vez significa que debe tomarse el tiempo para dimensionar ese hardware de manera adecuada, incluida la cuenta de la penalización del hipervisor. Sí, es posible que necesite un poco más de potencia de computación en total que si cada una de esas máquinas estuviera en su propio dispositivo físico (pista: en realidad probablemente necesite mucha menos potencia de computación total ), pero será mucho más barato, más eficiente en energía, y más fácil de mantener ejecutar un servidor físico de lo que es ejecutar muchos.

Acabo de actualizarme a un SSD (OCZ Vertex 2) y ejecuto mi entorno de desarrollo XP VM en él, soy desarrollador de software. Una cosa que he notado es que cuando inicio un programa (uno lo suficientemente grande como para tomar tiempo para cargar), un núcleo de la CPU virtual se pega. Esto sucede al cargar IE también. Como la CPU se desconecta, supongo que el cuello de botella es la CPU y no la SSD. Pero parece extraño, tengo la sensación de que si se hiciera lo mismo en una máquina física, se cargaría más rápido y creo que hay algo de procesamiento adicional que VMWare está haciendo que consume CPU en el acceso al disco.

Un ejemplo, uso Delphi y en una máquina física con un HDD normal, puede tomar 20 segundos comenzar desde un arranque en frío. En la VM que se ejecuta con un SSD, se carga en 19 segundos desde un arranque en frío. No hay mucha diferencia, apuesto a que si el SSD estuviera en la máquina física, se cargaría más rápido. Sin embargo, no verifiqué el uso de la CPU en la máquina física, es posible que la CPU también fuera el cuello de botella allí.

Pero la sensación de la VM es que el acceso al disco grava la VM.

Obviamente, una máquina virtual es más lenta que la máquina física. Pero cuando se encuentra en este escenario, debe evaluar qué es lo óptimo para cubrir sus necesidades. Si solo necesita un sistema y necesita que sea rápido, instálelo directamente en el hardware. Por otro lado, si necesita flexibilidad, escalabilidad (y todos los demás beneficios de virtualización: P) implemente una VM. Será más lento, pero en mi humilde opinión, en algunos casos está justificado y el rendimiento no es significativamente lento.

Parece que Microsoft ha realizado algunas pruebas de referencia utilizando el servidor BizTalk y SQL Server en diferentes configuraciones a este respecto. Ver enlace a continuación:

http://msdn.microsoft.com/en-us/library/cc768537(v=BTS.10).aspx

Idealmente, el rendimiento de la PC virtual es:

CPU: 96-97% de host

Red: 70-90% de host

Disco: 40-70% de host

Lamento no estar de acuerdo con TomTom.

He estado usando VMware Workstation durante un tiempo principalmente en Windows XP, Windows Vista y ahora en los sistemas nativos de Windows Seven para ejecutar diferentes versiones de Windows, así como Ubuntu.

Sí, un entorno virtualizado es más lento que un sistema nativo y puede estar en un rango de 5 a 100%.

El principal problema no es tanto la carga de la CPU sino la falta de memoria física.

Digamos que tiene un Windows Seven 64 Ultimate que se ejecuta en un sistema de 4 Gb que cuando está inactivo necesita casi 1.5 Gb y usa ~ 10% de la CPU. Lanzar la capa adicional de VMware le costará ~ 300 Kb y las cargas de CPU subirán hasta ~ 20%. Luego, el lanzamiento de un sistema virtual dentro de VMware solicitará, como mínimo, la cantidad de memoria que definió para esa máquina virtual que es un mínimo de 1 Gb para cualquier sistema decente. Luego verá la carga de la CPU ~ 60% si la máquina virtual es Ubuntu y ~ 80% para cualquier sabor del sistema operativo Windows reciente.

Ahora, iniciará diferentes aplicaciones dentro de esa máquina virtual.

Si la cantidad de memoria que ha configurado para esa máquina virtual no es suficiente, el sistema virtualizado comenzará a intercambiarse, y luego disminuirá drásticamente su rendimiento general y capacidad de respuesta.

Si la suma de la cantidad de memoria que ha configurado para esa máquina virtual más la cantidad de memoria necesaria para su sistema nativo está por encima de la cantidad de memoria de su sistema nativo, entonces es su sistema nativo el que va a cambiar, disminuyendo la velocidad tanto el sistema nativo como el virtualizado.

Por lo tanto, primero depende del equilibrio de la memoria necesaria para las máquinas nativas y virtualizadas.

Ahora es casi lo mismo con la carga de la CPU. Si una aplicación virtualizada necesita una gran carga de CPU, y una aplicación nativa también necesita una gran carga de CPU, su sistema nativo tendrá que administrar la prioridad y equilibrar la carga de la CPU entre sus diferentes aplicaciones, el sistema virtualizado no es más que una aplicación que El fenómeno es un problema clásico de carga de CPU que puede engañar con las prioridades de la aplicación.

Entonces, mi primer consejo si necesita usar la virtualización es poner un montón de memoria en su máquina, sea cual sea el sistema operativo que use de forma nativa o dentro de una máquina virtual.

Solo mis 2 centavos.

Atentamente.

En mi experiencia, las máquinas virtuales siempre son mucho más lentas que las físicas FUERA DE LA CAJA.

Solo lo notará cuando ejecute aplicaciones que golpeen el disco y graven mucho la CPU. He ejecutado muchas bases de datos y servidores web en máquinas virtuales y, como usuario final y los comentarios de otros usuarios finales (es decir, acceder a la aplicación desde un navegador web remoto), hay un retraso bastante grande al usar máquinas virtuales.

Por supuesto, una máquina virtual configurada correctamente puede llegar al 80% (no sé el número real) o lo que sea de la velocidad de la máquina física, pero terminas teniendo que profundizar en lo que está haciendo la aplicación y cómo la máquina virtual trabajos. Así que supongo que es una ecuación de costo de lo valioso que es su tiempo para configurar máquinas virtuales en comparación con la compra y el alojamiento de un nuevo servidor.

Para mí, las máquinas virtuales NO SON DE RENDIMIENTO, sino de ser más fáciles de administrar y de alojar varias máquinas virtuales de bajo rendimiento, por supuesto.