Compartir HPC en la nube - Calendae | Informática, Electrónica, CMS, Ciberseguridad

Compartir HPC en la nube

Hola, un placer verte por aquí. Te habla Simón Sánchez y esta vez te voy a contar sobre Compartir HPC en la nube

La computación en la nube ha conquistado a las empresas de Internet al permitirles escalar la infraestructura de forma rápida y económica en función de la demanda. Sin embargo, los usuarios de HPC han sido más cautelosos a la hora de trasladar sus cálculos a la nube. Las grandes aplicaciones científicas tienen necesidades computacionales diferentes a las de las empresas web. Las preocupaciones son bien conocidas. Por ejemplo, si bien muchas grandes empresas web satisfacen una gran cantidad de demandas a gran escala, el cálculo generalmente no requiere una coordinación a gran escala entre los componentes. Examinar grandes cantidades de datos se convierte en el desafío de escalar.

Por el contrario, muchas aplicaciones científicas pueden requerir una coordinación significativa entre una gran cantidad de nodos. En el ámbito de la HPC, se hace un gran esfuerzo para ocultar gran parte de la latencia de la coordinación con costosas redes de baja latencia y bibliotecas de comunicación optimizadas. Tales esfuerzos aún no se han traducido en el campo de la computación en la nube comercial, que por lo general todavía proporciona sistemas con diferentes cantidades de memoria instalada, pero rara vez interconecta de diferente calidad.

Después de varios años de experimentar con aplicaciones de HPC en un entorno de nube comercial, tenemos experiencia con una de las principales preocupaciones de HPC en la nube: la tenencia múltiple. Aunque se ha demostrado repetidamente que la virtualización en sí tiene poco efecto en la computación HPC en el núcleo, el rendimiento de la red puede verse afectado al pasar por el hipervisor. Notamos una complicación adicional: estos experimentos a menudo no implican competencia por los recursos de otros inquilinos.

Los proveedores comerciales de servicios en la nube aún no ofrecen tales garantías contra el uso compartido de nodos. De hecho, poner varios clientes en el mismo nodo, lo que se denomina multicliente, es una piedra angular del modelo de ingresos del proveedor de la nube. La tenencia múltiple puede tener efectos graves en el rendimiento de HPC. Hemos visto una degradación del rendimiento con el tiempo a medida que los recursos se suscribieron en exceso incluso en cálculos simples en el núcleo.

La Figura 1 anterior muestra el tiempo de ejecución de una multiplicación repetida de matriz a matriz en el núcleo (DGEMM, BLAS de nivel 3) utilizando los 8 núcleos de un solo nodo de nube en 6 horas. Usamos DGEMM porque es el componente básico para el resto de la biblioteca BLAS, que es la API más utilizada para álgebra lineal. Muchas aplicaciones de HPC utilizan alguna forma de DGEMM en el corazón de su cálculo, por lo que el rendimiento de esta simple operación es indicativo del rendimiento de estas aplicaciones.

El tiempo de ejecución de DGEMM de 6 horas más rápido (que se produce entre las 20:00 y las 20:30) es similar al de un nodo de clúster HPC típico. Sin embargo, el tiempo medio de ejecución en nuestro nodo en la nube es más de 8 veces peor con una desviación estándar del 33%. El hardware es bueno, como lo demuestra el mejor tiempo de ejecución, pero la competencia entre los inquilinos da como resultado una reducción en el rendimiento promedio con una amplia gama de resultados posibles. Por lo tanto, el rendimiento esperado de una simple multiplicación de matriz a matriz en la memoria en un nodo de nube de múltiples inquilinos no es bueno y fluctúa significativamente. Sin siquiera usar la red, no se puede esperar que los nodos en la nube funcionen como un clúster HPC típico debido a la concurrencia de otros inquilinos.

Dado que se ha demostrado que la virtualización en sí tiene poco efecto en los cálculos internos, está claro que la competencia por los recursos es probablemente el culpable, pero ¿la competencia por qué recursos? Nuestros experimentos DGEMM se configuraron para adaptarse a todos los datos en la memoria para que otras E / S no afectaran los resultados. Aunque los datos de las figuras no encajaban completamente en el caché de último nivel de la arquitectura, realizamos otros experimentos con conjuntos de datos más pequeños que exhiben un comportamiento similar. Nuestra hipótesis es que la competencia por el espacio de caché compartido de nivel superior juega un papel importante, aunque no hemos descartado todas las demás causas posibles.

Para explorar los efectos de la tenencia múltiple, redujimos la contención de nodos al infrautilizar los núcleos disponibles. En la Figura 2 a continuación, mostramos los tiempos de ejecución promedio y mínimo del mismo DGEMM repetido en el núcleo utilizando diferentes números de núcleo. Mientras que el inactivo rastrea la ejecución esperada en un nodo de clúster HPC, el promedio tiene un rendimiento deficiente. El mejor rendimiento se logra utilizando solo 1/4 del nudo. En contraste con los beneficios de usar múltiples núcleos para el paralelismo en un clúster, nuestro nodo compartido sufre de intentos de paralelismo. Dado que el uso de 2 subprocesos sigue siendo útil, supongamos que hay al menos otros 2-3 inquilinos que comparten el nodo con nosotros.

Por supuesto, las aplicaciones HPC no utilizan un solo nodo. Los efectos de compartir nodos pueden extenderse a trabajos grandes. Hicimos experimentos con el punto de referencia LINPACK para ver los efectos en múltiples procesos de nodos. HPL calcula la solución de un sistema aleatorio y denso de ecuaciones lineales mediante factorización LU con pivote parcial y dos soluciones triangulares. HPL también proporciona una relación favorable entre el movimiento de datos y el cálculo con n ^ 3 cálculos sobre n ^ 2 datos para minimizar las desventajas de una red lenta. Queríamos ver si el rendimiento de red ordinario de un proveedor de nube, que está muy por debajo de las interconexiones de alto rendimiento de una supercomputadora, superaba los efectos de rendimiento del uso compartido de nodos. Si es así, los proveedores de servicios en la nube podrían centrarse en mejorar el rendimiento de la red y aislar diferentes tipos de clientes para mejorar la experiencia del cliente de HPC. De lo contrario, queríamos identificar cuánto se podría mejorar el rendimiento al infrautilizar los núcleos en todos los nodos, como hicimos con un solo nodo.

Este es un enfoque simple que puede implementar el cliente y no requiere que el proveedor de la nube modifique ninguna infraestructura. Irónicamente, incluso si está usando menos de los nodos asignados, aún puede ahorrar dinero si el cálculo se completa más rápido incluso cuando está usando menos núcleos.

Nuestra experiencia es que los beneficios de la subutilización de nodos se extienden a trabajos agrupados con coordinación de red. El tiempo de ejecución de HPL se puede reducir en 2/3 utilizando solo la mitad de los núcleos de los nodos, incluso en un clúster de 3 o 4 nodos. Los efectos del rendimiento lento de la red aumentan con el tamaño del clúster, por lo que esperamos ganancias aún mayores de los clústeres más grandes. Por el contrario, también asumimos que una red más rápida aumentaría los beneficios de la subutilización al reducir el retraso debido a la sincronización entre nodos. La infrautilización de los nodos parece proporcionar tiempos de ejecución más cortos y mucho más estables con fluctuaciones significativamente menores, lo que debería proporcionar retrasos más cortos de la sincronización incluso sin efectos de red.

Si bien los clientes de HPC siempre se han preocupado principalmente por el rendimiento bruto, HPC en la nube presenta el aspecto de costo significativo. En la Figura 3 anterior, mostramos un diagrama de dispersión de los resultados de rendimiento frente a los costos para diferentes tasas de subutilización y tamaños de clúster para un tipo de instancia particular en el EC2 de Amazon (los costos fueron a marzo de 2010). En esta figura, todos los puntos representan el mismo cálculo. Las líneas conectan la misma cantidad de nodos en un clúster con diferentes niveles de subutilización. La esquina inferior izquierda es el cálculo más rápido y económico. La comparación de diferentes líneas demuestra la compensación entre agregar más núcleos por nodo (moverse a lo largo de la línea) o agregar nudos adicionales (saltar a una línea diferente). Aunque el uso de 4 nodos no es estrictamente necesario porque el cálculo cabe en la memoria de solo 3 nodos, el gráfico muestra que agregar un nodo más ayuda a que el cálculo finalice antes, ¡pero al mismo costo!

Si bien el rendimiento y el costo están estrechamente relacionados en el entorno de la nube, el rendimiento se ve afectado por la competencia de otros inquilinos desconocidos que comparten nodos. Por tanto, tanto el rendimiento como los costes son difíciles de estimar y cambiar de forma dinámica. Las cifras anteriores muestran fluctuaciones significativas en el tiempo de ejecución que dan como resultado fluctuaciones correspondientes en el costo por cálculo. Si bien podemos usar el tiempo promedio y el costo de ejecución para las estimaciones, la gran desviación estándar dificulta las estimaciones precisas. Creemos que los proveedores de servicios en la nube deben proporcionar a los clientes de HPC un rendimiento más estable para permitir un mejor modelado de costos.

HPC tiene necesidades informáticas exigentes. En nuestra experiencia, las ofertas comerciales actuales no satisfacen del todo estas necesidades. Sin embargo, hay caminos por recorrer. Amazon anunció la disponibilidad inmediata de instancias de computación en clúster diseñadas para el mercado de HPC. Nuestra experiencia con estos clústeres es todavía limitada, pero actualmente funcionan de manera similar a los clústeres HPC normales que no tienen interconexiones de supercomputadoras. Queda por ver si este rendimiento se mantendrá en el futuro cuando las instancias de Cluster Compute estén suscritas en exceso. En este caso de múltiples inquilinos, incluso podría ser mejor compartir con inquilinos desconocidos en instancias genéricas que con otros usuarios de HPC.

Además de los diferentes tipos de instancias, creemos que los proveedores de servicios en la nube que se dirigen a los usuarios de HPC deben utilizar acuerdos de QoS que brinden un rendimiento esperado específico y estable a lo largo del tiempo con poca variabilidad. Si bien el acceso exclusivo a los nodos es poco probable en una oferta comercial, las mediciones de rendimiento Online podrían hacer cumplir dichos contratos. Este enfoque requerirá implícitamente que los proveedores de la nube limiten el grado de tenencia múltiple y posiblemente nuevas técnicas para aislar los efectos sobre el rendimiento entre las VM que comparten un nodo. Sin embargo, muchas aplicaciones de HPC requieren un rendimiento estable debido a la coordinación significativa entre nodos en un clúster grande.

Para acceder a más información: Roman Iakymchuk, Jeff Napper y Paolo Bientinesi. Infrautilización de los recursos de HPC en las nubes. Informe Técnico AICES-2010 / 06-1. Junio ​​de 2010

Acerca de

Jeff Napper

Jeff Napper es ingeniero de sistemas de Hyves, un sitio web de redes sociales holandés y consultor de software sobre problemas de sistemas distribuidos. El trabajo en este artículo se realizó mientras yo trabajaba en la Universidad VU, Ámsterdam, en el proyecto XtreemOS grid OS patrocinado por la Unión Europea.

Paolo Bientinesi

El Prof. Paolo Bientinesi es Catedrático de Ciencias de la Computación en la Universidad RWTH de Aachen, Alemania. Dirige un equipo en AICES, realizando investigaciones en las áreas de álgebra lineal numérica, computación de alto rendimiento y automatización. En 2009 recibió el Premio Karl Arnold de la Academia de Ciencias y Humanidades de Renania del Norte-Westfalia por el destacado trabajo de investigación de un joven científico.

Roman Iakymchuk

Roman es actualmente miembro del Instituto Aachen de Estudios Avanzados en Ciencias de la Ingeniería Computacional (AICES) en la Universidad RWTH de Aachen, Alemania. Anteriormente, fue ingeniero de software en SoftServe, Inc. e investigador asistente en la Universidad Nacional Ivan Franko en Lviv, Ucrania.

Recuerda compartir en tus redes sociales para que tus colegas lo lean

??? ? ? ???

Comparte