As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá. # Personalização de SageMaker HyperPod clusters usando scripts de ciclo de vida SageMaker HyperPod oferece sempre clusters de up-and-running computação, que são altamente personalizáveis, pois você pode escrever scripts de ciclo de vida para informar SageMaker HyperPod como configurar os recursos do cluster. Os tópicos a seguir são as melhores práticas para preparar scripts de ciclo de vida para configurar SageMaker HyperPod clusters com ferramentas de gerenciamento de carga de trabalho de código aberto. Os tópicos a seguir discutem as melhores práticas detalhadas para preparar scripts de ciclo de vida para configurar as configurações do Slurm. SageMaker HyperPod ## Uma visão geral de alto nível O procedimento a seguir é o fluxo principal de provisionamento de um HyperPod cluster e sua configuração com o Slurm. As etapas são colocadas na ordem de uma abordagem de ***baixo para cima***. 1. Planeje como você deseja criar nós do Slurm em um HyperPod cluster. Por exemplo, se você quiser configurar dois nós do Slurm, precisará configurar dois grupos de instâncias em um HyperPod cluster. 1. Prepare a configuração do Slurm. Escolha uma das seguintes abordagens: + **Opção A: configuração orientada por API (recomendada)** — defina os tipos de nós e partições do Slurm diretamente na carga da `CreateCluster` API usando dentro de cada grupo de instâncias. `SlurmConfig` Com essa abordagem: + Nenhum `provisioning_parameters.json` arquivo é necessário + A topologia do Slurm é definida na carga útil da API junto com as definições do grupo de instâncias + FSx os sistemas de arquivos são configurados via per-instance-group `InstanceStorageConfigs` + A estratégia de configuração é controlada via `Orchestrator.Slurm.SlurmConfigStrategy` Exemplo `SlurmConfig` em um grupo de instâncias: ``` { "InstanceGroupName": "gpu-compute", "InstanceType": "ml.p4d.24xlarge", "InstanceCount": 8, "SlurmConfig": { "NodeType": "Compute", "PartitionNames": ["gpu-training"] } } ``` + **Opção B: Configuração legada** — Prepare um `provisioning_parameters.json` arquivo, que é um[Formulário de configuração para provisioning\$1parameters.json](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-provisioning-forms-slurm). `provisioning_parameters.json`deve conter informações de configuração do nó Slurm a serem provisionadas no cluster. HyperPod Isso deve refletir o design dos nós do Slurm da Etapa 1. 1. Prepare um conjunto de scripts de ciclo de vida para configurar o Slurm on HyperPod para instalar pacotes de software e configurar um ambiente no cluster para seu caso de uso. Você deve estruturar os scripts de ciclo de vida para serem executados coletivamente em um script Python central (`lifecycle_script.py`) e escrever um script de shell de ponto de entrada (`on_create.sh`) para executar o script Python. O script de shell do ponto de entrada é o que você precisa fornecer para uma solicitação de criação de HyperPod cluster posteriormente na Etapa 5. Além disso, observe que você deve escrever os scripts para esperar `resource_config.json` que sejam gerados HyperPod durante a criação do cluster. `resource_config.json`contém informações de recursos do HyperPod cluster, como endereços IP, tipos de instância e ARNs, e é o que você precisa usar para configurar o Slurm. 1. Reúna todos os arquivos das etapas anteriores em uma pasta. A estrutura da pasta depende da abordagem de configuração selecionada na Etapa 2. Se você selecionou a Opção A (configuração baseada em API): Sua pasta só precisa de scripts de ciclo de vida para tarefas de configuração personalizadas. A configuração e FSx montagem do Slurm são feitas automaticamente com HyperPod base na carga útil da API. ``` └── lifecycle_files // your local folder ├── on_create.sh ├── lifecycle_script.py └── ... // more setup scripts to be fed into lifecycle_script.py ``` **nota** O `provisioning_parameters.json` arquivo não é necessário ao usar a configuração orientada por API. Se você selecionou a Opção B (configuração antiga): Sua pasta deve incluir `provisioning_parameters.json` o conjunto completo de scripts de 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. Faça upload de todos os arquivos em um bucket do S3. Copie e mantenha o caminho do bucket do S3. Observe que você deve criar um caminho de bucket do S3 começando com `sagemaker-` porque precisa escolher um [Função do IAM para SageMaker HyperPod](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-role-for-hyperpod) anexo com [`AmazonSageMakerClusterInstanceRolePolicy`](security-iam-awsmanpol-AmazonSageMakerClusterInstanceRolePolicy.md), que só permite caminhos do bucket do S3 começando com o prefixo `sagemaker-`. O comando a seguir é um exemplo de comando para carregar todos os arquivos em um bucket do S3. ``` aws s3 cp --recursive ./lifecycle_files s3://sagemaker-hyperpod-lifecycle/src ``` 1. Prepare uma solicitação de criação de HyperPod cluster. + Opção 1: se você usar o AWS CLI, escreva uma solicitação de criação de cluster no formato JSON (`create_cluster.json`) seguindo as instruções em[Criar um novo cluster](sagemaker-hyperpod-operate-slurm-cli-command.md#sagemaker-hyperpod-operate-slurm-cli-command-create-cluster). + Opção 2: se você usa a interface de usuário do console SageMaker AI, preencha o formulário de solicitação de **criação de um cluster** na interface do usuário do HyperPod console seguindo as instruções em[Crie um SageMaker HyperPod cluster](sagemaker-hyperpod-operate-slurm-console-ui.md#sagemaker-hyperpod-operate-slurm-console-ui-create-cluster). Nesse estágio, certifique-se de criar grupos de instâncias na mesma estrutura planejada nas etapas 1 e 2. Além disso, especifique o bucket do S3 da Etapa 5 nos formulários de solicitação. 1. Envie a solicitação de criação do cluster. HyperPod provisiona um cluster com base na solicitação e, em seguida, cria um `resource_config.json` arquivo nas instâncias do HyperPod cluster e configura o Slurm no cluster que executa os scripts de ciclo de vida. Os tópicos a seguir explicam e aprofundam os detalhes sobre como organizar arquivos de configuração e scripts de ciclo de vida para que funcionem adequadamente durante a criação do HyperPod cluster. **Topics** + [Uma visão geral de alto nível](#sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-highlevel-overview) + [Scripts básicos de ciclo de vida fornecidos por HyperPod](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-base-config.md) + [Quais configurações específicas HyperPod gerenciam nos arquivos de configuração do Slurm](sagemaker-hyperpod-lifecycle-best-practices-slurm-what-hyperpod-overrides-in-slurm-conf.md) + [Rotações do Slurm log](sagemaker-hyperpod-slurm-log-rotation.md) + [Montando o Amazon FSx for Lustre e o Amazon FSx for OpenZFS em um cluster HyperPod](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-setup-with-fsx.md) + [Validando os arquivos de configuração JSON antes de criar um cluster Slurm no HyperPod](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-validate-json-files.md) + [Validando o tempo de execução antes de executar cargas de trabalho de produção em um HyperPod cluster Slurm](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-validate-runtime.md) + [Desenvolvendo scripts de ciclo de vida de forma interativa em um nó de cluster HyperPod](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-develop-lifecycle-scripts.md) # Scripts básicos de ciclo de vida fornecidos por HyperPod Esta seção mostra cada componente do fluxo básico de configuração do Slurm on HyperPod em uma abordagem de ***cima para baixo***. Ele começa com a preparação de uma solicitação de criação de HyperPod cluster para executar a `CreateCluster` API e se aprofunda na estrutura hierárquica até os scripts de ciclo de vida. Use os exemplos de scripts de ciclo de vida fornecidos no repositório do [Awsome Distributed Training](https://github.com/aws-samples/awsome-distributed-training/). GitHub Clone repositório executando o comando a seguir. ``` git clone https://github.com/aws-samples/awsome-distributed-training/ ``` Os scripts básicos do ciclo de vida para configurar um cluster Slurm estão disponíveis em SageMaker HyperPod . [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 ``` O fluxograma a seguir mostra uma visão geral detalhada de como você deve criar os scripts básicos do ciclo de vida. As descrições abaixo do diagrama e do guia de procedimentos explicam como eles funcionam durante a chamada da HyperPod `CreateCluster` API. ![\[Um fluxograma detalhado da criação do HyperPod cluster e da estrutura dos scripts do ciclo de vida.\]](http://docs.aws.amazon.com/pt_br/sagemaker/latest/dg/images/hyperpod-lifecycle-structure.png) ***Figura:** Um fluxograma detalhado da criação do HyperPod cluster e da estrutura dos scripts do ciclo de vida. (1) As setas tracejadas são direcionadas para onde as caixas são “chamadas” e mostram o fluxo dos arquivos de configuração e a preparação dos scripts do ciclo de vida. Tudo começa com a preparação do `provisioning_parameters.json` e os scripts do ciclo de vida. São então codificados em `lifecycle_script.py` para uma execução coletiva em ordem. E a execução do `lifecycle_script.py` script é feita pelo script `on_create.sh` shell, que deve ser executado no terminal da HyperPod instância. (2) As setas sólidas mostram o fluxo principal de criação do HyperPod cluster e como as caixas são “chamadas para” ou “enviadas para”. `on_create.sh`é necessário para a solicitação de criação de cluster, no formulário Criar uma solicitação de **cluster `create_cluster.json` ou no formulário Criar uma** solicitação de cluster na interface do console. Depois de enviar a solicitação, HyperPod executa a `CreateCluster` API com base nas informações de configuração fornecidas pela solicitação e nos scripts do ciclo de vida. (3) A seta pontilhada indica que a HyperPod plataforma cria `resource_config.json` nas instâncias do cluster durante o provisionamento de recursos do cluster. `resource_config.json`contém informações sobre os recursos do HyperPod cluster, como o ARN do cluster, os tipos de instância e os endereços IP. É importante observar que você deve preparar os scripts de ciclo de vida para esperar o arquivo `resource_config.json` durante a criação do cluster. Para mais informações, consulte o guia de procedimentos abaixo.* O guia de procedimentos a seguir explica o que acontece durante a criação HyperPod do cluster e como os scripts básicos do ciclo de vida são projetados. 1. `create_cluster.json`— Para enviar uma solicitação de criação de HyperPod cluster, você prepara um arquivo de `CreateCluster` solicitação no formato JSON. Neste exemplo de práticas recomendadas, presumimos que o arquivo de solicitação tenha um nome`create_cluster.json`. Escreva `create_cluster.json` para provisionar um HyperPod cluster com grupos de instâncias. A melhor prática é adicionar o mesmo número de grupos de instâncias que o número de nós do Slurm que você planeja configurar no HyperPod cluster. Certifique-se de dar nomes distintos aos grupos de instâncias que você atribuirá aos nós do Slurm que você planeja configurar. Além disso, é necessário especificar um caminho de bucket do S3 para armazenar todo o conjunto de arquivos de configuração e scripts de ciclo de vida no nome do campo `InstanceGroups.LifeCycleConfig.SourceS3Uri` no formulário de `CreateCluster` solicitação e especificar o nome do arquivo de um script de shell de ponto de entrada (suponha que ele seja nomeado `on_create.sh`) para `InstanceGroups.LifeCycleConfig.OnCreate`. **nota** Se você estiver usando o formulário de envio **Criar um cluster** na interface do HyperPod console, o console gerencia o preenchimento e o envio da `CreateCluster` solicitação em seu nome e executa a `CreateCluster` API no back-end. Nesse caso, você não precisa criar`create_cluster.json`; em vez disso, certifique-se de especificar as informações corretas de configuração do cluster no formulário de envio **Criar um cluster**. 1. `on_create.sh`— Para cada grupo de instâncias, você precisa fornecer um script de shell de ponto de entrada, executar comandos`on_create.sh`, executar scripts para instalar pacotes de software e configurar o ambiente de HyperPod cluster com o Slurm. As duas coisas que você precisa preparar são uma `provisioning_parameters.json` exigência HyperPod para configurar o Slurm e um conjunto de scripts de ciclo de vida para instalar pacotes de software. Esse script deve ser escrito para localizar e executar os seguintes arquivos, conforme mostrado no script de amostra em [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** Certifique-se de carregar todo o conjunto de scripts de ciclo de vida no local do S3 especificado `create_cluster.json`. Você também deve colocar o seu `provisioning_parameters.json` no mesmo local. 1. `provisioning_parameters.json`: Isso é um [Formulário de configuração para provisioning\$1parameters.json](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-provisioning-forms-slurm). O script `on_create.sh` encontra esse arquivo JSON e define a variável de ambiente para identificar o caminho até ele. Por meio desse arquivo JSON, você pode configurar os nós do Slurm e as opções de armazenamento, como o Amazon FSx for Lustre for Slurm, com os quais se comunicar. Em`provisioning_parameters.json`, certifique-se de atribuir os grupos de instâncias do HyperPod cluster usando os nomes que você especificou nos `create_cluster.json` nós do Slurm de forma adequada, com base em como você planeja configurá-los. O diagrama a seguir mostra um exemplo de como os dois arquivos de configuração JSON `provisioning_parameters.json` devem ser `create_cluster.json` gravados para atribuir grupos de HyperPod instâncias aos nós do Slurm. Neste exemplo, assumimos um caso de configuração de três nós do Slurm: nó controlador (gerenciamento), nó de login (que é opcional) e nó (de processamento) computacional. **dica** Para ajudá-lo a validar esses dois arquivos JSON, a equipe de HyperPod serviço fornece um script de validação,. [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 saber mais, consulte [Validando os arquivos de configuração JSON antes de criar um cluster Slurm no HyperPod](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-validate-json-files.md). ![\[Comparação direta entre arquivos.json.\]](http://docs.aws.amazon.com/pt_br/sagemaker/latest/dg/images/hyperpod-lifecycle-slurm-config.png) ***Figura:** Comparação direta entre `create_cluster.json` a criação HyperPod do cluster e a configuração `provisiong_params.json` do Slurm. O número de grupos de instâncias `create_cluster.json` deve corresponder ao número de nós que você deseja configurar como nós do Slurm. No caso do exemplo na figura, três nós do Slurm serão configurados em um HyperPod cluster de três grupos de instâncias. Você deve atribuir os grupos de instâncias do HyperPod cluster aos nós do Slurm especificando os nomes dos grupos de instâncias adequadamente.* 1. `resource_config.json`— Durante a criação do cluster, o `lifecycle_script.py` script é escrito para esperar um `resource_config.json` arquivo do HyperPod. Esse arquivo contém informações sobre o cluster, como tipos de instância e endereços IP. Quando você executa a `CreateCluster` API, HyperPod cria um arquivo de configuração de recursos `/opt/ml/config/resource_config.json` com base no `create_cluster.json` arquivo. O caminho do arquivo é salvo na variável de ambiente chamada `SAGEMAKER_RESOURCE_CONFIG_PATH`. **Importante** O `resource_config.json` arquivo é gerado automaticamente pela HyperPod plataforma e você NÃO precisa criá-lo. O código a seguir é para mostrar um exemplo do `resource_config.json` que seria criado a partir da criação do cluster com base no `create_cluster.json` na etapa anterior e para ajudar você a entender o que acontece no backend e como `resource_config.json` seria a aparência de uma geração automática. ``` { "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`— Esse é o script principal do Python que executa coletivamente scripts de ciclo de vida configurando o Slurm no cluster enquanto está sendo provisionado. HyperPod Esse script lê `provisioning_parameters.json` e `resource_config.json` recebe os caminhos especificados ou identificados em `on_create.sh`, passa as informações relevantes para cada script de ciclo de vida e, em seguida, executa os scripts de ciclo de vida em ordem. Os scripts de ciclo de vida são um conjunto de scripts que você tem total flexibilidade para personalizar para instalar pacotes de software e definir as configurações necessárias ou personalizadas durante a criação do cluster, como configurar o Slurm, criar usuários, instalar o Conda ou o Docker. O [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 amostra está preparado para executar outros scripts básicos de ciclo de vida no repositório, como iniciar o 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)), montar o FSx Amazon for Lustre () e configurar a contabilidade do 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)) e a contabilidade do 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) Você também pode adicionar mais scripts, empacotá-los no mesmo diretório e adicionar linhas de código `lifecycle_script.py` para permitir a HyperPod execução dos scripts. Para obter mais informações sobre os scripts de ciclo de vida básicos, consulte também [3.1 Scripts de ciclo de vida no repositório *Awsome* Distributed](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod#31-lifecycle-scripts) Training. GitHub **nota** HyperPod é executado [SageMaker HyperPod DLAMI](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-hyperpod-ami) em cada instância de um cluster, e a AMI tem pacotes de software pré-instalados que atendem às compatibilidades e funcionalidades entre eles. HyperPod Observe que, se você reinstalar qualquer um dos pacotes pré-instalados, você será responsável pela instalação de pacotes compatíveis e observe que algumas HyperPod funcionalidades podem não funcionar conforme o esperado. Além das configurações padrão, mais scripts para instalar o software a seguir estão disponíveis na pasta [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). O arquivo `lifecycle_script.py` já está preparado para incluir linhas de código para a execução dos scripts de instalação, portanto, consulte os itens a seguir para pesquisar essas linhas e descomente-as para ativá-las. 1. As linhas de código a seguir são para instalar o [Docker](https://www.docker.com/), o [Enroot](https://github.com/NVIDIA/enroot) e o [Pyxis](https://github.com/NVIDIA/pyxis). Esses pacotes são necessários para executar contêineres do Docker em um cluster do Slurm. Para ativar essa etapa de instalação, defina o parâmetro `enable_docker_enroot_pyxis` como `True` no arquivo [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. Você pode integrar seu HyperPod cluster ao [Amazon Managed Service for Prometheus [e ao Amazon Managed](https://docs.aws.amazon.com/grafana/latest/userguide/what-is-Amazon-Managed-Service-Grafana.html) Grafana para](https://docs.aws.amazon.com/prometheus/latest/userguide/what-is-Amazon-Managed-Service-Prometheus.html) exportar métricas HyperPod sobre o cluster e os nós do cluster para os painéis do Amazon Managed Grafana. Para exportar métricas e usar o [painel do Slurm](https://grafana.com/grafana/dashboards/4323-slurm-dashboard/), o [painel do Exportador NVIDIA DCGM Exporter](https://grafana.com/grafana/dashboards/12239-nvidia-dcgm-exporter-dashboard/), e o [painel Métricas do EFA](https://grafana.com/grafana/dashboards/20579-efa-metrics-dev/) on Amazon Managed Grafana, é necessário instalar o [exportador do Slurm para o Prometheus](https://github.com/vpenso/prometheus-slurm-exporter), o [exportador NVIDIA DCGM](https://github.com/NVIDIA/dcgm-exporter), e o [exportador de nós EFA](https://github.com/aws-samples/awsome-distributed-training/blob/main/4.validation_and_observability/3.efa-node-exporter/README.md). Para mais informações sobre como instalar os pacotes do exportador e usar os painéis do Grafana em um espaço de trabalho do Amazon Managed Grafana, consulte [SageMaker HyperPod monitoramento de recursos de cluster](sagemaker-hyperpod-cluster-observability-slurm.md). Para ativar essa etapa de instalação, defina o parâmetro `enable_observability` como `True` no arquivo [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. Carregue todos os arquivos e scripts de configuração da **Etapa 2** para o bucket do S3 que você fornece na solicitação `CreateCluster` na **Etapa 1**. Por exemplo, suponha que o seu `create_cluster.json` tenha o seguinte: ``` "LifeCycleConfig": { "SourceS3URI": "s3://sagemaker-hyperpod-lifecycle/src", "OnCreate": "on_create.sh" } ``` Em seguida, o seu `"s3://sagemaker-hyperpod-lifecycle/src"` deve conter `on_create.sh`, `lifecycle_script.py`, `provisioning_parameters.json`, e todos os outros scripts de configuração. Suponha que você tenha preparado os arquivos em uma pasta local da seguinte maneira: ``` └── 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 carregar os arquivos, use o comando S3 da seguinte maneira: ``` aws s3 cp --recursive ./lifecycle_scripts s3://sagemaker-hyperpod-lifecycle/src ``` # Quais configurações específicas HyperPod gerenciam nos arquivos de configuração do Slurm Quando você cria um cluster do Slurm no HyperPod, o HyperPod agente configura os [https://slurm.schedmd.com/gres.conf.html](https://slurm.schedmd.com/gres.conf.html)arquivos [https://slurm.schedmd.com/slurm.conf.html](https://slurm.schedmd.com/slurm.conf.html)e em `/opt/slurm/etc/` para gerenciar o cluster do Slurm com base na solicitação de criação do cluster e nos scripts HyperPod do ciclo de vida. A lista a seguir mostra quais parâmetros específicos o HyperPod agente manipula e substitui. **Importante** É altamente recomendável que você **não** altere esses parâmetros gerenciados pelo HyperPod. + Em [https://slurm.schedmd.com/slurm.conf.html](https://slurm.schedmd.com/slurm.conf.html), HyperPod configura os seguintes parâmetros básicos: `ClusterName` `SlurmctldHost``PartitionName`,, `NodeName` e. Além disso, para ativar a [Recuperação automática de nós e retomada automática](sagemaker-hyperpod-resiliency-slurm-auto-resume.md) funcionalidade, é HyperPod necessário definir `SchedulerParameters` os parâmetros `TaskPlugin` e da seguinte forma. O HyperPod agente configura esses dois parâmetros com os valores necessários por padrão. ``` TaskPlugin=task/none SchedulerParameters=permit_job_expansion ``` + Em [https://slurm.schedmd.com/gres.conf.html](https://slurm.schedmd.com/gres.conf.html), HyperPod gerencia `NodeName` os nós da GPU. # Rotações do Slurm log SageMaker HyperPod fornece rotação automática de registros para registros do daemon do Slurm para ajudar a gerenciar o uso do espaço em disco e manter o desempenho do sistema. A rotação de registros é crucial para evitar que os registros consumam espaço em disco excessivo e garantir a operação ideal do sistema, arquivando e removendo automaticamente arquivos de log antigos, mantendo as informações de registro recentes. As rotações de registros do Slurm são ativadas por padrão quando você cria um cluster. ## Como funciona a rotação de toras Quando ativada, a configuração de rotação de registros: + Monitora todos os arquivos de log do Slurm com a extensão `.log` localizada na `/var/log/slurm/` pasta no controlador, nos nós de login e computação. + Gira os registros quando eles atingem 50 MB de tamanho. + Mantém até dois arquivos de log rotacionados antes de excluí-los. + Envia SIGUSR2 sinal para os daemons do Slurm (`slurmctld`,`slurmd`, e`slurmdbd`) após a rotação. ## Lista de arquivos de log rotacionados Os registros do Slurm estão localizados no `/var/log/slurm/` diretório. A rotação de registros está ativada para todos os arquivos correspondentes`/var/log/slurm/*.log`. Quando a rotação ocorre, os arquivos girados têm sufixos numéricos (como). `slurmd.log.1` A lista a seguir não é exaustiva, mas mostra alguns dos arquivos de log essenciais que giram automaticamente: + `/var/log/slurm/slurmctld.log` + `/var/log/slurm/slurmd.log` + `/var/log/slurm/slurmdb.log` + `/var/log/slurm/slurmrestd.log` ## Ativar ou desativar a rotação de registros Você pode controlar o recurso de rotação de registros usando o `enable_slurm_log_rotation` parâmetro no `config.py` script dos scripts de ciclo de vida do seu cluster, conforme mostrado no exemplo a seguir: ``` class Config: # Set false if you want to disable log rotation of Slurm daemon logs enable_slurm_log_rotation = True # Default value ``` Para desativar a rotação de registros, defina o parâmetro como`False`, conforme mostrado no exemplo a seguir: ``` enable_slurm_log_rotation = False ``` **nota** Os scripts de ciclo de vida são executados em todos os nós do Slurm (controlador, login e nós de computação) durante a criação do cluster. Eles também são executados em novos nós quando adicionados ao cluster. A atualização das configurações de rotação de registros deve ser feita manualmente após a criação do cluster. A configuração de rotação do log é armazenada em`/etc/logrotate.d/sagemaker-hyperpod-slurm`. Recomendamos manter a rotação de registros ativada para evitar que os arquivos de log consumam espaço em disco excessivo. Para desativar a rotação de registros, exclua o `sagemaker-hyperpod-slurm` arquivo ou comente seu conteúdo adicionando `#` no início de cada linha no `sagemaker-hyperpod-slurm` arquivo. ## Configurações padrão de rotação de registros As configurações a seguir são definidas automaticamente para cada arquivo de log rotacionado: | Configuração | Valor | Description | | --- | --- | --- | | rotate | 2 | Número de arquivos de log rotacionados a serem mantidos | | size | 50 MB | Tamanho máximo antes da rotação | | copytruncate | habilitado | Copia e trunca o arquivo de log original | | compress | desabilitado | Os registros girados não são compactados | | missingok | habilitado | Não há erro se o arquivo de log estiver ausente | | notifempty | habilitado | Não gira arquivos vazios | | noolddir | habilitado | Arquivos rotacionados permanecem no mesmo diretório | # Montando o Amazon FSx for Lustre e o Amazon FSx for OpenZFS em um cluster HyperPod Para montar um sistema de arquivos compartilhado Amazon FSx for Lustre em seu HyperPod cluster, configure o seguinte. 1. Use a sua Amazon VPC. 1. Para que as instâncias de HyperPod cluster se comuniquem com sua VPC, certifique-se de anexá-las [Configuração SageMaker HyperPod com uma Amazon VPC personalizada](sagemaker-hyperpod-prerequisites.md#sagemaker-hyperpod-prerequisites-optional-vpc) à função do IAM para. SageMaker HyperPod 1. Em `create_cluster.json`, inclua as informações a seguir. ``` "VpcConfig": { "SecurityGroupIds": [ "string" ], "Subnets": [ "string" ] } ``` Para mais dicas sobre como configurar a Amazon VPC, consulte [Pré-requisitos para usar SageMaker HyperPod](sagemaker-hyperpod-prerequisites.md). 1. Para concluir a configuração do Slurm com o Amazon FSx for Lustre, você pode usar uma das seguintes abordagens. Você pode encontrar as FSx informações da Amazon no console do Amazon FSx for Lustre em sua conta ou executando o seguinte AWS CLI comando,`aws fsx describe-file-systems`. **Opção A: configuração baseada em API (recomendada)** Especifique a FSx configuração da Amazon diretamente na carga da CreateCluster API usando `InstanceStorageConfigs` dentro de cada grupo de instâncias. Essa abordagem é compatível tanto com FSx o Lustre quanto com FSx o OpenZFS e permite a configuração. per-instance-group FSx ``` "InstanceStorageConfigs": [ { "FsxLustreConfig": { "DnsName": "fs-12345678a90b01cde.fsx.us-west-2.amazonaws.com", "MountPath": "/fsx", "MountName": "1abcdefg" } } ] ``` FSx Para OpenZFS, use `FsxOpenZfsConfig` em vez disso: ``` "InstanceStorageConfigs": [ { "FsxOpenZfsConfig": { "DnsName": "fs-12345678a90b01cde.fsx.us-west-2.amazonaws.com", "MountPath": "/fsx-openzfs" } } ] ``` Para obter mais detalhes, consulte [Introdução ao SageMaker HyperPod uso da AWS CLI](sagemaker-hyperpod-quickstart.md). **Opção B: Configuração legada** Especifique o nome do Amazon FSx DNS e o nome da FSx montagem da Amazon `provisioning_parameters.json` conforme mostrado na figura na [Scripts básicos de ciclo de vida fornecidos por HyperPod](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-base-config.md) seção. ``` "fsx_dns_name": "fs-12345678a90b01cde.fsx.us-west-2.amazonaws.com", "fsx_mountname": "1abcdefg" ``` # Validando os arquivos de configuração JSON antes de criar um cluster Slurm no HyperPod Para validar os arquivos de configuração JSON antes de enviar uma solicitação de criação de cluster, use o script de validação de configuração [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). Esse script analisa e compara o arquivo JSON de configuração do HyperPod cluster e o arquivo JSON de configuração do Slurm e identifica se há alguma configuração incorreta de recursos entre os dois arquivos e também entre os recursos do Amazon EC2, Amazon VPC e Amazon. FSx Por exemplo, para validar os arquivos `create_cluster.json` e `provisioning_parameters.json` da seção [Scripts básicos de ciclo de vida fornecidos por HyperPod](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-base-config.md), execute o script de validação da seguinte maneira: ``` python3 validate-config.py --cluster-config create_cluster.json --provisioning-parameters provisioning_parameters.json ``` A seguir, um exemplo de saída de uma validação bem-sucedida. ``` ✔️ 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 ``` # Validando o tempo de execução antes de executar cargas de trabalho de produção em um HyperPod cluster Slurm Para verificar o tempo de execução antes de executar qualquer carga de trabalho de produção em um cluster do Slurm HyperPod, use o script de validação do tempo de execução. [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) Esse script verifica se o cluster Slurm tem todos os pacotes instalados para executar o Docker, se o cluster tem um sistema de arquivos Lustre montado FSx corretamente e um diretório de usuário compartilhando o sistema de arquivos, e se o deamon do Slurm está sendo executado em todos os nós de computação. Para executar o script em vários nós ao mesmo tempo, use `srun` conforme mostrado no exemplo a seguir, o comando de execução do script em um cluster do Slurm de 8 nós. ``` # The following command runs on 8 nodes srun -N 8 python3 hyperpod-precheck.py ``` **nota** Para saber mais sobre o script de validação, como quais funções de validação em tempo de execução o script fornece e diretrizes para resolver problemas que não passam nas validações, consulte [Validação em tempo de execução antes de executar cargas de trabalho](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod#35-runtime-validation-before-running-workloads) no repositório do *Awsome Distributed Training*. GitHub # Desenvolvendo scripts de ciclo de vida de forma interativa em um nó de cluster HyperPod Esta seção explica como você pode desenvolver scripts de ciclo de vida interativamente sem criar e excluir repetidamente um cluster. HyperPod 1. Crie um HyperPod cluster com os scripts básicos do ciclo de vida. 1. Faça login em um nó de cluster. 1. Desenvolva um script (`configure_xyz.sh`) editando-o e executando-o repetidamente no nó. 1. HyperPod executa os scripts de ciclo de vida como usuário raiz, portanto, recomendamos que você execute o `configure_xyz.sh` como usuário raiz durante o desenvolvimento para garantir que o script seja testado sob as mesmas condições durante a execução do. HyperPod 1. Integre o script `lifecycle_script.py` adicionando uma linha de código semelhante à seguinte: ``` ExecuteBashScript("./utils/configure_xyz.sh").run() ``` 1. Faça upload dos scripts de ciclo de vida atualizados no bucket do S3 que você usou inicialmente para carregar os scripts de ciclo de vida básicos. 1. Teste a versão integrada do `lifecycle_script.py` criando um novo HyperPod cluster. Você também pode usar a substituição manual de instâncias para testar os scripts de ciclo de vida atualizados criando novas instâncias. Para obter instruções detalhadas, consulte [Substituir manualmente um nó](https://docs.aws.amazon.com//sagemaker/latest/dg/sagemaker-hyperpod-resiliency-slurm-replace-faulty-instance.html#sagemaker-hyperpod-resiliency-slurm-replace-faulty-instance-replace). Observe que somente os nós de trabalho são substituíveis.