Escalado de clústeres para nodos dinámicos - 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.

Escalado de clústeres para nodos dinámicos

ParallelCluster admite Slurm los métodos para escalar los clústeres de forma dinámica mediante Slurm el complemento de ahorro de energía. Para obtener más información, consulte la Guía de programación en la nube y la Guía de ahorro de energía de Slurm en la documentación de Slurm.

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 instancias de EC2 y la asignación de las instancias de Amazon EC2 lanzadas a Slurm los nodos. Cada uno de estos dos pasos se puede realizar mediante una lógica all-or-nothingo con el máximo esfuerzo.

Para el lanzamiento de las 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

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

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

  • 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

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

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

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

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. Esto garantiza que el clúster se escale solo cuando esté disponible la capacidad requerida por 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

La estrategia agrupa las solicitudes de lanzamiento en lotes, uno por cada recurso informático 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, se interrumpe toda la capacidad no utilizada asociada, lo que garantiza 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 programa de Slurm currículum.

  • 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, 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 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.

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

Garantiza que no quede 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á costes 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 con el máximo esfuerzo:

Esta estrategia, denominada llamada a la API de instancia de lanzamiento de Amazon EC2, se orienta a 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 de máximo esfuerzo para lanzar las instancias de Amazon EC2 para todos los trabajos, además de la lógica de máximo esfuerzo para asignar las instancias de Amazon EC2 a los nodos de Slurm para cada trabajo.

La estrategia agrupa las solicitudes de lanzamiento en lotes, uno por cada recurso informático 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 con creces el límite predeterminado de 1000 instancias en múltiples 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 estrategias de ParallelCluster lanzamiento. Suponga que ha enviado dos trabajos solicitando 20 nodos 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. Una llamada exitosa tiene como resultado el lanzamiento de 20 instancias

  • all-or-nothing La asignación de las 20 instancias lanzadas a Slurm los nodos para el primer trabajo se ha realizado 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 ha realizado correctamente, ya que solo hay capacidad para otras 10 instancias. No se ha lanzado ninguna instancia en este momento

greedy-all-or-nothingescalado:

  • Se denomina API de instancia de lanzamiento Amazon EC2, que solicita 40 instancias, que es la capacidad total solicitada por todos los trabajos. Esto da como resultado el lanzamiento de 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 no asignadas finalizan

escalado al máximo:

  • Se denomina API de instancia de lanzamiento Amazon EC2, que solicita 40 instancias, que es la capacidad total solicitada por todos los trabajos. Esto da como resultado el lanzamiento de 30 instancias.

  • Si se intenta asignar 20 de las instancias lanzadas a Slurm los nodos para el primer trabajo, se consigue correctamente.

  • Otro de los mejores esfuerzos es asignar las 10 instancias lanzadas restantes a Slurm los nodos para el segundo trabajo, aunque la capacidad total solicitada fuera de 20. Sin embargo, dado que el trabajo solicitaba los 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 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.

ParallelCluster utiliza dos tipos de estrategias de asignación dinámica de nodos para escalar el clúster:

  • Asignación basada en la información de nodos solicitada disponible:
    • Reanudación de todos los nodos o escalado de lista de nodos:

      ParallelCluster amplía el clúster basándose únicamente en los nombres Slurm de la lista de nodos solicitada cuando Slurm ResumeProgram se ejecuta. Asigna recursos de computación a los nodos solo por nombre de nodo. La lista de nombres de nodos puede abarcar varios trabajos.

    • Reanudación a nivel de trabajo o escalado a nivel de trabajo:

      ParallelCluster amplía el clúster en función de los requisitos de cada trabajo, el número actual de nodos que están asignados al trabajo y los nodos que deben reanudarse. ParallelCluster obtiene esta información de la variable de SLURM_RESUME_FILE entorno.

  • Asignación con una estrategia de lanzamiento de Amazon EC2:
    • Escalado óptimo:

      ParallelCluster amplía el clúster mediante una llamada a la API de la instancia de lanzamiento de Amazon EC2 con una capacidad de destino mínima igual a 1, para lanzar algunas instancias, pero no necesariamente todas, necesarias para admitir los nodos solicitados.

    • Un ll-or-nothing escalamiento:

      ParallelCluster amplía el clúster mediante una llamada a la API de la instancia de lanzamiento de Amazon EC2 que solo tiene éxito si se lanzan todas las instancias necesarias para admitir los nodos solicitados. En este caso, llama a la API de la instancia de lanzamiento de Amazon EC2 con una capacidad de destino mínima igual a la capacidad total solicitada.

De forma predeterminada, ParallelCluster utiliza el escalado de listas de nodos con la mejor estrategia de lanzamiento de Amazon EC2 para lanzar algunas instancias, pero no necesariamente todas, necesarias para admitir los nodos solicitados. Intenta proporcionar la mayor capacidad posible para atender la carga de trabajo enviada.

A partir de la ParallelCluster versión 3.7.0, ParallelCluster utiliza el escalado a nivel de trabajo con una estrategia de lanzamiento de all-or-nothingEC2 para los trabajos enviados en modo exclusivo. Cuando envía un trabajo en modo exclusivo, el trabajo tiene acceso exclusivo a los nodos asignados. Para obtener más información, consulte EXCLUSIVE en la documentación de Slurm.

Para enviar un trabajo en modo exclusivo:

  • Pase la marca de exclusividad al enviar un trabajo de Slurm al clúster. Por ejemplo, sbatch ... --exclusive.

    OR

  • Envíe un trabajo a una cola de clústeres que se haya configurado con el valor JobExclusiveAllocation establecido en true.

Al enviar un trabajo en modo exclusivo:

  • ParallelCluster actualmente, agrupa las solicitudes de lanzamiento por lotes para incluir hasta 500 nodos. Si un trabajo solicita más de 500 nodos, ParallelCluster realiza una solicitud de all-or-nothinglanzamiento para cada conjunto de 500 nodos y una solicitud de lanzamiento adicional para el resto de los nodos.

  • Si la asignación de nodos se realiza en un único recurso de cómputo, ParallelCluster realiza una solicitud de all-or-nothinglanzamiento para cada conjunto de 500 nodos y una solicitud de lanzamiento adicional para el resto de los nodos. Si se produce un error en una solicitud de lanzamiento, ParallelCluster se cancela la capacidad no utilizada creada por todas las solicitudes de lanzamiento.

  • Si la asignación de nodos abarca varios recursos informáticos, ParallelCluster debe realizar una solicitud de all-or-nothinglanzamiento para cada recurso informático. Estas solicitudes también se agrupan en lotes. Si se produce un error en una solicitud de lanzamiento para uno de los recursos informáticos, ParallelCluster se cancela la capacidad no utilizada creada por todas las solicitudes de lanzamiento de los recursos informáticos.

escalamiento a nivel de trabajo con limitaciones conocidas de la estrategia de all-or-nothinglanzamiento:

  • 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 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.

AWS ParallelCluster utiliza solo un tipo de estrategia de asignación dinámica de nodos para escalar el clúster:

  • Asignación basada en la información de nodos solicitada disponible:

    • Reanudación de todos los nodos o escalado de la lista de nodos: cuando Slurm se ejecuta, ParallelCluster amplía el clúster basándose únicamente en los nombres Slurm de la lista de nodos solicitada. ResumeProgram Asigna recursos de computación a los nodos solo por nombre de nodo. La lista de nombres de nodos puede abarcar varios trabajos.

  • Asignación con una estrategia de lanzamiento de Amazon EC2:

    • Escalado óptimo: ParallelCluster amplía el clúster mediante una llamada a la API de la instancia de lanzamiento de Amazon EC2 con una capacidad de destino mínima igual a 1, para lanzar algunas instancias, pero no necesariamente todas, necesarias para admitir los nodos solicitados.

ParallelCluster utiliza el escalado de listas de nodos con una estrategia de lanzamiento de Amazon EC2 que hace todo lo posible para lanzar algunas instancias, pero no necesariamente todas, necesarias para admitir los nodos solicitados. Intenta proporcionar la mayor capacidad posible para atender la carga de trabajo enviada.

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.