Provisioning continuo per operazioni di cluster avanzate su Amazon EKS - Amazon SageMaker AI
Come funziona Misurazione dell'utilizzo Crea un cluster con il provisioning continuo abilitato

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Provisioning continuo per operazioni di cluster avanzate su Amazon EKS

SageMaker HyperPod I cluster Amazon creati con l'orchestrazione di Amazon EKS ora supportano il provisioning continuo, una nuova funzionalità che consente una maggiore flessibilità ed efficienza nell'esecuzione di carichi di lavoro su larga scala. AI/ML Il provisioning continuo consente di iniziare rapidamente la formazione, scalare senza problemi, eseguire la manutenzione senza interrompere le operazioni e avere una visibilità granulare sulle operazioni del cluster.

Nota

Il provisioning continuo è disponibile per i HyperPod cluster creati con l'orchestrazione EKS. I cluster creati con l'orchestrazione Slurm utilizzano un modello di scalabilità diverso.

Come funziona

Il provisioning continuo opera attraverso un'architettura basata sugli eventi che gestisce ogni istanza in modo indipendente. Quando si crea un HyperPod cluster, si specifica il numero di istanze desiderato per ogni gruppo di istanze. Il sistema di provisioning continuo:

  • Accetta la richiesta: registra il conteggio delle istanze di destinazione per ogni gruppo di istanze

  • Avvia il provisioning: avvia l'avvio delle istanze per soddisfare il conteggio previsto

    Monitora i progressi: monitora ogni tentativo di avvio dell'istanza e ne registra lo stato

  • Gestisce gli errori: riprova automaticamente gli avvii non riusciti

Il provisioning continuo è disabilitato per impostazione predefinita. Per utilizzare questa funzionalità, imposta su--node-provisioning-mode. Continuous

Con il provisioning continuo abilitato, è possibile avviare più operazioni di scalabilità contemporaneamente senza attendere il completamento delle operazioni precedenti. Ciò consente di scalare contemporaneamente diversi gruppi di istanze nello stesso cluster e di inviare più richieste di scalabilità allo stesso gruppo di istanze.

Il provisioning continuo consente inoltre l'accesso DescribeClusterEvente il monitoraggio dettagliato degli eventi e ListClusterEventla visibilità operativa.

Misurazione dell'utilizzo

HyperPod i cluster con provisioning continuo utilizzano la misurazione a livello di istanza per fornire una fatturazione accurata che rifletta l'utilizzo effettivo delle risorse. Questo approccio di misurazione si differenzia dalla tradizionale fatturazione a livello di cluster in quanto monitora ogni istanza in modo indipendente.

Fatturazione a livello di istanza

Con il provisioning continuo, la fatturazione inizia e si interrompe a livello di singola istanza anziché attendere le modifiche dello stato a livello di cluster. Questo approccio offre i seguenti vantaggi:

  • Precisione di fatturazione precisa: la fatturazione inizia quando inizia l'esecuzione dello script del ciclo di vita. Se lo script del ciclo di vita fallisce, la fornitura dell'istanza verrà ritentata e ti verrà addebitata la durata del runtime dello script del ciclo di vita.

  • Misurazione indipendente: il ciclo di vita di fatturazione di ogni istanza viene gestito separatamente, evitando errori di fatturazione a cascata

  • Aggiornamenti di fatturazione in tempo reale: la fatturazione inizia quando un'istanza inizia a eseguire lo script del ciclo di vita e si interrompe quando l'istanza entra in uno stato di terminazione

Ciclo di vita della fatturazione

Ogni istanza del HyperPod cluster segue questo ciclo di vita di fatturazione:

  • La fatturazione inizia: quando l'istanza viene avviata correttamente e inizia a eseguire lo script di configurazione del ciclo di vita

  • La fatturazione continua: per tutta la durata operativa dell'istanza

  • La fatturazione si interrompe: quando l'istanza entra in uno stato di chiusura, indipendentemente dal motivo della chiusura

Nota

La fatturazione non viene avviata per le istanze che non vengono avviate. Se l'avvio di un'istanza fallisce a causa di una capacità insufficiente o di altri problemi, non ti verrà addebitato alcun costo per il tentativo fallito. La fatturazione viene calcolata a livello di istanza e i costi vengono aggregati e riportati nell'Amazon Resource Name (ARN) del cluster.

Crea un cluster con il provisioning continuo abilitato

Nota

È necessario disporre di un cluster Amazon EKS esistente configurato con rete VPC e deve essere installato il grafico Helm richiesto. Inoltre, prepara uno script di configurazione del ciclo di vita e caricalo in un bucket Amazon S3 a cui può accedere il tuo ruolo di esecuzione.

La seguente AWS CLI operazione crea un HyperPod cluster con un gruppo di istanze e il provisioning continuo abilitato.

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>"
}

Dopo aver creato il cluster, puoi utilizzare ListClusterNodeso DescribeClusterNodeper trovare ulteriori informazioni sui nodi del cluster.

La chiamata a queste operazioni restituirà un ClusterInstanceStatusDetailsoggetto con uno dei seguenti valori:

  • In esecuzione: il nodo è integro e registrato presso il cluster orchestrator (EKS).

  • Errore: il provisioning del nodo non è riuscito, ma il sistema riproverà automaticamente a eseguire il provisioning con una nuova istanza. EC2

  • In sospeso: il provisioning o il riavvio del nodo è in corso.

  • ShuttingDown: La chiusura del nodo è in corso. Il nodo passerà allo stato di errore se la terminazione riscontra problemi oppure verrà rimosso correttamente dal cluster.

  • SystemUpdating: Il nodo è sottoposto a patch AMI, attivate manualmente o come parte dell'applicazione di patch ai cronjob.

  • DeepHealthCheckInProgress: Sono in corso controlli sanitari approfonditi () DHCs. Questa operazione potrebbe richiedere da pochi minuti a diverse ore a seconda della natura dei test. I nodi danneggiati vengono sostituiti e i nodi sani passano a Running.

  • NotFound: usato in BatchAddClusterNodesrisposta a indicare che un nodo è stato eliminato durante una riproduzione idempotente.