Informazioni sull'ottenibilità delle GPU con Dynamic Workload Scheduler

Questa pagina descrive lo schedulatore dei carichi di lavoro dinamici in Google Kubernetes Engine (GKE). Dynamic Workload Scheduler migliora l'accesso alle GPU e ottimizza i costi di pianificazione.

Le informazioni riportate in questa pagina possono aiutarti a:

  • Scopri come funziona Dynamic Workload Scheduler in GKE.
  • Decidi se Dynamic Workload Scheduler è adatto al tuo caso d'uso.
  • Gestisci le interruzioni utilizzando Dynamic Workload Scheduler.
  • Comprendi le limitazioni di Dynamic Workload Scheduler in GKE.

Questa pagina è rivolta a amministratori e operatori della piattaforma e ingegneri di machine learning (ML) che vogliono assicurarsi che l'infrastruttura dell'acceleratore sia ottimizzata per i loro carichi di lavoro.

Requisiti

Per utilizzare Dynamic Workload Scheduler in GKE, i cluster devono soddisfare i seguenti requisiti relativi alle versioni in base alla modalità di funzionamento:

Come funziona Dynamic Workload Scheduler

Dynamic Workload Scheduler è una piattaforma di gestione delle risorse e pianificazione dei job che ottimizza il modo in cui accedi alle GPU. Per utilizzare Dynamic Workload Scheduler, configura i pool di nodi in modo che funzionino con questo programma e specifica la capacità GPU richiesta nei carichi di lavoro. Per ulteriori informazioni, consulta Eseguire il deployment di GPU per i carichi di lavoro batch e IA con Dynamic Workload Scheduler.

GKE esegue automaticamente il provisioning delle VM completando la seguente procedura quando la capacità diventa disponibile:

  1. GKE identifica che nel tuo pool di nodi è abilitato Dynamic Workload Scheduler e che il carico di lavoro può attendere per un periodo di tempo indeterminato, finché tutti i nodi richiesti non sono pronti per l'uso contemporaneamente.
  2. Il gestore della scalabilità automatica dei cluster accetta la richiesta e calcola il numero di nodi necessari, trattandoli come una singola unità.
  3. Lo scheduler attende che tutte le risorse necessarie siano disponibili in una singola zona. I cluster che eseguono GKE versione 1.29.1-gke.1708000 e successive ottimizzano la selezione delle zone per tempi di attesa inferiori; le versioni precedenti potrebbero presentare code più lunghe.
  4. Il gestore della scalabilità automatica del cluster esegue il provisioning dei nodi necessari quando sono disponibili contemporaneamente. Tutti i pod del workload possono essere eseguiti insieme sui nodi appena provisionati. Questi nodi vengono eseguiti per un massimo di sette giorni o per una durata inferiore se specifichi un valore nel parametro maxRunDurationSeconds. Questo parametro è disponibile con GKE 1.28.5-gke.1355000 o versioni successive.
  5. Al termine del tempo di esecuzione definito nel parametro maxRunDurationSeconds, i nodi e i pod vengono prenotati.
  6. I nodi di cui è stato eseguito il provisioning non vengono riutilizzati tra le esecuzioni del workload. Ogni richiesta di provisioning attiva la creazione di nuovi nodi con la nuova durata di sette giorni. Se i pod terminano prima e i nodi non vengono più utilizzati, il gestore della scalabilità automatica del cluster li rimuove in base al profilo di scalabilità automatica.

GKE conteggia la durata di ogni richiesta di Dynamic Workload Scheduler a livello di nodo. Il tempo a disposizione per l'esecuzione dei pod potrebbe essere leggermente inferiore a causa di ritardi durante l'avvio. I tentativi di nuovo caricamento del pod condividono questa durata, il che significa che dopo il nuovo caricamento è disponibile meno tempo per i pod. GKE conteggia separatamente la durata di ogni richiesta di Dynamic Workload Scheduler.

Quando utilizzare Dynamic Workload Scheduler

Ti consigliamo di utilizzare Dynamic Workload Scheduler se i tuoi carichi di lavoro soddisfano tutte le seguenti condizioni:

  • Richiedi GPU per eseguire i tuoi carichi di lavoro.
  • Hai una capacità GPU riservata limitata o nessuna e hai bisogno di un accesso più affidabile alle GPU.
  • Il tuo workload è flessibile in termini di tempo e il tuo caso d'uso può permettersi di attendere per ottenere tutta la capacità richiesta, ad esempio quando GKE alloca le risorse GPU al di fuori delle ore di punta.
  • Il carico di lavoro richiede più nodi e non può iniziare a funzionare fino a quando non viene eseguito il provisioning di tutti i nodi GPU e non sono pronti contemporaneamente (ad esempio, se stai eseguendo carichi di lavoro di addestramento ML distribuiti).

Gestire le interruzioni nei carichi di lavoro che utilizzano Dynamic Workload Scheduler

I carichi di lavoro che richiedono la disponibilità di tutti i nodi o della maggior parte dei nodi in un pool di nodi sono sensibili agli sfollamenti. Inoltre, i nodi di cui è stato eseguito il provisioning utilizzando le richieste di Dynamic Workload Scheduler non supportano le operazioni di riparazione o upgrade automatici. Queste operazioni rimuovono tutti i carichi di lavoro da un nodo, impedendone l'esecuzione.

Best practice per ridurre al minimo le interruzioni del workload

Per ridurre al minimo le interruzioni dei carichi di lavoro in esecuzione che utilizzano Dynamic Workload Scheduler, svolgi le seguenti attività:

Limitazioni

  • L'anti-affinità tra pod non è supportata. Il gestore della scalabilità automatica dei cluster non prende in considerazione le regole di anti-affinità tra pod durante il provisioning dei nodi, il che potrebbe portare a carichi di lavoro non pianificabili. Questa situazione può verificarsi quando è stato eseguito il provisioning dei nodi per due o più oggetti Dynamic Workload Scheduler nello stesso pool di nodi.
  • Sono supportati solo i nodi GPU.
  • Le prenotazioni non sono supportate con Dynamic Workload Scheduler. Devi specificare --reservation-affinity=none quando crei il pool di nodi. Dynamic Workload Scheduler richiede e supporta solo il ANY criterio della località per la scalabilità automatica del cluster.
  • Una singola richiesta di Dynamic Workload Scheduler può creare fino a 1000 macchine virtuali (VM), ovvero il numero massimo di nodi per zona per un singolo node pool.
  • GKE utilizza la quota ACTIVE_RESIZE_REQUESTS di Compute Engine per controllare il numero di richieste di pianificatore dei carichi di lavoro dinamici in attesa in una coda. Per impostazione predefinita, questa quota ha un limite di 100 richieste per Google Cloud progetto. Se provi a creare una richiesta di pianificatore del carico di lavoro dinamico superiore a questa quota, la nuova richiesta non va a buon fine.
  • I pool di nodi che utilizzano Dynamic Workload Scheduler sono sensibili alle interruzioni perché il provisioning dei nodi avviene contemporaneamente. Per saperne di più, consulta Gestire le interruzioni nei carichi di lavoro che utilizzano Dynamic Workload Scheduler.
  • Potresti vedere altre VM di breve durata elencate nella console Google Cloud. Questo comportamento è intenzionale perché Compute Engine potrebbe creare e poi rimuovere immediatamente le VM finché non sarà disponibile la capacità di eseguire il provisioning di tutte le macchine richieste.
  • Le VM spot non sono supportate.

Passaggi successivi