Blog

Cloud Wars (II)

Seguimos con el ciclo de posts sobre el análisis que hicimos de cloud públicos para la charla que dimos en OpenExpo Day el pasado Junio. Tras el primer post en el que hablamos del contexto de las pruebas, regiones y zonas y versiones de evaluación comenzamos este segundo en el que hablaremos de las capacidades de la capa computación en cada proveedor y realizaremos pruebas de CPU.

Para estas pruebas utilizaremos el concepto máquina virtual e instancia de manera indistinta y en todo momento nos referimos a lo mismo.

 

Capa de Computación - Características generales

Sobre las características generales de la capa de computación es importante destacar:

  • Amazon realiza facturación por horas mientras Azure y Google lo hacen por minutos, facturando Google siempre un mínimo de 10 minutos
  • Google incorpora en sus tarifas habituales un sistema de ahorro de costes en base al uso al mes de cada máquina virtual. En este sentido Amazon ofrece capacidades de ahorro mediante el prepago de instancias (lo que llaman instancias reservadas) y Azure no tiene ninguna opción de ahorro directa (la tuvo anteriormente pero ya no está vigente).
  • Curiosamente Google no permite el redimensionado de máquinas virtuales de manera directa, obligando a desvincular los discos de la máquina vitual, eliminarla y crear una nueva con los discos de la máquina anterior. Realmente es un proceso sencillo pero más engorroso que en Amazon o Azure que permiten hacerlo directamente con el único requisito de que la máquina virtual o instancia esté parada.
  • Google contempla la creación de imágenes a nivel de disco y no de la instancia virtual en su conjunto, que pueda tener varios discos; es decir, es posible la creación de imágenes pero de un único disco y siempre de discos que no estén conectados a una máquina virtual lo que además impide hacerlas en caliente (sí se pueden hacer en caliente los snapshots de los discos). En Azure los snapshots también se realizan sobre discos y si queremos crear una imagen de una máquina virtual, ésta es "capturada" y destruida después de su creación. Los discos asociados no son eliminados y pueden reutilizarse pero resulta engorrosa la operativa de creación de nuevas máquinas virtuales, por ejemplo un escalado horizontal, tomando como base una instancia actualmente en funcionamiento.

 

Pruebas de CPU

A continuación vamos a comentar una prueba de performance de CPU que hicimos en los distintos proveedores. Para esta prueba utilizamos la herramienta stress-ng cuya finalidad precisamente es la de generar carga de CPU y memoria.

Las pruebas se realizaron sobre una máquina pequeña y una ya de cierto tamaño en cada proveedor (pueden verse los datos concretos de las instancias utilizadas en la diapositiva 16 de la presentación de la charla), para además de comparar los tres cloud entre sí, poder comparar como afecta el rendimiento en base al coste en un proveedor concreto.

Inicialmente se lanzó una prueba que únicamente generaba stress de CPU con un número de hilos igual al número de vCPU de la instancia o máquina virtual y posteriormente con el doble de hilos. Esta prueba se realizó en ejecuciones de 1, 15 y 60 minutos para comprobar además la estabilidad a lo largo del tiempo de la vitualización de los diferentes proveedores. El comando utilizado en este caso es:

stress-ng --cpu <hilos_cpu> --cpu-method all -t <minutos>m --metrics-brief

Los resultados obtenidos (media de todas las pruebas en cada instancia) son los que podemos ver en la siguiente gráfica (incluye tambien los datos de la siguiente prueba que incorpora stress de memoria RAM, como el gráfico es interactivo se puede hacer click sobre la leyenda verde para que se oculten las barras de dicha prueba y ver sólo los datos del test puro de CPU):

stress-ng nos devuelve como resultado el número de operaciones realizadas en el tiempo de ejecución y en la gráfica anterior representamos el coste por operación, es decir, dado el número total de operaciones obtenido se compara con el coste de la máquina virtual. De esta manera y viendo la gráfica comprobamos que:

  • En los tres proveedores el coste por operación es bastante caro en las instancias pequeñas en relación al coste en las instancias grandes, es decir, el performance de las instancias pequeñas es mucho peor y no es directamente proporcional al número de vCPUs
  • El coste por operación es prácticamente el mismo en los tres proveedores en las instancias grandes. En las instancias pequeñas, sí se aprecia diferencia entre los diferentes proveedores obteniendo un resultado considerablemente mejor en Google.
  • Duplicar el número de procesos no afecta prácticamente al resultado obtenido.

Dado que raramente en entornos reales realizamos únicamente procesamiento (cálculo matemático), hicimos una segunda prueba en la que añadimos pruebas con iosync y memoria virtual (barras verdes en el gráfico anterior) con el comando siguiente:

stress-ng --cpu 0 --io 10 --vm 5 --vm-bytes 1G --malloc 5 --malloc-bytes 1024000 --timeout 1800s --metrics-brief

La ejecución anterior se reperesenta en la barra verde y a partir de ella podemos comprobar que:

  • Se mantiene la diferencia de performance que ofrecen las máquinas virtuales pequeñas de las grandes.
  • Se detecta una diferencia mayor en el perfomance de las máquinas grandes entre los diferentes proveedores obteniendo Google el mejor perfomance y siendo Amazon el que peor resultado da en este caso

A la vista de los resultados, parece que si tenemos un proyecto puramente de cálculo, y sin tener en cuentas otros datos como Google puede ser una buena opción aunque los resultados en los tres proveedores son aceptables si los comparamos entre sí.

También cabe destacar que los resultados obtenidos son malos si los comparamos con los que ofrece cualquier servidor dedicado tradicional de proveedores como Hetzner u OVH por ejemplo, por lo que siempre se debe considerar si un cloud público es lo que realmente necesita nuestro proyecto, teniendo en cuenta estos aspectos técnicos, los requerimientos de escalado, el coste, etc.

 

Enlaces:

Newsletter de STR Sistemas

Suscríbete a nuestra newsletter para recibir contenido interesante del mundo DevOps y artículos escritos por nuestros técnicos

¡Usamos cookies propias y de terceros para mejorar tu experiencia en esta web! Si sigues navegando, consientes y aceptas estas cookies en tu ordenador, móvil o tablet.

Más información sobre las cookies y cómo cambiar su configuración en tu navegador aquí.

x