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 [DescribeClusterEvent](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_DescribeClusterEvent.html)monitoramento detalhado [ListClusterEvent](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_ListClusterEvents.html)de 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](sagemaker-hyperpod-eks-operate.md). 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::cluster/" } ``` Depois de criar seu cluster, você pode [DescribeClusterNode](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_DescribeClusterNode.html)usar [ListClusterNodes](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_ListClusterNodes.html)ou descobrir mais informações sobre os nós no cluster. Chamar essas operações retornará um [ClusterInstanceStatusDetails](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_ClusterInstanceStatusDetails.html)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 pela correção da AMI, acionada manualmente ou como parte dos cronjobs de correção. + **DeepHealthCheckInProgress**: [Verificações profundas de saúde (DHCs)](sagemaker-hyperpod-eks-resiliency-deep-health-checks.md) 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](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_BatchAddClusterNodes.html)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 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 primeiro`InService`. 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 `Creating` status até que pelo menos as MinCount instâncias sejam provisionadas e prontas com sucesso. Quando esse limite é atingido, o grupo de instâncias passa para. `InService` + **Grupos de instâncias existentes**: ao atualizar MinCount 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 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](#sagemaker-hyperpod-scaling-eks-mincount-rollback). ### 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`, como`BatchDeleteClusterNodes`, ou `UpdateClusterSoftware` estã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 `InService` estado + **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 `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ç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 [ListClusterEvents](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_ListClusterEvents.html)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 sobre o MinCount uso: + `MinInstanceCount`deve estar entre 0 e o valor `InstanceCount` (inclusive) do grupo de instâncias especificado em [CreateCluster](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_CreateCluster.html)nossa [UpdateCluster](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateCluster.html)solicitação + `MinInstanceCount`Definir como 0 (padrão) preserva o comportamento padrão de escalabilidade contínua + A configuração `MinInstanceCount` igual a `InstanceCount` fornece comportamento de all-or-nothing escalabilidade + 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ância 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: + Tentativas de provisionar instâncias usando o primeiro tipo de instância na 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 como`Continuous`. 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` para 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](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_BatchAddClusterNodes.html)para adicionar nós com tipos de instância e zonas de disponibilidade específicos. Isso é particularmente útil quando o escalonamento automático do 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 do grupo de instâncias flexíveis Use [DescribeCluster](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_DescribeCluster.html)para ver os tipos de instância e a divisão por tipo do seu grupo de instâncias flexíveis. A resposta inclui: + `InstanceRequirements`— Os tipos de instância atuais e desejados para o grupo de instâncias + `InstanceTypeDetails`— Um per-instance-type detalhamento 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 do 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](sagemaker-hyperpod-eks-autoscaling.md) Quando você faz referência a um grupo de instâncias flexíveis em uma `HyperPodNodeClass` configuração, o Karpenter automaticamente: + Detecta os tipos de instância compatíveis do grupo de instâncias flexíveis + Seleciona o tipo de instância e a zona de disponibilidade ideais com base nos requisitos e preços do pod + Dimensiona o grupo de instâncias flexíveis usando `BatchAddClusterNodes` chamadas direcionadas com o tipo de instância e a zona de disponibilidade selecionados **nota** Quando o Karpenter gerencia o escalonamento, ele 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 provisionamento nativo HyperPod da (como `CreateCluster` e`UpdateCluster`), 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.