View a markdown version of this page

Aprovisionamiento continuo para mejorar las operaciones de los clústeres con Slurm - Amazon SageMaker AI

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.

Aprovisionamiento continuo para mejorar las operaciones de los clústeres con Slurm

SageMaker HyperPod Los clústeres de Amazon creados con la orquestación de Slurm ahora admiten el aprovisionamiento continuo, una capacidad que permite una mayor flexibilidad y eficiencia al ejecutar cargas de trabajo a gran escala. AI/ML El aprovisionamiento continuo le permite empezar a entrenar rápidamente, escalar sin problemas, realizar tareas de mantenimiento sin interrumpir las operaciones y obtener una visión detallada de las operaciones del clúster.

nota

El aprovisionamiento continuo está disponible como configuración opcional para los nuevos HyperPod clústeres creados con la orquestación de Slurm. Los clústeres existentes que utilizan el modelo de escalado anterior no se pueden migrar al aprovisionamiento continuo en este momento.

Funcionamiento

El sistema de aprovisionamiento continuo presenta una arquitectura del estado deseado que reemplaza el modelo de escalado tradicional. all-or-nothing En el modelo anterior, si un grupo de instancias no se podía aprovisionar por completo, se producía un error en toda la operación de creación o actualización del clúster y se revertía. Con el aprovisionamiento continuo, el sistema acepta una capacidad parcial y continúa aprovisionando las instancias restantes de forma asíncrona.

El sistema de aprovisionamiento continuo:

  • Acepta la solicitud: registra el recuento de instancias de destino de cada grupo de instancias.

  • Inicia el aprovisionamiento: comienza a lanzar instancias para todos los grupos de instancias en paralelo.

  • Aprovisiona primero los nodos prioritarios: el clúster pasa a una InService vez que se aprovisione correctamente al menos un nodo controlador (y un nodo de inicio de sesión, si se especifica un grupo de instancias de inicio de sesión).

  • Realiza un seguimiento del progreso: supervisa cada intento de lanzamiento de una instancia y registra su estado.

  • Gestiona los errores: reintenta automáticamente los lanzamientos fallidos de los nodos de trabajo de forma asíncrona.

El aprovisionamiento continuo está deshabilitado de forma predeterminada. Para usar esta función, configúrela en NodeProvisioningMode su solicitudContinuous. CreateCluster

Con el aprovisionamiento continuo activado, puede iniciar varias operaciones de escalado simultáneamente sin esperar a que se completen las operaciones anteriores. Esto le permite escalar diferentes grupos de instancias en el mismo clúster de forma simultánea y enviar varias solicitudes de escalado al mismo grupo de instancias.

Aprovisionamiento basado en prioridades

Los clústeres de Slurm requieren que un nodo controlador esté operativo antes de que los nodos trabajadores puedan registrar y aceptar trabajos. El aprovisionamiento continuo lo gestiona automáticamente mediante un aprovisionamiento basado en prioridades:

  1. El grupo de instancias del controlador se aprovisiona primero.

  2. Una vez que un nodo controlador está en buen estado, los nodos de inicio de sesión y los nodos de trabajo comienzan a aprovisionarse en paralelo.

  3. El clúster InService pasa a tener un nodo controlador activo y otro nodo de inicio de sesión activo (si se especifica un grupo de instancias de inicio de sesión). Si no se especifica ningún grupo de instancias de inicio de sesión, el clúster pasa a InService él tan pronto como se aprovisione el nodo controlador.

  4. Los nodos de trabajo que no se pueden aprovisionar inmediatamente debido a restricciones de capacidad entran en un bucle de reintentos asíncrono y se añaden al clúster de Slurm automáticamente a medida que están disponibles.

Gestión de los fallos del controlador

Durante la creación del clúster, si el nodo controlador no se aprovisiona, el comportamiento depende de si el error se puede volver a intentar o no.

Errores que se pueden volver a intentar (por ejemplo, instancias en mal estado o errores transitorios):

  • HyperPod reemplaza continuamente la instancia y vuelve a intentar el aprovisionamiento hasta que se activa el controlador.

  • Los nodos de trabajo y de inicio de sesión que ya se han aprovisionado permanecen disponibles, pero el clúster no pasa a ellos InService hasta que el controlador esté en buen estado.

Errores que no se pueden volver a intentar (por ejemplo, no hay capacidad disponible para el tipo de instancia del controlador o se ha producido un error en el script del ciclo de vida):

  • El clúster está marcado como. Failed

  • Se le notifica el motivo del error y debe tomar medidas correctivas, como elegir un tipo de instancia diferente, corregir los scripts del ciclo de vida o volver a intentarlo en una zona de disponibilidad diferente.

Requisitos previos

El aprovisionamiento continuo requiere que los parámetros de aprovisionamiento de Slurm (tipos de nodos, nombres de particiones) se proporcionen a través de la carga útil de la API en el campo de cada grupo de instancias. SlurmConfig Los clústeres que se basan en el provisioning_parameters.json archivo heredado de Amazon S3 no son compatibles con el aprovisionamiento continuo.

nota

Las siguientes características no son compatibles actualmente con el aprovisionamiento continuo en los clústeres de Slurm: migración de clústeres existentes, configuración de nodos de múltiples cabezales mediante una topología de Slurm basada en API y. SlurmConfigStrategy El aprovisionamiento continuo funciona exclusivamente en modo de fusión para la administración. slurm.conf

Medición de uso

HyperPod Los clústeres con aprovisionamiento continuo utilizan la medición a nivel de instancia para proporcionar una facturación precisa que refleje el uso real de los recursos. Este enfoque de medición se diferencia de la facturación tradicional de clústeres, ya que hace un seguimiento de cada instancia de forma independiente.

Facturación por instancia

Con el aprovisionamiento continuo, la facturación comienza y termina en cada instancia en lugar de esperar a que cambie el estado del clúster. A continuación se enumeran los beneficios de este enfoque:

  • Precisión de la facturación: la facturación comienza cuando se inicia la ejecución del script de ciclo de vida. Si el script del ciclo de vida falla, se volverá a intentar aprovisionar la instancia y se le cobrará por la duración del tiempo de ejecución del script del ciclo de vida.

  • Medición independiente: el ciclo de vida de facturación de cada instancia se gestiona por separado, lo que evita que se produzcan errores de facturación en cascada.

  • Actualizaciones de facturación en tiempo real: la facturación comienza cuando una instancia comienza a ejecutar su script de configuración del ciclo de vida y se detiene cuando la instancia entra en un estado de finalización.

Ciclo de vida de facturación

Cada instancia de tu HyperPod clúster sigue este ciclo de vida de facturación:

  • La facturación comienza: cuando la instancia se lanza correctamente y comienza a ejecutar su script de configuración del ciclo de vida.

  • La facturación continúa: durante toda la vida operativa de la instancia.

  • La facturación se detiene: cuando la instancia entra en un estado de finalización, independientemente del motivo de la finalización.

nota

La facturación no se inicia en el caso de las instancias que no se consiguen lanzar. Si el lanzamiento de una instancia falla debido a una falta de capacidad o por otros problemas, no se le cobrará por ese intento fallido. La facturación se calcula por instancia y los costos se agregan y anotan en el Nombre de recurso de Amazon (ARN) de su clúster.

Creación de un clúster con el aprovisionamiento continuo activado

nota

Prepare un script de configuración del ciclo de vida y cárguelo en un bucket de Amazon S3 al que pueda acceder su rol de ejecución. Para obtener más información, consulte SageMaker HyperPod Operaciones de clúster de Slurm.

Prepare un archivo de solicitud de CreateCluster API en formato JSON. Configura NodeProvisioningMode Continuous y proporciona información sobre la topología de Slurm en el campo de cada grupo de instancias. SlurmConfig

// create_cluster.json { "ClusterName": "my-training-cluster", "NodeProvisioningMode": "Continuous", "Orchestrator": { "Slurm": {} }, "InstanceGroups": [ { "InstanceGroupName": "controller-group", "InstanceType": "ml.m5.xlarge", "InstanceCount": 1, "LifeCycleConfig": { "SourceS3Uri": "s3://amzn-s3-demo-bucket/lifecycle-scripts/src/", "OnCreate": "on_create.sh" }, "ExecutionRole": "arn:aws:iam::111122223333:role/iam-role-for-cluster", "SlurmConfig": { "NodeType": "Controller" } }, { "InstanceGroupName": "login-group", "InstanceType": "ml.m5.xlarge", "InstanceCount": 1, "LifeCycleConfig": { "SourceS3Uri": "s3://amzn-s3-demo-bucket/lifecycle-scripts/src/", "OnCreate": "on_create.sh" }, "ExecutionRole": "arn:aws:iam::111122223333:role/iam-role-for-cluster", "SlurmConfig": { "NodeType": "Login" } }, { "InstanceGroupName": "worker-gpu-a", "InstanceType": "ml.p5.48xlarge", "InstanceCount": 16, "LifeCycleConfig": { "SourceS3Uri": "s3://amzn-s3-demo-bucket/lifecycle-scripts/src/", "OnCreate": "on_create.sh" }, "ExecutionRole": "arn:aws:iam::111122223333:role/iam-role-for-cluster", "SlurmConfig": { "NodeType": "Compute", "PartitionNames": ["gpu-training"] } } ], "VpcConfig": { "SecurityGroupIds": ["sg-12345678"], "Subnets": ["subnet-12345678"] } }

Ejecuta el create-cluster comando para enviar la solicitud.

aws sagemaker create-cluster \ --cli-input-json file://complete/path/to/create_cluster.json

Esto devuelve el ARN del nuevo clúster.

{ "ClusterArn": "arn:aws:sagemaker:us-west-2:111122223333:cluster/abcde12345" }

Administración de la configuración de Slurm

El aprovisionamiento continuo funciona exclusivamente en modo de fusión para slurm.conf la administración de particiones. En el modo de fusión, HyperPod aplica los cambios de configuración de sus particiones de forma aditiva sobre cualquier elemento que haya modificado. slurm.conf HyperPod solo actualiza las secciones relacionadas con la partición slurm.conf (como las entradas del nombre de la partición y del nombre del nodo); los demás parámetros de configuración de Slurm no se modifican. Esto significa:

  • Se conservan sus modificaciones manuales. slurm.conf

  • No se detectan desviaciones automáticamente ni se resuelven los conflictos entre las modificaciones y HyperPod el estado esperado.

El SlurmConfigStrategy parámetro (Managed,Merge,Overwrite) no es compatible con el aprovisionamiento continuo. Si se transfiere cualquier SlurmConfigStrategy valor, se produce un error de API.