View a markdown version of this page

Provisionamento contínuo para operações de cluster aprimoradas com o Slurm - SageMaker IA da Amazon
Como funcionaProvisionamento baseado em prioridadesTratamento de falhas no controladorPré-requisitosMedição do usoCriar um cluster com o provisionamento contínuo habilitadoGerenciamento de configuração do Slurm

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

Provisionamento contínuo para operações de cluster aprimoradas com o Slurm

SageMaker HyperPod Os clusters da Amazon criados com a orquestração do Slurm agora oferecem suporte ao provisionamento contínuo, um recurso que permite maior flexibilidade e eficiência ao executar cargas de trabalho em grande escala. AI/ML O provisionamento contínuo permite que você comece a treinar rapidamente, escale sem problemas, realize a manutenção sem interromper as operações e tenha visibilidade granular das operações do cluster.

nota

O provisionamento contínuo está disponível como uma configuração opcional para novos HyperPod clusters criados com a orquestração do Slurm. No momento, os clusters existentes que usam o modelo de escalabilidade anterior não podem ser migrados para o provisionamento contínuo.

Como funciona

O sistema de provisionamento contínuo introduz uma arquitetura de estado desejado que substitui o modelo de escalabilidade tradicional. all-or-nothing No modelo anterior, se algum grupo de instâncias não pudesse ser totalmente provisionado, toda a operação de criação ou atualização do cluster falhava e era revertida. Com o provisionamento contínuo, o sistema aceita capacidade parcial e continua a provisionar as instâncias restantes de forma assíncrona.

O sistema de provisionamento contínuo:

  • Aceita a solicitação: registra a contagem de instâncias de destino para cada grupo de instâncias.

  • Inicia o provisionamento: começa a lançar instâncias para todos os grupos de instâncias em paralelo.

  • Provisiona os nós prioritários primeiro: o cluster faz a transição para InService depois que pelo menos um nó controlador (e um nó de login, se um grupo de instâncias de login for especificado) for provisionado com sucesso.

  • Monitora o progresso: monitora cada tentativa de inicialização da instância e registra o status.

  • Lida com falhas: repete automaticamente as inicializações com falha nos nós de trabalho de forma assíncrona.

O provisionamento contínuo está desabilitado por padrão. Para usar esse recurso, NodeProvisioningMode defina como Continuous em sua CreateCluster solicitação.

Com o provisionamento contínuo habilitado, você pode iniciar várias operações de ajuste de escala simultaneamente, sem precisar esperar a conclusão das operações anteriores. Isso permite escalar diferentes grupos de instâncias no mesmo cluster simultaneamente e enviar várias solicitações de ajuste de escala ao mesmo grupo de instâncias.

Provisionamento baseado em prioridades

Os clusters do Slurm exigem que um nó controlador esteja operacional antes que os nós de trabalho possam registrar e aceitar trabalhos. O provisionamento contínuo lida com isso automaticamente por meio do provisionamento baseado em prioridades:

  1. O grupo de instâncias do controlador é provisionado primeiro.

  2. Quando um nó controlador está íntegro, os nós de login e os nós de trabalho começam a ser provisionados em paralelo.

  3. O cluster muda para InService quando um nó controlador está ativo e um nó de login está ativo (se um grupo de instâncias de login for especificado). Se nenhum grupo de instâncias de login for especificado, o cluster será transferido InService assim que o nó do controlador for provisionado.

  4. Os nós de trabalho que não podem ser provisionados imediatamente devido a restrições de capacidade entram em um loop de repetição assíncrona e são adicionados ao cluster Slurm automaticamente assim que ficam disponíveis.

Tratamento de falhas no controlador

Durante a criação do cluster, se o nó do controlador falhar no provisionamento, o comportamento depende se o erro pode ser repetido ou não.

Erros que podem ser repetidos (por exemplo, instâncias não íntegras ou falhas transitórias):

  • HyperPod substitui continuamente a instância e tenta novamente o provisionamento até que o controlador seja ativado.

  • Os nós de trabalho e de login que já foram provisionados permanecem disponíveis, mas o cluster não faz a transição InService até que o controlador esteja íntegro.

Erros que não podem ser repetidos (por exemplo, nenhuma capacidade disponível para o tipo de instância do controlador ou falha no script do ciclo de vida):

  • O cluster está marcado comoFailed.

  • Você é notificado sobre o motivo da falha e deve tomar medidas corretivas, como escolher um tipo de instância diferente, corrigir scripts de ciclo de vida ou tentar novamente em uma zona de disponibilidade diferente.

Pré-requisitos

O provisionamento contínuo exige que os parâmetros de provisionamento do Slurm (tipos de nós, nomes de partições) sejam fornecidos por meio da carga útil da API no campo de cada grupo de instâncias. SlurmConfig Os clusters que dependem do provisioning_parameters.json arquivo legado no Amazon S3 não são compatíveis com o provisionamento contínuo.

nota

Atualmente, os seguintes recursos não são compatíveis com o provisionamento contínuo em clusters Slurm: migração de clusters existentes, configuração de nós com várias cabeças por meio da topologia Slurm baseada em API e. SlurmConfigStrategy O provisionamento contínuo opera exclusivamente no modo de mesclagem para gerenciamento. slurm.conf

Medição do uso

HyperPod clusters com provisionamento contínuo usam a medição em nível de instância para fornecer um faturamento preciso que reflita o uso real dos recursos. Essa abordagem de medição difere do faturamento tradicional em nível de cluster, pois rastreia cada instância de forma independente.

Faturamento em nível de instância

Com o provisionamento contínuo, o faturamento começa e termina em nível de instância, em vez de esperar por mudanças de estado em nível de cluster. Isso oferece os seguintes benefícios:

  • Faturamento preciso: o faturamento começa quando a execução do script de ciclo de vida começa. Se o script do ciclo de vida falhar, o provisionamento da instância será repetido e você será cobrado pela duração do tempo de execução do script do ciclo de vida.

  • Medição independente: o ciclo de vida de faturamento de cada instância é gerenciado separadamente, evitando erros de cobrança em cascata.

  • Atualizações de faturamento em tempo real: o faturamento começa quando uma instância começa a executar seu script de configuração do ciclo de vida e termina quando a instância entra em um estado de encerramento.

Ciclo de vida do faturamento

Cada instância em seu HyperPod cluster segue esse ciclo de vida de faturamento:

  • O faturamento começa: quando a instância é iniciada com sucesso e começa a executar seu script de configuração do ciclo de vida.

  • O faturamento continua: durante toda a vida operacional da instância.

  • O faturamento é interrompido: quando a instância entra em um estado de encerramento, independentemente do motivo da rescisão.

nota

O faturamento não começa para instâncias que falham na inicialização. Se a execução de uma instância falhar devido a insuficiência de capacidade ou a outros problemas, você não receberá cobranças por essa tentativa malsucedida. O faturamento é calculado em nível de instância e os custos são agregados e relatados no nome do recurso da Amazon (ARN) do cluster.

Criar um cluster com o provisionamento contínuo habilitado

nota

Prepare um script de configuração do ciclo de vida e carregue-o em um bucket do Amazon S3 que sua função de execução possa acessar. Para obter mais informações, consulte SageMaker HyperPod Operações de cluster do Slurm.

Prepare um arquivo de solicitação de CreateCluster API no formato JSON. Configure NodeProvisioningMode Continuous e forneça informações de topologia do Slurm no campo de cada grupo de instâncias. SlurmConfig

// create_cluster.json
{
    "ClusterName": "my-training-cluster",
    "NodeProvisioningMode": "Continuous",
    "Orchestrator": {
        "Slurm": {}
    },
    "InstanceGroups": [
        {
            "InstanceGroupName": "controller-group",
            "InstanceType": "ml.m5.xlarge",
            "InstanceCount": 1,
            "LifeCycleConfig": {
                "SourceS3Uri": "s3://amzn-s3-demo-bucket/lifecycle-scripts/src/",
                "OnCreate": "on_create.sh"
            },
            "ExecutionRole": "arn:aws:iam::111122223333:role/iam-role-for-cluster",
            "SlurmConfig": {
                "NodeType": "Controller"
            }
        },
        {
            "InstanceGroupName": "login-group",
            "InstanceType": "ml.m5.xlarge",
            "InstanceCount": 1,
            "LifeCycleConfig": {
                "SourceS3Uri": "s3://amzn-s3-demo-bucket/lifecycle-scripts/src/",
                "OnCreate": "on_create.sh"
            },
            "ExecutionRole": "arn:aws:iam::111122223333:role/iam-role-for-cluster",
            "SlurmConfig": {
                "NodeType": "Login"
            }
        },
        {
            "InstanceGroupName": "worker-gpu-a",
            "InstanceType": "ml.p5.48xlarge",
            "InstanceCount": 16,
            "LifeCycleConfig": {
                "SourceS3Uri": "s3://amzn-s3-demo-bucket/lifecycle-scripts/src/",
                "OnCreate": "on_create.sh"
            },
            "ExecutionRole": "arn:aws:iam::111122223333:role/iam-role-for-cluster",
            "SlurmConfig": {
                "NodeType": "Compute",
                "PartitionNames": ["gpu-training"]
            }
        }
    ],
    "VpcConfig": {
        "SecurityGroupIds": ["sg-12345678"],
        "Subnets": ["subnet-12345678"]
    }
}

Execute o create-cluster comando para enviar a solicitação.

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

Isso retorna o ARN do novo cluster.

{
    "ClusterArn": "arn:aws:sagemaker:us-west-2:111122223333:cluster/abcde12345"
}

Gerenciamento de configuração do Slurm

O provisionamento contínuo opera exclusivamente no modo de mesclagem para slurm.conf gerenciamento de partições. No modo de mesclagem, HyperPod aplica suas alterações de configuração de partição de forma aditiva sobre o que você modificou. slurm.conf HyperPod atualiza somente as seções relacionadas à partição slurm.conf (como entradas de nome da partição e nome do nó); outros parâmetros de configuração do Slurm não são modificados. Isso significa que:

  • Suas edições manuais slurm.conf são preservadas.

  • Não há detecção automática de desvios ou resolução de conflitos entre suas modificações e HyperPod o estado esperado.

O SlurmConfigStrategy parâmetro (Managed,Merge,Overwrite) não é compatível com o provisionamento contínuo. A transmissão de qualquer SlurmConfigStrategy valor resulta em um erro de API.