Scalabilità del cluster per nodi dinamici - 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à.

Scalabilità del cluster per nodi dinamici

ParallelCluster supporta Slurm i metodi per scalare dinamicamente i cluster utilizzando il plug-in power Slurm saver. Per ulteriori informazioni, consulta la Cloud Scheduling Guide e la SlurmPower Saving Guide nella documentazione. Slurm

A partire dalla ParallelCluster versione 3.8.0, ParallelCluster utilizza il ripristino 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 ripresi. 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

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, Parellelcluster elabora in sequenza più batch.

Garantisce che nessuna istanza rimanga 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.

ParallelCluster utilizza 2 tipi di strategie di allocazione dinamica dei nodi per scalare il cluster:

  • Allocazione basata sulle informazioni richieste disponibili sui nodi:

    • Ripresa di tutti i nodi o ridimensionamento dell'elenco dei nodi:

      ParallelCluster ridimensiona il cluster in base solo ai nomi degli elenchi Slurm di nodi richiesti quando viene eseguito. Slurm ResumeProgram Alloca le risorse di calcolo ai nodi solo in base al nome del nodo. L'elenco dei nomi dei nodi può includere più processi.

    • Curriculum a livello di lavoro o scalabilità a livello di lavoro:

      ParallelCluster ridimensiona il cluster in base ai requisiti di ciascun processo, al numero corrente di nodi allocati al processo e ai nodi che devono essere ripristinati. ParallelCluster ottiene queste informazioni dalla variabile di ambiente. SLURM_RESUME_FILE

  • Allocazione con una strategia di lancio di Amazon EC2:

    • Scalabilità al massimo:

      ParallelCluster ridimensiona il cluster utilizzando una chiamata API di avvio di Amazon EC2 con la capacità di destinazione minima pari a 1, per avviare alcune, ma non necessariamente tutte, le istanze necessarie per supportare i nodi richiesti.

    • Una scalabilità: ll-or-nothing

      ParallelCluster aumenta la scalabilità del cluster utilizzando una chiamata API di avvio di Amazon EC2 che ha esito positivo solo se vengono lanciate tutte le istanze necessarie per supportare i nodi richiesti. In questo caso, chiama l'API dell'istanza di avvio di Amazon EC2 con la capacità target minima pari alla capacità totale richiesta.

Per impostazione predefinita, ParallelCluster utilizza il ridimensionamento dell'elenco dei nodi con una strategia di lancio di Amazon EC2 al massimo per avviare alcune, ma non necessariamente tutte, le istanze necessarie per supportare i nodi richiesti. Cerca di fornire quanta più capacità possibile per soddisfare il carico di lavoro inviato.

A partire dalla ParallelCluster versione 3.7.0, ParallelCluster utilizza la scalabilità a livello di processo con una strategia di lancio all-or-nothingEC2 per i lavori inviati in modalità esclusiva. Quando invii un lavoro in modalità esclusiva, il lavoro ha accesso esclusivo ai nodi allocati. Per ulteriori informazioni, consulta EXCLUSIVE nella Slurm documentazione.

Per inviare un'offerta di lavoro in modalità esclusiva:

  • Passa il flag esclusivo quando invii un Slurm lavoro al cluster. Ad esempio, sbatch ... --exclusive.

    O

  • Invia un lavoro a una coda del cluster che è stata configurata con JobExclusiveAllocationset to. true

Quando invii un lavoro in modalità esclusiva:

  • ParallelCluster attualmente i batch lanciano richieste per includere fino a 500 nodi. Se un processo richiede più di 500 nodi, ParallelCluster effettua una richiesta di all-or-nothingavvio per ogni set di 500 nodi e una richiesta di avvio aggiuntiva per il resto dei nodi.

  • Se l'allocazione dei nodi è in una singola risorsa di elaborazione, ParallelCluster effettua una richiesta di all-or-nothingavvio per ogni set di 500 nodi e una richiesta di avvio aggiuntiva per il resto dei nodi. Se una richiesta di avvio fallisce, ParallelCluster termina la capacità inutilizzata creata da tutte le richieste di avvio.

  • Se l'allocazione dei nodi si estende su più risorse di elaborazione, ParallelCluster deve effettuare una richiesta di all-or-nothingavvio per ogni risorsa di calcolo. Anche queste richieste vengono raggruppate. Se una richiesta di avvio fallisce per una delle risorse di calcolo, ParallelCluster interrompe la capacità inutilizzata creata da tutte le richieste di avvio delle risorse di calcolo.

scalabilità a livello di lavoro con limitazioni note della strategia di lancio: all-or-nothing

  • Quando invii un lavoro in una risorsa di calcolo con un singolo tipo di istanza, in una coda che si estende su più zone di disponibilità, la chiamata all'API di avvio di all-or-nothingEC2 ha esito positivo 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

AWS ParallelCluster utilizza solo un tipo di strategia di allocazione dinamica dei nodi per scalare il cluster:

  • Allocazione basata sulle informazioni richieste disponibili sul nodo:

    • Ripresa di tutti i nodi o ridimensionamento dell'elenco dei nodi: ParallelCluster ridimensiona il cluster in base solo ai nomi degli elenchi Slurm di nodi richiesti quando viene eseguito. Slurm ResumeProgram Alloca le risorse di calcolo ai nodi solo in base al nome del nodo. L'elenco dei nomi dei nodi può includere più processi.

  • Allocazione con una strategia di lancio di Amazon EC2:

    • Scalabilità ottimale: aumenta la ParallelCluster scalabilità del cluster utilizzando una chiamata API di avvio di Amazon EC2 con la capacità target minima pari a 1, per avviare alcune, ma non necessariamente tutte, le istanze necessarie per supportare i nodi richiesti.

ParallelCluster utilizza il ridimensionamento dell'elenco dei nodi con una strategia di lancio di Amazon EC2 al massimo per avviare alcune, ma non necessariamente tutte, le istanze necessarie per supportare i nodi richiesti. Cerca di fornire quanta più capacità possibile per soddisfare il carico di lavoro inviato.

Limitazioni

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