View a markdown version of this page

Provisioning continuo per operazioni avanzate del cluster con Slurm - Amazon SageMaker AI
Come funzionaProvisioning basato sulla prioritàGestione degli errori del controllerPrerequisitiMisurazione dell’utilizzoCreazione di un cluster con provisioning continuo abilitatoGestione della configurazione Slurm

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.

  2. Una volta che un nodo controller è integro, i nodi di accesso e i nodi di lavoro iniziano il provisioning in parallelo.

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

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

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.