Los usuarios de sistemas virtualizados, y especialmente los proveedores de servicios, a menudo se preguntan: "¿cómo aprovechar al máximo el hardware disponible?" Y en este contexto, a menudo tenemos que discutir el hipervisor KVM y las diferencias entre las diferentes versiones de Virtuozzo. En esta publicación hablaremos de una serie de pruebas del último sistema de virtualización junto con estimaciones del rendimiento real bajo cargas típicas, así como teniendo en cuenta los parches Meltdown y Spectre.
¿Qué es lo más importante para una empresa de hosting o para un departamento de TI que necesita organizar el soporte para la cantidad máxima de tareas en el equipo existente? Si una empresa trabaja de acuerdo con un modelo orientado a servicios o vende servicios, la práctica muestra que lo principal es el indicador de ganancias por servidor. Qué tecnologías se utilizan al mismo tiempo y debido a que se logra la densidad de distribución, los representantes comerciales no están tan preocupados.
Sin embargo, la pregunta de por qué usamos KVM como hipervisor en Virtuozzo 7, y cómo diferimos de un simple sistema de virtualización OpenSource en este caso, se hace con mucha frecuencia. Y hoy quiero darle una respuesta.
En el pasado, Virtuozzo trabajaba con su propio hipervisor propietario, pero hace varios años nos dimos cuenta de que desarrollarlo es más costoso y más difícil que optimizar un KVM razonablemente exitoso y eficiente. Sin embargo, KVM no es un punto de referencia para el rendimiento y, como cualquier plataforma OpenSource, debe actualizarse con un archivo. Esto es parte de nuestro departamento de desarrollo. Optimizamos el código, lo integramos con la plataforma de almacenamiento de datos y otros componentes, aumentando así la productividad y la densidad.
Comparación con otros hipervisores.
Una de las pruebas que utilizamos para medir el rendimiento es la tienda de DVD. Utiliza un conjunto clásico de software de servidor: Linux, Apache, MySQL, PHP (LAMP). Dentro de cada máquina virtual, la prueba emula el funcionamiento de una tienda de DVD en línea. El resultado de la prueba es el número de transacciones comprometidas en total en todas las máquinas virtuales (eje de ordenadas). El número de máquinas virtuales involucradas en la prueba aumenta secuencialmente de 1 a 100 (eje de abscisas).
LÁMPARA: OpenSource QEMU KVM vs Virtuozzo @ CentOS 7.4 (máquinas virtuales)
Como puede ver en los gráficos anteriores, el rendimiento de las máquinas virtuales con CentOS Linux 7.4 ejecutándose en el hipervisor Virtuozzo 7 es hasta un 30% más alto que cuando se inicia una carga similar en el KVM estándar. La mayor diferencia se observa en el punto del sobre-compromiso de la CPU, donde el número total de núcleos de procesador asignados a todas las máquinas virtuales alcanza el número de núcleos físicos del servidor de la CPU. Para este servidor, este punto corresponde a 20 máquinas virtuales. Además, el núcleo de Virtuozzo 7 y la política de gestión de memoria adaptativa aseguran un funcionamiento estable de las máquinas virtuales después del punto de sobrecompromiso de RAM, donde la cantidad total de RAM asignada a todas las máquinas virtuales excede el tamaño de la memoria física del servidor. Con tal carga, el KVM estándar no puede crear las condiciones para el funcionamiento normal.
Se realizó otra comparación entre el hipervisor Virtuozzo 7 y Microsoft Hyper-V 3.0. Aquí, el rendimiento se evaluó mediante la prueba vConsolidate, y Windows Server 2012 R2 se utilizó como sistema operativo invitado para máquinas virtuales.
vConsolidate: Hyper-V vs Virtuozzo @ Windows 2012 R2 (máquinas virtuales)
A diferencia de la tienda de DVD, en vConsolidate la carga no es la misma para todas las máquinas virtuales. En esta prueba, se dividen en las llamadas CSU (Unidades de acumulación de consolidación). Cada CSU es un grupo de cuatro máquinas virtuales que cargan SPECjbb, WebBench y SysBench (OLTP). La cuarta VM en cada CSU está inactiva, es decir, sin carga. El resultado cuantitativo es la media geométrica de los resultados de las tres pruebas mencionadas anteriormente obtenidas en total de todas las máquinas virtuales (eje de ordenadas). El número de CSU involucradas en la prueba aumenta secuencialmente de 1 a 24 (abscisa).
Para ambos hipervisores, la prueba se realizó dos veces: con parches para las vulnerabilidades Meltdown y Spectre instalados, así como sin ellos. La aproximación de los resultados muestra que Virtuozzo 7 en promedio muestra un rendimiento 15% mayor que el hipervisor "nativo" de Microsoft.
Derretimiento y espectro
Como saben, el 4 de enero de 2018, toda la comunidad de TI estaba entusiasmada por el descubrimiento de vulnerabilidades conceptuales a gran escala en todos los procesadores Intel, con la excepción de Itanium y Atom anteriores (hasta 2013). El uso de estas vulnerabilidades permite que cualquier proceso no privilegiado en el sistema acceda a los datos del núcleo (Meltdown) o los datos de otro proceso (Spectre). Los desarrolladores de software se centraron en lanzar actualizaciones de software para abordar estas vulnerabilidades. Sin embargo, los usuarios naturalmente tenían preguntas sobre cómo estas actualizaciones afectaban el rendimiento del sistema.
Verificamos cómo los parches para Meltdown y Spectre afectan el rendimiento de los contenedores con CentOS Linux 7.4 usando la prueba vConsolidate como ejemplo. Luego realizamos otra medición: con el núcleo, un compilador modificado compilado con la opción "Retpoline" (por ejemplo, GCC y Clang / LLVM ofrecen esta opción).
Rendimiento con Retpoline: vConsolidate @ CentOS 7.4 (contenedores)
Como puede ver en los gráficos anteriores, la aplicación de parches contra Meltdown y Spectre reduce significativamente el rendimiento del contenedor. Además, el parche más "difícil" fue para Spectre-V2. Sin embargo, el uso del compilador con la nueva opción Retpoline le permite abandonar con seguridad este parche en sistemas con procesadores más antiguos que Skylake y recuperar hasta un 25% del rendimiento. Sin embargo, todavía perdimos alrededor del 5% debido a parches para Meltdown y Spectre-V1.
Rendimiento con Retpoline: vConsolidate @ CentOS 7.4 (máquinas virtuales)
En el caso de CentOS Linux 7.4, la situación dentro de las máquinas virtuales es un poco más optimista: los parches para Meltdown y Spectre degradan el rendimiento en solo un 15%, y la diferencia de rendimiento entre el núcleo no parcheado y el núcleo compilado con Retpoline es solo del 1-2%. Por lo tanto, el uso del nuevo compilador hizo posible compensar casi por completo la caída en el rendimiento. Sin embargo, vale la pena considerar que las tres mediciones se realizaron en las mismas máquinas virtuales, con núcleos de SO invitados sin parchear. La actualización de los sistemas operativos invitados generará una degradación adicional del rendimiento para las aplicaciones del usuario.
Rendimiento con Retpoline: vConsolidate @ Windows 2012 R2 (máquinas virtuales)
El último gráfico de hoy es una comparación similar, pero con las máquinas virtuales de Windows Server 2012 R2. Aquí la desaceleración de los parches no fue tan grande y ascendió a aproximadamente el 10%, y el uso del núcleo con Retpoline permitió reducir la diferencia al 2-3% en relación con el núcleo sin parchear.
Conclusión
Por supuesto, KVM no modificado tiene sus ventajas, y la principal ventaja es que es gratis. Pero las pruebas realizadas demuestran que las mejoras privadas y la modernización pueden mejorar el rendimiento de la infraestructura utilizada. Es decir, si necesita colocar un máximo de contenedores y máquinas virtuales, garantizar un almacenamiento permanente para ellos, todo en la misma plataforma y con un mínimo de bailes chamánicos, el KVM mejorado es mucho más efectivo, especialmente si los servicios que se ejecutan en la plataforma muestran buenos márgenes y brindan real el dinero En este caso, el costo de las licencias y el soporte más que vale la pena en el menor tiempo posible.
La fuerza de VZ7 sigue siendo el soporte de diferentes tipos de máquinas virtuales y contenedores en la misma plataforma, y con un mayor rendimiento para cada categoría de objetos virtuales. Sin embargo, tampoco se puede hablar de una panacea aquí. Por ejemplo, si un aumento en la densidad no aporta financiación adicional a la organización, y su propio personal puede administrar y finalizar las soluciones OpenSource, entonces la lógica tiende a utilizar herramientas abiertas, incluidos CentOS y el KVM original.
Por cierto, en la próxima publicación hablaremos sobre la evolución de nuestro almacenamiento distribuido y sus capacidades reales para trabajar con máquinas virtuales y contenedores.