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 avanzate del cluster con Slurm
SageMaker HyperPod I cluster Amazon creati con l'orchestrazione Slurm ora supportano il provisioning continuo, una funzionalità che consente maggiore flessibilità ed efficienza durante l'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 nuovi cluster creati con l'orchestrazione Slurm. HyperPod Al momento, i cluster esistenti che utilizzano il modello di scalabilità precedente non possono essere migrati al provisioning continuo.
## Come funziona
Il sistema di provisioning continuo introduce un'architettura dello stato desiderato che sostituisce il modello di scalabilità tradizionale. all-or-nothing Nel modello precedente, se non era possibile effettuare il provisioning completo di un gruppo di istanze, l'intera operazione di creazione o aggiornamento del cluster non funzionava e veniva ripristinata. Con il provisioning continuo, il sistema accetta una capacità parziale e continua a fornire le istanze rimanenti in modo asincrono.
Il sistema di provisioning continuo:
+ **Accetta la richiesta**: registra il numero di istanze di destinazione per ogni gruppo di istanze.
+ **Avvia il provisioning**: inizia a lanciare le istanze per tutti i gruppi di istanze in parallelo.
+ Effettua **innanzitutto il provisioning dei nodi prioritari**: il cluster passa a `InService` dopo che almeno un nodo controller (e un nodo di accesso, se viene specificato un gruppo di istanze di login) è stato eseguito correttamente.
+ Monitora l'**avanzamento**: monitora ogni tentativo di avvio dell'istanza e ne registra lo stato.
+ **Gestisce gli errori**: riprova automaticamente gli avvii non riusciti per i nodi di lavoro in modo asincrono.
Il provisioning continuo è disabilitato per impostazione predefinita. Per utilizzare questa funzionalità, impostala nella richiesta. `NodeProvisioningMode` `Continuous` `CreateCluster`
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.
## Provisioning basato sulla priorità
I cluster Slurm richiedono che un nodo controller sia operativo prima che i nodi di lavoro possano registrare e accettare lavori. Il provisioning continuo gestisce questo problema automaticamente tramite il provisioning basato sulle priorità:
1. Il gruppo di istanze del controller viene fornito per primo.
1. Una volta che un nodo controller è integro, i nodi di accesso e i nodi di lavoro iniziano il provisioning in parallelo.
1. Il cluster passa alla fase in `InService` cui un nodo di controller è attivo e un nodo di accesso è attivo (se viene specificato un gruppo di istanze di login). Se non viene specificato alcun gruppo di istanze di login, la transizione del cluster avviene non `InService` appena viene effettuato il provisioning del nodo di controller.
1. I nodi di lavoro che non possono essere immediatamente forniti a causa di vincoli di capacità entrano in un ciclo di tentativi asincrono e vengono aggiunti automaticamente al cluster Slurm non appena diventano disponibili.
## Gestione degli errori del controller
Durante la creazione del cluster, se il nodo controller non riesce a eseguire il provisioning, il comportamento dipende dal fatto che l'errore sia riprovabile o meno.
**Errori rieseguibili (ad esempio, istanze non integre o errori** temporanei):
+ HyperPod sostituisce continuamente l'istanza e riprova il provisioning fino all'attivazione del controller.
+ I nodi di lavoro e di accesso che sono già stati forniti rimangono disponibili, ma il cluster non effettua la transizione `InService` finché il controller non è integro.
**Errori non ripetibili** (ad esempio, nessuna capacità disponibile per il tipo di istanza del controller o l'errore dello script del ciclo di vita):
+ Il cluster è contrassegnato come. `Failed`
+ Il motivo dell'errore viene notificato all'utente e deve intraprendere azioni correttive, ad esempio scegliere un tipo di istanza diverso, correggere gli script del ciclo di vita o riprovare in un'altra zona di disponibilità.
## Prerequisiti
Il provisioning continuo richiede che i parametri di provisioning di Slurm (tipi di nodi, nomi delle partizioni) siano forniti tramite il payload dell'API nel campo di ciascun gruppo di istanze. `SlurmConfig` I cluster che si basano sul `provisioning_parameters.json` file legacy in Amazon S3 non sono compatibili con il provisioning continuo.
**Nota**
Le seguenti funzionalità non sono attualmente supportate con il provisioning continuo sui cluster Slurm: migrazione di cluster esistenti, configurazione a nodi multipli tramite topologia Slurm basata su API e. `SlurmConfigStrategy` Il provisioning `slurm.conf` continuo funziona esclusivamente in modalità di fusione per la gestione.
## 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 tiene traccia di ogni istanza in modo indipendente.
**Fatturazione a livello di istanza**
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 fallisce, la fornitura dell'istanza verrà ritentata e all'utente 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 di configurazione 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 ha inizio**: 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 terminazione, indipendentemente dal motivo della chiusura.
**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**
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. Per ulteriori informazioni, consulta [SageMaker HyperPod Operazioni del cluster Slurm](sagemaker-hyperpod-operate-slurm.md).
Prepara un file di richiesta `CreateCluster` API in formato JSON. Imposta `NodeProvisioningMode` `Continuous` e fornisci informazioni sulla topologia Slurm nel campo di ogni gruppo di istanze. `SlurmConfig`
```
// create_cluster.json
{
"ClusterName": "my-training-cluster",
"NodeProvisioningMode": "Continuous",
"Orchestrator": {
"Slurm": {}
},
"InstanceGroups": [
{
"InstanceGroupName": "controller-group",
"InstanceType": "ml.m5.xlarge",
"InstanceCount": 1,
"LifeCycleConfig": {
"SourceS3Uri": "s3://amzn-s3-demo-bucket/lifecycle-scripts/src/",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "arn:aws:iam::111122223333:role/iam-role-for-cluster",
"SlurmConfig": {
"NodeType": "Controller"
}
},
{
"InstanceGroupName": "login-group",
"InstanceType": "ml.m5.xlarge",
"InstanceCount": 1,
"LifeCycleConfig": {
"SourceS3Uri": "s3://amzn-s3-demo-bucket/lifecycle-scripts/src/",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "arn:aws:iam::111122223333:role/iam-role-for-cluster",
"SlurmConfig": {
"NodeType": "Login"
}
},
{
"InstanceGroupName": "worker-gpu-a",
"InstanceType": "ml.p5.48xlarge",
"InstanceCount": 16,
"LifeCycleConfig": {
"SourceS3Uri": "s3://amzn-s3-demo-bucket/lifecycle-scripts/src/",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "arn:aws:iam::111122223333:role/iam-role-for-cluster",
"SlurmConfig": {
"NodeType": "Compute",
"PartitionNames": ["gpu-training"]
}
}
],
"VpcConfig": {
"SecurityGroupIds": ["sg-12345678"],
"Subnets": ["subnet-12345678"]
}
}
```
Esegui il `create-cluster` comando per inviare la richiesta.
```
aws sagemaker create-cluster \
--cli-input-json file://complete/path/to/create_cluster.json
```
Questo restituisce l'ARN del nuovo cluster.
```
{
"ClusterArn": "arn:aws:sagemaker:us-west-2:111122223333:cluster/abcde12345"
}
```
## Gestione della configurazione Slurm
Il provisioning continuo funziona esclusivamente in modalità di fusione per la gestione delle partizioni. `slurm.conf` In modalità merge, HyperPod applica le modifiche alla configurazione delle partizioni in modo additivo alle modifiche apportate. `slurm.conf` HyperPod aggiorna solo le sezioni relative alla partizione di `slurm.conf` (come le voci relative al nome della partizione e al nome del nodo); gli altri parametri di configurazione di Slurm non vengono modificati. Ciò significa che:
+ Le modifiche manuali di vengono mantenute. `slurm.conf`
+ Non è previsto il rilevamento automatico delle deviazioni o la risoluzione dei conflitti tra le modifiche apportate e HyperPod lo stato previsto.
Il `SlurmConfigStrategy` parametro (`Managed`,`Merge`,`Overwrite`) non è supportato con il provisioning continuo. Il passaggio di qualsiasi `SlurmConfigStrategy` valore genera un errore API.