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 no Amazon EKS
SageMaker HyperPod Os clusters da Amazon criados com a orquestração do Amazon EKS agora oferecem suporte ao provisionamento contínuo, um novo recurso que permite maior flexibilidade e eficiência na execução de 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 EKS. Os clusters criados com a orquestração do Slurm usam um modelo de ajuste de escala diferente.
Como funciona
O sistema de provisionamento contínuo introduz uma arquitetura de estado desejado que substitui o modelo tradicional baseado em solicitações. Essa nova arquitetura permite operações paralelas e sem bloqueio em diferentes níveis de recurso, mantendo a estabilidade e o desempenho do sistema. 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 executar instâncias para atingir a contagem pretendida.
Monitora o progresso: monitora cada tentativa de execução da instância e registra o status.
-
Lida com falhas: repete automaticamente as execuções que falharam.
O provisionamento contínuo está desabilitado por padrão. Para usar esse recurso, defina --node-provisioning-mode como Continuous.
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.
O provisionamento contínuo também oferece acesso ao DescribeClusterEventmonitoramento detalhado ListClusterEventde eventos e visibilidade operacional.
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 de ciclo de vida falhar, o provisionamento da instância será repetido e você receberá cobrança pela duração do tempo de execução do script de ciclo de vida.
-
Medição independente: o ciclo de vida do faturamento de cada instância é gerenciado separadamente, evitando erros de faturamento em cascata.
-
Atualizações de faturamento em tempo real: o faturamento começa quando uma instância começa a executar o respectivo script de 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 êxito e começa a executar o respectivo script de configuração do ciclo de vida.
-
O faturamento continua durante todo o ciclo de vida operacional da instância.
-
O faturamento é interrompido quando a instância entra em um estado de encerramento, independentemente do respectivo motivo.
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
Você deve ter um cluster do Amazon EKS já configurado com rede VPC e o chart do Helm necessário instalado. Além disso, prepare um script de configuração de ciclo de vida e carregue-o em um bucket do Amazon S3 que seu perfil de execução possa acessar. Para obter mais informações, consulte Gerenciamento de SageMaker HyperPod clusters orquestrados pelo Amazon EKS.
A AWS CLI operação a seguir cria um HyperPod cluster com um grupo de instâncias e o provisionamento contínuo ativado.
aws sagemaker create-cluster \ --cluster-name $HP_CLUSTER_NAME \ --orchestrator 'Eks={ClusterArn='$EKS_CLUSTER_ARN'}' \ --vpc-config '{ "SecurityGroupIds": ["'$SECURITY_GROUP'"], "Subnets": ["'$SUBNET'"] }' \ --instance-groups '{ "InstanceGroupName": "ig-1", "InstanceType": "ml.c5.2xlarge", "InstanceCount": 2, "LifeCycleConfig": { "SourceS3Uri": "s3://'$BUCKET_NAME'", "OnCreate": "on_create_noop.sh" }, "ExecutionRole": "'$EXECUTION_ROLE'", "ThreadsPerCore": 1, "TrainingPlanArn": "" }' \ --node-provisioning-mode Continuous // Expected Output: { "ClusterArn": "arn:aws:sagemaker:us-west-2:<account-id>:cluster/<cluster-id>" }
Depois de criar seu cluster, você pode DescribeClusterNodeusar ListClusterNodesou descobrir mais informações sobre os nós no cluster.
Chamar essas operações retornará um ClusterInstanceStatusDetailsobjeto com um dos seguintes valores:
-
Running: o nó está íntegro e registrado no orquestrador de cluster (EKS).
-
Falha: o provisionamento do nó falhou, mas o sistema tentará automaticamente o provisionamento novamente com uma nova instância. EC2
-
Pending: o nó está sendo provisionado ou reinicializado.
-
ShuttingDown: O encerramento do nó está em andamento. O nó fará a transição para o status Failure se houver problemas no encerramento ou será removido com êxito do cluster.
-
SystemUpdating: o nó está passando pela correção da AMI, acionada manualmente ou como parte dos cronjobs de correção.
-
DeepHealthCheckInProgress: Verificações profundas de saúde (DHCs) estão sendo conduzidas. Isso pode levar de alguns minutos a várias horas, dependendo da natureza dos testes. Os nós com defeito são substituídos e os nós íntegros passam para Running.
-
NotFound: usado em BatchAddClusterNodesresposta para indicar que um nó foi excluído durante a reprodução idempotente.
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 faça a transição 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 se tornar o primeiroInService. MinCount Podem ocorrer breves quedas abaixo 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 no
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.InService -
Grupos de instâncias existentes: ao atualizar MinCount 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 continua tentando iniciar instâncias adicionais até que seja TargetCount alcançada.
-
Tempo limite e reversão: se MinCount não puder ser satisfeito em 3 horas, o sistema reverte 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
Grupos de instâncias com MinCount configurado apresentam 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 mínimo de capacidade 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 MinCount TargetCount valores para corrigir erros de configuração
-
A exclusão de clusters e grupos de 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 selecionará primeiro as instâncias com problemas de integridade e depois as que foram provisionadas mais recentemente.
-
Transição de status: o grupo de instâncias muda 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ça novamente a partir da atualização mais recente.
MinCount eventos
O sistema emite eventos específicos para ajudar você a monitorar MinCount as operações:
-
Capacidade mínima atingida: emitida quando um grupo de instâncias alcança sua 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 ListClusterEventspara 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 \ --orchestrator 'Eks={ClusterArn='$EKS_CLUSTER_ARN'}' \ --vpc-config '{ "SecurityGroupIds": ["'$SECURITY_GROUP'"], "Subnets": ["'$SUBNET'"] }' \ --instance-groups '{ "InstanceGroupName": "worker-group", "InstanceType": "ml.p4d.24xlarge", "InstanceCount": 64, "MinInstanceCount": 50, "LifeCycleConfig": { "SourceS3Uri": "s3://'$BUCKET_NAME'", "OnCreate": "on_create.sh" }, "ExecutionRole": "'$EXECUTION_ROLE'" }' \ --node-provisioning-mode Continuous
Principais considerações sobre o MinCount uso:
-
MinInstanceCountdeve estar entre 0 e o valorInstanceCount(inclusive) do grupo de instâncias especificado em CreateClusternossa UpdateClustersolicitação -
MinInstanceCountDefinir como 0 (padrão) preserva o comportamento padrão de escalabilidade contínua -
A configuração
MinInstanceCountigual aInstanceCountfornece comportamento de all-or-nothing escalabilidade -
MinCount só está disponível para clusters com
NodeProvisioningModedefinido comoContinuous