View a markdown version of this page

Provisionamento contínuo para operações aprimoradas de cluster com o Slurm - SageMaker IA da Amazon

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 aprimoradas de cluster com o Slurm

SageMaker HyperPod Os clusters da Amazon criados com a orquestração 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 HyperPod clusters criados com a orquestração Slurm.

Como funciona

O sistema de provisionamento contínuo introduz uma arquitetura de estado desejado que substitui o modelo tradicional de escalabilidade do tipo tudo ou nada. 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 a 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 iniciar instâncias para todos os grupos de instâncias em paralelo.

  • Provisiona primeiro os nós prioritários: o cluster faz a transição para InService depois de pelo menos um nó controlador (e um nó de login, se um grupo de instâncias de login for especificado) ser 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 falhadas dos 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.

Priority-based provisionamento

Os clusters 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ó do controlador está íntegro, os nós de login e os nós de trabalho começam a provisionar em paralelo.

  3. O cluster faz a transição 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 para 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 ciclo de repetição assíncrona e são adicionados automaticamente ao cluster Slurm à medida que são disponibilizados.

Tratamento de falhas do controlador

Durante a criação do cluster, se o nó do controlador falhar no provisionamento, o comportamento dependerá 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 provisionar novamente até que o controlador apareça.

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

Non-retryable erros (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 do 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 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: configuração de nós de várias cabeças por meio API-based da topologia Slurm 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 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.

Instance-level faturamento

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, a provisão da instância será repetida 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 faturamento em cascata.

  • Real-time atualizações de faturamento: 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 do encerramento.

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 faça o upload para 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 Slurm.

Prepare um arquivo de solicitação de CreateCluster API no formato JSON. NodeProvisioningModeDefina 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 aditivamente sobre tudo o que você modificou. slurm.conf HyperPod atualiza apenas as seções relacionadas à partição do 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 em slurm.conf são preservadas.

  • Não há detecção automática de desvio 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. Passar qualquer SlurmConfigStrategy valor resulta em um erro de API.

Requisitos mínimos de capacidade (MinCount)

O MinCount recurso permite que você especifique o número mínimo de instâncias que devem ser provisionadas com sucesso antes que um grupo de instâncias passe para o status. InService Esse recurso fornece melhor controle sobre as operações de escalabilidade e ajuda a evitar cenários em que grupos de instâncias parcialmente provisionados não possam ser usados de forma eficaz para treinar cargas de trabalho.

Importante

MinCount não é uma garantia permanente de capacidade mínima. Isso só garante que o número mínimo especificado de instâncias esteja disponível quando o grupo de instâncias é criado pela primeira vezInService. Breves quedas abaixo MinCount podem ocorrer durante operações normais, como substituições de instâncias não íntegras ou atividades de manutenção.

Como MinCount funciona

Quando você cria ou atualiza um grupo de instâncias com MinCount enabled, ocorre o seguinte comportamento:

  • Novos grupos de instâncias: o grupo de instâncias permanece em Creating status até que pelo menos as MinCount instâncias sejam provisionadas e estejam prontas com sucesso. Quando esse limite é atingido, o grupo de instâncias faz a transição para o. InService

  • Grupos de instâncias existentes: ao atualizar MinCount em um grupo de instâncias existente, o status muda para Updating até que o novo MinCount requisito seja atendido.

  • Escalabilidade contínua: se TargetCount for maior que MinCount, o sistema de escalabilidade contínua continuará tentando iniciar instâncias adicionais até TargetCount ser atingido.

  • Tempo limite e reversão: se MinCount não puder ser satisfeito em 3 horas, o sistema reverterá automaticamente o grupo de instâncias para seu último estado válido conhecido. Para obter mais informações sobre o comportamento de reversão, consulte Comportamento de reversão automática.

Status do grupo de instâncias durante MinCount as operações

Os grupos de instâncias MinCount configurados exibem o seguinte comportamento de status:

Criando

Para novos grupos de instâncias quando CurrentCount < MinCount. O grupo de instâncias permanece nesse status até que o requisito mínimo de capacidade seja atendido.

Atualização

Para grupos de instâncias existentes, quando MinCount é modificado e CurrentCount < MinCount. O grupo de instâncias permanece nesse status até que o novo requisito de capacidade mínima seja atendido.

InService

Quando MinCount ≤ CurrentCount ≤ TargetCount. O grupo de instâncias está pronto para uso e todas as operações de mutação estão desbloqueadas.

Durante Creating nosso Updating status, as seguintes restrições se aplicam:

  • Operações mutantesBatchAddClusterNodes, comoBatchDeleteClusterNodes, ou UpdateClusterSoftware estão bloqueadas

  • Você ainda pode modificar TargetCount valores MinCount e corrigir erros de configuração

  • A exclusão de grupos de clusters e instâncias é sempre permitida

Comportamento de reversão automática

Se um grupo de instâncias não conseguir alcançá-lo MinCount em 3 horas, o sistema iniciará automaticamente uma reversão para evitar a espera indefinida:

  • Novos grupos de instâncias: MinCount e TargetCount são redefinidos para (0, 0)

  • Grupos de instâncias existentes: MinCount e TargetCount são restaurados aos valores do último InService estado

  • Seleção de instâncias para encerramento: se as instâncias precisarem ser encerradas durante a reversão, o sistema seleciona primeiro as instâncias não íntegras e depois as que foram provisionadas mais recentemente.

  • Transição de status: o grupo de instâncias passa imediatamente para o InService status após o início da reversão, permitindo que o sistema de escalabilidade contínua gerencie a capacidade de acordo com as configurações de reversão

O tempo limite de 3 horas é redefinido sempre MinCount que é atualizado. Por exemplo, se você atualizar MinCount várias vezes, o período de tempo limite começará a partir da atualização mais recente.

MinCount eventos

O sistema emite eventos específicos para ajudar você a rastrear MinCount as operações:

  • Capacidade mínima alcançada: emitida quando um grupo de instâncias atinge com êxito sua capacidade MinCount e faz a transição para InService

  • Reversão iniciada: emitida quando o tempo limite de 3 horas expira e a reversão automática começa

Você pode monitorar esses eventos usando ListClusterEvents para acompanhar o progresso de suas MinCount operações.

Uso da API

MinCount é especificado usando o MinInstanceCount parâmetro nas configurações do grupo de instâncias:

aws sagemaker create-cluster \ --cluster-name $HP_CLUSTER_NAME \ --instance-groups '[ { "InstanceGroupName": "controller-machine", "InstanceType": "ml.c5.xlarge", "InstanceCount": 1, "SlurmConfig": {"NodeType": "Controller"}, "LifeCycleConfig": { "SourceS3Uri": "s3://'$BUCKET_NAME'", "OnCreate": "on_create.sh" }, "ExecutionRole": "'$EXECUTION_ROLE'", "ThreadsPerCore": 2 }, { "InstanceGroupName": "my-login-group", "InstanceType": "ml.c5.xlarge", "InstanceCount": 1, "SlurmConfig": {"NodeType": "Login"}, "LifeCycleConfig": { "SourceS3Uri": "s3://'$BUCKET_NAME'", "OnCreate": "on_create.sh" }, "ExecutionRole": "'$EXECUTION_ROLE'", "ThreadsPerCore": 1 }, { "InstanceGroupName": "worker-group-1", "InstanceType": "ml.c5.xlarge", "MinInstanceCount": 1, "InstanceCount": 2, "SlurmConfig": { "NodeType": "Compute", "PartitionNames": ["p1"] }, "LifeCycleConfig": { "SourceS3Uri": "s3://'$BUCKET_NAME'", "OnCreate": "on_create.sh" }, "ExecutionRole": "'$EXECUTION_ROLE'", "ThreadsPerCore": 1 } ]' \ --vpc-config '{ "SecurityGroupIds": ["'$SECURITY_GROUP'"], "Subnets": ["'$SUBNET'"] }' \ --node-provisioning-mode Continuous

Principais considerações de MinCount uso:

  • MinInstanceCountdeve estar entre 0 e o valor InstanceCount (inclusivo) do grupo de instâncias especificado em CreateCluster ou na UpdateCluster solicitação

  • MinInstanceCountA configuração como 0 (padrão) preserva o comportamento padrão de escalabilidade contínua

  • O padrão MinInstanceCount para Controller e Login InstanceGroup é definido como 1 durante a criação do cluster

  • Definir MinInstanceCount igual a InstanceCount fornece um comportamento de escalabilidade de tudo ou nada

  • MinCount só está disponível para clusters com NodeProvisioningMode definido como Continuous