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 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 l’addestramento, scalare senza problemi, eseguire la manutenzione senza interrompere le operazioni e avere una visibilità granulare sulle operazioni del cluster.
Nota
Il provisioning continuo è disponibile come configurazione opzionale per i cluster creati con l'orchestrazione EKS. HyperPod HyperPod i cluster creati con l'orchestrazione Slurm supportano anche il provisioning continuo. Per informazioni dettagliate, vedi Provisioning continuo per operazioni di cluster avanzate con Slurm.
Come funziona
Il sistema di provisioning continuo introduce un’architettura dello stato desiderato che sostituisce il tradizionale modello basato sulla richiesta. Questa nuova architettura consente operazioni parallele e non bloccanti su diversi livelli di risorse, mantenendo al contempo la stabilità e le prestazioni del sistema. Il sistema di provisioning continuo:
-
Accetta la richiesta: registra il numero delle istanze di destinazione per ogni gruppo di istanze
-
Avvia il provisioning: avvia le istanze per raggiungere il conteggio previsto
Monitora lo stato di avanzamento: monitora ogni tentativo di avvio dell’istanza e registra lo stato
-
Gestisce gli errori: riprova automaticamente gli avvii non riusciti
Il provisioning continuo è disabilitato per impostazione predefinita. Per utilizzare questa funzionalità, imposta --node-provisioning-mode su Continuous.
Con il provisioning continuo abilitato, puoi avviare più operazioni di dimensionamento 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 dimensionamento allo stesso gruppo di istanze.
Il provisioning continuo consente inoltre di accedere e accedere al monitoraggio dettagliato degli eventi DescribeClusterEvent e alla visibilità operativa ListClusterEvent.
Misurazione dell’utilizzo
HyperPod i cluster con provisioning continuo utilizzano la misurazione a livello di istanza per fornire una fatturazione accurata che rifletta l'effettivo utilizzo delle risorse. Questo approccio di misurazione si differenzia dalla tradizionale fatturazione a livello di cluster in quanto tiene traccia di ogni istanza in modo indipendente.
Instance-level fatturazione
Con il provisioning continuo, la fatturazione inizia e si arresta a livello della singola istanza anziché attendere le modifiche dello stato a livello di cluster. Questa funzionalità fornisce i seguenti vantaggi:
-
Accuratezza di fatturazione: la fatturazione inizia quando inizia l’esecuzione dello script del ciclo di vita. Se lo script del ciclo di vita non riesce, l’allocazione dell’istanza verrà ritentata e verrà addebitata la durata del runtime dello script del ciclo di vita.
-
Misurazione indipendente: il ciclo di vita della fatturazione di ogni istanza viene gestito separatamente, evitando errori di fatturazione a cascata
-
Real-time aggiornamenti di fatturazione: 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 arresta: quando l’istanza entra in uno stato di terminazione, indipendentemente dal motivo della terminazione
Nota
La fatturazione non inizia in caso di errori di avvio delle istanze. Se l’avvio di un’istanza non riesce a causa di una capacità insufficiente o di altri problemi, non verrà addebitato alcun costo per il tentativo non riuscito. La fatturazione viene calcolata a livello di istanza e i costi sono aggregati e riportati nel nome della risorsa Amazon (ARN) del cluster.
Creazione di un cluster con provisioning continuo abilitato
Nota
È necessario che sia configurato un cluster Amazon EKS esistente con la rete VPC e che sia installato il grafico Helm richiesto. Inoltre, devi preparare uno script di configurazione del ciclo di vita e devi caricarlo in un bucket Amazon S3 a cui può accedere il tuo ruolo di esecuzione. Per ulteriori informazioni, consulta Gestione dei SageMaker HyperPod cluster orchestrati da Amazon EKS.
La seguente AWS CLI operazione crea un HyperPod cluster con un gruppo di istanze e il provisioning continuo è abilitato.
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>" }
Dopo aver creato il cluster, puoi utilizzare ListClusterNodes or DescribeClusterNode per trovare ulteriori informazioni sui nodi del cluster.
La chiamata a queste operazioni restituirà un ClusterInstanceStatusDetails oggetto con uno dei seguenti valori:
-
Running: il nodo è integro e registrato con l’orchestratore del cluster (EKS).
-
Failure: il provisioning del nodo non è riuscito, ma il sistema riprova automaticamente a eseguire il provisioning con una nuova istanza EC2.
-
Pending: è in corso il provisioning o il riavvio del nodo.
-
ShuttingDown: La terminazione del nodo è in corso. Il nodo viene rimosso correttamente dal cluster oppure passa in stato di errore se si verificano errori durante la terminazione.
-
SystemUpdating: il nodo è sottoposto a patch AMI, attivate manualmente o come parte dell'applicazione di patch ai cronjobs.
-
DeepHealthCheckInProgress: Sono in corso controlli sanitari approfonditi (DHC). Questa operazione potrebbe richiedere da pochi minuti a diverse ore a seconda della natura dei test. I nodi danneggiati vengono sostituiti e i nodi integri passano in stato Running.
-
NotFound: utilizzato in BatchAddClusterNodes risposta per indicare che un nodo è stato eliminato durante la riproduzione idempotente.
Requisiti minimi di capacità () MinCount
La MinCount funzionalità consente di specificare il numero minimo di istanze di cui è necessario eseguire correttamente il provisioning prima che un gruppo di istanze passi allo stato. InService Questa funzionalità offre un migliore controllo sulle operazioni di scalabilità e aiuta a prevenire scenari in cui i gruppi di istanze parzialmente assegnati non possono essere utilizzati efficacemente per l'addestramento dei carichi di lavoro.
Importante
MinCount non è una garanzia permanente di capacità minima. Assicura che il numero minimo di istanze specificato sia disponibile solo quando il gruppo di istanze diventa InService disponibile per la prima volta. Di seguito MinCount possono verificarsi brevi cali durante le normali operazioni, ad esempio sostituzioni di istanze non integre o attività di manutenzione.
Come funziona MinCount
Quando si crea o si aggiorna un gruppo di istanze con MinCount abilitato, si verifica il seguente comportamento:
-
Nuovi gruppi di istanze: lo
Creatingstato del gruppo di istanze rimane attivo fino a quando almeno MinCount le istanze non vengono eseguite correttamente e sono pronte. Una volta raggiunta questa soglia, il gruppo di istanze passa a.InService -
Gruppi di istanze esistenti: quando si MinCount esegue l'aggiornamento su un gruppo di istanze esistente, lo stato cambia
Updatingfino a quando non viene soddisfatto il nuovo MinCount requisito. -
Scalabilità continua: se TargetCount è maggiore di MinCount, il sistema di ridimensionamento continuo continua a tentare di avviare istanze aggiuntive finché non viene raggiunto. TargetCount
-
Timeout e rollback: se MinCount non può essere soddisfatto entro 3 ore, il sistema ripristina automaticamente il gruppo di istanze all'ultimo stato valido noto. Per ulteriori informazioni sul comportamento di rollback, vedi Comportamento di rollback automatico.
Stato del gruppo di istanze durante le operazioni MinCount
I gruppi di istanze MinCount configurati presentano il seguente comportamento di stato:
- Creazione in corso
-
Per i nuovi gruppi di istanze quando CurrentCount < MinCount. Il gruppo di istanze rimane in questo stato fino a quando non viene soddisfatto il requisito minimo di capacità.
- Aggiornamento in corso
-
Per i gruppi di istanze esistenti quando MinCount è modificato e CurrentCount < MinCount. Il gruppo di istanze rimane in questo stato finché non viene soddisfatto il nuovo requisito di capacità minima.
- InService
-
Quando MinCount ≤ CurrentCount ≤ TargetCount. Il gruppo di istanze è pronto per l'uso e tutte le operazioni di mutazione sono sbloccate.
Durante Updating lo stato Creating o, si applicano le seguenti restrizioni:
-
Operazioni di mutazione come
BatchAddClusterNodes,BatchDeleteClusterNodes, oUpdateClusterSoftwaresono bloccate -
È comunque possibile modificare TargetCount i valori MinCount AF per correggere gli errori di configurazione
-
L'eliminazione di cluster e gruppi di istanze è sempre consentita
Comportamento di rollback automatico
Se un gruppo di istanze non riesce a raggiungerlo MinCount entro 3 ore, il sistema avvia automaticamente un rollback per evitare attese indefinite:
-
Nuovi gruppi di istanze: MinCount e TargetCount vengono reimpostati su (0, 0)
-
Gruppi di istanze esistenti: MinCount e TargetCount vengono ripristinati ai loro valori dall'ultimo
InServicestato -
Selezione dell'istanza per la chiusura: se le istanze devono essere terminate durante il rollback, il sistema seleziona prima le istanze non integre, quindi quelle di cui è stato effettuato il provisioning più recente.
-
Transizione di stato: il gruppo di istanze passa immediatamente
InServiceallo stato dopo l'avvio del rollback, consentendo al sistema di scalabilità continua di gestire la capacità in base alle impostazioni di rollback
Il timeout di 3 ore si ripristina ogni volta che viene aggiornato. MinCount Ad esempio, se si esegue l'aggiornamento MinCount più volte, il periodo di timeout riparte dall'aggiornamento più recente.
MinCount eventi
Il sistema emette eventi specifici per aiutarti a tenere traccia MinCount delle operazioni:
-
Capacità minima raggiunta: emessa quando un gruppo di istanze raggiunge con successo la sua MinCount e passa a
InService -
Rollback avviato: emesso quando scade il timeout di 3 ore e inizia il rollback automatico
Puoi monitorare questi eventi utilizzando lo strumento per tracciare lo stato di avanzamento delle tue ListClusterEvents operazioni. MinCount
Utilizzo delle API
MinCount viene specificato utilizzando il MinInstanceCount parametro nelle configurazioni dei gruppi di istanze:
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
Considerazioni chiave per MinCount l'utilizzo:
-
MinInstanceCountdeve essere compreso tra 0 e il valoreInstanceCount(incluso) del gruppo di istanze specificato nella CreateCluster richiesta UpdateCluster -
L'impostazione
MinInstanceCountsu 0 (impostazione predefinita) mantiene il comportamento standard di ridimensionamento continuo -
L'impostazione
MinInstanceCountuguale aInstanceCountfornisce un comportamento di ridimensionamento tutto o niente -
MinCount è disponibile solo per i cluster con impostazione su
NodeProvisioningModeContinuous
Gruppi di istanze flessibili
I gruppi di istanze flessibili consentono di specificare più tipi di istanze all'interno di un singolo gruppo di istanze. Ciò semplifica la gestione dei cluster riducendo il numero di gruppi di istanze da creare e gestire, in particolare per i carichi di lavoro di inferenza che utilizzano la scalabilità automatica.
Con gruppi di istanze flessibili,: HyperPod
-
Tenta di effettuare il provisioning delle istanze utilizzando il primo tipo di istanza nell'elenco
-
Ritorna ai tipi di istanza successivi se la capacità non è disponibile
-
Termina per prime le istanze del tipo di istanza con la priorità più bassa durante lo scaling down
Nota
I gruppi di istanze flessibili sono disponibili solo per i cluster impostati su. NodeProvisioningMode Continuous Le InstanceRequirements proprietà InstanceType e si escludono a vicenda: è possibile specificare l'una o l'altra, ma non entrambe.
Crea un cluster con un gruppo di istanze flessibile
Usa InstanceRequirements invece di InstanceType per creare un gruppo di istanze flessibile. L'ordine dei tipi di istanza nell'elenco determina la priorità per il provisioning.
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
Scalabilità mirata con BatchAddClusterNodes
Quando si utilizzano gruppi di istanze flessibili, è possibile utilizzare BatchAddClusterNodes per aggiungere nodi con tipi di istanze e zone di disponibilità specifici. Ciò è particolarmente utile quando la scalabilità automatica di Karpenter determina il tipo di istanza e la zona di disponibilità ottimali per il carico di lavoro.
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"] } ]'
Visualizza i dettagli flessibili del gruppo di istanze
Utilizzalo DescribeCluster per visualizzare i tipi di istanze e la suddivisione per tipo del tuo gruppo di istanze flessibili. La risposta include:
-
InstanceRequirements— I tipi di istanza attuali e desiderati per il gruppo di istanze -
InstanceTypeDetails— Una suddivisione per tipo di istanza che mostra il numero e la configurazione di ogni tipo di istanza nel gruppo
Utilizzo di gruppi di istanze flessibili con la scalabilità automatica di Karpenter
I gruppi di istanze flessibili si integrano con HyperPod la scalabilità automatica gestita da Karpenter. Per ulteriori informazioni sulla configurazione di Karpenter, vedere. Scalabilità automatica su EKS SageMaker HyperPod Quando si fa riferimento a un gruppo di istanze flessibile in una HyperPodNodeClass configurazione, Karpenter automaticamente:
-
Rileva i tipi di istanza supportati dal gruppo di istanze flessibile
-
Seleziona il tipo di istanza e la zona di disponibilità ottimali in base ai requisiti e ai prezzi dei pod
-
Scala il gruppo di istanze flessibile utilizzando
BatchAddClusterNodeschiamate mirate con il tipo di istanza e la zona di disponibilità selezionati
Nota
Quando Karpenter gestisce la scalabilità, utilizza la propria logica di selezione basata sui requisiti e sui prezzi dei pod per determinare il tipo di istanza da fornire. Ciò è diverso dalla priorità in ordine di elenco utilizzata dal HyperPod provisioning nativo (ad esempio CreateCluster andUpdateCluster), in cui il primo tipo di istanza dell'elenco viene sempre tentato per primo.
Ciò elimina la necessità di creare gruppi di istanze separati per ogni tipo di istanza e configurare manualmente Karpenter in modo che faccia riferimento a più gruppi.