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á.
# Começando a SageMaker HyperPod usar o AWS CLI
[O tutorial a seguir demonstra como criar um novo SageMaker HyperPod cluster com o Slurm por meio dos AWS CLI comandos para. SageMaker HyperPod](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-cli) Ao final deste tutorial, você terá um cluster Slurm funcional com um nó controlador, um nó de login e um grupo de trabalhadores de computação, prontos para programar e executar cargas de trabalho de ML. O tutorial aborda a configuração da topologia do Slurm, as opções de configuração do ciclo de vida do nó, o armazenamento compartilhado FSx opcional e como se conectar ao seu cluster.
Antes de começar, certifique-se de ter concluído [Pré-requisitos para usar SageMaker HyperPod](sagemaker-hyperpod-prerequisites.md) (VPC, cotas, FSx) e [AWS Identity and Access Management para SageMaker HyperPod](sagemaker-hyperpod-prerequisites-iam.md) (funções do IAM, função de execução com). `AmazonSageMakerClusterInstanceRolePolicy`
## Principais conceitos
Esta seção aborda os principais conceitos de configuração para criar um cluster SageMaker HyperPod Slurm. A compreensão desses conceitos ajudará você a fazer escolhas informadas ao configurar seu cluster, mas se quiser começar imediatamente, pode ir diretamente até aqui [Crie seu cluster do](#smcluster-getting-started-slurm-cli-create-cluster) e consultá-lo conforme necessário.
Ao criar um Slurm-orchestrated cluster, você faz duas opções de configuração independentes:
1. **Configuração da topologia do Slurm** — Como a topologia do cluster do Slurm (funções de nós, partições) é definida?
1. **Configuração do ciclo de vida do nó** — Como os nós são provisionados e personalizados?
Para a topologia do Slurm, este tutorial usa a abordagem de API-driven configuração, na qual você define funções e partições de nós diretamente na `CreateCluster` solicitação usando em cada grupo de instâncias e `SlurmConfig` no `Orchestrator.Slurm` nível do cluster. Essa é a abordagem recomendada para novos clusters. Ele fornece uma única fonte confiável, validação integrada e detecção de desvios na configuração de partições, sem arquivos adicionais para gerenciar. Como alternativa, você pode usar um `provisioning_parameters.json` arquivo legado armazenado no Amazon S3 para compatibilidade com versões anteriores dos clusters existentes. Para obter detalhes sobre a abordagem antiga, consulte[SageMaker HyperPod Configuração do Slurm](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-slurm-configuration).
Para configuração do ciclo de vida do nó, SageMaker HyperPod oferece suporte a três opções. No caso mais simples, você omite `LifeCycleConfig` totalmente e configura HyperPod automaticamente os nós usando a AMI-based configuração, configurando o Slurm e pacotes essenciais, como Docker, Enroot e Pyxis, para executar cargas de trabalho de ML, sem a necessidade de scripts ou bucket do Amazon S3. Se precisar de personalizações além da AMI-based configuração, você pode fornecer um script de extensão por meio do `OnInitComplete` qual é executado após a conclusão da configuração. Para ter controle total sobre toda a sequência de provisionamento, o `OnCreate` caminho permite que seus scripts sejam donos de tudo, inclusive quando o Slurm é iniciado.
Para cargas de trabalho de ML, você normalmente também precisará de um sistema de arquivos compartilhado de alto desempenho para dados de treinamento, pontos de verificação e bibliotecas compartilhadas. SageMaker HyperPod suporta Amazon FSx for Lustre e FSx for OpenZFS, configurados por grupo de instâncias via. `InstanceStorageConfigs` A configuração do FSx é opcional para criação de clusters, mas recomendada para cargas de trabalho de produção.
### Configurando a topologia do Slurm por meio da API
Todos os exemplos deste tutorial usam a configuração de topologia do API-driven Slurm, na qual você define a estrutura do cluster do Slurm diretamente na solicitação da `CreateCluster` API, em vez de por meio de um arquivo de configuração separado.
Um cluster Slurm requer pelo menos um nó controlador (que executa o `slurmctld` daemon e coordena o agendamento de trabalhos) e um ou mais nós de computação (que executam trabalhos). Opcionalmente, você pode adicionar um nó de login para fornecer aos usuários um ponto de acesso dedicado para enviar e gerenciar trabalhos sem fazer login diretamente no controlador. Na solicitação da API, você atribui a cada grupo de instâncias sua função Slurm usando`SlurmConfig`, especificando se o grupo serve como controlador, login ou nó de computação. Os grupos de computação também são mapeados para uma ou mais partições do Slurm, que funcionam como filas lógicas que organizam como os trabalhos são agendados em diferentes conjuntos de nós.
No nível do cluster, `Orchestrator.Slurm` controla como HyperPod gerencia a configuração da partição em`slurm.conf`. Você escolhe uma estratégia que determina se HyperPod é a única fonte confiável para a topologia de partições, se ela sobrescreve as alterações manuais ou se mescla a API-defined configuração com qualquer edição manual que você tenha feito. Aqui está uma referência para os campos usados.
**SlurmConfig**(por grupo de instâncias):
```
"SlurmConfig": {
"NodeType": "Controller | Login | Compute",
"PartitionNames": ["partition-name"]
}
```
| Campo | Description |
| --- | --- |
| NodeType | Obrigatório. A função do Slurm para esse grupo de instâncias. Valores válidos: Controller, Login, Compute. Exatamente um grupo de instâncias deve serController. |
| PartitionNames | Condicional. Nomes de partições do Slurm. Obrigatório para o tipo de Compute nó; não permitido para Controller ouLogin. |
**Orchestrator.Slurm**(nível de cluster):
```
"Orchestrator": {
"Slurm": {
"SlurmConfigStrategy": "Managed | Overwrite | Merge"
}
}
```
`SlurmConfigStrategy`determina como HyperPod gerencia os mapeamentos de partição para nó no `slurm.conf` nó controlador. Ao criar ou atualizar um cluster, HyperPod grava a configuração da partição `slurm.conf` com base no que `SlurmConfig` você definiu em cada grupo de instâncias, mapeando grupos de instâncias de computação para suas partições atribuídas e registrando os nós de controlador e login com as funções apropriadas do Slurm.
A estratégia escolhida controla o que acontece quando a configuração da partição é `slurm.conf` modificada fora da API, por exemplo, por um administrador editando o arquivo diretamente no nó do controlador. Com`Managed`, HyperPod trata a API como a única fonte confiável e detectará e bloqueará atualizações se o `slurm.conf` disco estiver flutuando. Com`Overwrite`, HyperPod força a API-defined configuração no controlador, descartando qualquer edição manual no. `slurm.conf` Isso é útil para se recuperar de uma alteração não intencional. Com`Merge`, HyperPod preserva as edições manuais `slurm.conf` e as mescla com a configuração da API, oferecendo aos usuários avançados a flexibilidade de manter `slurm.conf` configurações personalizadas junto com as partições. API-managed
| Estratégia | Detecção de desvio de partição | Mudanças manuais | Caso de uso |
| --- | --- | --- | --- |
| Managed (padrão) | Ativado; bloqueia as atualizações se o desvio for encontrado | Não compatível | Fonte única de verdade |
| Overwrite | Desabilitado | Substituído na atualização | Recuperação da deriva |
| Merge | Desabilitado | Preservado e mesclado | slurm.confNecessidades personalizadas |
**Importante**
A detecção de desvios se aplica somente à configuração da partição Slurm em `slurm.conf` (mapeamentos de partição para nó definidos por meio da API). Alterações em outras `slurm.conf` configurações, como parâmetros de agendamento, limites de recursos ou configuração contábil, não são monitoradas e não serão detectadas ou relatadas pelo HyperPod.
**nota**
Se você preferir definir a topologia do Slurm usando um `provisioning_parameters.json` arquivo em vez da API, omita dos grupos de instâncias e `SlurmConfig` da solicitação do cluster e faça o upload `Orchestrator.Slurm` do arquivo no Amazon S3 junto com os scripts de ciclo de vida do nó. Para obter detalhes, consulte [SageMaker HyperPod Configuração do Slurm](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-slurm-configuration).
### Opções de configuração do ciclo de vida do nó
Ao criar um cluster SageMaker HyperPod Slurm, você escolhe como os nós de cada grupo de instâncias são provisionados configurando o `LifeCycleConfig` bloco na solicitação. `CreateCluster` SageMaker HyperPod oferece suporte a três opções de configuração do ciclo de vida de nós, cada uma oferecendo um nível diferente de controle sobre o processo de provisionamento.
Somente com a **AMI-based configuração**, você omite `LifeCycleConfig` totalmente. HyperPod configura automaticamente os nós usando a AMI-based configuração, configurando o Slurm, instalando pacotes essenciais e iniciando todos os serviços necessários. Esse é o caminho mais simples e não requer scripts ou bucket do Amazon S3.
Com a opção **Extension**, você especifica `OnInitComplete` `LifeCycleConfig` junto com um script de extensão `SourceS3Uri` apontando para o seu script de extensão no Amazon S3. HyperPod executa primeiro a AMI-based configuração completa e, em seguida, executa seu script. Isso permite que você adicione personalizações, como agentes de monitoramento, integração LDAP ou montagens de armazenamento adicionais, sem gerenciar o provisionamento básico.
Com a opção **Personalizada**, você especifica `OnCreate` `LifeCycleConfig` junto com um `SourceS3Uri` apontamento para seu script de ciclo de vida completo definido no Amazon S3. HyperPod não executa a AMI-based configuração e não inicia o Slurm. Seus scripts são donos de toda a sequência de provisionamento. Isso lhe dá controle total sobre qual software está instalado, como ele é configurado e quando o Slurm é iniciado.
| Opção de ciclo de vida do nó | É necessário um bucket Amazon S3? | Scripts para carregar? | LifeCycleConfig na API? |
| --- | --- | --- | --- |
| AMI-based somente configuração (mais simples) | Não | Não | Omitir totalmente |
| Extensão (OnInitComplete) | Sim | Somente seu script de extensão | OnInitComplete \+ SourceS3Uri |
| Personalizado (OnCreate) | Sim | Conjunto completo de scripts de ciclo de vida | OnCreate \+ SourceS3Uri |
**nota**
A configuração opcional do ciclo de vida do nó é suportada somente para Slurm-orchestrated clusters. EKS-orchestrated clusters e clusters Slurm que usam `NodeProvisioningMode` Continuous continuam sendo necessários `LifeCycleConfig` com `OnCreate` e `SourceS3Uri` em cada grupo de instâncias.
**nota**
`OnCreate`e `OnInitComplete` são mutuamente exclusivos. Especificar ambos no mesmo grupo de instâncias resulta em um erro de validação.
### Configuração de FSx e VPC
Para cargas de trabalho de ML, um sistema de arquivos compartilhado de alto desempenho é essencial para armazenar dados de treinamento, pontos de verificação de modelos e bibliotecas compartilhadas nos nós do cluster. SageMaker HyperPod suporta Amazon FSx for Lustre e FSx for OpenZFS, configurados por grupo de instâncias via. `InstanceStorageConfigs` Os sistemas de arquivos FSx residem em sua VPC, portanto, uma configuração de VPC personalizada () é necessária ao usar FSx. `VpcConfig`
A configuração do FSx funciona com todas as três opções de configuração do ciclo de vida dos nós. Ao usar a AMI-based configuração ou`OnInitComplete`, HyperPod manipula a montagem do FSx automaticamente. Ao usar`OnCreate`, seus scripts de ciclo de vida são responsáveis pela montagem.
**FSx for Lustre:**
```
"InstanceStorageConfigs": [
{
"FsxLustreConfig": {
"DnsName": "fs-0abc123def456789.fsx.us-west-2.amazonaws.com",
"MountPath": "/fsx",
"MountName": "abcdefgh"
}
}
]
```
| Campo | Description |
| --- | --- |
| DnsName | Obrigatório. O nome DNS do sistema de arquivos FSx for Lustre. |
| MountPath | Opcional. O caminho de montagem local na instância. Padrão: /fsx |
| MountName | Obrigatório. O nome da montagem do sistema de arquivos FSx for Lustre. Encontre isso no console FSx for Lustre ou via. aws fsx describe-file-systems |
**FSx para OpenZFS:**
```
"InstanceStorageConfigs": [
{
"FsxOpenZfsConfig": {
"DnsName": "fs-0xyz789abc123456.fsx.us-west-2.amazonaws.com",
"MountPath": "/shared"
}
}
]
```
| Campo | Description |
| --- | --- |
| DnsName | Obrigatório. O nome DNS do FSx para o sistema de arquivos OpenZFS. |
| MountPath | Opcional. O caminho de montagem local na instância. Padrão: /home |
**nota**
Cada grupo de instâncias pode ter no máximo um FSx for Lustre e um FSx para OpenZFS. Grupos de instâncias diferentes podem montar sistemas de arquivos diferentes.
**Configuração de VPC** (necessária para FSx):
Adicione `VpcConfig` no nível do cluster em sua `CreateCluster` solicitação:
```
"VpcConfig": {
"SecurityGroupIds": ["sg-0abc123def456789a"],
"Subnets": ["subnet-0abc123def456789a"]
}
```
Para obter mais informações sobre como configurar uma VPC, consulte. [Pré-requisitos para usar SageMaker HyperPod](sagemaker-hyperpod-prerequisites.md) Para obter mais informações sobre a configuração do FSx, consulte. [Pré-requisitos para usar SageMaker HyperPod](sagemaker-hyperpod-prerequisites.md)
## Crie seu cluster do
Esta seção explica como criar um cluster usando cada uma das três opções de configuração do ciclo de vida do nó descritas em. [Opções de configuração do ciclo de vida do nó](#smcluster-getting-started-slurm-cli-lifecycle-options) Para a maioria dos usuários, recomendamos começar com a **Opção A**, somente AMI-based configuração. Ele não requer scripts ou bucket do Amazon S3 e fornece um cluster totalmente funcional pronto para uso. Escolha a Opção B se precisar adicionar personalizações à AMI-based configuração ou a Opção C se precisar de controle total sobre o processo de provisionamento.
`ExecutionRole`Em todos os exemplos, forneça o ARN da função do IAM que você criou com o managed `AmazonSageMakerClusterInstanceRolePolicy` in. [Pré-requisitos para usar SageMaker HyperPod](sagemaker-hyperpod-prerequisites.md)
### Opção A: somente AMI-based configuração (sem configuração do ciclo de vida)
Esse é o caminho mais simples. Nenhum bucket, scripts ou arquivos de configuração do Amazon S3 são necessários. SageMaker HyperPod configura nós automaticamente usando a AMI-based configuração, instalando software essencial e aplicando configurações para que o cluster esteja pronto para executar cargas de trabalho de ML imediatamente. Todos os pacotes de software estão incorporados na AMI, portanto, nenhum acesso à Internet é necessário durante o provisionamento.
A tabela a seguir lista os recursos incluídos na AMI-based configuração:
| Recurso | Description |
| --- | --- |
| Daemons do Slurm | Daemons de controle e computação iniciados automaticamente |
| Docker | Tempo de execução do contêiner para criar e executar contêineres de ML |
| Enraizar | Execução de contêineres sem raiz para cargas de trabalho do Slurm |
| Pyxis | Plugin Slurm para integração de contêineres |
| Contabilidade de favelas | Configura a contabilidade de tarefas do Slurm para rastrear o histórico de tarefas e o consumo de recursos |
| MariaDB | Implanta o MariaDB no nó do controlador como banco de dados de apoio para a contabilidade do Slurm |
| Geração de chaves SSH | Par de chaves gerado para o usuário padrão do Ubuntu |
| Propagação SSH | Credenciais de usuário propagadas entre nós de computação para trabalhos de vários nós |
| Rotação do registro do Slurm | Evita o inchaço dos registros e problemas de disco cheio |
| Configuração do diretório inicial | Diretório inicial do usuário Ubuntu montado no sistema de arquivos compartilhado |
1. Salve o seguinte 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}}"]
}
}
```
Observe que não `LifeCycleConfig` é especificado em qualquer grupo de instâncias.
A topologia do Slurm é definida por meio `SlurmConfig` de cada grupo de instâncias: `my-controller-group` recebe a `Controller` função (executa`slurmctld`), `my-login-group` serve como `Login` nó para acesso do usuário e `worker-group-1` é um `Compute` nó atribuído `partition-1` para agendamento de tarefas. No nível do cluster, `SlurmConfigStrategy: "Managed"` garante HyperPod é a única fonte confiável para a configuração de partições. O grupo de trabalho inclui um sistema de arquivos FSx for Lustre `/fsx` montado para armazenamento `VpcConfig` compartilhado e é especificado no nível do cluster conforme necessário para o FSx.
**dica**
Se você estiver testando sem FSx, você pode omitir `InstanceStorageConfigs` e remover `FsxLustreConfig` `VpcConfig` da solicitação. O FSx não é necessário para a criação de clusters, mas é recomendado para cargas de trabalho de ML de produção.
1. Crie o cluster:
```
aws sagemaker create-cluster \
--cli-input-json {{file://create_cluster.json}}
```
1. Verifique o status:
```
aws sagemaker describe-cluster --cluster-name {{my-hyperpod-cluster}}
```
Somente com a AMI-based configuração, os grupos de instâncias na resposta não incluem um `LifeCycleConfig` bloco. Veja a seguir um exemplo truncado que mostra o grupo de instâncias do controlador:
```
{
"ClusterName": "my-hyperpod-cluster",
"ClusterStatus": "InService",
"InstanceGroups": [
{
"InstanceGroupName": "my-controller-group",
"SlurmConfig": { "NodeType": "Controller" }
}
]
}
```
Depois que o status mudar para**InService**, prossiga para[Conecte-se ao seu cluster](#smcluster-getting-started-slurm-cli-connect).
### Opção B: Estender a AMI-based configuração com OnInitComplete
Use essa opção quando precisar de personalizações além da AMI-based configuração, como agentes de monitoramento, LDAP/SSSD integração ou montagens de armazenamento adicionais. SageMaker HyperPod executa a AMI-based configuração primeiro e, em seguida, executa seu script de extensão.
1. Escreva seu script de extensão. Por exemplo,`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."
```
**Usando scripts de extensão do repositório Awsome Distributed Training**
A [pasta Extensions](https://github.com/awslabs/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/Extensions) no repositório do Awsome Distributed Training fornece scripts de extensão prontos para uso para tarefas comuns, como adicionar usuários e permitir a observabilidade. Cada recurso é independente em seu próprio diretório com seu próprio script de ponto de entrada que pode ser fornecido diretamente como `OnInitComplete` script.
Para clusters que precisam de vários recursos, recomendamos usar o `run_extensions.sh` script disponível no nível superior da pasta Extensões. Esse script orquestra todos os scripts de extensão disponíveis e fornece alternâncias booleanas simples para ativar ou desativar cada recurso. Para usá-lo, faça o upload da pasta Extensions inteira no seu bucket do Amazon S3 e especifique `run_extensions.sh` como script: `OnInitComplete`
```
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`, ative ou desative cada recurso definindo o sinalizador correspondente:
```
ENABLE_ADD_USERS="true"
ENABLE_OBSERVABILITY="true"
```
O arquivo de configuração de cada recurso habilitado deve ser preenchido antes do upload para o Amazon S3. Consulte o README no diretório de cada recurso para obter detalhes de configuração.
1. Faça o upload para o Amazon S3 (o caminho do bucket deve começar com`s3://sagemaker-`):
```
aws s3 cp extend-defaults.sh \
s3://sagemaker-{{amzn-s3-demo-bucket}}/scripts/
```
1. Salve o seguinte 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**
Quando `OnInitComplete` é especificado, `SourceS3Uri` é obrigatório. `OnCreate`e `OnInitComplete` não podem ser usados juntos no mesmo grupo de instâncias.
**dica**
Você pode misturar opções em um cluster. Por exemplo, use a AMI-based configuração somente no controlador e `OnInitComplete` nos trabalhadores.
A topologia do Slurm é a mesma da Opção A. Cada grupo de instâncias tem uma `SlurmConfig` definição de sua função de nó e atribuição de partição, e `SlurmConfigStrategy: "Managed"` é definida no nível do cluster. A única diferença é a adição de `LifeCycleConfig` with`OnInitComplete`, que instrui HyperPod a execução do script de extensão após a conclusão da AMI-based configuração em cada nó. Para adicionar FSx, inclua `FsxLustreConfig` ou `FsxOpenZfsConfig` participe `InstanceStorageConfigs` dos grupos de instâncias relevantes e adicione `VpcConfig` no nível do cluster, conforme descrito em. [Configuração de FSx e VPC](#smcluster-getting-started-slurm-cli-fsx-vpc)
1. Crie o cluster:
```
aws sagemaker create-cluster \
--cli-input-json {{file://create_cluster.json}}
```
1. Verifique o status:
```
aws sagemaker describe-cluster --cluster-name {{my-hyperpod-cluster}}
```
Com`OnInitComplete`, a resposta aparece `OnInitComplete` no`LifeCycleConfig`. Veja a seguir um exemplo truncado que mostra o grupo de instâncias do 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"
}
}
]
}
```
Depois que o status mudar para**InService**, prossiga para[Conecte-se ao seu cluster](#smcluster-getting-started-slurm-cli-connect).
### Opção C: controle personalizado total com OnCreate (avançado)
Use essa opção quando precisar de controle total sobre o provisionamento, incluindo instalar software, fazer alterações na infraestrutura e decidir quando iniciar o Slurm. Com`OnCreate`, SageMaker HyperPod **não** executa a AMI-based configuração e **não** inicia o Slurm automaticamente.
**nota**
Se você é novato SageMaker HyperPod e não tem requisitos específicos de personalização, recomendamos começar com a Opção A ou a Opção B. Você sempre pode migrar para o modo personalizado posteriormente.
1. Prepare e faça upload de scripts de ciclo de vida para o Amazon S3. Se começar do zero, use os scripts de amostra do [ GitHub repositório 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
```
Faça o upload para o Amazon S3 (o caminho do bucket deve começar com`s3://sagemaker-`):
```
aws s3 sync . \
s3://sagemaker-{{amzn-s3-demo-bucket}}/lifecycle/src
```
Para saber mais sobre os scripts de ciclo de vida, consulte [Personalização de SageMaker HyperPod clusters usando scripts de ciclo de vida](sagemaker-hyperpod-lifecycle-best-practices-slurm.md).
1. Salve o seguinte 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"
}
}
}
```
A topologia do Slurm segue o mesmo `SlurmConfig` padrão das outras opções. A principal diferença é `LifeCycleConfig` com`OnCreate`. Isso faz com HyperPod que você ignore totalmente a AMI-based configuração e, em vez disso, execute seu `on_create.sh` script. Seus scripts são responsáveis pela sequência completa de provisionamento, incluindo a instalação do software, a configuração do Slurm e a inicialização dos daemons do Slurm. Para adicionar FSx, inclua `FsxLustreConfig` ou `FsxOpenZfsConfig` participe `InstanceStorageConfigs` dos grupos de instâncias relevantes e adicione `VpcConfig` no nível do cluster, conforme descrito em. [Configuração de FSx e VPC](#smcluster-getting-started-slurm-cli-fsx-vpc)
1. Crie o cluster:
```
aws sagemaker create-cluster \
--cli-input-json {{file://create_cluster.json}}
```
1. Verifique o status:
```
aws sagemaker describe-cluster --cluster-name {{my-hyperpod-cluster}}
```
Com`OnCreate`, a resposta aparece `OnCreate` no`LifeCycleConfig`. Veja a seguir um exemplo truncado que mostra o grupo de instâncias do 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"
}
}
]
}
```
Depois que o status mudar para**InService**, prossiga para[Conecte-se ao seu cluster](#smcluster-getting-started-slurm-cli-connect).
### Erros comuns de validação
| Erro | Resolução |
| --- | --- |
| “O cluster deve ter exatamente um InstanceGroup com o tipo de nó do controlador” | Certifique-se de que exatamente um grupo de instâncias tenhaSlurmConfig.NodeType: "Controller" |
| “As partições só podem ser atribuídas aos tipos de nós de computação” | Remover PartitionNames de Controller nossos grupos de Login instâncias |
| “As configurações FSx são suportadas apenas para VPC personalizada” | Adicione VpcConfig à sua solicitação ao usar FSx |
| “LifeCycleConfig é necessário, por exemplo, grupo...” | Clusters EKS ou Slurm Continuous. NodeProvisioningMode A configuração opcional do ciclo de vida do nó não é suportada. |
| “OnCreate e OnInitComplete em LifeCycleConfig são mutuamente exclusivos...” | Remova um OnCreate ouOnInitComplete. Não é possível especificar ambos. |
| “LifeCycleConfig por exemplo, o grupo está incompleto...” | Quando OnCreate ou OnInitComplete é especificado, também SourceS3Uri deve ser fornecido. |
| “LifeCycleConfig é opcional, mas requer uma AMI compatível...” | Execute UpdateClusterSoftware para atualizar para uma AMI que ofereça suporte à configuração opcional do ciclo de vida do nó. |
| “LifeCycleConfig por exemplo, o grupo é fornecido, mas não contém nenhuma configuração...” | Especifique SourceS3Uri com OnCreate ouOnInitComplete, ou omita LifeCycleConfig totalmente. |
## Conecte-se ao seu cluster
Depois que o status do cluster mudar para **InService** (normalmente de 10 a 15 minutos), conecte-se e verifique.
1. Liste os nós do cluster para obter IDs de instância:
```
aws sagemaker list-cluster-nodes --cluster-name {{my-hyperpod-cluster}}
```
1. Conecte-se usando o Gerenciador AWS Systems Manager de Sessões:
```
aws ssm start-session \
--target sagemaker-cluster:{{my-hyperpod-cluster}}_{{my-login-group}}-{{i-0abc123def456789b}} \
--region {{us-west-2}}
```
1. Verifique se o Slurm está configurado corretamente:
```
# Check Slurm nodes
sinfo
# Check Slurm partitions
sinfo -p partition-1
# Submit a test job
srun -p partition-1 --nodes=1 hostname
```
Para obter mais informações sobre a execução de cargas de trabalho de ML, consulte[Trabalhos em SageMaker HyperPod clusters](sagemaker-hyperpod-run-jobs-slurm.md).
## Exclua o cluster e limpe os recursos.
Após o teste, exclua o cluster para evitar cobranças contínuas:
```
aws sagemaker delete-cluster --cluster-name {{my-hyperpod-cluster}}
```
Se você usou scripts de ciclo de vida de nós (opção B ou opção C), limpe o bucket do Amazon S3:
```
aws s3 rm s3://sagemaker-{{amzn-s3-demo-bucket}}/{{lifecycle/src}} --recursive
```
Se você usou somente a AMI-based configuração (Opção A), nenhuma limpeza do Amazon S3 é necessária para scripts de ciclo de vida do nó.
Se você executou cargas de trabalho de treinamento, verifique também se há dados ou artefatos no Amazon S3, no Amazon FSx for Lustre ou no Amazon Elastic File System e exclua-os para evitar cobranças.
## Tópicos relacionados
+ [SageMaker HyperPod Configuração do Slurm](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-slurm-configuration)
+ [Personalização de SageMaker HyperPod clusters usando scripts de ciclo de vida](sagemaker-hyperpod-lifecycle-best-practices-slurm.md)
+ [Configuração FSx via InstanceStorageConfigs](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-slurm-fsx-config)
+ [SageMaker HyperPod Operações de cluster do Slurm](sagemaker-hyperpod-operate-slurm.md)
+ [Scripts de extensão para SageMaker HyperPod](https://github.com/awslabs/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/Extensions)
+ [Personalização de SageMaker HyperPod clusters usando scripts de ciclo de vida](sagemaker-hyperpod-lifecycle-best-practices-slurm.md)