Muchos clientes nuevos, cuando comienzan a usar CloudSigma, quieren probar el rendimiento; a menudo buscan comparar los resultados de rendimiento entre los servidores en la nube y su propia infraestructura, y eso tiene sentido. Una comparación directa de precios por recurso no cuenta ni de lejos toda la historia; lo que realmente importa es el resultado final, ¿cuánto cuesta realizar una tarea informática específica?
Para cualquier requisito dado, la cantidad de recursos necesarios para lograrlo puede variar ampliamente entre nubes. Esto significa que comparar solo precios no funciona. La otra cara de la moneda es que comparar el rendimiento de forma aislada no es mejor. Las comparaciones significativas deben combinar tanto el precio como el rendimiento para calcular alguna medida de costo por unidad informática. En esta publicación voy a compartir algunas de mis reflexiones sobre la evaluación comparativa de nuestros servidores en la nube y otros. También proporcionaré algunos consejos para obtener resultados útiles y lo que realmente significan.
Advertencias de salud
Para explicarlo de antemano, soy bastante escéptico sobre las pruebas de rendimiento en general. Rara vez ofrecen una visión real del uso en el mundo real. En resumen, no hay un sustituto real para ejecutar las aplicaciones reales que planea usar en la plataforma. Si puede lograr esto a un costo razonable en términos de tiempo, entonces no hay sustituto para tal ejercicio.
Otro factor es qué tan ocupado esté el proveedor de la nube. Puede realizar pruebas de rendimiento en servidores en la nube y obtener resultados excelentes. Sin embargo, estos pueden deberse en gran medida al nivel de uso (o la falta del mismo) de ese proveedor en particular. Eso puede no ser una señal positiva. Podría reflejar dificultades en la operación, pérdida de clientes, problemas pasados con la disponibilidad y la confiabilidad, etc. Por lo tanto, siempre debe investigar al proveedor de la nube en busca de interrupciones pasadas y otros problemas potenciales al interpretar sus resultados de rendimiento.
Como advertencia de salud final, el rendimiento no es el único factor que debe considerar. A menudo, un menor rendimiento puede reflejar una arquitectura de hardware subyacente más robusta (y redundante). Por lo tanto, siempre es importante tener una comprensión muy clara de sobre qué infraestructura está construida la nube. De este modo, puede comparar los resultados de manera justa, lo que le permitirá tomar una decisión de compra significativa.
Definir el problema
Más adelante en esta publicación, expongo los diversos aspectos del rendimiento y la mejor manera de interpretar los resultados. Sin embargo, antes de realizar cualquier prueba de rendimiento, es importante caracterizar el tipo de computación que buscará realizar en la nube; esto determinará la importancia relativa de las diferentes métricas de rendimiento. Por ejemplo, si busca ubicar un servidor de base de datos y este estará bajo un fuerte acceso de lectura pero bajo acceso de escritura, debe prestar atención al rendimiento del disco en la nube y, en particular, al acceso de lectura no secuencial.
Por lo tanto, antes de comenzar cualquier prueba de rendimiento de servidores en la nube, codifique realmente lo que consideraría un buen rendimiento de la nube. Debe determinar qué aspectos son clave y tienen un impacto desproporcionado en el rendimiento de su computación en el mundo real. Una vez que tenga una idea clara de esto, estará en condiciones de comenzar a analizar las pruebas de rendimiento.
Rendimiento computacional
Cuando analizamos el rendimiento computacional bruto, estamos hablando de CPU y RAM. Las diferencias de rendimiento a nivel puramente computacional entre las nubes en realidad no son tan grandes. Sin embargo, existen algunos factores que están causando las diferencias reales.
Con diferencia, el factor más importante que afecta al rendimiento computacional en la nube es la contención. Las nubes públicas son entornos multiinquilino. La RAM y el almacenamiento no se pueden sobreasignar en la práctica (aunque se pueden vender en exceso), pero la CPU sí se puede y se hace. Los niveles de contención varían considerablemente, pero esencialmente los proveedores de nube pública pueden vender la capacidad de CPU de un host físico a más del 100%.
Algunos de los proveedores más grandes utilizan ratios de contención de CPU de más de tres veces. Esto significa que la capacidad total de CPU ‘vendida’ de todos los servidores virtuales en la misma máquina física podría ser tres veces su capacidad real de CPU. Hacen esto porque la mayoría de los servidores virtuales no utilizan nada parecido al 100% de su asignación de CPU la mayor parte del tiempo. Aun así, los ratios de contención afectarán directamente a los puntos de referencia de rendimiento de los servidores en la nube y al uso en el mundo real. Si la contención es alta (es decir, en cualquier valor superior al 200% de asignación de CPU), el rendimiento del servidor en la nube se deteriorará significativamente.
En pocas palabras, si la carga en cualquier máquina física supera el 1 por núcleo, las tareas computacionales se ponen en cola y el tiempo que tarda esa máquina virtual en completar el trabajo será mayor. Dado que la mayoría de las nubes cobran en función de la capacidad/hora, esto tiene un impacto directo en los costes para los clientes de esa nube.
El otro factor importante que afecta al rendimiento computacional es el número de núcleos de CPU a los que tiene acceso la máquina virtual. Esto no es un factor para todas las aplicaciones, pero muchas aplicaciones modernas sí admiten subprocesos múltiples. Efectivamente, esto significa que la aplicación y/o el sistema operativo es capaz de distribuir las tareas computacionales entre múltiples núcleos. Un gran consejo para mejorar el rendimiento de su computación es hacer coincidir el número de hilos (es decir, núcleos) que una aplicación puede admitir con el número de núcleos a los que tiene acceso la máquina virtual.
Desafortunadamente, esto no es posible con muchas nubes públicas. Esto se debe a que sus plataformas de virtualización no admiten la virtualización a nivel de núcleo de CPU. En otras palabras, cada núcleo solo puede estar en uso por una máquina virtual a la vez. En las nubes que sí admiten la virtualización de núcleos de CPU, debería experimentar variando el número de núcleos para esa máquina mientras mantiene el mismo tamaño total de CPU.
Por ejemplo, si tiene una máquina de 2GHz, puede ver cómo duplicar los núcleos en uso de dos a cuatro afecta a sus pruebas de rendimiento. Al hacer esto, las aplicaciones que se ejecutan en esa máquina virtual podrán ejecutar tareas a través de cuatro núcleos simultáneamente. En nuestro caso, puede configurar el número de núcleos que utiliza una máquina virtual a través de la pestaña ‘avanzado’ en el modal de detalles del servidor de la consola web. Solo recuerde verificar siempre cuál es el tamaño de núcleo estándar del proveedor de la nube antes de sobrescribir manualmente el número de núcleos en uso. En nuestro caso es de 2.2GHz por núcleo, pero varía de una nube a otra.
Recomendaría considerar el uso de POV-RAY, CoreMark, Dhrystone o Whetstone para realizar pruebas de rendimiento de servidores en la nube.
Almacenamiento: el verdadero punto de referencia de rendimiento de los servidores en la nube
Todo el rendimiento está limitado por el eslabón más débil donde se desarrolla un cuello de botella. Actualmente, la tecnología ha avanzado significativamente en el campo de la virtualización con respecto al uso de CPU y RAM. Por ejemplo, una sola máquina física se puede virtualizar y tener múltiples servidores en la nube con una pérdida mínima en el rendimiento total agregado. Lamentablemente, en el caso del almacenamiento, todavía queda mucho camino por recorrer. El resultado final es que, en la mayoría de los casos, el rendimiento de los servidores virtuales en la nube está determinado por el rendimiento de la solución de almacenamiento de esa nube.
En resumen, el almacenamiento es actualmente el factor limitante en el rendimiento de la mayoría de las tareas computacionales en la nube. Independientemente de los resultados que pov-ray y otras pruebas de rendimiento puedan producir para tareas puramente computacionales, la realidad es que la velocidad con la que el servidor virtual puede recuperar y escribir datos en los discos de almacenamiento físico determinará el rendimiento en el mundo real de un servidor en la nube actualmente.
Con esto en mente, las diferencias reales observadas en el rendimiento en la nube, incluso con respecto a las tareas computacionales, tienden a derivarse de las diferencias en el rendimiento del almacenamiento. Como se mencionó anteriormente en esta publicación, existen necesidades de clientes muy diferentes según la tarea informática. Esto nunca es más cierto que con respecto al almacenamiento. ¿Necesita un acceso de lectura rápido a grandes fragmentos secuenciales de datos (como la transmisión de contenido multimedia) o a pequeñas piezas de información dispares (quizás en una gran base de datos)? ¿Necesita mantener un acceso de escritura intensivo para datos que cambian rápidamente y a los que se accede periódicamente en grandes ráfagas? Existen numerosos escenarios y cada uno funcionará de manera diferente en la misma plataforma.
Fundamentalmente, las diferencias de rendimiento se reducen a la arquitectura. Esas diferencias en la arquitectura suelen ser el resultado de diferentes grados de robustez con respecto al almacenamiento de datos, su redundancia y, por lo tanto, la probabilidad de que se pierdan de forma irreparable. A un alto nivel, las nubes emplean soluciones de datos centralizadas en forma de una Red de área de almacenamiento (SAN) o soluciones de almacenamiento local más distribuidas. En ellas, el almacenamiento se encuentra en cada máquina física individual.
Las buenas SAN tienen intrínsecamente un alto nivel de redundancia incorporado. Sin embargo, el rendimiento se ve afectado ya que los datos deben enviarse desde la SAN a través de la red a la CPU y la RAM de la máquina virtual para las tareas informáticas. Como resultado, las nubes basadas en SAN tienden a tener un rendimiento inferior en igualdad de condiciones en comparación con las nubes con soluciones de almacenamiento distribuido local. Otra desventaja de una SAN es que representa un punto único de fallo muy grande. Las SAN son extremadamente fiables. Si alguna vez fallan gravemente (y ha ocurrido), es probable que se enfrente a una interrupción del servicio muy grande y a la corrupción de los datos.
La mayoría de los proveedores de nube que utilizan SAN no emplean soluciones de conmutación por error totalmente redundantes del tipo que se utiliza en el entorno empresarial, principalmente por razones de costes. Es importante darse cuenta de que no todas las SAN son iguales y entender qué nivel de redundancia emplea el proveedor de nube con sus SAN.
Las nubes basadas en almacenamiento local tienden a tener un buen rendimiento de disco. Sin embargo, a menudo solo ofrecen almacenamiento local de forma no persistente. Esta no es una comparación justa con el almacenamiento persistente. El almacenamiento temporal no tiene por qué ser robusto frente a fallos de la misma manera que el almacenamiento permanente. Siempre es importante comparar el almacenamiento persistente con el almacenamiento persistente para obtener resultados significativos.
Al analizar nubes con soluciones de almacenamiento local distribuido, también es necesario saber qué redundancia tienen. Los discos duros fallan a un ritmo significativo, por lo que el método de almacenamiento es fundamental. La mayoría de los proveedores utilizan alguna forma de RAID pero existen niveles de seguridad muy diferentes. En el extremo inferior se encuentra RAID1, donde dos discos se reflejan esencialmente entre sí. Esto suele tener un buen rendimiento. Pero cuando un disco falla, hasta que el disco de reemplazo copia todos los datos del disco antiguo, los datos corren el riesgo de perderse por completo si el segundo disco (con una gran carga de trabajo) falla. Además, durante cualquier reconstrucción de la matriz RAID1, es probable que el rendimiento del disco sea mucho menor de lo normal.
Por lo tanto, muchos proveedores utilizan RAID5 (resistente a la falla de un disco) o RAID6 (resistente a la falla de dos discos). RAID6 ofrece, con diferencia, la solución más segura para el almacenamiento local, pero penaliza enormemente el rendimiento. Nuestro enfoque consiste en utilizar RAID6 pero combinándolo con tarjetas controladoras RAID de hardware de gama alta. Tienen grandes cachés de memoria y cuentan con respaldo de batería. Las tarjetas controladoras RAID que utilizamos son, de hecho, significativamente más caras que las matrices de discos completas. De este modo, podemos ofrecer un rendimiento comparable al de configuraciones mucho menos resistentes, al tiempo que seguimos ofreciendo la gran red de seguridad del almacenamiento RAID6. Lea más sobre la configuración de nuestra infraestructura de nube, sobre la cual somos muy abiertos.
Recomiendo usar IOzone o Bonnie++ para las pruebas de rendimiento del disco.
Por lo tanto, al interpretar los resultados de las pruebas de rendimiento de almacenamiento, asegúrese de contar también con la siguiente información:
- ¿qué arquitectura de almacenamiento utiliza la nube (local, SAN, otra)?
- ¿qué medidas de redundancia y conmutación por error se han implementado para los datos?
- ¿el almacenamiento que estoy evaluando es temporal o persistente?
Combinar las respuestas a estas tres preguntas con los resultados de las pruebas de rendimiento le dará una idea bastante clara del rendimiento real del almacenamiento.
Redes
Determinar y medir el rendimiento de la red es significativamente más sencillo que el rendimiento informático y de disco. El rendimiento de la red tiene dos aspectos clave: la latencia y el ancho de banda.
Dependiendo de sus necesidades, la latencia de la red que utiliza el proveedor de la nube puede ser importante o no. Si utiliza la nube para operaciones que son en gran medida independientes, es poco probable que la latencia sea una prioridad. Sin embargo, si ejecuta aplicaciones en tiempo real que interactúan con el mundo exterior a la nube, la latencia será un factor determinante y crítico del rendimiento.
Por lo general, la gran mayoría de la latencia se debe a la mera distancia física. Por ejemplo, la mayor parte de la latencia entre Londres y San Francisco es en realidad el tiempo que tarda la luz en cubrir esa distancia. Las diferencias en la latencia están determinadas por la variada eficiencia de la ruta tomada. Este es el aspecto que difiere de una nube a otra. La eficiencia de la ruta es el resultado directo de los proveedores de red con los que la nube tiene conexiones directas. Esto ocurre ya sea adquiriendo conectividad IP de ellos o mediante peering. Al analizar las latencias, simplemente puede hacer ping a su servidor en la nube y determinar su rendimiento. Sin embargo, es importante determinar el rendimiento entre sus usuarios finales reales y su servidor en la nube.
Si la mayoría de sus usuarios se encuentran en una zona geográfica o el acceso se realizará principalmente desde la oficina central de su empresa, es importante probar el rendimiento desde esas ubicaciones. Los servicios comerciales como Pingdom ofrecen una forma rentable de determinar la latencia desde una gran cantidad de ubicaciones generales simultáneamente en todo el mundo.
El ancho de banda real que su servidor en la nube puede alcanzar también es muy importante. A diferencia de las soluciones de alojamiento más tradicionales, los proveedores de nube suelen cobrar en relación con el volumen total de transferencia de datos. En otras palabras, no depende del tiempo como en una modalidad por Mbit que le proporciona un nivel fijo de conectividad las 24 horas, los 7 días de la semana. A pesar de esto, muchos proveedores de nube ‘limitarán’ el ancho de banda a cualquier servidor virtual. Esto será invisible para el usuario hasta que alcance ese límite. Si tiene un perfil de ancho de banda con picos muy pronunciados, este podría ser un factor de rendimiento importante a tener en cuenta.
Para probar el ancho de banda real de su servidor en la nube, es importante intentar descargar datos al servidor en la nube desde una fuente que no esté restringiendo realmente la velocidad de transferencia por su parte. A menudo encuentro que una excelente manera de determinar la velocidad disponible es descargar un archivo grande de un proveedor importante como Microsoft, Ubuntu o incluso mejor, actualizando el sistema operativo. Esto suele descargar muchos archivos diferentes de varias ubicaciones simultáneamente. Le dará una idea bastante clara de la velocidad de su conexión.
A menudo descargo un Fedora live CD desde su sitio principal como una prueba estándar, pero como mínimo siempre debería experimentar con algunos archivos y ubicaciones diferentes. Si insiste en tener su propia red corporativa muy rápida, es posible que prefiera descargar un archivo desde su servidor en la nube a su propia red como prueba.
Ahora vuelva a añadir el precio para ponderar los resultados
Con los métodos anteriores, debería poder hacerse una buena idea de cómo rinden los distintos proveedores de servidores en la nube. Además, debería saber en qué aspectos centrarse que sean más importantes para sus necesidades particulares.
El paso final es añadir una dimensión de precios a los resultados de la evaluación comparativa. No existe una fórmula para esto. Depende del rendimiento relativo de los diversos aspectos anteriores y usted los determina. Si una nube ofrece un rendimiento un 40% mejor (según lo determine usted) pero solo es un 30% más cara, entonces claramente resulta atractiva. Asimismo, si tiene una gran necesidad de ancho de banda, un menor rendimiento computacional puede verse superado por un plan de precios de transferencia de datos competitivo. La clave para tomar la decisión correcta es reunir todos los diversos factores.
Finalmente, la evaluación comparativa debe ser parte de un proceso más amplio para determinar qué servidores en la nube son los adecuados para usted. Esto debería incluir otros aspectos. Por ejemplo, estos pueden incluir acuerdos de nivel de servicio, consideraciones de dependencia del proveedor o de los datos, ubicación física y jurisdicción legal. Al reunir todos estos aspectos, se posicionará para tomar la decisión correcta sobre el proveedor de computación en la nube.
Comentarios
Aún no hay comentarios. Sea el primero.