View a markdown version of this page

Provisionamento contínuo para operações de cluster aprimoradas no Amazon EKS - 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 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. HyperPod clusters criados com a orquestração Slurm também oferecem suporte ao provisionamento contínuo. Para obter detalhes, consulte Provisionamento contínuo para operações aprimoradas de cluster com o Slurm.

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 a DescribeClusterEvent e ListClusterEvent para monitoramento detalhado de eventos e visibilidade operacional.

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

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

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 usar ListClusterNodes ou DescribeClusterNode para descobrir mais informações sobre os nós no cluster.

Chamar essas operações retornará um ClusterInstanceStatusDetails objeto com um dos seguintes valores:

  • Running: o nó está íntegro e registrado no orquestrador de cluster (EKS).

  • Failure: o provisionamento do nó falhou, mas o sistema automaticamente tentará reprovisionar com uma nova instância do 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 por uma correção de AMI, acionada manualmente ou como parte da correção de cronjobs.

  • 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 BatchAddClusterNodes resposta 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 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 \ --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 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

  • 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

Grupos de instâncias flexíveis

Grupos de instâncias flexíveis permitem que você especifique vários tipos de instâncias em um único grupo de instâncias. Isso simplifica o gerenciamento de clusters ao reduzir o número de grupos de instâncias que você precisa criar e gerenciar, especialmente para cargas de trabalho de inferência que usam escalonamento automático.

Com grupos de instâncias flexíveis, HyperPod:

  • Tenta provisionar instâncias usando o primeiro tipo de instância em sua lista

  • Volta para os tipos de instância subsequentes se a capacidade não estiver disponível

  • Encerra primeiro as instâncias do tipo de instância de menor prioridade durante a redução

nota

Grupos de instâncias flexíveis só estão disponíveis para clusters com NodeProvisioningMode definido comoContinuous. As InstanceRequirements propriedades InstanceType e são mutuamente exclusivas — você pode especificar uma ou outra, mas não ambas.

Crie um cluster com um grupo de instâncias flexível

Use InstanceRequirements em vez de InstanceType criar um grupo de instâncias flexível. A ordem dos tipos de instância na lista determina a prioridade do provisionamento.

aws sagemaker create-cluster \ --cluster-name $HP_CLUSTER_NAME \ --orchestrator 'Eks={ClusterArn='$EKS_CLUSTER_ARN'}' \ --vpc-config '{ "SecurityGroupIds": ["'$SECURITY_GROUP'"], "Subnets": ["'$SUBNET_AZ1'", "'$SUBNET_AZ2'"] }' \ --instance-groups '[{ "InstanceGroupName": "flexible-ig", "InstanceRequirements": { "InstanceTypes": ["ml.p5.48xlarge", "ml.p4d.24xlarge", "ml.g6.48xlarge"] }, "InstanceCount": 10, "LifeCycleConfig": { "SourceS3Uri": "s3://'$BUCKET_NAME'", "OnCreate": "on_create.sh" }, "ExecutionRole": "'$EXECUTION_ROLE'" }]' \ --node-provisioning-mode Continuous

Escalabilidade direcionada com BatchAddClusterNodes

Ao usar grupos de instâncias flexíveis, você pode usar BatchAddClusterNodes para adicionar nós com tipos de instância e zonas de disponibilidade específicos. Isso é particularmente útil quando o escalonamento automático Karpenter determina o tipo de instância e a zona de disponibilidade ideais para sua carga de trabalho.

aws sagemaker batch-add-cluster-nodes \ --cluster-name $HP_CLUSTER_NAME \ --nodes-to-add '[ { "InstanceGroupName": "flexible-ig", "IncrementTargetCountBy": 1, "InstanceTypes": ["ml.p5.48xlarge"], "AvailabilityZones": ["us-west-2a"] } ]'

Veja detalhes flexíveis do grupo de instâncias

Use DescribeCluster para visualizar os tipos de instância e o detalhamento por tipo do seu grupo flexível de instâncias. A resposta inclui:

  • InstanceRequirements— Os tipos de instância atuais e desejados para o grupo de instâncias

  • InstanceTypeDetails— Um detalhamento por tipo de instância mostrando a contagem e a configuração de cada tipo de instância no grupo

Usando grupos de instâncias flexíveis com o escalonamento automático Karpenter

Grupos de instâncias flexíveis se integram ao HyperPod escalonamento automático gerenciado do Karpenter. Para obter mais informações sobre como configurar o Karpenter, consulte. Escalonamento automático no EKS SageMaker HyperPod Quando você faz referência a um grupo de instâncias flexível em uma HyperPodNodeClass configuração, o Karpenter automaticamente:

  • Detecta os tipos de instâncias compatíveis do grupo flexível de instâncias

  • Seleciona o tipo de instância e a zona de disponibilidade ideais com base nos requisitos e preços do pod

  • Dimensiona o grupo flexível de instâncias usando BatchAddClusterNodes chamadas direcionadas com o tipo de instância e a zona de disponibilidade selecionados

nota

Quando a Karpenter gerencia o escalonamento, ela usa sua própria lógica de seleção com base nos requisitos e preços do pod para determinar qual tipo de instância provisionar. Isso difere da prioridade de ordem de lista usada pelo HyperPod provisionamento nativo (como CreateCluster andUpdateCluster), em que o primeiro tipo de instância na lista sempre é tentado primeiro.

Isso elimina a necessidade de criar grupos de instâncias separados para cada tipo de instância e configurar manualmente o Karpenter para referenciar vários grupos.