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.

Cómo empezar a SageMaker HyperPod usar el AWS CLI

El siguiente tutorial muestra cómo crear un nuevo SageMaker HyperPod clúster con Slurm mediante los AWS CLI comandos para. SageMaker HyperPod Al final de este tutorial, dispondrá de un clúster de Slurm en funcionamiento con un nodo controlador, un nodo de inicio de sesión y un grupo de trabajo de cómputo, listo para programar y ejecutar cargas de trabajo de aprendizaje automático. El tutorial cubre la configuración de la topología de Slurm, las opciones de configuración del ciclo de vida de los nodos, el almacenamiento compartido FSx opcional y cómo conectarse a su clúster.

Antes de empezar, asegúrese de haber completado las funciones Requisitos previos para su uso SageMaker HyperPod (VPC, cuotas, FSx) y AWS Identity and Access Management para SageMaker HyperPod (funciones de IAM, función de ejecución con). AmazonSageMakerClusterInstanceRolePolicy

Conceptos clave

En esta sección se describen los conceptos básicos de configuración para crear un SageMaker HyperPod clúster de Slurm. Comprender estos conceptos le ayudará a tomar decisiones informadas a la hora de configurar su clúster, pero si quiere empezar de inmediato, puede ir directamente a esta sección Cree su clúster de y volver a consultarla si es necesario.

Al crear un Slurm-orchestrated clúster, debe elegir dos opciones de configuración independientes:

Para la topología de Slurm, en este tutorial se utiliza el enfoque de API-driven configuración, en el que se definen las funciones y particiones de los nodos directamente en la CreateCluster solicitud, SlurmConfig en cada grupo de instancias y Orchestrator.Slurm a nivel de clúster. Este es el enfoque recomendado para los clústeres nuevos. Proporciona una única fuente de información fiable, una validación integrada y una detección de desviaciones en la configuración de las particiones, sin necesidad de gestionar archivos adicionales. Como alternativa, puede utilizar un provisioning_parameters.json archivo antiguo almacenado en Amazon S3 para garantizar la compatibilidad con versiones anteriores de los clústeres existentes. Para obtener más información sobre el enfoque heredado, consulteSageMaker HyperPod Configuración de Slurm.

Para la configuración del ciclo de vida de los nodos, SageMaker HyperPod admite tres opciones. En el caso más simple, se omite LifeCycleConfig por completo y HyperPod se configuran los nodos automáticamente mediante la AMI-based configuración, configurando Slurm y paquetes esenciales como Docker, Enroot y Pyxis para ejecutar cargas de trabajo de aprendizaje automático, sin necesidad de scripts ni de un bucket de Amazon S3. Si necesita personalizaciones además de la AMI-based configuración, puede proporcionar un script de extensión que se ejecute una vez finalizada la configuración. OnInitComplete Para tener el control total de toda la secuencia de aprovisionamiento, la OnCreate ruta permite que tus scripts se encarguen de todo, incluso cuando se inicia Slurm.

Para las cargas de trabajo de aprendizaje automático, normalmente también necesitarás un sistema de archivos compartido de alto rendimiento para entrenar los datos, los puntos de control y las bibliotecas compartidas. SageMaker HyperPod es compatible con Amazon FSx for Lustre y FSx para OpenZFS, configurados por grupo de instancias mediante. InstanceStorageConfigs La configuración de FSx es opcional para la creación de clústeres, pero se recomienda para las cargas de trabajo de producción.

Configuración de la topología de Slurm mediante la API

Todos los ejemplos de este tutorial utilizan la configuración de topología de API-driven Slurm, en la que se define la estructura de clústeres de Slurm directamente en la solicitud de CreateCluster API, en lugar de hacerlo a través de un archivo de configuración independiente.

Un clúster de Slurm requiere al menos un nodo controlador (que ejecuta el slurmctld daemon y coordina la programación de los trabajos) y uno o más nodos de procesamiento (que ejecutan los trabajos). Si lo desea, puede añadir un nodo de inicio de sesión para proporcionar a los usuarios un punto de acceso dedicado para enviar y gestionar los trabajos sin necesidad de iniciar sesión directamente en el controlador. En la solicitud de API, asignas a cada grupo de instancias su función de SlurmSlurmConfig, especificando si el grupo actúa como controlador, inicio de sesión o nodo de cómputo. Los grupos de cómputo también se asignan a una o más particiones de Slurm, que actúan como colas lógicas que organizan la programación de los trabajos en distintos conjuntos de nodos.

A nivel de clúster, Orchestrator.Slurm controla la forma en que se HyperPod gestiona la configuración de las particiones. slurm.conf Usted elige una estrategia que determine si HyperPod es la única fuente de información fiable para la topología de particiones, si sobrescribe los cambios manuales o si combina la API-defined configuración con cualquier edición manual que haya realizado. Esta es una referencia para los campos utilizados.

SlurmConfig(por grupo de instancias):

"SlurmConfig": {
    "NodeType": "Controller | Login | Compute",
    "PartitionNames": ["partition-name"]
}

Orchestrator.Slurm(nivel de clúster):

"Orchestrator": {
    "Slurm": {
        "SlurmConfigStrategy": "Managed | Overwrite | Merge"
    }
}

SlurmConfigStrategydetermina cómo HyperPod gestiona las asignaciones de partición a nodo en slurm.conf el nodo controlador. Al crear o actualizar un clúster, HyperPod escribe la configuración de la partición en slurm.conf función de la SlurmConfig que haya definido en cada grupo de instancias, mapea los grupos de instancias de cómputo a las particiones asignadas y registra los nodos de controlador e inicio de sesión con las funciones de Slurm adecuadas.

La estrategia que elijas controla lo que ocurre cuando la configuración de la partición slurm.conf se modifica fuera de la API, por ejemplo, cuando un administrador edita el archivo directamente en el nodo controlador. ConManaged, HyperPod trata a la API como la única fuente de información y detectará y bloqueará las actualizaciones slurm.conf en caso de que no haya espacio en el disco. ConOverwrite, HyperPod fuerza la API-defined configuración hacia el controlador y descarta cualquier modificación manual. slurm.conf Esto es útil para recuperarse de un cambio imprevisto. ConMerge, HyperPod conserva las ediciones manuales slurm.conf y las fusiona con la configuración de la API, lo que brinda a los usuarios avanzados la flexibilidad de mantener slurm.conf configuraciones personalizadas junto con las particiones. API-managed

Opciones de configuración del ciclo de vida del nodo

Al crear un clúster de SageMaker HyperPod Slurm, debes configurar el LifeCycleConfig bloque de la solicitud para elegir cómo se aprovisionarán los nodos de cada grupo de instancias. CreateCluster SageMaker HyperPod admite tres opciones de configuración del ciclo de vida de los nodos, cada una de las cuales ofrece un nivel diferente de control sobre el proceso de aprovisionamiento.

Solo con AMI-based la configuración, se omite por completo. LifeCycleConfig HyperPod configura automáticamente los nodos mediante la AMI-based configuración, la configuración de Slurm, la instalación de los paquetes esenciales y el inicio de todos los servicios necesarios. Esta es la ruta más sencilla y no requiere ningún bucket ni scripts de Amazon S3.

Con la opción Extension, debe especificar OnInitComplete LifeCycleConfig junto con un SourceS3Uri puntero el script de extensión en Amazon S3. HyperPod ejecuta primero la AMI-based configuración completa y, a continuación, ejecuta el script. Esto le permite añadir personalizaciones, como agentes de supervisión, integración con LDAP o montajes de almacenamiento adicionales, sin gestionar el aprovisionamiento básico.

Con la opción Personalizado, puede especificar OnCreate LifeCycleConfig y SourceS3Uri señalar el conjunto de scripts de ciclo de vida completo de Amazon S3. HyperPod no ejecuta la AMI-based configuración ni inicia Slurm. Sus scripts son los propietarios de toda la secuencia de aprovisionamiento. Esto le da un control total sobre el software que se instala, cómo se configura y cuándo se inicia Slurm.

Configuración de FSx y VPC

Para las cargas de trabajo de aprendizaje automático, un sistema de archivos compartido de alto rendimiento es esencial para almacenar los datos de entrenamiento, los puntos de control de los modelos y las bibliotecas compartidas en los nodos del clúster. SageMaker HyperPod es compatible con Amazon FSx for Lustre y FSx para OpenZFS, configurados por grupo de instancias mediante. InstanceStorageConfigs Los sistemas de archivos FSx residen en la VPC, por lo que se requiere una configuración de VPC personalizada () cuando se utiliza FSx. VpcConfig

La configuración de FSx funciona con las tres opciones de configuración del ciclo de vida de los nodos. Cuando se utiliza AMI-based la configuración oOnInitComplete, HyperPod gestiona el montaje de FSx automáticamente. Cuando se usaOnCreate, los scripts de ciclo de vida son responsables del montaje.

FSx for Lustre:

"InstanceStorageConfigs": [
    {
        "FsxLustreConfig": {
            "DnsName": "fs-0abc123def456789.fsx.us-west-2.amazonaws.com",
            "MountPath": "/fsx",
            "MountName": "abcdefgh"
        }
    }
]

FSx para OpenZFS:

"InstanceStorageConfigs": [
    {
        "FsxOpenZfsConfig": {
            "DnsName": "fs-0xyz789abc123456.fsx.us-west-2.amazonaws.com",
            "MountPath": "/shared"
        }
    }
]

Configuración de VPC (necesaria para FSx):

Añada VpcConfig a nivel de clúster en su CreateCluster solicitud:

"VpcConfig": {
    "SecurityGroupIds": ["sg-0abc123def456789a"],
    "Subnets": ["subnet-0abc123def456789a"]
}

Para obtener más información sobre la configuración de una VPC, consulte. Requisitos previos para su uso SageMaker HyperPod Para obtener más información sobre la configuración de FSx, consulte. Requisitos previos para su uso SageMaker HyperPod

Cree su clúster de

En esta sección, se explica cómo crear un clúster mediante cada una de las tres opciones de configuración del ciclo de vida de los nodos que se describen enOpciones de configuración del ciclo de vida del nodo. Para la mayoría de los usuarios, recomendamos comenzar con la opción A, solo con AMI-based la configuración. No requiere scripts ni un bucket de Amazon S3 y ofrece un clúster completamente funcional listo para usar. Elija la opción B si necesita añadir personalizaciones a la AMI-based configuración, o la opción C si necesita un control total sobre el proceso de aprovisionamiento.

ExecutionRolePara todos los ejemplos, proporcione el ARN del rol de IAM que creó con el administrado. AmazonSageMakerClusterInstanceRolePolicy Requisitos previos para su uso SageMaker HyperPod

Opción A: solo AMI-based configuración (sin configuración del ciclo de vida)

Esta es la ruta más sencilla. No se necesita ningún bucket, script ni archivo de configuración de Amazon S3. SageMaker HyperPod configura los nodos automáticamente mediante la AMI-based configuración, instalando el software esencial y aplicando las configuraciones para que el clúster esté listo para ejecutar cargas de trabajo de aprendizaje automático desde el primer momento. Todos los paquetes de software están integrados en la AMI, por lo que no se requiere acceso a Internet durante el aprovisionamiento.

En la siguiente tabla se enumeran las capacidades incluidas en la AMI-based configuración:

Opción B: Amplíe AMI-based la configuración con OnInitComplete

Use esta opción cuando necesite personalizaciones adicionales a la AMI-based configuración, como agentes de monitoreo, LDAP/SSSD integraciones o montajes de almacenamiento adicionales. SageMaker HyperPod ejecuta primero AMI-based la configuración y, a continuación, ejecuta el script de extensión.

Opción C: Control totalmente personalizado con OnCreate (avanzado)

Utilice esta opción cuando necesite tener un control total sobre el aprovisionamiento, lo que incluye la instalación del software, la realización de cambios en la infraestructura y la decisión de cuándo iniciar Slurm. ConOnCreate, SageMaker HyperPod no ejecuta la AMI-based configuración y no inicia Slurm automáticamente.

Errores de validación comunes

Conéctese a su clúster

Una vez que el estado del clúster cambie a InService (normalmente de 10 a 15 minutos), conéctese y compruébelo.

Para obtener más información sobre la ejecución de cargas de trabajo de aprendizaje automático, consulte. Trabajos en SageMaker HyperPod clústeres

Eliminación del clúster y limpieza de recursos

Tras realizar las pruebas, elimine el clúster para evitar que se sigan cobrando cargos:

aws sagemaker delete-cluster --cluster-name my-hyperpod-cluster

Si utilizó scripts de ciclo de vida de nodos (opción B u opción C), limpie el bucket de Amazon S3:

aws s3 rm s3://sagemaker-amzn-s3-demo-bucket/lifecycle/src --recursive

Si ha utilizado únicamente AMI-based la configuración (opción A), no es necesaria ninguna limpieza de Amazon S3 para los scripts del ciclo de vida de los nodos.

Si ejecutó cargas de trabajo de entrenamiento, compruebe también si hay datos o artefactos en Amazon S3, Amazon FSx for Lustre o Amazon Elastic File System y elimínelos para evitar cargos.

Temas relacionados