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
InServicedepois 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:
-
O grupo de instâncias do controlador é provisionado primeiro.
-
Quando um nó do controlador está íntegro, os nós de login e os nós de trabalho começam a provisionar em paralelo.
-
O cluster faz a transição para
InServicequando 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 paraInServiceassim que o nó do controlador for provisionado. -
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
InServiceaté 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 como
Failed. -
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.confsã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
Creatingstatus 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
Updatingaté 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 mutantes
BatchAddClusterNodes, comoBatchDeleteClusterNodes, ouUpdateClusterSoftwareestã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
InServiceestado -
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
InServicestatus 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 valorInstanceCount(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
MinInstanceCountpara Controller e Login InstanceGroup é definido como 1 durante a criação do cluster -
Definir
MinInstanceCountigual aInstanceCountfornece um comportamento de escalabilidade de tudo ou nada -
MinCount só está disponível para clusters com
NodeProvisioningModedefinido comoContinuous