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 para HyperPod clusters criados com a orquestração EKS. Os clusters criados com a orquestração do Slurm usam um modelo de escalabilidade diferente.
Como funciona
O provisionamento contínuo opera por meio de uma arquitetura orientada por eventos que gerencia cada instância de forma independente. Ao criar um HyperPod cluster, você especifica o número desejado de instâncias para cada grupo de instâncias. 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 atingir a contagem alvo
Monitora o progresso: monitora cada tentativa de execução da instância e registra o status
-
Lida com falhas: repete automaticamente lançamentos com falha
O provisionamento contínuo está desativado por padrão. Para usar esse recurso, --node-provisioning-mode
defina comoContinuous
.
Com o provisionamento contínuo ativado, você pode iniciar várias operações de escalabilidade simultaneamente sem esperar que as operações anteriores sejam concluídas. Isso permite escalar diferentes grupos de instâncias no mesmo cluster simultaneamente e enviar várias solicitações de escalabilidade para o mesmo grupo de instâncias.
O provisionamento contínuo também oferece acesso ao DescribeClusterEventmonitoramento detalhado ListClusterEventde eventos e visibilidade operacional.
Medição de 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 no nível da instância individual, em vez de esperar pelas mudanças de estado no nível do cluster. Essa abordagem oferece os seguintes benefícios:
-
Precisão precisa do faturamento: o faturamento começa quando a execução do script do 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 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 à capacidade insuficiente ou a outros problemas, você não será cobrado por essa tentativa malsucedida. O faturamento é calculado no nível da instância e os custos são agregados e relatados sob o Amazon Resource Name (ARN) do seu cluster.
Crie um cluster com o provisionamento contínuo ativado
nota
Você deve ter um cluster Amazon EKS existente configurado com rede VPC e o gráfico Helm necessário instalado. Além disso, 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.
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-dev 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:
-
Em execução: 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
-
Pendente: o nó está sendo provisionado ou reinicializado.
-
ShuttingDown: O encerramento do nó está em andamento. O nó fará a transição para o status de Falha se o encerramento tiver problemas ou será removido com sucesso 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 defeituosos são substituídos e os nós saudáveis passam para Running.
-
NotFound: usado em BatchAddClusterNodesresposta para indicar que um nó foi excluído durante a reprodução idempotente.