Massimizza la flessibilità e l'efficienza dei cluster e dei job

Questa pagina fornisce best practice e strategie di pianificazione per aiutarti a progettare cluster Managed Service for Apache Spark resilienti che massimizzano l'ottenibilità delle risorse nelle regioni Google Cloud , riducono i ritardi di provisioning e sfruttano le ottimizzazioni delle prestazioni e dei costi.

Panoramica della disponibilità delle risorse

L'esecuzione di job su cluster Managed Service for Apache Spark rigidi crea single point of failure che possono causare interruzioni dei job ed errori dei cluster e dei job a causa di indisponibilità localizzata o ritardi nel provisioning.

Il rischio di indisponibilità delle risorse è elevato per i cluster configurati con uno dei seguenti anti-pattern rigidi:

  • Posizionamento in una zona fissa: impostazione come hardcoded di una singola zona utilizzando il flag o il campo zone anziché consentire ad AutoZone di Managed Service for Apache Spark di posizionare dinamicamente il cluster nella zona ottimale. Questo anti-pattern impedisce alla creazione del cluster di utilizzare le risorse di computing disponibili nelle zone adiacenti.
  • Un solo tipo o una sola generazione di macchina per ruolo del nodo: limitazione dei ruoli dei nodi a un solo tipo o una sola generazione di macchina. Questo anti-pattern impedisce al cluster di utilizzare le alternative.
  • Troppo poche famiglie di macchine con il livello di priorità più alto: l'elenco di una o due famiglie di macchine al livello 0 di una policy per VM flessibile, anche se sono definiti livelli di riserva. Questo anti-pattern riduce il pool di risorse da cui Managed Service for Apache Spark può attingere per primo, il che aumenta la probabilità di dover ricorrere a livelli inferiori o di ritardi nel provisioning.
  • Scalabilità verticale con un numero inferiore di VM di grandi dimensioni: scalabilità verticale dei cluster per fare affidamento su un numero ridotto di VM di grandi dimensioni. Questo anti-pattern limita la flessibilità di pianificazione.
  • Creazione di cluster "tutto o niente": richiede il provisioning simultaneo di tutti i nodi worker anziché utilizzare la creazione parziale del cluster abbinata alla scalabilità automatica. Questo anti-pattern causa l'errore di creazione del cluster se non è possibile allocare un nodo worker a causa della temporanea indisponibilità delle risorse.
  • Picchi di pianificazione: attivazione di pipeline batch di grandi dimensioni durante le ore di utilizzo di picco, il che aumenta la contesa regionale.

L'ottenibilità delle risorse è la pratica di progettare job in modo che siano flessibili dal punto di vista dell'hardware, multizona e scalabili. Disaccoppiando i cluster dalle configurazioni rigide e abilitando i fallback delle famiglie di macchine multiple, puoi aumentare i tassi di successo della creazione, ridurre al minimo la latenza di avvio e rispettare costantemente gli SLA.

Suggerimenti per l'ottenimento delle risorse

Adotta le seguenti ottimizzazioni per migliorare la disponibilità delle risorse e la stabilità dei job:

Utilizza VM flessibili

La funzionalità VM flessibile consente di specificare un elenco classificato di tipi di VM per i nodi worker master, primari e secondari. In questo modo, i tassi di successo della creazione aumentano, poiché vengono valutati i tipi di VM elencati e vengono selezionate automaticamente le zone con capacità disponibile.

Suggerimenti: utilizza VM flessibili con override dei dischi, che ti consentono di specificare diversi tipi di dischi, ad esempio Hyperdisk e disco permanente, per diverse famiglie di macchine candidate nella stessa policy del cluster. Puoi anche combinare le famiglie di macchine Gen2 e Gen4 all'interno di un'unica policy per scalare i job in un pool più ampio e aggirare i limiti di capacità.

Specifica almeno tre famiglie di macchine distinte al ranking 0. Managed Service for Apache Spark attinge prima dall'elenco con la priorità più alta (ranking 0), quindi un ranking 0 ampio offre alla creazione del cluster il pool più grande di risorse candidate prima di passare ai ranking inferiori. La combinazione delle famiglie Gen4 e Gen2 al livello 0 è il modo più efficace per ampliare questo pool.

Per i workload per uso generico, ad esempio i job attualmente in esecuzione su macchine N2 o N2D, utilizza i seguenti ranking:

  • Rank 0: N4, N4D (con Hyperdisk bilanciato), N2, N2D
  • Ranking 1: C4, C4D (con Hyperdisk bilanciato), C2D. Le unità SSD locali possono essere utilizzate con C4 e C4D, ma in genere 8 o 16 core supportano solo 1-2 unità SSD locali.
  • Classifica 2: E2 (prestazioni inferiori; utilizza solo se necessario)

Ad esempio, per i job che utilizzano n2d-standard-16, i ranking sono:

  • Rank 0: n4-standard-16, n4d-standard-16, n2-standard-16, n2d-standard-16
  • Posizione 1: c4-standard-16, c4d-standard-16, c2d-standard-16
  • Livello 2: e2-standard-16

Poiché N4 e N4D richiedono Hyperdisk e N2 e N2D utilizzano un disco permanente, definisci il ranking 0 come due selezioni di istanze che condividono lo stesso ranking, ma utilizzano valori diskConfig diversi. Ad esempio, i seguenti flag gcloud dataproc clusters create definiscono la policy dei worker primari per l'esempio precedente:

gcloud dataproc clusters create CLUSTER_NAME \
    --region=REGION \
    --zone="" \
    --num-workers=NUM_WORKERS \
    --worker-instance-selection='{"machineTypes":["n4-standard-16","n4d-standard-16"],"rank":0,"diskConfig":{"bootDiskType":"hyperdisk-balanced","bootDiskSizeGb":BOOT_DISK_SIZE_GB}}' \
    --worker-instance-selection='{"machineTypes":["n2-standard-16","n2d-standard-16"],"rank":0,"diskConfig":{"bootDiskType":"pd-balanced","bootDiskSizeGb":BOOT_DISK_SIZE_GB}}' \
    --worker-instance-selection='{"machineTypes":["c4-standard-16","c4d-standard-16"],"rank":1,"diskConfig":{"bootDiskType":"hyperdisk-balanced","bootDiskSizeGb":BOOT_DISK_SIZE_GB}}' \
    --worker-instance-selection='{"machineTypes":["c2d-standard-16"],"rank":1,"diskConfig":{"bootDiskType":"pd-balanced","bootDiskSizeGb":BOOT_DISK_SIZE_GB}}' \
    --worker-instance-selection='{"machineTypes":["e2-standard-16"],"rank":2,"diskConfig":{"bootDiskType":"pd-balanced","bootDiskSizeGb":BOOT_DISK_SIZE_GB}}'

Quando utilizzi le VM flessibili, tieni presente i seguenti fattori:

  • Supporto di tipi di dischi misti: i tipi di macchine Gen3 e Gen4 supportano solo i tipi di dischi Hyperdisk e non supportano i tipi di Persistent Disk. Quando combini Gen2 e Gen4, specifica un diskConfig per ogni selezione di istanza in instanceFlexibilityPolicy. Per saperne di più, consulta Override dei dischi.

  • Quote delle risorse: quando definisci una policy per le VM flessibili con tipi di riserva, Compute Engine controlla le quote per tutti i tipi e i dischi candidati nella regione. Assicurati che al tuo progetto siano allocate quote di computing e disco sufficienti per tutti gli elementi configurati.

  • Sconti di Compute Engine: approfitta degli sconti per impegno di utilizzo (CUD) flessibili per applicare risparmi basati sulla spesa a più famiglie di VM e regioni.

  • Prezzi: utilizza il Calcolatore prezzi diGoogle Cloud per confrontare i costi di ogni livello della policy.

Per i modelli di configurazione e gli esempi di deployment, consulta:

Utilizza il posizionamento automatico delle zone

Utilizza il posizionamento AutoZone per consentire a Managed Service for Apache Spark di selezionare la zona migliore per il provisioning delle risorse. Se utilizzi reti Virtual Private Cloud (VPC) personalizzate, assicurati che la subnet abbia un numero sufficiente di indirizzi IP in tutte le zone della regione.

Utilizza tipi di macchine più piccoli

Progetta i job in modo che scalino orizzontalmente su tipi di macchine più piccoli (4, 8 o 16 core) anziché verticalmente con VM più grandi. Le VM di dimensioni più piccole hanno una disponibilità maggiore tra le zone, il che aiuta a prevenire ritardi nella creazione.

  • Esamina e riprogetta i job che utilizzano tipi di macchine di grandi dimensioni per i nodi driver.
  • Esamina i job che eseguono solo nodi driver senza nodi worker (cluster a nodo singolo). I job in esecuzione su cluster a nodo singolo non possono fare lo scale up in modo dinamico e associano l'esecuzione a un singolo host fisico.

Utilizza la scalabilità automatica dei cluster

Utilizza la scalabilità automatica dei cluster con un numero massimo di istanze sufficiente per gestire la capacità dei job con variabilità delle risorse (picchi).

Utilizza la creazione parziale del cluster con la scalabilità automatica

Utilizza la creazione parziale del cluster, che ti consente di specificare un numero minimo di worker primari con la scalabilità automatica. Se il cluster inizia con un numero di worker inferiore a quello richiesto, la scalabilità automatica può aggiungere altri worker in modo dinamico non appena le risorse diventano disponibili.

Pianifica i job al di fuori delle ore di punta

Pianifica i job durante le ore non di punta, ad esempio a metà giornata e nei fine settimana. Pianifica in orari non standard, ad esempio alle 10:07 anziché alle 10:00, per evitare picchi di pianificazione.

Passaggi successivi