Uno de los últimos proyectos que he realizado últimamente ha tenido como punto fuerte y principal las estadísticas (usando graphite y collectd principalmente) y paravirtualización empleando Xen (a través de los servicios de Amazon). De pronto un problema de rendimiento. ¿Por qué un incremento en E/S eleva tanto el uso de la CPU en Xen?
Leyendo sobre virtualización me encontré que hay varios tipos. No voy a profundizar mucho en este tema porque aún tengo que leer mucho más, pero la parte que leí detenidamente fue la relacionada con la paravirtualización.
La paravirtualización es un tipo de virtualización que se realiza a través de modificaciones en el sistema huésped para poder acceder directamente y sin mediación, al hardware del anfitrión. Esto quiere decir que la virtualización es bastante liviana y el rendimiento de los sistemas huéspedes suelen ser más altos que en el resto de virtualizaciones.
No obstante, hay varios tipos de paravirtualizaciones y distintos fabricantes y/o desarrolladores que han implementado estas soluciones de formas diferentes. El foco para algunos ha sido emplear el máximo posible de CPU para los huéspedes y para otros que no hubiese penalización en el uso de los dispositivos de entrada/salida (como las interfaces de red).
Xen: Maximizando el uso de la CPU
En el grupo de maximizar el uso de la CPU se encuentra XenServer. Este sistema, aunque considerado un poco antiguo, es ampliamente usado por Amazon Web Services en sus sistemas EC2 y tiene la peculiaridad de tener un alto rendimiento a nivel de CPU.
KVM: Maximizando las Entradas/Salidas
Si nos surge la necesidad de virtualizar (o paravirtualizar) y nuestro negocio se basará en un alto grado de tráfico por la red sin un gran uso de la CPU, nuestra solución óptima es KVM. Este sistema es usado por proveedores como DigitalOcean. Tiene algo menos de rendimiento en tareas que requiren de mayor uso de CPU, pero a cambio un mejor rendimiento en alto volumen de transferencia de datos.
Caso práctico: Graphite
Tal y como comenté en un artículo anterior sobre graphite. En el proyecto alojado en Amazon Web Services comenzó a aparecer un uso desorbitado de CPU que no se correspondía con los datos obtenidos por la herramienta top.
Tras analizar y detectar que el problema estaba en carbon, el demonio encargado de recepcionar todos los datos estadísticos de graphite. Cuando apagamos el servidor el consumo de CPU decrecía y cuando lo volvíamos a conectar volvía a aumentar. El problema no estaba solo en el tráfico generado por la entrada de los datos, sino también en su almacenamiento a través de whisper en el sistema de ficheros.
Barajamos varias ideas: clusterizar la solución para tener varias máquinas de carbon o cambiar de proveedor. Tras analizar ambas opciones comprobamos que era menos costoso cambiar de proveedor que emplear dos máquinas, por lo que migramos graphite al completo de Amazon Web Services a DigitalOcean.
El cambio de XenServer a KVM se notó inmediatamente. Siendo una máquina muy parecida en características, el problema de CPU no apareció en ningún momento. El montaje se realizó de forma rápida gracias a Puppet y pudimos continuar con el diseño de la infraestructura.
Conclusiones
Siempre he buscado entender y comprender la tecnología que empleo para saber si puedo sacar partido mejor o peor de los elementos de que dispongo para construir infraestructuras.
Siempre que puedo, intento agregar nuevos elementos, nuevas herramientas, para construir fácilmente entornos complejos. Es increíble encontrar estos casos y poder aprovechar lo aprendido para encontrar la mejor solución sin agregar complejidad al producto final.
¿Te has encontrado algún problema virtualizando que hayas podido solucionar cambiando de tecnología de virtualización? ¿Hay problemas que no has podido solucionar con virtualización y has tenido que recurrir al servidor físico? ¿Qué tecnologías consideras mejor para tu sector? ¿Conoces más proveedores de XenServer, KVM, OpenVZ u otras tecnologías?
