Comparando el rendimiento de diferentes hypervisores: Filosofía
Hola
En los últimos meses, una de las cuestiones que empieza a aparecer con mas frecuencia encima de la mesa es la de las comparativas que las diferentes plataformas de virtualización ofrecen en términos de rendimiento. Sin que todavía hayan terminado de despejarse las discusiones sobre las ventajas que las iguales, similares o diferentes funcionalidades aportan a las soluciones de virtualización de los diferentes fabricantes, parece que se abre este nuevo frente, muy propio por otro lado de las tecnologías que han alcanzado ya un punto importante de madurez en lo que al interés y adopción del mercado se refiere, y por supuesto, de la presencia en el mismo de diferentes competidores.
Durante los años que llevo metido en este mundillo, gran parte de ellos dedicado sobre todo a los sistemas operativos Windows y servidores que corren por encima, este tipo de comparaciones han sido, y seguirán siendo, argumentos principales en las batallas entre los diferentes competidores y de sus defensores y detractores. Me consta que ya era así antes, y supongo que así seguirá siendo en el futuro. Sin embargo, la virtualización, redescubierta en los últimos años gracias sobre todo a los avances realizados sobre los procesadores ia32 por parte de Intel y AMD, y al margen de que todos estemos de acuerdo en los importantes beneficios que supone, esta potenciando que volvamos a cometer muchas veces el viejo error de confundir el fin con los medios, olvidándonos de que desde los tiempos remotos la tecnología se ha venido usando para resolver problemas concretos.Por muy entretenido que sea comparar acaloradamente arquitecturas, funcionalidades y datos históricos de las diferentes tecnologías, nos olvidamos de que a la gente que se dedica a diseñar, implementar y operar soluciones de IT no les pagan por montar tal o cual sistema operativo, o unos u otros productos por encima, o hacerlo en físico o en virtual. Les suelen pagar porque, monten lo que monten y como o monten, aquello se ajuste bien a lo que se les demanda en cada momento. Y si se pierde este punto de vista, gran parte de las preguntas si no todas tienen una única respuesta. Depende
Se ven a menudo situaciones en las que todo parece reducirse a botes de RAM, CPU y Disco dando saltos de hypervisor en hypervisor. Pero la virtualización no se trata de arrancar máquinas virtuales sobre un hypervisor y verlas, verdes, en estado “running” dentro de una u otra consola de gestión. Supongo que la gente no se pone delante de un rack recién conectado a la luz y sembrado de servidores recién ensamblados y se relaja y disfruta viendo parpadear las luces verdes con el sentimiento de haber terminado un trabajo bien hecho. Todo esto parece ser una obviedad, pero lo cierto es que casi a diario uno se encuentra con situaciones en las que, en base uno u otro conjunto de funcionalidades, se asevera que tal o cual solución es capaz de consolidar una u otra cantidad de maquinas virtuales de unas características determinadas. Y lo cierto es que eso puede ser verdad, o no. Depende. Porque de lo que de verdad si que se trata es de saber si un cierto conjunto de máquinas virtuales, cada una de ellas haciendo su trabajo, pueden ser consolidadas sobre que cantidad de hardware usando tal o cual tecnología de virtualización y si vamos a sacar el rendimiento que se espera de todas y cada una de ellas.
Rendimiento : Proporción entre el producto o el resultado obtenido y los medios utilizados
Performance: Efficiency: effective operation as measured by a comparison of production with cost (as in energy, time, and money)
Siempre le he escuchado decir a mi amigo Alberto Camina que el análisis del rendimiento es ciencia, pero que su optimización es arte. A la vista de las definiciones anteriores no puedo estar más de acuerdo, sobre todo en la acepción inglesa que responde sin duda al carácter mucho más práctico que tienen los anglosajones si se les compara con los latinos. Datos como el número de máquinas virtuales por servidor, procesador o core, medidas del consumo de recursos de la propia pila de virtualización, o sumas y restas de memoria RAM son completamente inútiles como parámetro de entrada si lo que aspiramos es a montar una solución virtualizada. Cuando de verdad estos datos valen para algo es cuando se obtienen a partir de una solución que esta dando el servicio para el cual ha sido diseñada, y con un rendimiento que esta dentro de los márgenes acordados. Ese es el momento de sacar conclusiones, que nos permitirán extrapolarlas a escenarios que sean similares.
Benchmark: a : a point of reference from which measurements may be made b : something that serves as a standard by which others may be measured or judged c : a standardized problem or test that serves as a basis for evaluation or comparison (as of computer system performance)
Para resolver en parte del problema anterior y podernos hacer una idea antes de tener que tomar una decisión acerca del camino a seguir, se suele recurrir a estudios de benchmarking. Dichos estudios se componen de una metodología, que detalla qué es lo que se va a probar y como, y una serie de herramientas diseñadas para medir diferentes aspectos del rendimiento de un sistema/aplicación y que se eligen en función de para qué se supone que vaya a servir en el futuro lo que se pretende medir, y de unas conclusiones que en muchas ocasiones se ciñen exclusivamente a presentar los datos obtenidos, y en otras se ponen además dentro del contexto de los costes que suponen en términos de tiempo y dinero. La idea es que si esta bien hecho, el estudio pueda servir como referencia a la hora de estudiar casos más particulares, y por supuesto, de nada vale si los resultados no son 100% repetibles por un tercero si se sigue paso a paso la metodología utilizada.
Piloto : en aposición, indica que la cosa designada por el nombre que le precede funciona como modelo o con carácter experimental
Sin embargo, como todos sabemos, el mundo real supera siempre a la ficción. Y mucho más a menudo de lo que sería deseable, resulta que los puntos de partida a partir de los cuales se ha realizado el benchmark no se pueden aplicar exactamente a nuestra situación, y de hecho no existe una herramienta que sea capaz de simular la carga de trabajo que necesitamos para simular nuestro entorno. Cuando se esta pensando en la estrategia que se va a seguir a la hora de ofrecer un determinado servicio es muy importante conocer de antemano el patrón de la demanda que éste va a tener. No es el mismo el uso que hacen de un equipo cliente, una base de datos, un sistema de mensajería o cualquier cosa que se os ocurra un banco que una factoría. Incluso con las mismas versiones de productos y modelos del diferente hardware, la manera en la que se usan y los patrones pueden ser totalmente diferentes. Y eso es así incluso para diferentes tipos de usuarios (clientes de esos servicios) dentro de una misma organización. Y gracias a esto (o a pesar de :-)), desarrolladores y personal de IT cobran sus sueldos a final de mes. Esta es la razón por la que antes de decidirse por tecnologías, productos, soluciones o como lo queramos llamar, se suele optar por montar pilotos a partir de los cuales que seamos capaces de comprobar si lo que hemos visto en los diferentes bechmarks se cumple en nuestro caso, o directamente evaluar por nosotros mismos la configuración más conveniente.
Para complicar aun más la situación, los datos obtenidos de estos ejercicios de benchmarking y pilotaje pueden ser incluso todavía insuficientes a la hora de ponerse a diseñar, implementar y operar un conjunto de servicios virtualizados, o abordar un proyecto de consolidación mediante virtualización de los ya existentes. Cuando hablamos de Capacity Planning, es decir, de prever cuantos recursos vamos a necesitar para ofrecer el nivel de servicio que se nos demanda, la exactitud de los datos que podamos tener sobre la mesa puede ser determinante. Es muy frecuente encontrarse ante proyectos de consolidación en los que se solicita una infraestructura para virtualizar una serie de equipos de los que se proporciona características de CPU, RAM, Red y Almacenamiento, así como sistema operativo y role. ¿Que ha de suponerse en estos casos?. ¿Porcentajes de uso mínimos, máximos, utilización media…?. Cualquier suposición será potencialmente contraproducente y arriesgada si no se es capaz de tener, al menos, una grafica de utilización de los recursos obtenida durante un periodo de tiempo significativo de cada una de las cargas de trabajo, de manera que podamos saber por ejemplo cuales se suman en un momento dado o cuantas se compensan. Porque por mucha flexibilidad e inteligencia adicional que nos ofrezca la virtualización, si la demanda sobrepasa a la capacidad, el servicio se ve irremediablemente impactado.
Espero que llegados a este punto haya sido capaz de hacer entender que no se trata de qué hypervisor consume más o menos CPU, Memoria, Disco o Red, sino de quien es más eficiente logrando que lo que corre por encima tenga el mejor rendimiento mientras esta haciendo el trabajo que le toca, que no es otro que dar servicio. Y que si bien los cuatro parámetros básicos anteriores son sin duda importantes, el termino “Eficiencia” abarca más cosas y reducir toda esta problemática a la mera comparación de características no suele llevar a resultados que se puedan utilizar en la práctica.
Obviamente, a los que como yo trabajan para una de las partes implicadas no les queda mas remedio que arrimar el ascua a su sardina. En virtud de todo lo explicado anteriormente, lo que viene a continuación no debería ser considerado a la hora de extraer conclusiones concretas, pero si para plantearse revisar algunos mitos y leyendas, y ponerse manos a la obra a sacar nuestras propias conclusiones. En cualquier caso aquí va.
Cuando hablamos de hypervisores, estamos hablando de paravirtualización en la gran mayoría de los casos. Es decir, el sistema operativo invitado debe ser modificado para que pueda utilizar las hypercalls que expone un hypervisor determinado, y funcionar de una manera mucho más eficiente a la hora de interactuar con los recursos. Sin estos componentes instalados en sistema operativo que corre en la máquina virtual, todo lo que podemos hacer es emular un entorno de hardware determinado de modo que el sistema operativo invitado funciona totalmente ignorante de su suerte y sin aprovecharse de gran parte de las ventajas que le ofrece la pila de virtualización. Tanto cuando hablamos de funcionalidades como de rendimiento, no hay que considerar únicamente al hypervisor sino también con esa pieza software que “aligera” el kernel del invitado. Y ambos son igual de importantes, ya que no tienen sentido por separado.
Bajo mi punto de vista, el que el ciclo de desarrollo de un hypervisor vaya parejo y ligado al del kernel del sistema operativo que se va a virtualizar, tanto en su variante cliente como servidora, es un hecho diferencial y que tiene y tendrá cada vez más impacto, no solo en rendimiento, sino en otros muchos factores como la inclusión del conocimiento de las aplicaciones que corren encima dentro de la propia tecnología. Eso sucede en el caso de Hyper-V y las versiones de Windows a partir de Windows Vista y Windows Server 2008, pero también en el caso de Linux, tanto en los casos de las distros comerciales como las las de libre distribución. Y todo esto sin perder de vista que al final gran parte del trabajo recae sobre el procesador, que absorbe cada vez más y más funcionalidades relacionadas con la virtualización.
Por eso ahora el discurso se desplaza a las nubes y a su gestión.
Saludos