Slurm estrategias de asignación dinámica de nodos en la versión 3.8.0 - AWS ParallelCluster

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Slurm estrategias de asignación dinámica de nodos en la versión 3.8.0

A partir de la ParallelCluster versión 3.8.0, ParallelCluster utiliza la reanudación a nivel de trabajo o el escalado a nivel de trabajo como estrategia de asignación dinámica de nodos predeterminada para escalar el clúster: ParallelCluster amplía el clúster en función de los requisitos de cada trabajo, la cantidad de nodos asignados al trabajo y los nodos que deben reanudarse. ParallelCluster obtiene esta información de la variable de entorno SLURM_RESUME_FILE.

El escalado de los nodos dinámicos es un proceso de dos pasos, que implica el lanzamiento de las EC2 instancias y la asignación de las EC2 instancias de Amazon lanzadas al Slurm nodos. Cada uno de estos dos pasos se puede realizar utilizando una all-or-nothingo más lógicas.

Para el lanzamiento de las EC2 instancias de Amazon:

  • all-or-nothingllama a la EC2 API de Amazon de lanzamiento con un objetivo mínimo igual a la capacidad total del objetivo

  • best-effort llama a la EC2 API de Amazon de lanzamiento con un objetivo mínimo igual a 1 y la capacidad objetivo total igual a la capacidad solicitada

Para la asignación de las EC2 instancias de Amazon a Slurm nodos:

  • all-or-nothingasigna EC2 instancias de Amazon a Slurm nodos solo si es posible asignar una EC2 instancia de Amazon a cada nodo solicitado

  • best-effort asigna instancias de Amazon EC2 a Slurm nodos, incluso si todos los nodos solicitados no están cubiertos por la capacidad de la EC2 instancia de Amazon

    Las posibles combinaciones de las estrategias anteriores se traducen en las estrategias de ParallelCluster lanzamiento.

The available ParallelCluster estrategias de lanzamiento that can be set into the ScalingStrategy cluster configuration to be used with escalado a nivel de trabajo are:

all-or-nothingescalado:

Esta estrategia implica AWS ParallelCluster iniciar una llamada a la API de Amazon EC2 Launch Instance para cada trabajo, que requiere todas las instancias necesarias para que los nodos de cómputo solicitados se lancen correctamente. Así se garantiza que el clúster se escale solo cuando esté disponible la capacidad necesaria para el trabajo, lo que evita que queden instancias inactivas al final del proceso de escalado.

La estrategia utiliza una all-or-nothinglógica para el lanzamiento de las EC2 instancias de Amazon para cada trabajo, además de una all-or-nothinglógica para la asignación de las EC2 instancias de Amazon a Slurm nodos.

Esta estrategia agrupa las solicitudes de lanzamiento en lotes, uno por cada recurso de computación solicitado y hasta 500 nodos cada uno. Para las solicitudes que abarcan varios recursos informáticos o que superan los 500 nodos, procesa varios lotes de ParallelCluster forma secuencial.

Si se produce un error en un lote de un solo recurso, finaliza toda la capacidad no utilizada asociada, de manera que no quede ninguna instancia inactiva al final del proceso de escalado.

Limitaciones

  • El tiempo necesario para escalar es directamente proporcional al número de trabajos enviados por ejecución del Slurm reanudar el programa.

  • La operación de escalado está limitada por el límite de la cuenta de RunInstances recursos, establecido en 1000 instancias de forma predeterminada. Esta limitación está de acuerdo con las políticas de limitación AWS de EC2 API de Amazon. Para obtener más información, consulta la documentación de regulación de EC2 API de Amazon.

  • Al enviar un trabajo en un recurso informático con un solo tipo de instancia, en una cola que abarca varias zonas de disponibilidad, la llamada a la API de all-or-nothing EC2lanzamiento solo se realiza correctamente si se puede proporcionar toda la capacidad en una sola zona de disponibilidad.

  • Cuando envías un trabajo en un recurso informático con varios tipos de instancias, en una cola con una única zona de disponibilidad, la llamada a la API de EC2 lanzamiento de all-or-nothingAmazon solo se realiza correctamente si un único tipo de instancia puede proporcionar toda la capacidad.

  • Cuando envías un trabajo en un recurso informático con varios tipos de instancias, en una cola que abarca varias zonas de disponibilidad, no se admite la llamada a la API de EC2 lanzamiento de all-or-nothingAmazon y, en cambio, ParallelCluster realiza el escalado al máximo.

greedy-all-or-nothingescalado:

Esta variante de la all-or-nothing estrategia sigue garantizando que el clúster escale solo cuando esté disponible la capacidad requerida por trabajo, lo que evita las instancias inactivas al final del proceso de escalado, pero implica ParallelCluster iniciar una llamada a la API de la instancia de EC2 lanzamiento de Amazon que apunta a una capacidad objetivo mínima de 1, intentando maximizar la cantidad de nodos lanzados hasta la capacidad solicitada. La estrategia utiliza una lógica de máximo esfuerzo para el lanzamiento de las EC2 instancias para todos los trabajos, además de la all-or-nothinglógica para la asignación de las EC2 instancias de Amazon a Slurm nodos para cada trabajo.

Esta estrategia agrupa las solicitudes de lanzamiento en lotes, uno por cada recurso de computación solicitado y hasta 500 nodos cada uno. Para las solicitudes que abarcan varios recursos informáticos o que superan los 500 nodos, procesa varios lotes de ParellelCluster forma secuencial.

Así, se garantiza que no queda ninguna instancia inactiva al final del proceso de escalado, maximizando el rendimiento a costa de una sobreescalabilidad temporal durante el proceso de escalado.

Limitaciones

  • Es posible que se produzca un sobreescalado temporal, lo que conllevará costos adicionales para las instancias que pasen a un estado de ejecución antes de completar el escalado.

  • Se aplica el mismo límite de instancias que en la all-or-nothing estrategia, sujeto al límite AWS de la cuenta de RunInstances recursos.

Escalado óptimo:

Esta estrategia denomina llamada a la API de instancias de EC2 lanzamiento de Amazon y se orienta a una capacidad mínima de 1 y busca alcanzar la capacidad total solicitada a costa de dejar las instancias inactivas después de la ejecución del proceso de escalado si no está disponible toda la capacidad solicitada. La estrategia utiliza una lógica de máximo esfuerzo para lanzar las EC2 instancias de Amazon para todos los trabajos, además de la lógica de máximo esfuerzo para asignar las EC2 instancias de Amazon a los nodos de Slurm para cada trabajo.

Esta estrategia agrupa las solicitudes de lanzamiento en lotes, uno por cada recurso de computación solicitado y hasta 500 nodos cada uno. En el caso de solicitudes que abarquen varios recursos de cómputo o que superen los 500 nodos, ParallelCluster procesa varios lotes de forma secuencial.

Esta estrategia permite escalar mucho más allá del límite predeterminado de 1000 instancias en varias ejecuciones de procesos de escalado, a costa de tener instancias inactivas en los diferentes procesos de escalado.

Limitaciones

  • Es posible que las instancias estén inactivas al final del proceso de escalado, en el caso de que no sea posible asignar todos los nodos solicitados por los trabajos.

El siguiente es un ejemplo que muestra cómo se comporta el escalado de los nodos dinámicos utilizando las diferentes ParallelCluster estrategias de lanzamiento. Supongamos que ha enviado dos trabajos solicitando 20 nodos cada uno, es decir, un total de 40 nodos del mismo tipo, pero solo hay 30 EC2 instancias de Amazon disponibles para cubrir la capacidad solicitada EC2.

all-or-nothingescalado:

  • Para el primer trabajo, se llama a una API de instancia de EC2 lanzamiento de all-or-nothingAmazon, que solicita 20 instancias. Si la llamada es correcta, se lanzarán 20 instancias.

  • all-or-nothing asignación de las 20 instancias lanzadas a Slurm los nodos para el primer trabajo se han realizado correctamente

  • Se llama a otra API de instancias de EC2 lanzamiento de all-or-nothingAmazon, que solicita 20 instancias para el segundo trabajo. La llamada no se realiza correctamente, ya que solo hay capacidad para otras 10 instancias. Así pues, en este caso no se lanza ninguna instancia.

greedy-all-or-nothingescalado:

  • Se llama a la API de instancias de EC2 lanzamiento de Amazon que mejor esfuerzo solicita 40 instancias, que es la capacidad total solicitada por todos los trabajos. Esto hace que se lancen 30 instancias.

  • Una all-or-nothingasignación de 20 de las instancias lanzadas a Slurm los nodos para el primer trabajo se han realizado correctamente

  • Otra all-or-nothingasignación del resto de las instancias lanzadas a Slurm Se ha intentado utilizar nodos para el segundo trabajo, pero dado que solo hay 10 instancias disponibles del total de 20 solicitadas por el trabajo, la asignación no se ha realizado correctamente

  • Las 10 instancias lanzadas que no se han asignado finalizan.

Escalado óptimo:

  • Se llama a la API de instancias de EC2 lanzamiento de Amazon que mejor esfuerzo solicita 40 instancias, que es la capacidad total solicitada por todos los trabajos. Esto hace que se lancen 30 instancias.

  • Lo mejor es asignar 20 de las instancias lanzadas a Slurm los nodos del primer trabajo se han realizado correctamente.

  • Otra de las mejores tareas consiste en asignar las 10 instancias lanzadas restantes a Slurm los nodos del segundo trabajo se han realizado correctamente, incluso si la capacidad total solicitada era de 20. Sin embargo, dado que el trabajo solicitaba los 20 nodos y solo era posible asignar EC2 instancias de Amazon a 10 de ellos, el trabajo no puede iniciarse y las instancias se quedan inactivas hasta que se encuentre capacidad suficiente para iniciar las 10 instancias que faltan en una llamada posterior del proceso de escalado, o el programador programe el trabajo en otros nodos de cómputo que ya estén en ejecución.