Cloud Wars (III)
A continuación os presentamos el último post de la serie de pruebas sobre AWS, Azure y Google Cloud de nuestra charla Cloud Wars. En este caso vamos a comentar características y pruebas sobre el almacenamiento, dejando el resto de pruebas y análisis que hicimos y que son más de "comentar" para el vídeo que publicamos hace unas semanas.
Capa de Computación - Características del almacenamiento
Las máquinas virtuales necesitan de almacenamiento para funcionar y por tanto la parte de almacenamiento está vinculada a la capa de computación en los proveedores analizados.
Algunas características básicas:
- todos los proveedores ofrecen almacenamiento permanente que realmente es almacenamiento de red basado en discos SATA
- además en el momento actual todos los proveedores ofrecen almacenamiento SSD (en algunos casos todavía con ciertas restricciones) dada la importancia del IO en multitud de escenarios. AWS permite elegir almacenamiento SSD en el que podemos especificar la cantidad de IOPS asegurados (máximo de relación 30:1 con respecto al tamaño del disco) mientras que Azure sólo lo tiene disponible en algunas regiones
- todos ofrecen almacenamiento efímero mediante almacenamiento local del host de virtualización en el que se encuentra nuestra instancia aunque AWS está dejando de incluir esta opción en las familias más modernas que ha lanzado como c4 o m4
- en todos los casos podemos hacer snapshots de los volúmenes, hacer que sean cifrados, y hacer hot swap de los discos
Pruebas de IO
Además del análisis de características se realizaron unas pruebas prácticas para medir el rendimiento del almacenamiento en los diferentes proveedores.
La primera prueba consiste básicamente en la creación de fichero de 1GB mediante el comando dd con el uso de IO direct (sin uso de memoria intermedia, buffers, etc.) obteniendo los siguientes datos:
A la vista de los datos anteriores se aprecia una ligera ventaja de AWS hacia Google y cómo Azure está muy lejos del perfomance de los anteriores. Sin embargo la prueba anterior aunque mide el IO no es muy válida para entornos reales ya que los sistemas funcionan con todas sus capacidad en conjunto por lo que las repetimos sin el IO Direct para que fueran reales obteniendo los siguientes datos:
De esta gráfica sacamos varias conclusiones importantes y muy claras:
- el perfomance de IO en AWS va muy vinculado al tamaño de instancia y esto es debido a la limitación de red que tienen las instancias más pequeñas
- Google es el que mejor perfomance ofrece
- Azure ofrece un rendimiento de IO muy malo en comparación con el resto de proveedores analizados, teniendo en cuenta que no fue posible hacer pruebas sobre su nuevo almacenamiento premium en las instancias de tipo DS dado que no estaban disponibles para cuentas en modo de prueba
Pruebas sobre MySQL
Por último, para probar el funcionamiento en entornos reales que usamos a diario con muchos clientes se realizó un benchmark básico del funcionamiento de un servidor de base de datos de MySQL en el cual es muy influyente el IO, pero también se ve en conjunto el funcionamiento de la CPU, la capa de virtualización, memoria RAM, etc.. Esta prueba se realizó únicamente sobre la modalidad de máquina grande.
Tras la ejecución de la prueba varias veces, obtuvimos los siguientes resultados medios (el valor mostrado es el tiempo medio de ejecución de todas las consultas de cada prueba):
El resultado de esta prueba confirma los datos obtenidos anteriormente posicionando en valores similares de perfomance global a Google y AWS y dejando con bastante peor resultado a Azure lastrado principalmente por el rendimiento del IO.
Es destacable igualmente indicar que durante la ejecución de la prueba en AWS nos encontramos con una incidencia puntual que sucede con poca frecuencia y cada vez menos (aunque más de la deseada) en AWS en el que de repente y sin razón aparente una instancia comienza a funcionar de manera muy degradada. Esto normalmente y según creencia popular, muy razonada por otro lado, es debido a la carga que están generando los vecinos que puedes tener en un momento dado en el nodo de virtualización, los sistemas de red o de almacenamiento y que finalmente perjudican el rendimiento de máquinas virtuales de terceros.
Enlaces: