View a markdown version of this page

Começando a SageMaker HyperPod usar o AWS CLI - SageMaker Inteligência Artificial da Amazon
Principais conceitosCrie seu cluster doConecte-se ao seu clusterExclua o cluster e limpe os recursos.Tópicos relacionados

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 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 (VPC, cotas, FSx) e AWS Identity and Access Management para SageMaker HyperPod (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 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?

  2. 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, consulteSageMaker HyperPod Configuração do Slurm.

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 usandoSlurmConfig, 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 emslurm.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"
    }
}

SlurmConfigStrategydetermina 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. ComManaged, HyperPod trata a API como a única fonte confiável e detectará e bloqueará atualizações se o slurm.conf disco estiver flutuando. ComOverwrite, 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. ComMerge, 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.

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

OnCreatee 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 ouOnInitComplete, HyperPod manipula a montagem do FSx automaticamente. Ao usarOnCreate, 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 Para obter mais informações sobre a configuração do FSx, consulte. Pré-requisitos para usar SageMaker HyperPod

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ó 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.

ExecutionRoleEm 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

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 SlurmDaemons de controle e computação iniciados automaticamente
DockerTempo de execução do contêiner para criar e executar contêineres de ML
EnraizarExecução de contêineres sem raiz para cargas de trabalho do Slurm
PyxisPlugin Slurm para integração de contêineres
Contabilidade de favelasConfigura a contabilidade de tarefas do Slurm para rastrear o histórico de tarefas e o consumo de recursos
MariaDBImplanta o MariaDB no nó do controlador como banco de dados de apoio para a contabilidade do Slurm
Geração de chaves SSHPar de chaves gerado para o usuário padrão do Ubuntu
Propagação SSHCredenciais de usuário propagadas entre nós de computação para trabalhos de vários nós
Rotação do registro do SlurmEvita o inchaço dos registros e problemas de disco cheio
Configuração do diretório inicialDiretório inicial do usuário Ubuntu montado no sistema de arquivos compartilhado

  1. Salve o seguinte comocreate_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 (executaslurmctld), 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.

  2. Crie o cluster:

    aws sagemaker create-cluster \
    --cli-input-json file://create_cluster.json

  3. 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 paraInService, prossiga paraConecte-se ao seu cluster.

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 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://<bucket>/<prefix>/
|-- run_extensions.sh          (OnInitComplete target)
|-- detect-node/               (node type detection utility)
|-- add-users/                 (user management scripts + config)
|-- observability/             (observability scripts + config)

    Dentrorun_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.

  2. Faça o upload para o Amazon S3 (o caminho do bucket deve começar coms3://sagemaker-):

    aws s3 cp extend-defaults.sh \
    s3://sagemaker-amzn-s3-demo-bucket/scripts/

  3. Salve o seguinte comocreate_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. OnCreatee 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 withOnInitComplete, 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

  4. Crie o cluster:

    aws sagemaker create-cluster \
    --cli-input-json file://create_cluster.json

  5. Verifique o status:

    aws sagemaker describe-cluster --cluster-name my-hyperpod-cluster

    ComOnInitComplete, a resposta aparece OnInitComplete noLifeCycleConfig. 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 paraInService, prossiga paraConecte-se ao seu cluster.

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. ComOnCreate, 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:

    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 coms3://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.

  2. Salve o seguinte comocreate_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 comOnCreate. 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

  3. Crie o cluster:

    aws sagemaker create-cluster \
    --cli-input-json file://create_cluster.json

  4. Verifique o status:

    aws sagemaker describe-cluster --cluster-name my-hyperpod-cluster

    ComOnCreate, a resposta aparece OnCreate noLifeCycleConfig. 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 paraInService, prossiga paraConecte-se ao seu cluster.

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

  2. 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

  3. 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, consulteTrabalhos em SageMaker HyperPod clusters.

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.