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](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-cli) 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](sagemaker-hyperpod-prerequisites.md) (VPC, cuotas, FSx) y [AWS Identity and Access Management para SageMaker HyperPod](sagemaker-hyperpod-prerequisites-iam.md) (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](#smcluster-getting-started-slurm-cli-create-cluster) y volver a consultarla si es necesario. Al crear un Slurm-orchestrated clúster, debe elegir dos opciones de configuración independientes: 1. **Configuración de la topología de Slurm**: ¿cómo se define la topología del clúster de Slurm (funciones de nodo, particiones)? 1. **Configuración del ciclo de vida de los nodos**: ¿cómo se aprovisionan y personalizan los nodos? 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, consulte[SageMaker HyperPod Configuración de Slurm](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-slurm-configuration). 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 Slurm`SlurmConfig`, 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"] } ``` | Campo | Description (Descripción) | | --- | --- | | NodeType | Obligatorio. El rol de Slurm para este grupo de instancias. Valores válidos: Controller, Login, Compute. Debe existir exactamente un grupo de instancias. Controller | | PartitionNames | Condicional. Nombres de particiones de Slurm. Necesario para Compute el tipo de nodo; no permitido para Controller o. Login | **Orchestrator.Slurm**(nivel de clúster): ``` "Orchestrator": { "Slurm": { "SlurmConfigStrategy": "Managed | Overwrite | Merge" } } ``` `SlurmConfigStrategy`determina 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. Con`Managed`, 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. Con`Overwrite`, 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. Con`Merge`, 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 | Strategy (Estrategia) | Detección de desviación de particiones | Cambios manuales | Caso de uso | | --- | --- | --- | --- | | Managed (predeterminado) | Activado; bloquea las actualizaciones si se detecta una desviación | No compatible | Una única fuente de verdad | | Overwrite | Deshabilitado | Se sobrescribe en la actualización | Recuperación de una deriva | | Merge | Deshabilitado | Preservado y fusionado | slurm.confNecesidades personalizadas | **importante** La detección de desviaciones solo se aplica a la configuración de particiones de Slurm en `slurm.conf` (las asignaciones de partición a nodo definidas a través de la API). Los cambios en otros `slurm.conf` ajustes, como los parámetros de programación, los límites de recursos o la configuración de la contabilidad, no se supervisan y no los detectarán ni informarán al respecto. HyperPod **nota** Si prefieres definir la topología de Slurm mediante un `provisioning_parameters.json` archivo en lugar de la API, omítelo en los grupos `SlurmConfig` de instancias y en la solicitud `Orchestrator.Slurm` de clúster, y sube el archivo a Amazon S3 junto con los scripts del ciclo de vida del nodo. Para obtener más información, consulte [SageMaker HyperPod Configuración de Slurm](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-slurm-configuration). ### 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. | Opción de ciclo de vida del nodo | ¿Necesita un bucket de Amazon S3? | ¿Secuencias de comandos para cargar? | LifeCycleConfig ¿en la API? | | --- | --- | --- | --- | | AMI-based solo configuración (la más sencilla) | No | No | Omitir por completo | | Extensión () OnInitComplete | Sí | Solo tu script de extensión | OnInitComplete \+ SourceS3Uri | | Personalizado (OnCreate) | Sí | Conjunto de scripts de ciclo de vida completo | OnCreate \+ SourceS3Uri | **nota** La configuración opcional del ciclo de vida de los nodos solo se admite para Slurm-orchestrated los clústeres. EKS-orchestrated Los clústeres y los clústeres de Slurm que utilizan `NodeProvisioningMode` Continuous siguen siendo necesarios `LifeCycleConfig` con `OnCreate` y dentro de cada `SourceS3Uri` grupo de instancias. **nota** `OnCreate`y `OnInitComplete` se excluyen mutuamente. Si se especifican ambos en el mismo grupo de instancias, se produce un error de validación. ### 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 o`OnInitComplete`, HyperPod gestiona el montaje de FSx automáticamente. Cuando se usa`OnCreate`, 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" } } ] ``` | Campo | Description (Descripción) | | --- | --- | | DnsName | Obligatorio. El nombre DNS del sistema de archivos FSx for Lustre. | | MountPath | Opcional. La ruta de montaje local de la instancia. Valor predeterminado: /fsx | | MountName | Obligatorio. El nombre de montaje del sistema de archivos FSx for Lustre. Encuéntrelo en la consola FSx for Lustre o a través de. aws fsx describe-file-systems | **FSx para OpenZFS:** ``` "InstanceStorageConfigs": [ { "FsxOpenZfsConfig": { "DnsName": "fs-0xyz789abc123456.fsx.us-west-2.amazonaws.com", "MountPath": "/shared" } } ] ``` | Campo | Description (Descripción) | | --- | --- | | DnsName | Obligatorio. El nombre DNS del sistema de archivos FSx para OpenZFS. | | MountPath | Opcional. La ruta de montaje local de la instancia. Valor predeterminado: /home | **nota** Cada grupo de instancias puede tener como máximo una configuración FSx for Lustre y una FSx para OpenZFS. Los distintos grupos de instancias pueden montar diferentes sistemas de archivos. **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](sagemaker-hyperpod-prerequisites.md) Para obtener más información sobre la configuración de FSx, consulte. [Requisitos previos para su uso SageMaker HyperPod](sagemaker-hyperpod-prerequisites.md) ## 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 en[Opciones de configuración del ciclo de vida del nodo](#smcluster-getting-started-slurm-cli-lifecycle-options). 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. `ExecutionRole`Para todos los ejemplos, proporcione el ARN del rol de IAM que creó con el administrado. `AmazonSageMakerClusterInstanceRolePolicy` [Requisitos previos para su uso SageMaker HyperPod](sagemaker-hyperpod-prerequisites.md) ### 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: | Funcionalidad | Description (Descripción) | | --- | --- | | Demonios de Slurm | Los daemons de controlador y cómputo se iniciaron automáticamente | | Docker | Tiempo de ejecución de contenedores para crear y ejecutar contenedores de aprendizaje automático | | Enroot | Ejecución de contenedores sin root para cargas de trabajo de Slurm | | Pyxis | Complemento Slurm para la integración de contenedores | | Contabilidad Slurm | Configura la contabilidad de trabajos de Slurm para rastrear el historial de trabajos y el consumo de recursos | | MariaDB | Despliega MariaDB en el nodo controlador como base de datos de respaldo para la contabilidad de Slurm | | Generación de claves SSH | Par de claves generado para el usuario predeterminado de Ubuntu | | Propagación de SSH | Las credenciales de usuario se propagan entre los nodos de cómputo para trabajos de varios nodos | | Rotación de registros de Slurm | Evita que el registro se sobrecargue y que el disco se llene | | Configuración del directorio principal | El directorio principal de usuarios de Ubuntu está montado en un sistema de archivos compartido | 1. Guarde lo siguiente como: `create_cluster.json` ``` { "ClusterName": "my-hyperpod-cluster", "InstanceGroups": [ { "InstanceGroupName": "my-controller-group", "InstanceType": "ml.c5.xlarge", "InstanceCount": 1, "SlurmConfig": { "NodeType": "Controller" }, "ExecutionRole": "arn:aws:iam::{{111122223333}}:role/HyperPodExecutionRole", "InstanceStorageConfigs": [ { "EbsVolumeConfig": { "VolumeSizeInGB": 500 } } ] }, { "InstanceGroupName": "my-login-group", "InstanceType": "ml.m5.4xlarge", "InstanceCount": 1, "SlurmConfig": { "NodeType": "Login" }, "ExecutionRole": "arn:aws:iam::{{111122223333}}:role/HyperPodExecutionRole" }, { "InstanceGroupName": "worker-group-1", "InstanceType": "ml.trn1.32xlarge", "InstanceCount": 1, "SlurmConfig": { "NodeType": "Compute", "PartitionNames": ["partition-1"] }, "ExecutionRole": "arn:aws:iam::{{111122223333}}:role/HyperPodExecutionRole", "InstanceStorageConfigs": [ { "FsxLustreConfig": { "DnsName": "{{fs-0abc123def456789.fsx.us-west-2.amazonaws.com}}", "MountPath": "/fsx", "MountName": "{{abcdefgh}}" } } ] } ], "Orchestrator": { "Slurm": { "SlurmConfigStrategy": "Managed" } }, "VpcConfig": { "SecurityGroupIds": ["{{sg-0abc123def456789a}}"], "Subnets": ["{{subnet-0abc123def456789a}}"] } } ``` Ten en cuenta que no `LifeCycleConfig` se especifica en ningún grupo de instancias. La topología de Slurm se define `SlurmConfig` en cada grupo de instancias: `my-controller-group` se le asigna el `Controller` rol (se ejecuta`slurmctld`), `my-login-group` sirve como `Login` nodo para el acceso de los usuarios y `worker-group-1` es un `Compute` nodo asignado `partition-1` para la programación de tareas. A nivel de clúster, `SlurmConfigStrategy: "Managed"` asegura que HyperPod es la única fuente de información fiable para la configuración de las particiones. El grupo de trabajo incluye un sistema de archivos FSx for Lustre `/fsx` montado para el almacenamiento compartido y se especifica a nivel de `VpcConfig` clúster según sea necesario para FSx. **sugerencia** Si está realizando pruebas sin FSx, puede omitir o eliminar `FsxLustreConfig` `VpcConfig` de `InstanceStorageConfigs` la solicitud. FSx no es necesario para la creación de clústeres, pero se recomienda para las cargas de trabajo de ML de producción. 1. Cree el clúster: ``` aws sagemaker create-cluster \ --cli-input-json {{file://create_cluster.json}} ``` 1. Compruebe el estado: ``` aws sagemaker describe-cluster --cluster-name {{my-hyperpod-cluster}} ``` Solo con AMI-based la configuración, los grupos de instancias de la respuesta no incluyen ningún bloque. `LifeCycleConfig` El siguiente es un ejemplo truncado que muestra el grupo de instancias del controlador: ``` { "ClusterName": "my-hyperpod-cluster", "ClusterStatus": "InService", "InstanceGroups": [ { "InstanceGroupName": "my-controller-group", "SlurmConfig": { "NodeType": "Controller" } } ] } ``` Cuando el estado cambie a**InService**, continúe con. [Conéctese a su clúster](#smcluster-getting-started-slurm-cli-connect) ### 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. 1. Escribe tu script de extensión. Por ejemplo`extend-defaults.sh`: ``` #!/bin/bash set -e echo "Running post-initialization customizations..." # Example: Install a monitoring agent # apt-get install -y my-monitoring-agent # Example: Configure LDAP integration # /opt/custom/setup-ldap.sh # Example: Mount an additional S3 bucket # mount-s3 my-data-bucket /mnt/s3-data echo "Custom extensions complete." ``` **Uso de scripts de extensión del repositorio Awsome Distributed Training** La [carpeta de extensiones](https://github.com/awslabs/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/Extensions) del repositorio de Awsome Distributed Training proporciona scripts de extensión listos para usar para tareas comunes, como añadir usuarios y habilitar la observabilidad. Cada capacidad está contenida en su propio directorio con su propio script de punto de entrada que se puede proporcionar directamente como script. `OnInitComplete` Para los clústeres que necesitan múltiples capacidades, recomendamos utilizar el `run_extensions.sh` script disponible en el nivel superior de la carpeta de extensiones. Este script organiza todos los scripts de extensión disponibles y proporciona sencillos ajustes booleanos para activar o desactivar cada función. Para usarlo, cargue toda la carpeta Extensions a su bucket de Amazon S3 y especifique `run_extensions.sh` como `OnInitComplete` script: ``` s3://// |-- run_extensions.sh (OnInitComplete target) |-- detect-node/ (node type detection utility) |-- add-users/ (user management scripts + config) |-- observability/ (observability scripts + config) ``` Dentro`run_extensions.sh`, habilite o deshabilite cada capacidad configurando el indicador correspondiente: ``` ENABLE_ADD_USERS="true" ENABLE_OBSERVABILITY="true" ``` El archivo de configuración de cada capacidad habilitada debe rellenarse antes de cargarlo en Amazon S3. Consulte el archivo README del directorio de cada capacidad para obtener detalles de configuración. 1. Cargue en Amazon S3 (la ruta del bucket debe empezar por`s3://sagemaker-`): ``` aws s3 cp extend-defaults.sh \ s3://sagemaker-{{amzn-s3-demo-bucket}}/scripts/ ``` 1. Guarde lo siguiente como`create_cluster.json`: ``` { "ClusterName": "my-hyperpod-cluster", "InstanceGroups": [ { "InstanceGroupName": "my-controller-group", "InstanceType": "ml.c5.xlarge", "InstanceCount": 1, "SlurmConfig": { "NodeType": "Controller" }, "LifeCycleConfig": { "OnInitComplete": "extend-defaults.sh", "SourceS3Uri": "s3://sagemaker-{{amzn-s3-demo-bucket}}/scripts/" }, "ExecutionRole": "arn:aws:iam::{{111122223333}}:role/HyperPodExecutionRole", "InstanceStorageConfigs": [ { "EbsVolumeConfig": { "VolumeSizeInGB": 500 } } ] }, { "InstanceGroupName": "my-login-group", "InstanceType": "ml.m5.4xlarge", "InstanceCount": 1, "SlurmConfig": { "NodeType": "Login" }, "LifeCycleConfig": { "OnInitComplete": "extend-defaults.sh", "SourceS3Uri": "s3://sagemaker-{{amzn-s3-demo-bucket}}/scripts/" }, "ExecutionRole": "arn:aws:iam::{{111122223333}}:role/HyperPodExecutionRole" }, { "InstanceGroupName": "worker-group-1", "InstanceType": "ml.trn1.32xlarge", "InstanceCount": 1, "SlurmConfig": { "NodeType": "Compute", "PartitionNames": ["partition-1"] }, "LifeCycleConfig": { "OnInitComplete": "extend-defaults.sh", "SourceS3Uri": "s3://sagemaker-{{amzn-s3-demo-bucket}}/scripts/" }, "ExecutionRole": "arn:aws:iam::{{111122223333}}:role/HyperPodExecutionRole" } ], "Orchestrator": { "Slurm": { "SlurmConfigStrategy": "Managed" } } } ``` **importante** Si `OnInitComplete` se especifica, `SourceS3Uri` es obligatorio. `OnCreate`y `OnInitComplete` no se pueden usar juntos en el mismo grupo de instancias. **sugerencia** Puedes combinar opciones dentro de un clúster. Por ejemplo, utilice AMI-based la configuración solo en el controlador y `OnInitComplete` en los trabajadores. La topología de Slurm es la misma que la de la opción A. Cada grupo de instancias tiene una `SlurmConfig` función de nodo y una asignación de particiones definidas, y `SlurmConfigStrategy: "Managed"` se establece a nivel de clúster. La única diferencia es la adición de `LifeCycleConfig` with`OnInitComplete`, que indica HyperPod que debes ejecutar el script de extensión una vez finalizada la AMI-based configuración en cada nodo. Para agregar FSx, incluya `FsxLustreConfig` o incluya `FsxOpenZfsConfig` `InstanceStorageConfigs` en los grupos de instancias relevantes y agréguelos `VpcConfig` a nivel de clúster, como se describe en. [Configuración de FSx y VPC](#smcluster-getting-started-slurm-cli-fsx-vpc) 1. Cree el clúster: ``` aws sagemaker create-cluster \ --cli-input-json {{file://create_cluster.json}} ``` 1. Compruebe el estado: ``` aws sagemaker describe-cluster --cluster-name {{my-hyperpod-cluster}} ``` Con`OnInitComplete`, la respuesta se muestra `OnInitComplete` en. `LifeCycleConfig` El siguiente es un ejemplo truncado que muestra el grupo de instancias del controlador: ``` { "ClusterName": "my-hyperpod-cluster", "ClusterStatus": "InService", "InstanceGroups": [ { "InstanceGroupName": "my-controller-group", "SlurmConfig": { "NodeType": "Controller" }, "LifeCycleConfig": { "SourceS3Uri": "s3://sagemaker-{{amzn-s3-demo-bucket}}/scripts/", "OnInitComplete": "extend-defaults.sh" } } ] } ``` Cuando el estado cambie a**InService**, continúe con. [Conéctese a su clúster](#smcluster-getting-started-slurm-cli-connect) ### 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. Con`OnCreate`, SageMaker HyperPod no ejecuta la AMI-based configuración y ****no**** inicia Slurm automáticamente. **nota** Si es nuevo SageMaker HyperPod y no tiene requisitos de personalización específicos, le recomendamos que comience con la opción A o la opción B. Siempre podrá migrar al modo personalizado más adelante. 1. Prepare y cargue los scripts del ciclo de vida en Amazon S3. Si empieza desde cero, utilice los scripts de muestra del [ GitHub repositorio Awsome Distributed Training](https://github.com/aws-samples/awsome-distributed-training/): ``` git clone https://github.com/aws-samples/awsome-distributed-training/ cd awsome-distributed-training/1.architectures/5.sagemaker_hyperpods/LifecycleScripts/base-config ``` Cargue en Amazon S3 (la ruta del bucket debe empezar por`s3://sagemaker-`): ``` aws s3 sync . \ s3://sagemaker-{{amzn-s3-demo-bucket}}/lifecycle/src ``` Para obtener más información sobre los scripts de ciclo de vida, consulte [Personalización de SageMaker HyperPod clústeres mediante scripts de ciclo de vida](sagemaker-hyperpod-lifecycle-best-practices-slurm.md). 1. Guarde lo siguiente como`create_cluster.json`: ``` { "ClusterName": "my-hyperpod-cluster", "InstanceGroups": [ { "InstanceGroupName": "my-controller-group", "InstanceType": "ml.c5.xlarge", "InstanceCount": 1, "SlurmConfig": { "NodeType": "Controller" }, "LifeCycleConfig": { "SourceS3Uri": "s3://sagemaker-{{amzn-s3-demo-bucket}}/lifecycle/src", "OnCreate": "on_create.sh" }, "ExecutionRole": "arn:aws:iam::{{111122223333}}:role/HyperPodExecutionRole", "InstanceStorageConfigs": [ { "EbsVolumeConfig": { "VolumeSizeInGB": 500 } } ] }, { "InstanceGroupName": "my-login-group", "InstanceType": "ml.m5.4xlarge", "InstanceCount": 1, "SlurmConfig": { "NodeType": "Login" }, "LifeCycleConfig": { "SourceS3Uri": "s3://sagemaker-{{amzn-s3-demo-bucket}}/lifecycle/src", "OnCreate": "on_create.sh" }, "ExecutionRole": "arn:aws:iam::{{111122223333}}:role/HyperPodExecutionRole" }, { "InstanceGroupName": "worker-group-1", "InstanceType": "ml.trn1.32xlarge", "InstanceCount": 1, "SlurmConfig": { "NodeType": "Compute", "PartitionNames": ["partition-1"] }, "LifeCycleConfig": { "SourceS3Uri": "s3://sagemaker-{{amzn-s3-demo-bucket}}/lifecycle/src", "OnCreate": "on_create.sh" }, "ExecutionRole": "arn:aws:iam::{{111122223333}}:role/HyperPodExecutionRole" } ], "Orchestrator": { "Slurm": { "SlurmConfigStrategy": "Managed" } } } ``` La topología de Slurm sigue el mismo `SlurmConfig` patrón que las demás opciones. La diferencia clave es con. `LifeCycleConfig` `OnCreate` Esto indica HyperPod que hay que saltarse AMI-based la configuración por completo y ejecutar el `on_create.sh` script en su lugar. Sus scripts son responsables de toda la secuencia de aprovisionamiento, que incluye la instalación del software, la configuración de Slurm y el inicio de los daemons de Slurm. Para agregar FSx, incluya `FsxLustreConfig` o incluya `FsxOpenZfsConfig` `InstanceStorageConfigs` en los grupos de instancias relevantes y agréguelos `VpcConfig` a nivel de clúster, como se describe en. [Configuración de FSx y VPC](#smcluster-getting-started-slurm-cli-fsx-vpc) 1. Cree el clúster: ``` aws sagemaker create-cluster \ --cli-input-json {{file://create_cluster.json}} ``` 1. Compruebe el estado: ``` aws sagemaker describe-cluster --cluster-name {{my-hyperpod-cluster}} ``` Con`OnCreate`, la respuesta se muestra `OnCreate` en. `LifeCycleConfig` El siguiente es un ejemplo truncado que muestra el grupo de instancias del controlador: ``` { "ClusterName": "my-hyperpod-cluster", "ClusterStatus": "InService", "InstanceGroups": [ { "InstanceGroupName": "my-controller-group", "SlurmConfig": { "NodeType": "Controller" }, "LifeCycleConfig": { "SourceS3Uri": "s3://sagemaker-{{amzn-s3-demo-bucket}}/lifecycle/src", "OnCreate": "on_create.sh" } } ] } ``` Cuando el estado cambie a**InService**, continúe con. [Conéctese a su clúster](#smcluster-getting-started-slurm-cli-connect) ### Errores de validación comunes | Error | Resolución | | --- | --- | | «El clúster debe tener exactamente uno InstanceGroup con un tipo de nodo controlador» | Asegúrese de que exactamente un grupo de instancias tengaSlurmConfig.NodeType: "Controller" | | «Las particiones solo se pueden asignar a los tipos de nodos de cómputo» | Elimine PartitionNames de Controller nuestros grupos de Login instancias | | «Las configuraciones de FSx solo se admiten para VPC personalizadas» | VpcConfigAñádalo a su solicitud cuando utilice FSx | | «LifeCycleConfig es obligatorio para el grupo de instancias...» | Clústeres EKS o Slurm Continuous. NodeProvisioningMode No se admite la configuración opcional del ciclo de vida de los nodos. | | «OnCreate e OnInitComplete in LifeCycleConfig se excluyen mutuamente...» | Elimine una de OnCreate las dosOnInitComplete. No puede especificar ambos. | | «LifeCycleConfig por ejemplo, el grupo está incompleto...» | Cuando se especifique OnCreate o OnInitComplete se especifique, también SourceS3Uri debe proporcionarse. | | «LifeCycleConfig es opcional pero requiere una AMI compatible...» | Ejecute UpdateClusterSoftware para actualizar a una AMI que admita la configuración opcional del ciclo de vida del nodo. | | «LifeCycleConfig porque se proporciona un grupo de instancias pero no contiene ninguna configuración...» | Especifique SourceS3Uri con OnCreate oOnInitComplete, u omita LifeCycleConfig por completo. | ## 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. 1. Enumere los nodos del clúster para obtener los ID de las instancias: ``` aws sagemaker list-cluster-nodes --cluster-name {{my-hyperpod-cluster}} ``` 1. Conéctese mediante el administrador de AWS Systems Manager sesiones: ``` aws ssm start-session \ --target sagemaker-cluster:{{my-hyperpod-cluster}}_{{my-login-group}}-{{i-0abc123def456789b}} \ --region {{us-west-2}} ``` 1. Compruebe que Slurm esté configurado correctamente: ``` # Check Slurm nodes sinfo # Check Slurm partitions sinfo -p partition-1 # Submit a test job srun -p partition-1 --nodes=1 hostname ``` 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](sagemaker-hyperpod-run-jobs-slurm.md) ## 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 + [SageMaker HyperPod Configuración de Slurm](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-slurm-configuration) + [Personalización de SageMaker HyperPod clústeres mediante scripts de ciclo de vida](sagemaker-hyperpod-lifecycle-best-practices-slurm.md) + [Configuración de FSx mediante InstanceStorageConfigs](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-slurm-fsx-config) + [SageMaker HyperPod Operaciones de clúster de Slurm](sagemaker-hyperpod-operate-slurm.md) + [Scripts de extensión para SageMaker HyperPod](https://github.com/awslabs/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/Extensions) + [Personalización de SageMaker HyperPod clústeres mediante scripts de ciclo de vida](sagemaker-hyperpod-lifecycle-best-practices-slurm.md)