Slurmstrategie di allocazione dinamica dei nodi nella versione 3.8.0 - AWS ParallelCluster

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

Slurmstrategie di allocazione dinamica dei nodi nella versione 3.8.0

A partire dalla ParallelCluster versione 3.8.0, ParallelCluster utilizza la scalabilità a livello di processo o la scalabilità a livello di processo come strategia di allocazione dinamica dei nodi predefinita per ParallelCluster scalare il cluster: ridimensiona il cluster in base ai requisiti di ciascun job, al numero di nodi allocati al job e ai nodi che devono essere ripristinati. ParallelCluster ottiene queste informazioni dalla variabile di ambiente SLURM_RESUME_FILE.

La scalabilità per i nodi dinamici è un processo in due fasi, che prevede il lancio delle istanze EC2 e l'assegnazione delle istanze Amazon EC2 avviate ai nodi. Slurm Ciascuno di questi due passaggi può essere eseguito utilizzando una logica o best-effort. all-or-nothing

Per il lancio delle istanze Amazon EC2:

  • all-or-nothingchiama l'API Amazon EC2 di lancio con un target minimo pari alla capacità target totale

  • best-effort chiama il lancio dell'API Amazon EC2 con un target minimo pari a 1 e la capacità target totale è uguale alla capacità richiesta

Per l'assegnazione delle istanze Slurm Amazon EC2 ai nodi:

  • all-or-nothingassegna istanze Amazon EC2 Slurm ai nodi solo se è possibile assegnare un'istanza Amazon EC2 a ogni nodo richiesto

  • best-effort assegna le istanze di Amazon EC2 Slurm ai nodi anche se tutti i nodi richiesti non sono coperti dalla capacità delle istanze di Amazon EC2

    Le possibili combinazioni delle strategie di cui sopra si traducono nelle strategie di lancio. ParallelCluster

Esempio
The available ParallelCluster strategie di lancio that can be set into the ScalingStrategy cluster configuration to be used with scalabilità a livello di lavoro are:

all-or-nothingridimensionamento:

Questa strategia prevede l' AWS ParallelCluster avvio di una chiamata API di avvio di Amazon EC2 per ogni job, che richiede che tutte le istanze necessarie per il corretto avvio dei nodi di calcolo richiesti. Ciò garantisce la scalabilità del cluster solo quando è disponibile la capacità richiesta per processo, evitando che le istanze inattive rimangano inattive alla fine del processo di scalabilità.

La strategia utilizza una all-or-nothinglogica per il lancio delle istanze Amazon EC2 per ogni processo e una all-or-nothinglogica per l'assegnazione delle istanze Amazon EC2 ai nodi. Slurm

La strategia raggruppa le richieste di lancio in batch, uno per ogni risorsa di calcolo richiesta e fino a 500 nodi ciascuno. Per le richieste che riguardano più risorse di elaborazione o superano i 500 nodi, elabora in sequenza più batch. ParallelCluster

L'errore del batch di una singola risorsa comporta la chiusura di tutta la capacità inutilizzata associata, garantendo che nessuna istanza rimanga inattiva al termine del processo di scalabilità.

Limitazioni

  • Il tempo impiegato per il ridimensionamento è direttamente proporzionale al numero di lavori inviati per esecuzione del programma di curriculum. Slurm

  • L'operazione di scalabilità è limitata dal limite dell'account di RunInstances risorse, impostato a 1000 istanze per impostazione predefinita. Questa limitazione è conforme alle politiche AWS di limitazione delle API EC2, per maggiori dettagli, consulta la documentazione sulla limitazione delle API di Amazon EC2

  • Quando invii un lavoro in una risorsa di elaborazione con un singolo tipo di istanza, in una coda che si estende su più zone di disponibilità, la chiamata all'API di avvio all-or-nothingEC2 ha successo solo se tutta la capacità può essere fornita in un'unica zona di disponibilità.

  • Quando invii un lavoro in una risorsa di calcolo con più tipi di istanze, in una coda con un'unica zona di disponibilità, la all-or-nothingchiamata all'API di avvio di Amazon EC2 ha successo solo se tutta la capacità può essere fornita da un singolo tipo di istanza.

  • Quando invii un lavoro in una risorsa di calcolo con più tipi di istanze, in una coda che si estende su più zone di disponibilità, la chiamata API di lancio di Amazon EC2 all-or-nothingnon è supportata ed esegue invece la scalabilità ottimale. ParallelCluster

greedy-all-or-nothingridimensionamento:

Questa variante della all-or-nothing strategia garantisce comunque la scalabilità del cluster solo quando è disponibile la capacità richiesta per processo, evitando le istanze inattive alla fine del processo di scalabilità, ma implica l'avvio di ParallelCluster una chiamata API di avvio di Amazon EC2 che mira a una capacità target minima di 1, nel tentativo di massimizzare il numero di nodi avviati fino alla capacità richiesta. La strategia utilizza una logica best-effort per il lancio delle istanze EC2 per tutti i job, oltre alla all-or-nothinglogica per l'assegnazione delle istanze Amazon EC2 ai nodi per ogni job. Slurm

La strategia raggruppa le richieste di lancio in batch, uno per ogni risorsa di calcolo richiesta e fino a 500 nodi ciascuno. Per le richieste che riguardano più risorse di elaborazione o superano i 500 nodi, elabora in sequenza più batch. ParellelCluster

Garantisce che nessuna istanza venga lasciata inattiva alla fine del processo di scalabilità, massimizzando la velocità effettiva a scapito di un temporaneo sovradimensionamento durante il processo di scalabilità.

Limitazioni

  • È possibile un sovradimensionamento temporaneo, che comporta costi aggiuntivi per le istanze che passano allo stato di esecuzione prima del completamento della scalabilità.

  • Si applica lo stesso limite di istanze previsto dalla all-or-nothing strategia, soggetto al limite dell'account di AWS risorse. RunInstances

scalabilità con il massimo sforzo:

Questa strategia prevede una chiamata all'API di avvio di Amazon EC2 mirando a una capacità minima di 1 e mirando a raggiungere la capacità totale richiesta al costo di lasciare le istanze inattive dopo l'esecuzione del processo di scalabilità se non tutta la capacità richiesta è disponibile. La strategia utilizza una logica best-effort per il lancio delle istanze Amazon EC2 per tutti i lavori, oltre alla logica best-effort per l'assegnazione delle istanze Amazon EC2 ai nodi Slurm per ogni processo.

La strategia raggruppa le richieste di avvio in batch, uno per ogni risorsa di calcolo richiesta e fino a 500 nodi ciascuno. Per le richieste che riguardano più risorse di elaborazione o superano i 500 nodi, elabora in sequenza più batch. ParallelCluster

Questa strategia consente di scalare ben oltre il limite predefinito di 1000 istanze su più esecuzioni di processi di scalabilità, al costo di avere istanze inattive tra i diversi processi di scalabilità.

Limitazioni

  • Possibili istanze inattive in esecuzione alla fine del processo di scalabilità, nel caso in cui non sia possibile allocare tutti i nodi richiesti dai job.

Di seguito è riportato un esempio che mostra come si comporta il ridimensionamento dei nodi dinamici utilizzando le diverse strategie di lancio. ParallelCluster Supponiamo di aver inviato due lavori per la richiesta di 20 nodi ciascuno, per un totale di 40 nodi dello stesso tipo, ma che siano disponibili solo 30 istanze Amazon EC2 per coprire la capacità richiesta su EC2.

all-or-nothingridimensionamento:

  • Per il primo processo, viene chiamata un'API di avvio di all-or-nothingAmazon EC2, che richiede 20 istanze. Una chiamata riuscita dà come risultato il lancio di 20 istanze

  • all-or-nothing l'assegnazione delle 20 istanze avviate ai Slurm nodi per il primo processo ha esito positivo

  • Viene chiamata un'altra API di avvio di all-or-nothingAmazon EC2, che richiede 20 istanze per il secondo processo. La chiamata non ha esito positivo, poiché è disponibile solo la capacità per altre 10 istanze. Al momento non viene avviata alcuna istanza

greedy-all-or-nothingridimensionamento:

  • Viene chiamata un'API di avvio Amazon EC2 che richiede 40 istanze, ovvero la capacità totale richiesta da tutti i processi. Ciò si traduce nel lancio di 30 istanze

  • all-or-nothingL'assegnazione di 20 delle istanze avviate ai Slurm nodi per il primo processo ha esito positivo

  • Viene tentata un'altra all-or-nothingassegnazione delle istanze avviate rimanenti ai Slurm nodi per il secondo processo, ma poiché ci sono solo 10 istanze disponibili su un totale di 20 richieste dal processo, l'assegnazione non ha esito positivo

  • Le 10 istanze avviate non assegnate vengono terminate

scalabilità con il massimo sforzo:

  • Viene chiamata un'API di avvio Amazon EC2 che richiede 40 istanze, ovvero la capacità totale richiesta da tutti i processi. Ciò si traduce nel lancio di 30 istanze.

  • L'assegnazione ottimale di 20 delle istanze lanciate ai Slurm nodi per il primo processo ha esito positivo.

  • Un'altra assegnazione ottimale delle restanti 10 istanze avviate ai Slurm nodi per il secondo processo ha esito positivo, anche se la capacità totale richiesta era di 20. Tuttavia, poiché il processo richiedeva i 20 nodi ed era possibile assegnare istanze Amazon EC2 solo a 10 di essi, il processo non può essere avviato e le istanze vengono lasciate inattive, finché non viene trovata una capacità sufficiente per avviare le 10 istanze mancanti in una chiamata successiva del processo di scalabilità, oppure lo scheduler pianifica il processo su altri nodi di calcolo già in esecuzione.