Entonces, ¿cuál es la sobrecarga de la virtualización y cuándo debería preocuparme?

16

Estoy buscando buenas reglas generales para entender cuándo NO virtualizar una máquina.

Por ejemplo, sé que un proceso totalmente vinculado a la CPU con una utilización cercana al 100% probablemente no sea una buena idea para virtualizar, pero ¿tiene algún sentido ejecutar algo que aproveche la CPU la mayor parte del tiempo una "cantidad sustancial" (digamos 40 o 50%)?

Otro ejemplo: si virtualizo 1000 máquinas, incluso si se utilizan de forma ligera o moderada, probablemente sería malo ejecutar todo eso en un host con solo 4 núcleos.

¿Alguien puede resumir sugerencias sobre la virtualización basada en la carga de trabajo de la máquina o la gran cantidad de máquinas invitadas en comparación con los recursos del host?

Por lo general, virtualizo en hosts de Windows usando VirtualBox o VMWare, pero supongo que esta es una pregunta bastante genérica.

kvista
fuente
1
incluso con algunas tareas vinculadas a la CPU, la virtualización tiene un punto: permitir a los usuarios enviar trabajos a clústeres ya que las imágenes de VM les permiten un control mucho mayor sobre el entorno en el que se ejecutan los trabajos de lo que sería posible con un simple programador por lotes, por ejemplo.
Flexo
Pero en algún momento la programación de la "ejecución de VM" parece una sobrecarga innecesaria cuando ya es bastante difícil programar subprocesos dentro de una sola VM, ¿estoy en lo cierto?
kvista

Respuestas:

13

Subsistema de disco. Este suele ser el recurso menos compartible. Memoria, por supuesto, pero esa es evidente.

Las limitaciones del subsistema de disco funcionan en ambos sentidos. Si un sistema usa una gran cantidad de E / S de disco, otros invitados disminuyen la velocidad. Si este invitado está en producción, es probable que necesite una respuesta rápida a las consultas web. Esto puede ser muy frustrante y también una gran razón por la cual no alquilar hardware virtual. Puede minimizar este problema utilizando discos dedicados.

El uso de solo 512 MB de memoria en Invitados coloca todo el caché de disco en el host. Y no se divide por igual entre los invitados.

No te preocupes por la CPU IO. De esta manera, la virtualización es muy eficiente, a menudo relacionada como solo múltiples procesos que se ejecutan en el mismo sistema. Rara vez veo sistemas multi-xeon que se ejecutan al 100% en la CPU.

editar: errores tipográficos

Antti Rytsölä
fuente
3
los requisitos de E / S de disco pesado serían la razón número 1 para no virtualizar: es el recurso más afectado por las penalizaciones de virtualización, consulte codinghorror.com/blog/2006/10/…
Jeff Atwood
Gracias, ambos comentarios son útiles. Me pregunto si alguien sabe por qué el uso elevado del disco es problemático para virtualizar. ¿Por qué los ingenieros de virtualización ignorarían ese problema relativamente básico? ¿O es fundamentalmente más complejo que la virtualización de la CPU?
kvista
Nota: @Jeff, estoy leyendo tu publicación de blog de 2006 y supongo que eso explicará por qué mejor (es decir, la reserva del huso), pero mi pregunta a los diseñadores / implementadores de virtualización sigue siendo la misma: ¿esto es fundamentalmente problemático para la virtualización en una forma en que la virtualización de CPU no lo es?
kvista
3
Solo hay tantas búsquedas que un disco duro puede hacer. Para un disco duro de 5 ms, esto sería 200 búsquedas por segundo. Y, en general, cuando un sistema operativo copia archivos o escanea directorios, siempre usa el 100% del disco io. Durante este tiempo, todas las solicitudes pequeñas del disco se retrasan, y hay muchas. También los búferes del sistema de archivos se desperdician debido a la copia. Se podría decir que nuestro concepto de SO operativo se basa en un disco duro inactivo.
Antti Rytsölä
1
Gracias. Supongo que sería interesante ver si los SSD cambian esta ecuación. Pero ahora estamos llegando demasiado al modo de discusión. Lo entiendo, gracias a todos.
kvista
15

Cosas que nunca pondría en una VM:

  • Cualquier cosa que use hardware específico que no se pueda virtualizar: generalmente gráficos, bastantes módulos de seguridad de hardware, cualquier cosa con controladores personalizados (controladores de red de propósito especial, por ejemplo).

  • Sistemas con problemas de licencia. Algunos cargos de software por CPU física o núcleo, no importa cuán pocos haya asignado a la VM. Te verían afectado en una auditoría si tuvieras licencia de software para un solo núcleo que se ejecuta en una VM en un servidor de 32 núcleos.

Cosas que desalentaría poner en una VM:

  • Software que ya hace un esfuerzo por utilizar todos los recursos en hardware básico. Las máquinas que trabajan como parte de un esfuerzo de "big data", como hadoop, generalmente están diseñadas para funcionar en metal desnudo.

  • Cualquier cosa que se vaya a ajustar para utilizar los recursos. Cuando realmente comienza a ajustar una base de datos, las máquinas virtuales que compiten por los recursos realmente van a poner una llave en el trabajo.

  • Cualquier cosa que ya tenga un gran cuello de botella. Ya no juega bien consigo mismo, probablemente no jugará bien con otros.

Hay algunas cosas que son bastante impresionantes para poner en máquinas virtuales:

  • Cualquier cosa que pase mucho tiempo inactiva. Los hosts de servicios públicos como el correo y DNS tienen dificultades para generar suficiente carga en el hardware moderno para garantizar servidores dedicados.

  • Aplicaciones que no se escalan bien (o fácilmente) por sí mismas. El código heredado con bastante frecuencia cae en esta categoría. Si la aplicación no se expande para ocupar el servidor, use muchos pequeños servidores virtuales.

  • Proyectos / aplicaciones que comienzan poco a poco pero crecen. Es mucho más fácil agregar recursos a una VM (así como pasar a un hardware más nuevo y más grande) en lugar de comenzar desde cero.

Además, no estoy seguro de si está exagerando acerca de colocar una gran cantidad de máquinas virtuales en un solo host, pero si está tratando de obtener una gran relación VM: HW, es posible que desee considerar ESX, Xen, KVM. Te irá mucho mejor que usar VMware o virtualbox en Windows.

Cakemox
fuente
1
+1 comentarios organizados muy útiles: ¡gracias!
kvista
Un comentario más: incluso si uso ESX, etc. Supongo que en algún momento no tiene sentido colocar máquinas X en un host de núcleo Y. ¿Cuáles son buenas reglas generales? Supongo que los documentos técnicos sobre virtualización en algún lugar deben abordar este problema, pero lamentablemente no puedo encontrarlo fácilmente.
kvista
1
Para VMware, puede comenzar aquí: vmware.com/technology/whyvmware/calculator
Cakemox
Para la referencia: según el enlace VMWare anterior, puede configurar hasta 30 máquinas virtuales por CPU. El valor predeterminado es 6 máquinas virtuales por CPU.
Alex Yursha
4

Hay dos puntos para el rendimiento de virtualización.

  • cuello de botella compartido
  • emulación

En cuellos de botella compartidos, ¿quién más está en el mismo hierro? Si está ubicado en un entorno virtualizado, depende mucho de que el socio de alojamiento sea honesto con usted.

Creo que la pregunta principal para el rendimiento bruto (particularmente la interactividad) es qué partes del sistema de virtualización se emulan. Esto difiere según la configuración. El disco y la red son los candidatos típicos. Como regla general, la emulación duplica el "costo" de rendimiento de realizar una acción, por lo que cualquier tiempo de latencia de hardware debe contarse al doble y cualquier número de interrupción debe reducirse a la mitad.

Bittrance
fuente
1
los números que vi fueron CPU al 96-97%, red al 70-90% y disco al 40-70% (de metal desnudo)
Jeff Atwood
1
El comentario de la regla general de +1 es útil.
kvista
2

En definitiva, cualquier carga de alto rendimiento no debe virtualizarse. Las revisiones de rendimiento de la virtualización no son triviales. Vea los resultados de mis pruebas aquí:

http://www.altechnative.net/2012/08/04/virtual-performance-part-1-vmware/

OTOH, si está buscando consolidar una cantidad de máquinas que en su mayoría están inactivas todo el tiempo, la virtualización es el camino a seguir.

Gordan
fuente
1

Buena respuesta de anttiR.

Además, los sistemas de tiempo crítico. Me acabo de dar cuenta de que la podredumbre de Hyper-V (vm se está quedando atrás lentamente, todos los sistemas operativos modernos en vm hacen eso, se vuelven a sincronizar a menudo) no está funcionando bien con algunas aplicaciones críticas que estoy desarrollando. Además, voy a usar "mucha" CPU allí, y planeo obtener una máquina de 12 núcleos solo para esa aplicación en producción.

TomTom
fuente
Asterisk es una de esas aplicaciones. Obtiene algunas cosas muy funky que suceden durante las llamadas de conferencia cuando se visualizan.
Ryaner el
Tengo el problema con la estabilidad del reloj para las grabaciones de datos;) Gracias a Dios, recibo una marca de tiempo confiable de la fuente de datos, pero es difícil averiguar si hay problemas de red cuando el reloj del sistema no es estable.
TomTom el