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. # Personalización de SageMaker HyperPod clústeres mediante scripts de ciclo de vida SageMaker HyperPod siempre ofrece up-and-running clústeres de procesamiento, que son altamente personalizables, ya que puede escribir scripts de ciclo de vida que indiquen SageMaker HyperPod cómo configurar los recursos del clúster. Los siguientes temas son prácticas recomendadas para preparar scripts de ciclo de vida para configurar SageMaker HyperPod clústeres con herramientas de gestión de cargas de trabajo de código abierto. En los siguientes temas, se analizan en profundidad las mejores prácticas para preparar scripts de ciclo de vida para configurar las configuraciones de Slurm. SageMaker HyperPod ## Descripción general El siguiente procedimiento es el flujo principal de aprovisionamiento de un HyperPod clúster y su configuración con Slurm. Los pasos se ordenan siguiendo un enfoque ***ascendente***. 1. Planifique cómo quiere crear los nodos de Slurm en un clúster. HyperPod Por ejemplo, si quieres configurar dos nodos de Slurm, tendrás que configurar dos grupos de instancias en un clúster. HyperPod 1. Prepara la configuración de Slurm. Elija uno de los siguientes enfoques: + **Opción A: Configuración basada en API (recomendada)**: defina los tipos de nodos y las particiones de Slurm directamente en la carga útil de la `CreateCluster` API utilizando `SlurmConfig` cada grupo de instancias. Con este enfoque: + No se necesita ningún `provisioning_parameters.json` archivo + La topología de Slurm se define en la carga útil de la API junto con las definiciones de los grupos de instancias + FSx Los sistemas de archivos se configuran mediante per-instance-group `InstanceStorageConfigs` + La estrategia de configuración se controla mediante `Orchestrator.Slurm.SlurmConfigStrategy` Ejemplo `SlurmConfig` en un grupo de instancias: ``` { "InstanceGroupName": "gpu-compute", "InstanceType": "ml.p4d.24xlarge", "InstanceCount": 8, "SlurmConfig": { "NodeType": "Compute", "PartitionNames": ["gpu-training"] } } ``` + **Opción B: Configuración antigua**: prepara un `provisioning_parameters.json` archivo, que es un[Formulario de configuración para provisioning\$1parameters.json](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-provisioning-forms-slurm). `provisioning_parameters.json`debe contener la información de configuración del nodo de Slurm que se va a aprovisionar en el clúster. HyperPod Esto debería reflejar el diseño de los nodos de Slurm del paso 1. 1. Prepare un conjunto de scripts de ciclo de vida para configurar Slurm, HyperPod instalar paquetes de software y configurar un entorno en el clúster para su caso de uso. Debe estructurar los scripts de ciclo de vida para que se ejecuten de forma colectiva y en orden en un script de Python central (`lifecycle_script.py`) y escribir un script de intérprete de comandos de punto de entrada (`on_create.sh`) para ejecutar el script de Python. El script de shell de punto de entrada es lo que debe proporcionar a una solicitud de creación de HyperPod clústeres más adelante en el paso 5. Además, tenga en cuenta que debe escribir los scripts para esperar `resource_config.json` que se generen HyperPod durante la creación del clúster. `resource_config.json`contiene información sobre los recursos del HyperPod clúster, como las direcciones IP, los tipos de instancias y ARNs, y es lo que debe usar para configurar Slurm. 1. Reúna todos los archivos de los pasos anteriores en una carpeta. La estructura de carpetas depende del enfoque de configuración que haya seleccionado en el paso 2. Si seleccionó la opción A (configuración basada en API): La carpeta solo necesita scripts de ciclo de vida para las tareas de configuración personalizadas. La configuración y el FSx montaje de Slurm se gestionan automáticamente en HyperPod función de la carga útil de la API. ``` └── lifecycle_files // your local folder ├── on_create.sh ├── lifecycle_script.py └── ... // more setup scripts to be fed into lifecycle_script.py ``` **nota** El `provisioning_parameters.json` archivo no es necesario cuando se utiliza una configuración basada en API. Si seleccionó la opción B (configuración antigua): La carpeta debe incluir `provisioning_parameters.json` el conjunto completo de scripts del ciclo de vida. ``` └── lifecycle_files // your local folder ├── provisioning_parameters.json ├── on_create.sh ├── lifecycle_script.py └── ... // more setup scrips to be fed into lifecycle_script.py ``` 1. Cargue todos los archivos en un bucket de S3. Copie y conserve la ruta del bucket de S3. Tenga en cuenta que debe crear una ruta de bucket de S3 que empiece por `sagemaker-`, ya que tiene que elegir un [Función de IAM para SageMaker HyperPod](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-role-for-hyperpod) asociado a [`AmazonSageMakerClusterInstanceRolePolicy`](security-iam-awsmanpol-AmazonSageMakerClusterInstanceRolePolicy.md), que solo permite las rutas de bucket de S3 que comienzan con el prefijo `sagemaker-`. El siguiente comando es un ejemplo de comando para cargar todos los archivos en un bucket de S3. ``` aws s3 cp --recursive ./lifecycle_files s3://sagemaker-hyperpod-lifecycle/src ``` 1. Prepare una solicitud HyperPod de creación de clústeres. + Opción 1: Si utilizas el AWS CLI, escribe una solicitud de creación de clústeres en formato JSON (`create_cluster.json`) siguiendo las instrucciones que se indican en[Creación de un nuevo clúster](sagemaker-hyperpod-operate-slurm-cli-command.md#sagemaker-hyperpod-operate-slurm-cli-command-create-cluster). + Opción 2: Si utilizas la interfaz de usuario de la consola de SageMaker IA, rellena el formulario de solicitud de **creación de un clúster** en la interfaz de usuario de la HyperPod consola siguiendo las instrucciones que se indican en[Crea un SageMaker HyperPod clúster](sagemaker-hyperpod-operate-slurm-console-ui.md#sagemaker-hyperpod-operate-slurm-console-ui-create-cluster). En esta fase, asegúrese de crear grupos de instancias en la misma estructura que planeó en los pasos 1 y 2. Además, asegúrese de especificar el bucket de S3 del paso 5 en los formularios de solicitud. 1. Envía la solicitud de creación del clúster. HyperPod aprovisiona un clúster en función de la solicitud y, a continuación, crea un `resource_config.json` archivo en las instancias del HyperPod clúster y configura Slurm en el clúster ejecutando los scripts del ciclo de vida. En los siguientes temas se explica y profundiza en los detalles sobre cómo organizar los archivos de configuración y los scripts del ciclo de vida para que funcionen correctamente durante la creación del HyperPod clúster. **Topics** + [Descripción general](#sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-highlevel-overview) + [Los scripts de ciclo de vida básicos proporcionados por HyperPod](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-base-config.md) + [Qué configuraciones específicas se administran en los archivos de configuración HyperPod de Slurm](sagemaker-hyperpod-lifecycle-best-practices-slurm-what-hyperpod-overrides-in-slurm-conf.md) + [Registra rotaciones de Slurm](sagemaker-hyperpod-slurm-log-rotation.md) + [Montaje de Amazon FSx for Lustre y Amazon FSx for OpenZFS en un clúster HyperPod](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-setup-with-fsx.md) + [Validar los archivos de configuración JSON antes de crear un clúster de Slurm en HyperPod](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-validate-json-files.md) + [Validar el tiempo de ejecución antes de ejecutar las cargas de trabajo de producción en un clúster de Slurm HyperPod](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-validate-runtime.md) + [Desarrollar scripts de ciclo de vida de forma interactiva en un nodo de clúster HyperPod](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-develop-lifecycle-scripts.md) # Los scripts de ciclo de vida básicos proporcionados por HyperPod En esta sección se explican todos los componentes del proceso básico de configuración de Slurm on con un HyperPod enfoque ***descendente***. Comienza con la preparación de una solicitud de creación de HyperPod clústeres para ejecutar la `CreateCluster` API y profundiza en la estructura jerárquica hasta llegar a los scripts del ciclo de vida. Usa los ejemplos de scripts de ciclo de vida que se proporcionan en el repositorio de [Awsome Distributed Training GitHub ](https://github.com/aws-samples/awsome-distributed-training/). Clone el repositorio ejecutando el siguiente comando. ``` git clone https://github.com/aws-samples/awsome-distributed-training/ ``` Los scripts básicos del ciclo de vida para configurar un clúster de Slurm SageMaker HyperPod están disponibles en. [https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config) ``` cd awsome-distributed-training/1.architectures/5.sagemaker_hyperpods/LifecycleScripts/base-config ``` En el siguiente diagrama de flujo, se muestra una descripción detallada de cómo debe diseñar los scripts de ciclo de vida básicos. Las descripciones que aparecen debajo del diagrama y la guía de procedimientos explican cómo funcionan durante la llamada a la HyperPod `CreateCluster` API. ![\[Un diagrama de flujo detallado de la creación de HyperPod clústeres y la estructura de los scripts del ciclo de vida.\]](http://docs.aws.amazon.com/es_es/sagemaker/latest/dg/images/hyperpod-lifecycle-structure.png) ***Figura:** Un diagrama de flujo detallado de la creación de HyperPod clústeres y la estructura de los scripts de ciclo de vida. (1) Las flechas discontinuas se dirigen hacia donde se llaman los cuadros y muestran el flujo de preparación de los archivos de configuración y los scripts de ciclo de vida. Comienza con la preparación de `provisioning_parameters.json` y los scripts de ciclo de vida. Luego estos se codifican en `lifecycle_script.py` para permitir una ejecución colectiva en orden. Y la ejecución del `lifecycle_script.py` script la realiza el script del `on_create.sh` shell, que se ejecuta en el terminal de la HyperPod instancia. (2) Las flechas continuas muestran el flujo principal de creación del HyperPod clúster y cómo se «invoca» o se «envía» a las casillas. `on_create.sh`es obligatorio para la solicitud de creación de un clúster, ya sea en el formulario de solicitud de **creación de un clúster** de la interfaz de usuario de la consola `create_cluster.json` o en el formulario de solicitud de creación de un clúster. Tras enviar la solicitud, HyperPod ejecuta la `CreateCluster` API en función de la información de configuración proporcionada en la solicitud y en los scripts del ciclo de vida. (3) La flecha punteada indica que la HyperPod plataforma crea instancias `resource_config.json` en el clúster durante el aprovisionamiento de los recursos del clúster. `resource_config.json`contiene información sobre los recursos del HyperPod clúster, como el ARN del clúster, los tipos de instancias y las direcciones IP. Es importante tener en cuenta que debe preparar los scripts de ciclo de vida para que esperen el archivo `resource_config.json` durante la creación del clúster. Para obtener más información, consulte la guía de procedimientos que se incluye a continuación.* La siguiente guía de procedimientos explica qué ocurre durante la creación HyperPod del clúster y cómo se diseñan los scripts del ciclo de vida básico. 1. `create_cluster.json`— Para enviar una solicitud de creación de HyperPod clústeres, debe preparar un archivo de `CreateCluster` solicitud en formato JSON. En este ejemplo de prácticas recomendadas, asumimos que el archivo de solicitud se denomina `create_cluster.json`. Escribe `create_cluster.json` para aprovisionar un HyperPod clúster con grupos de instancias. La mejor práctica es agregar la misma cantidad de grupos de instancias que la cantidad de nodos de Slurm que planeas configurar en el HyperPod clúster. Asegúrese de asignar nombres distintivos a los grupos de instancias que asignará a los nodos de Slurm que piensa configurar. Además, debe especificar una ruta de bucket de S3 para almacenar todo el conjunto de archivos de configuración y scripts de ciclo de vida en el nombre de campo `InstanceGroups.LifeCycleConfig.SourceS3Uri` del formulario de solicitud `CreateCluster`, y especificar el nombre de archivo de un script de intérprete de comandos de punto de entrada (supongamos que se denomina `on_create.sh`) en `InstanceGroups.LifeCycleConfig.OnCreate`. **nota** Si utilizas el formulario de envío **para crear un clúster** en la interfaz de usuario de la HyperPod consola, la consola se encarga de rellenar y enviar la `CreateCluster` solicitud en tu nombre y ejecuta la `CreateCluster` API en el backend. En este caso, no es necesario que cree `create_cluster.json`; en cambio, debe asegurarse de especificar la información de configuración del clúster correcta en el formulario de envío **Crear un clúster**. 1. `on_create.sh`— Para cada grupo de instancias, debes proporcionar un script shell de punto de entrada para ejecutar comandos`on_create.sh`, ejecutar scripts para instalar paquetes de software y configurar el entorno del HyperPod clúster con Slurm. Las dos cosas que debes preparar son una `provisioning_parameters.json` necesaria HyperPod para configurar Slurm y un conjunto de scripts de ciclo de vida para instalar paquetes de software. Este script debe escribirse para buscar y ejecutar los siguientes archivos, tal y como se muestra en el script de ejemplo que aparece en [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/on_create.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/on_create.sh). **nota** Asegúrese de cargar todo el conjunto de scripts de ciclo de vida en la ubicación de S3 que especifique en `create_cluster.json`. También debe colocar el archivo `provisioning_parameters.json` en la misma ubicación. 1. `provisioning_parameters.json`: este es un [Formulario de configuración para provisioning\$1parameters.json](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-provisioning-forms-slurm). El script `on_create.sh` busca este archivo JSON y define la variable de entorno para identificar la ruta al mismo. A través de este archivo JSON, puede configurar los nodos de Slurm y las opciones de almacenamiento, como Amazon FSx for Lustre for Slurm, con los que comunicarse. En`provisioning_parameters.json`, asegúrate de asignar los grupos de instancias del HyperPod clúster a los nodos de Slurm con los nombres que especificaste en `create_cluster.json` función de cómo planeas configurarlos. En el siguiente diagrama, se muestra un ejemplo de cómo se `provisioning_parameters.json` deben escribir los dos archivos `create_cluster.json` de configuración de JSON para asignar grupos de HyperPod instancias a los nodos de Slurm. En este ejemplo, asumimos que se configuran tres nodos de Slurm: el nodo controlador (de administración), el nodo de inicio de sesión (que es opcional) y el nodo de computación (de trabajo). **sugerencia** Para ayudarte a validar estos dos archivos JSON, el equipo de HyperPod servicio proporciona un script de validación,. [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/validate-config.py](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/validate-config.py) Para obtener más información, consulte [Validar los archivos de configuración JSON antes de crear un clúster de Slurm en HyperPod](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-validate-json-files.md). ![\[Comparación directa entre archivos .json.\]](http://docs.aws.amazon.com/es_es/sagemaker/latest/dg/images/hyperpod-lifecycle-slurm-config.png) ***Figura:** Comparación directa entre la creación `create_cluster.json` de HyperPod clústeres y la configuración `provisiong_params.json` de Slurm. El número de grupos de instancias en `create_cluster.json` debe coincidir con el número de nodos que desea configurar como nodos de Slurm. En el caso del ejemplo de la figura, se configurarán tres nodos de Slurm en un HyperPod clúster de tres grupos de instancias. Debes asignar los grupos de instancias del HyperPod clúster a los nodos de Slurm especificando los nombres de los grupos de instancias en consecuencia.* 1. `resource_config.json`— Durante la creación del clúster, el `lifecycle_script.py` script se escribe esperando un `resource_config.json` archivo del mismo. HyperPod Este archivo contiene información sobre el clúster, como los tipos de instancias y las direcciones IP. Al ejecutar la `CreateCluster` API, HyperPod crea un archivo de configuración de recursos en `/opt/ml/config/resource_config.json` función del `create_cluster.json` archivo. La ruta del archivo se guarda en la variable de entorno denominada `SAGEMAKER_RESOURCE_CONFIG_PATH`. **importante** La HyperPod plataforma genera automáticamente el `resource_config.json` archivo y NO es necesario que lo cree. El siguiente código sirve para mostrar un ejemplo del archivo `resource_config.json` que se crearía a partir de la creación de un clúster en función del archivo `create_cluster.json` del paso anterior. Además, le ayudará a entender qué ocurre en el backend y qué aspecto tendría un archivo `resource_config.json` generado automáticamente. ``` { "ClusterConfig": { "ClusterArn": "arn:aws:sagemaker:us-west-2:111122223333:cluster/abcde01234yz", "ClusterName": "your-hyperpod-cluster" }, "InstanceGroups": [ { "Name": "controller-machine", "InstanceType": "ml.c5.xlarge", "Instances": [ { "InstanceName": "controller-machine-1", "AgentIpAddress": "111.222.333.444", "CustomerIpAddress": "111.222.333.444", "InstanceId": "i-12345abcedfg67890" } ] }, { "Name": "login-group", "InstanceType": "ml.m5.xlarge", "Instances": [ { "InstanceName": "login-group-1", "AgentIpAddress": "111.222.333.444", "CustomerIpAddress": "111.222.333.444", "InstanceId": "i-12345abcedfg67890" } ] }, { "Name": "compute-nodes", "InstanceType": "ml.trn1.32xlarge", "Instances": [ { "InstanceName": "compute-nodes-1", "AgentIpAddress": "111.222.333.444", "CustomerIpAddress": "111.222.333.444", "InstanceId": "i-12345abcedfg67890" }, { "InstanceName": "compute-nodes-2", "AgentIpAddress": "111.222.333.444", "CustomerIpAddress": "111.222.333.444", "InstanceId": "i-12345abcedfg67890" }, { "InstanceName": "compute-nodes-3", "AgentIpAddress": "111.222.333.444", "CustomerIpAddress": "111.222.333.444", "InstanceId": "i-12345abcedfg67890" }, { "InstanceName": "compute-nodes-4", "AgentIpAddress": "111.222.333.444", "CustomerIpAddress": "111.222.333.444", "InstanceId": "i-12345abcedfg67890" } ] } ] } ``` 1. `lifecycle_script.py`— Este es el script principal de Python que ejecuta colectivamente los scripts del ciclo de vida que configuran Slurm en el HyperPod clúster mientras se aprovisiona. Este script lee en `provisioning_parameters.json` y `resource_config.json` desde las rutas especificadas o identificadas en `on_create.sh`, pasa la información relevante a cada script de ciclo de vida y, a continuación, ejecuta los scripts de ciclo de vida en orden. Los scripts de ciclo de vida son un conjunto de scripts que puede personalizar con total flexibilidad para instalar paquetes de software y establecer las configuraciones necesarias o personalizadas durante la creación del clúster, como la configuración de Slurm, la creación de usuarios o la instalación de Conda o Docker. El [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/lifecycle_script.py](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/lifecycle_script.py)script de ejemplo está preparado para ejecutar otros scripts de ciclo de vida básicos en el repositorio, como el lanzamiento de Slurm deamons () [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/start_slurm.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/start_slurm.sh), el montaje de Amazon FSx for Lustre () y la configuración de la contabilidad de MariaDB ([https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/mount_fsx.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/mount_fsx.sh)) y la contabilidad de RDS (). [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/setup_mariadb_accounting.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/setup_mariadb_accounting.sh) También puede añadir más scripts, empaquetarlos en el mismo directorio y añadir líneas de código para que puedan ejecutarse. `lifecycle_script.py` HyperPod Para obtener más información sobre los scripts básicos del ciclo de vida, consulte también los [scripts del ciclo de vida 3.1](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod#31-lifecycle-scripts) en el * GitHub repositorio de Awsome Distributed Training*. **nota** HyperPod se ejecuta [SageMaker HyperPod DLAMI](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-hyperpod-ami) en cada instancia de un clúster y la AMI tiene paquetes de software preinstalados que cumplen las compatibilidades entre ellos y HyperPod las funcionalidades. Tenga en cuenta que si reinstala alguno de los paquetes preinstalados, usted es responsable de instalar los paquetes compatibles y tenga en cuenta que es posible que algunas HyperPod funcionalidades no funcionen del modo esperado. Además de las configuraciones predeterminadas, en la carpeta [https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/utils](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/utils) hay más scripts para instalar el siguiente software. El archivo `lifecycle_script.py` ya está preparado para incluir líneas de código para ejecutar los scripts de instalación, así que consulte los siguientes elementos para buscar esas líneas y quitar las marcas de comentario para activarlas. 1. Las siguientes líneas de código sirven para instalar [Docker](https://www.docker.com/), [Enroot](https://github.com/NVIDIA/enroot) y [Pyxis](https://github.com/NVIDIA/pyxis). Estos paquetes son necesarios para ejecutar contenedores de Docker en un clúster de Slurm. Para habilitar este paso de instalación, defina el parámetro `enable_docker_enroot_pyxis` para `True` en el archivo [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/config.py](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/config.py). ``` # Install Docker/Enroot/Pyxis if Config.enable_docker_enroot_pyxis: ExecuteBashScript("./utils/install_docker.sh").run() ExecuteBashScript("./utils/install_enroot_pyxis.sh").run(node_type) ``` 1. Puede integrar su HyperPod clúster con [Amazon Managed Service for Prometheus](https://docs.aws.amazon.com/prometheus/latest/userguide/what-is-Amazon-Managed-Service-Prometheus.html) [y Amazon Managed](https://docs.aws.amazon.com/grafana/latest/userguide/what-is-Amazon-Managed-Service-Grafana.html) Grafana para exportar métricas HyperPod sobre el clúster y los nodos del clúster a los paneles de Amazon Managed Grafana. Para exportar métricas y usar el [panel de Slurm](https://grafana.com/grafana/dashboards/4323-slurm-dashboard/), el [panel de NVIDIA DCGM Exporter](https://grafana.com/grafana/dashboards/12239-nvidia-dcgm-exporter-dashboard/) y el [panel de métricas de EFA](https://grafana.com/grafana/dashboards/20579-efa-metrics-dev/) en Amazon Managed Grafana, debe instalar el [exportador de Slurm para Prometheus](https://github.com/vpenso/prometheus-slurm-exporter), el [exportador de NVIDIA DCGM](https://github.com/NVIDIA/dcgm-exporter) y el [exportador de nodos de EFA](https://github.com/aws-samples/awsome-distributed-training/blob/main/4.validation_and_observability/3.efa-node-exporter/README.md). Para obtener más información sobre la instalación de los paquetes de exportador y el uso de los paneles de Grafana en un espacio de trabajo de Amazon Managed Grafana, consulte [SageMaker HyperPod monitoreo de recursos de clústeres](sagemaker-hyperpod-cluster-observability-slurm.md). Para habilitar este paso de instalación, defina el parámetro `enable_observability` para `True` en el archivo [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/config.py](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/config.py). ``` # Install metric exporting software and Prometheus for observability if Config.enable_observability: if node_type == SlurmNodeType.COMPUTE_NODE: ExecuteBashScript("./utils/install_docker.sh").run() ExecuteBashScript("./utils/install_dcgm_exporter.sh").run() ExecuteBashScript("./utils/install_efa_node_exporter.sh").run() if node_type == SlurmNodeType.HEAD_NODE: wait_for_scontrol() ExecuteBashScript("./utils/install_docker.sh").run() ExecuteBashScript("./utils/install_slurm_exporter.sh").run() ExecuteBashScript("./utils/install_prometheus.sh").run() ``` 1. Asegúrese de cargar todos los archivos de configuración y los scripts de configuración del **Paso 2** en el bucket de S3 que haya indicado en la solicitud `CreateCluster` del **paso 1**. Por ejemplo, supongamos que su solicitud `create_cluster.json` tiene lo siguiente. ``` "LifeCycleConfig": { "SourceS3URI": "s3://sagemaker-hyperpod-lifecycle/src", "OnCreate": "on_create.sh" } ``` En este caso, `"s3://sagemaker-hyperpod-lifecycle/src"` debería contener `on_create.sh`, `lifecycle_script.py`, `provisioning_parameters.json` y todos los demás scripts de configuración. Suponga que ha preparado los archivos en una carpeta local de la siguiente manera. ``` └── lifecycle_files // your local folder ├── provisioning_parameters.json ├── on_create.sh ├── lifecycle_script.py └── ... // more setup scrips to be fed into lifecycle_script.py ``` Para cargar los archivos, utilice el comando de S3 de la siguiente manera. ``` aws s3 cp --recursive ./lifecycle_scripts s3://sagemaker-hyperpod-lifecycle/src ``` # Qué configuraciones específicas se administran en los archivos de configuración HyperPod de Slurm Al crear un clúster de Slurm en HyperPod, el HyperPod agente configura los [https://slurm.schedmd.com/gres.conf.html](https://slurm.schedmd.com/gres.conf.html)archivos [https://slurm.schedmd.com/slurm.conf.html](https://slurm.schedmd.com/slurm.conf.html)y `/opt/slurm/etc/` para gestionar el clúster de Slurm en función de la solicitud de creación del clúster y de los scripts HyperPod del ciclo de vida. La siguiente lista muestra qué parámetros específicos gestiona y sobrescribe el HyperPod agente. **importante** Se recomienda encarecidamente **no** cambiar estos parámetros gestionados por HyperPod. + En [https://slurm.schedmd.com/slurm.conf.html](https://slurm.schedmd.com/slurm.conf.html), HyperPod configura los siguientes parámetros básicos: `ClusterName``SlurmctldHost`,`PartitionName`, y`NodeName`. Además, para habilitar la [Recuperación automática de nodos y reanudación automática](sagemaker-hyperpod-resiliency-slurm-auto-resume.md) funcionalidad, HyperPod requiere que los `SchedulerParameters` parámetros `TaskPlugin` y estén configurados de la siguiente manera. El HyperPod agente configura estos dos parámetros con los valores necesarios de forma predeterminada. ``` TaskPlugin=task/none SchedulerParameters=permit_job_expansion ``` + En [https://slurm.schedmd.com/gres.conf.html](https://slurm.schedmd.com/gres.conf.html), HyperPod gestiona `NodeName` los nodos de la GPU. # Registra rotaciones de Slurm SageMaker HyperPod proporciona una rotación automática de registros para los registros de los daemon de Slurm para ayudar a administrar el uso del espacio en disco y mantener el rendimiento del sistema. La rotación de registros es crucial para evitar que los registros consuman demasiado espacio en el disco y garantizar un funcionamiento óptimo del sistema, ya que archiva y elimina automáticamente los archivos de registro antiguos y, al mismo tiempo, conserva la información de registro reciente. Las rotaciones de registros de Slurm están habilitadas de forma predeterminada al crear un clúster. ## Cómo funciona la rotación de registros Cuando está habilitada, la configuración de rotación de registros: + Supervisa todos los archivos de registro de Slurm con la extensión `.log` ubicada en la `/var/log/slurm/` carpeta de los nodos de controlador, inicio de sesión y cómputo. + Rota los registros cuando alcanzan un tamaño de 50 MB. + Mantiene hasta dos archivos de registro rotados antes de eliminarlos. + Envía SIGUSR2 una señal a los demonios de Slurm (`slurmctld``slurmd`, y) tras la rotación. `slurmdbd` ## Lista de archivos de registro rotados Los registros de Slurm se encuentran en el directorio. `/var/log/slurm/` La rotación de registros está habilitada para todos los archivos que coincidan. `/var/log/slurm/*.log` Cuando se produce la rotación, los archivos girados tienen sufijos numéricos (por ejemplo,). `slurmd.log.1` La siguiente lista no es exhaustiva, pero muestra algunos de los archivos de registro críticos que giran automáticamente: + `/var/log/slurm/slurmctld.log` + `/var/log/slurm/slurmd.log` + `/var/log/slurm/slurmdb.log` + `/var/log/slurm/slurmrestd.log` ## Habilite o deshabilite la rotación de registros Puede controlar la función de rotación de registros mediante el `enable_slurm_log_rotation` parámetro del `config.py` script de los scripts del ciclo de vida de su clúster, como se muestra en el siguiente ejemplo: ``` class Config: # Set false if you want to disable log rotation of Slurm daemon logs enable_slurm_log_rotation = True # Default value ``` Para deshabilitar la rotación de registros, defina el parámetro en`False`, como se muestra en el siguiente ejemplo: ``` enable_slurm_log_rotation = False ``` **nota** Los scripts del ciclo de vida se ejecutan en todos los nodos de Slurm (nodos de controlador, inicio de sesión y procesamiento) durante la creación del clúster. También se ejecutan en nodos nuevos cuando se agregan al clúster. La actualización de las configuraciones de rotación de registros debe realizarse manualmente después de la creación del clúster. La configuración de rotación del registro se almacena en`/etc/logrotate.d/sagemaker-hyperpod-slurm`. Se recomienda mantener habilitada la rotación de registros para evitar que los archivos de registro consuman demasiado espacio en disco. Para deshabilitar la rotación de registros, elimine el `sagemaker-hyperpod-slurm` archivo o comente su contenido añadiéndolo `#` al principio de cada línea del `sagemaker-hyperpod-slurm` archivo. ## Configuración de rotación de registros predeterminada Los siguientes ajustes se configuran automáticamente para cada archivo de registro que se rota: | Opción | Valor | Description (Descripción) | | --- | --- | --- | | rotate | 2 | Número de archivos de registro rotados que se deben conservar | | size | 50 MB | Tamaño máximo antes de la rotación | | copytruncate | enabled | Copia y trunca el archivo de registro original | | compress | disabled | Los registros rotados no se comprimen | | missingok | enabled | No hay error si falta el archivo de registro | | notifempty | enabled | No gira los archivos vacíos | | noolddir | enabled | Los archivos rotados permanecen en el mismo directorio | # Montaje de Amazon FSx for Lustre y Amazon FSx for OpenZFS en un clúster HyperPod Para montar un sistema de archivos compartidos de Amazon FSx for Lustre en su HyperPod clúster, configure lo siguiente. 1. Utilice su Amazon VPC. 1. Para que las instancias de HyperPod clúster se comuniquen dentro de su VPC, asegúrese de asociarlas [Configuración SageMaker HyperPod con una Amazon VPC personalizada](sagemaker-hyperpod-prerequisites.md#sagemaker-hyperpod-prerequisites-optional-vpc) a la función de IAM para. SageMaker HyperPod 1. En `create_cluster.json`, incluya la siguiente información de la VPC. ``` "VpcConfig": { "SecurityGroupIds": [ "string" ], "Subnets": [ "string" ] } ``` Para obtener más consejos sobre cómo configurar Amazon VPC, consulte [Requisitos previos para su uso SageMaker HyperPod](sagemaker-hyperpod-prerequisites.md). 1. Para terminar de configurar Slurm con Amazon FSx for Lustre, puede utilizar uno de los siguientes enfoques. Puedes encontrar la FSx información de Amazon en la consola Amazon FSx for Lustre de tu cuenta o ejecutando el siguiente AWS CLI comando,`aws fsx describe-file-systems`. **Opción A: configuración basada en API (recomendada)** Especifica la FSx configuración de Amazon directamente en la carga útil de la CreateCluster API desde cada grupo de instancias. `InstanceStorageConfigs` Este enfoque es compatible tanto FSx con Lustre como con OpenZFS, y FSx permite la configuración. per-instance-group FSx ``` "InstanceStorageConfigs": [ { "FsxLustreConfig": { "DnsName": "fs-12345678a90b01cde.fsx.us-west-2.amazonaws.com", "MountPath": "/fsx", "MountName": "1abcdefg" } } ] ``` FSx Para OpenZFS, utilice en su lugar: `FsxOpenZfsConfig` ``` "InstanceStorageConfigs": [ { "FsxOpenZfsConfig": { "DnsName": "fs-12345678a90b01cde.fsx.us-west-2.amazonaws.com", "MountPath": "/fsx-openzfs" } } ] ``` Para obtener más información, consulte [Cómo empezar a SageMaker HyperPod usar la AWS CLI](sagemaker-hyperpod-quickstart.md). **Opción B: configuración antigua** Especifique el nombre FSx DNS de Amazon y el nombre de FSx montaje de Amazon `provisioning_parameters.json` como se muestra en la figura de la [Los scripts de ciclo de vida básicos proporcionados por HyperPod](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-base-config.md) sección. ``` "fsx_dns_name": "fs-12345678a90b01cde.fsx.us-west-2.amazonaws.com", "fsx_mountname": "1abcdefg" ``` # Validar los archivos de configuración JSON antes de crear un clúster de Slurm en HyperPod Para validar los archivos de configuración JSON antes de enviar una solicitud de creación de clúster, utilice el script de validación de la configuración [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/validate-config.py](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/validate-config.py). Este script analiza y compara el archivo JSON de configuración del HyperPod clúster y el archivo JSON de configuración de Slurm, e identifica si hay algún error de configuración de los recursos entre los dos archivos y también entre los recursos de Amazon EC2, Amazon VPC y Amazon. FSx Por ejemplo, para validar los archivos `create_cluster.json` y `provisioning_parameters.json` de la sección [Los scripts de ciclo de vida básicos proporcionados por HyperPod](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-base-config.md), ejecute el script de validación de la siguiente manera. ``` python3 validate-config.py --cluster-config create_cluster.json --provisioning-parameters provisioning_parameters.json ``` A continuación, se muestra un ejemplo del resultado de una validación correcta. ``` ✔️ Validated instance group name worker-group-1 is correct ... ✔️ Validated subnet subnet-012345abcdef67890 ... ✔️ Validated security group sg-012345abcdef67890 ingress rules ... ✔️ Validated security group sg-012345abcdef67890 egress rules ... ✔️ Validated FSx Lustre DNS name fs-012345abcdef67890.fsx.us-east-1.amazonaws.com ✔️ Validated FSx Lustre mount name abcdefgh ✅ Cluster Validation succeeded ``` # Validar el tiempo de ejecución antes de ejecutar las cargas de trabajo de producción en un clúster de Slurm HyperPod Para comprobar el tiempo de ejecución antes de ejecutar cualquier carga de trabajo de producción en un clúster de Slurm HyperPod, utilice el script de validación del tiempo de ejecución. [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/hyperpod-precheck.py](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/hyperpod-precheck.py) Este script comprueba si el clúster de Slurm tiene todos los paquetes instalados para ejecutar Docker, si el clúster tiene un sistema de archivos correctamente montado FSx para Lustre y un directorio de usuarios que comparte el sistema de archivos, y si el deamon de Slurm se ejecuta en todos los nodos de cómputo. Para ejecutar el script en varios nodos a la vez, utilice `srun` de la forma que se indica en el siguiente comando de ejemplo para ejecutar el script en un clúster de Slurm de 8 nodos. ``` # The following command runs on 8 nodes srun -N 8 python3 hyperpod-precheck.py ``` **nota** Para obtener más información sobre el script de validación, por ejemplo, qué funciones de validación en tiempo de ejecución proporciona el script y pautas para resolver los problemas que no superan las validaciones, consulte [Validación en tiempo de ejecución antes de ejecutar cargas](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod#35-runtime-validation-before-running-workloads) de trabajo en el * GitHub repositorio de Awsome Distributed Training*. # Desarrollar scripts de ciclo de vida de forma interactiva en un nodo de clúster HyperPod En esta sección se explica cómo puede desarrollar scripts de ciclo de vida de forma interactiva sin tener que crear y eliminar un HyperPod clúster de forma repetida. 1. Cree un HyperPod clúster con los scripts de ciclo de vida básicos. 1. Inicie sesión en un nodo del clúster. 1. Desarrolle un script (`configure_xyz.sh`) editándolo y ejecutándolo repetidamente en el nodo. 1. HyperPod ejecuta los scripts del ciclo de vida como usuario root, por lo que le recomendamos que los ejecute `configure_xyz.sh` como usuario root durante el desarrollo para asegurarse de que el script se prueba en las mismas condiciones mientras se ejecuta HyperPod. 1. Integre el script en `lifecycle_script.py` añadiendo una línea de código similar a la siguiente. ``` ExecuteBashScript("./utils/configure_xyz.sh").run() ``` 1. Cargue los scripts de ciclo de vida actualizados en el bucket de S3 que utilizó inicialmente para cargar los scripts de ciclo de vida básicos. 1. Pruebe la versión integrada de `lifecycle_script.py` creando un HyperPod clúster nuevo. También puede utilizar el reemplazo manual de instancias para probar los scripts de ciclo de vida actualizados mediante la creación de nuevas instancias. Para obtener instrucciones detalladas, consulta [Reemplazar manualmente un nodo](https://docs.aws.amazon.com//sagemaker/latest/dg/sagemaker-hyperpod-resiliency-slurm-replace-faulty-instance.html#sagemaker-hyperpod-resiliency-slurm-replace-faulty-instance-replace). Tenga en cuenta que solo los nodos de trabajo son reemplazables.