Actualidad
Cliente/Servidor

El rendimiento del servidor en la nube no siempre es consistente

Los beneficios del trabajo cloud son innumerables, pero algunas veces no son factibles ya que pueden manifestar métricas de rendimiento radicalmente diferentes, medidas segundo a segundo.

servidores sala

Muchos elementos del cloud computing son indiscutiblemente beneficiosos. La posibilidad de rápidamente provisionar, clonar e implantar servidores para abordar problemas de capacidad es un plus definitivo, y el hecho de que sin esfuerzo se puedan añadir elementos como balanceadores de carga, grandes capacidades de almacenamiento y bases de datos, es igualmente atractivo. No obstante hay también elementos menos atractivos que también hay que conocer. Por ejemplo el hecho de que en muchos casos, instancias de servidor en la nube puedan manifestar métricas de rendimiento radicalmente diferentes, medidas segundo a segundo.

Seguro, los SLAs y las garantías dadas por el suministrador del servicio en la nube, permiten abordar estos problemas una vez ocurridos, pero cuando el tiempo es crítico, no hay nada que se pueda hacer, nada más que comunicar el problema y esperar que se resuelva rápidamente. Se puede tener visibilidad de lo que están haciendo las instancias, pero no se tiene ni idea de lo que está haciendo el hardware que está debajo, como está configurado o cuán sobrecargado está. Esa es la naturaleza de la nube.
No hay secreto en cómo operan los suministradores de cloud computing. Ellos han construido herramientas sobre diferentes plataformas de virtualización para una provisión de VM en auto-servicio, pero al final todo se reduce a las mismas plataformas básicas de virtualización que usamos “en casa”. En estas, no obstante, controlamos todo, lo de dentro y lo de fuera, lo que no es el caso en la nube.
Digamos por ejemplo que vamos a implantar un servicio en una nube pública que va a requerir un cierto número de servidores Web, al menos un servidor de base de datos y un balanceador de carga. El balanceador de carga es ejecutado por el suministrador de la nube, y no tenemos visibilidad de su carga o rendimiento. Como resultado, si empezamos a ver que el número de conexiones de entrada baja, no podemos saber si es que la carga de entrada está cayendo o si es que hay un problema de capacidad con el balanceador de carga.  O pongamos otro ejemplo, podemos encontrar que el rendimiento de nuestros servidores Web varía enormemente, a pesar de que estén configurados de forma idéntica.
Haciendo una prueba con un suministrador de cloud bien conocido, corrí algunos test del servidor que daba el servicio. Básicamente usé la herramienta  de benchmark de Apache para medir el rendimiento de Nginx en el host, así que estaba atacando el servidor desde sí mismo, solicitando el mismo fichero PNG 3000 veces, con 20 conexiones concurrentes, y un segundo de descanso entre cada prueba. La configuración de Nginx se dispuso para poner en cache esos ficheros, así que lo que hacía era simplemente extraer la imagen de la RAM y enviarlo, sin involucración de I/O de disco.
En el transcurso de seis pasadas del test, pude ver un máximo de 7.749,1 peticiones por segundo, y un mínimo de 4.754,43 peticiones por segundo. La media entre todos los tests fue de 6.499,19 peticiones por segundo.  Esto representa un rango importante de variabilidad en los resultados, lo que hace difícil hacer una previsión de métricas de escalabilidad.
Por otro lado, corriendo las mismas pruebas contra una VM in-house con el mismo número de vCPUs y RAM, pude ver un máximo de 15.176,66 peticiones por segundo y un mínimo de 14.507,47 peticiones por segundo, con una media de 14.829,52 peticiones por segundo. Estos son obviamente resultados mucho más consistentes.  Son también casi tres veces más altos que los resultados de la instancia en la nube.
Las CPUs en uso eran diferentes, lo que explica algo la disparidad. La VM in-house utilizó CPUs Intel Xeon E5-2670 a 2.6 GHz con 20MB de cache, mientras que la instancia en la nube utilizó CPUs AMD Opteron 4332 HE a 3.0 GHz con 2MB de cache. Pero esta no es toda la historia. Debería haber tenido resultados igualmente consistentes, aunque más bajos, en la instancia en la nube. En cambio, tuve un rango de casi el 50% del resultado medio. Esto se compara con un rango de menos del 5% de la media de la VM in-house.
Los servidores cloud se venden generalmente por el número de vCPU, RAM y utilización de ancho de banda, pero claramente no todas las instancias se crean igual. Pero incluso si así fuera, la capacidad del hardware que está debajo puede variar grandemente dependiendo de dónde se ejecuta la instancia.  La solución desde un punto de vista puramente operacional es sobredimensionar la infraestructura cloud para considerar esas grandes disparidades en el rendimiento, pero esto también tiene sus problemas, incluyendo claro el coste adicional.
También, incluso si la instancia se sobredimensiona, el rendimiento puede sufrir si el balanceador de carga trata de nivelar una carga entrante con diferentes instancias con diferentes niveles de prestaciones, aunque éstas sean ostensiblemente idénticas en especificaciones.  Si el balanceador de carga dirige el tráfico a la instancia con menos carga, medido por número de conexiones, esa instancia puede muy bien estar a bajo rendimiento comparada con otras instancias “idénticas”, que pueden estar gestionando más conexiones pero que realmente están operando más rápido.
No hay una buena solución a este problema, que no sea estar atento y presionar al suministrador de la nube para que entregue lo que prometió.  Recomendaría ejecutar pruebas de rendimiento programadas para chequear los niveles de rendimiento a lo largo del tiempo, y utilizar estos resultados como munición en discusiones posteriores con el suministrador.
Las razones de utilización de la nube pueden ser muchas, pero los servidores cloud no son ciertamente la panacea que parece que pudieran ser.

Whitepaper emc-cio-it-as-a-service-wp Whitepapers