View a markdown version of this page

Começando a SageMaker HyperPod usar o AWS CLI - SageMaker IA da Amazon
Principais conceitosCrie seu cluster doConectar ao 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 em funcionamento 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 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. Compreender esses conceitos o ajudará a fazer escolhas informadas ao configurar seu cluster, mas se quiser começar imediatamente, você pode ir diretamente para o site Crie seu cluster do e consultá-lo novamente, conforme necessário.

Ao criar um Slurm-orchestrated cluster, você faz duas opções de configuração independentes:

  1. Configuração da topologia Slurm — Como a topologia do cluster Slurm (funções dos nós, partições) é definida?

  2. Configuração do ciclo de vida dos nós — Como os nós são provisionados e personalizados?

Para a topologia Slurm, este tutorial usa a abordagem de API-driven configuração, na qual você define as funções e partições dos 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 precisar gerenciar arquivos adicionais. Como alternativa, você pode usar um provisioning_parameters.json arquivo legado armazenado no Amazon S3 para compatibilidade retroativa com clusters existentes. Para obter detalhes sobre a abordagem legada, 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 controlem 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 treinar dados, 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 a criação de clusters, mas recomendada para cargas de trabalho de produção.

Configurando a topologia Slurm por meio da API

Todos os exemplos neste tutorial usam a configuração da topologia API-driven Slurm, na qual você define a estrutura do cluster Slurm diretamente na solicitação da CreateCluster API, em vez de por meio de um arquivo de configuração separado.

Um cluster Slurm exige pelo menos um nó controlador (que executa o slurmctld daemon e coordena o agendamento do trabalho) 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 Slurm, que funcionam como filas lógicas que organizam a forma 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 substitui 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 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 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. Quando você cria ou atualiza um cluster, HyperPod grava a configuração da partição slurm.conf com base no SlurmConfig que 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 Slurm apropriadas.

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 que edita 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 para o controlador, descartando qualquer edição manual em. 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 Alterações manuais Caso de uso
Managed (padrão) Ativado; bloqueia as atualizações se a deriva for encontrada 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 desvio 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 pela HyperPod.

nota

Se você preferir definir a topologia Slurm usando um provisioning_parameters.json arquivo em vez da API, omita dos grupos de instâncias e da solicitação SlurmConfig do cluster e faça o upload Orchestrator.Slurm do arquivo para o Amazon S3 junto com os scripts do 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 nenhum bucket ou script do Amazon S3.

Com a opção Extensão, você especifica OnInitComplete LifeCycleConfig junto com um SourceS3Uri apontamento para 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 adicionar 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 possuem toda a sequência de provisionamento. Isso lhe dá controle total sobre qual software está instalado, como está configurado e quando o Slurm é iniciado.

Opção de ciclo de vida do nó Precisa de um bucket Amazon S3? Scripts para fazer upload? 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 Os clusters da Amazon continuam exigindo LifeCycleConfig com OnCreate e SourceS3Uri em cada grupo de instâncias.

nota

OnCreatee OnInitComplete são mutuamente exclusivos. Especificar os dois no mesmo grupo de instâncias resulta em um erro de validação.

Configuração 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 oferece suporte ao Amazon FSx for Lustre e ao FSx for OpenZFS, configurados por grupo de instâncias via. InstanceStorageConfigs Os sistemas de arquivos FSx residem em sua VPC, portanto, uma configuração personalizada da VPC (VpcConfig) é necessária ao usar o FSx.

A configuração do FSx funciona com todas as opções de configuração do ciclo de vida dos três 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 para 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 de 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 sistema de arquivos FSx for 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 uma configuração FSx para Lustre e uma 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, consultePré-requisitos para usar SageMaker HyperPod. Para obter mais informações sobre a configuração do FSx, consultePré-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 dos nós 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 com a 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.

Pois ExecutionRole em todos os exemplos, forneça o ARN da função do IAM que você criou com o gerenciado AmazonSageMakerClusterInstanceRolePolicy emPré-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, script ou arquivo de configuração do Amazon S3 é necessário. SageMaker HyperPod configura os 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 prontas para uso. Todos os pacotes de software são incorporados à 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 SlurmDaemons de controlador e computação iniciados automaticamente
DockerTempo de execução do contêiner para criar e executar contêineres de ML
EnrootExecução de contêineres sem raiz para cargas de trabalho Slurm
PyxisPlugin Slurm para integração de contêineres
Contabilidade de favelasConfigura a contabilidade de tarefas do Slurm para rastrear o histórico do trabalho 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 pelos nós de computação para trabalhos com vários nós
Rotação de troncos de slurmEvita o inchaço dos registros e problemas com o disco cheio
Configuração do diretório inicialDiretó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 nenhum LifeCycleConfig é especificado em qualquer grupo de instâncias.

    A topologia Slurm é definida por meio SlurmConfig de cada grupo de instâncias: my-controller-group recebe a Controller função (execuçõesslurmctld), 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 que HyperPod seja a única fonte confiável para a configuração de partições. O grupo de trabalho inclui um sistema de arquivos FSx for Lustre montado /fsx para armazenamento compartilhado e VpcConfig é especificado no nível do cluster conforme necessário para o FSx.

    dica

    Se você estiver testando sem FSx, você pode omitir FsxLustreConfig InstanceStorageConfigs e remover 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, continue paraConectar ao 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 depois 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 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 o 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 para seu bucket do Amazon S3 e especifique run_extensions.sh como OnInitComplete script:

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

    No interiorrun_extensions.sh, ative ou desative cada recurso definindo o sinalizador correspondente:

    ENABLE_ADD_USERS="true"
ENABLE_OBSERVABILITY="true"

    Cada arquivo de configuração do 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 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. 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 SlurmConfig define sua função de nó e sua atribuição de partição, e SlurmConfigStrategy: "Managed" é definido no nível do cluster. A única diferença é a adição de LifeCycleConfig withOnInitComplete, que indica que você HyperPod deve executar seu script de extensão após a conclusão da AMI-based configuração em cada nó. Para adicionar FSx, inclua FsxLustreConfig ou entre FsxOpenZfsConfig InstanceStorageConfigs nos grupos de instâncias relevantes e adicione VpcConfig no nível do cluster, conforme descrito emConfiguração 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, continue paraConectar ao 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ê é novo 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 poderá migrar para o modo personalizado posteriormente.

  1. Prepare e faça upload de scripts de ciclo de vida para o Amazon S3. Se estiver começando do zero, use os scripts de amostra do GitHub repositório https://github.com/aws-samples/awsome-distributed-training/ 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 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 Slurm segue o mesmo SlurmConfig padrão das outras opções. A principal diferença é LifeCycleConfig comOnCreate. Isso indica HyperPod que você deve ignorar completamente a AMI-based configuração e, em vez disso, executar 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 entre FsxOpenZfsConfig InstanceStorageConfigs nos grupos de instâncias relevantes e adicione VpcConfig no nível do cluster, conforme descrito emConfiguração 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, continue paraConectar ao cluster.

Erros comuns de validação

Erro Resolução
“O cluster deve ter exatamente um InstanceGroup com o tipo de nó controlador” Certifique-se de que exatamente um grupo de instâncias tenhaSlurmConfig.NodeType: "Controller"
“As partições só podem ser atribuídas a tipos de nós de computação” Remover PartitionNames de Controller nossos grupos de Login instâncias
“As configurações FSx são suportadas somente para VPC personalizada” Adicione VpcConfig à sua solicitação ao usar o FSx
“LifeCycleConfig é necessário, por exemplo, grupo...” Clusters EKS. 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 for 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 ou OnInitComplete ou omita LifeCycleConfig totalmente.

Conectar ao 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, consulteEmpregos em SageMaker HyperPod clusters.

Exclua o cluster e limpe os recursos.

Depois de testar, 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 dos 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 dos nós.

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.