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.
Estrategias de asignación de nodos dinámicos en Slurm 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 nodos dinámicos es un proceso de dos pasos que implica el lanzamiento de instancias de EC2 y la asignación de las instancias de Amazon EC2 lanzadas a los nodos de Slurm. Cada uno de estos dos pasos se puede realizar utilizando una o más lógicas. all-or-nothing
Al iniciar instancias de Amazon EC2:
-
all-or-nothingllama a la API Amazon EC2 de lanzamiento con un objetivo mínimo igual a la capacidad total del objetivo
-
óptimo llama al lanzamiento de la API de Amazon EC2 con un destino mínimo igual a 1 y una capacidad de destino total equivalente a la capacidad solicitada
Al asignar las instancias de Amazon EC2 a los nodos de Slurm:
-
all-or-nothingasigna instancias de Amazon EC2 Slurm a los nodos solo si es posible asignar una instancia de Amazon EC2 a cada nodo solicitado
-
óptimo asigna instancias de Amazon EC2 a los nodos de Slurm incluso si alguno de los nodos solicitados no está cubierto por la capacidad de instancias de Amazon EC2
Las posibles combinaciones de las estrategias anteriores se traducen en estrategias de ParallelCluster lanzamiento.
ejemplo
all-or-nothingescalado:
Esta estrategia implica AWS ParallelCluster iniciar una llamada a la API de la instancia de lanzamiento de Amazon EC2 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 instancias de Amazon EC2 para cada trabajo y una all-or-nothinglógica para la asignación de las instancias de Amazon EC2 a los nodos. Slurm
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 que se necesita para escalar es directamente proporcional al número de trabajos enviados por cada ejecución del programa de reanudación de Slurm.
-
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 regulación AWS de las API de EC2. Para obtener más información, consulte la documentación de regulación de las API de Amazon EC2.
-
Cuando envía 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 lanzamiento de all-or-nothingEC2 solo se realiza correctamente si se puede proporcionar toda la capacidad en una sola zona de disponibilidad.
-
Al enviar 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 lanzamiento de all-or-nothingAmazon EC2 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 all-or-nothingAPI de lanzamiento de Amazon EC2 ParallelCluster y, en cambio, 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 lanzamiento de Amazon EC2 que apunta a una capacidad objetivo mínima de 1, con el fin de maximizar el número de nodos lanzados hasta la capacidad solicitada. La estrategia utiliza una lógica de máximo esfuerzo para el lanzamiento de las instancias EC2 para todos los trabajos, además de la all-or-nothinglógica para la asignación de las instancias de Amazon EC2 Slurm a los nodos de 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 hace una llamada a la API de instancia de lanzamiento de Amazon EC2 con una capacidad mínima de 1 y tiene como objetivo alcanzar la capacidad total solicitada a costa de dejar las instancias inactivas tras la ejecución del proceso de escalado si no está disponible toda la capacidad solicitada. La estrategia utiliza una lógica óptima para lanzar instancias de Amazon EC2 para todos los trabajos y una lógica óptima para asignar las instancias de Amazon EC2 a los nodos de Slurm de 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 ParallelCluster 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 en los que se solicitaban 20 nodos para cada uno, es decir, un total de 40 nodos del mismo tipo, pero solo hay 30 instancias de Amazon EC2 disponibles para cubrir la capacidad solicitada en EC2.
all-or-nothingescalado:
-
Para el primer trabajo, se llama a una API de instancia de lanzamiento de all-or-nothingAmazon EC2, que solicita 20 instancias. Si la llamada es correcta, se lanzarán 20 instancias.
-
all-or-nothing La asignación de las 20 instancias lanzadas a Slurm los nodos para el primer trabajo se realizó correctamente
-
Se llama a otra API de instancia de lanzamiento de all-or-nothingAmazon EC2, 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 una API de instancia de lanzamiento de Amazon EC2 de tipo óptimo, que solicita 40 instancias, que es la capacidad total solicitada por todos los trabajos. Esto hace que se lancen 30 instancias.
-
La all-or-nothingasignación de 20 de las instancias lanzadas a Slurm los nodos para el primer trabajo se realiza correctamente
-
Se intenta volver a all-or-nothingasignar las instancias lanzadas restantes a Slurm los 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 realiza correctamente
-
Las 10 instancias lanzadas que no se han asignado finalizan.
Escalado óptimo:
-
Se llama a una API de instancia de lanzamiento de Amazon EC2 de tipo óptimo, que solicita 40 instancias, que es la capacidad total solicitada por todos los trabajos. Esto hace que se lancen 30 instancias.
-
Se realiza correctamente una asignación de tipo óptimo de las 20 instancias lanzadas a los nodos de Slurm para el primer trabajo.
-
Se lanza una segunda asignación de tipo óptimo con las 10 instancias restantes a los nodos de Slurm para el segundo trabajo, aunque la capacidad total solicitada fuera de 20. Sin embargo, como el trabajo requería 20 nodos y solo era posible asignar instancias de Amazon EC2 a 10 de ellos, el trabajo no puede iniciarse y las instancias se quedan inactivas hasta que se encuentre la capacidad suficiente para iniciar las 10 instancias restantes en una llamada posterior del proceso de escalado, o cuando el programador programe el trabajo en otros nodos de computación que ya estén ejecutándose.
