Considerazioni sulle prestazioni

Questa pagina fornisce indicazioni sulla configurazione dell'ambiente Google Cloud Managed Lustre per ottenere il miglior rendimento.

Per visualizzare i numeri di rendimento specifici per ogni livello di rendimento, consulta Livelli di rendimento.

Rendimento dopo l'aumento della capacità

L'aumento della capacità di archiviazione di un'istanza esistente ne aumenta il throughput e le IOPS massimi e, possibilmente, le prestazioni dei metadati.

Le prestazioni di throughput di lettura migliorano gradualmente man mano che vengono scritti nuovi dati e ridistribuiti nello spazio di archiviazione aggiuntivo. Le prestazioni di velocità effettiva di scrittura aumentano immediatamente.

Utilizzo elevato della capacità

Quando l'utilizzo della capacità di archiviazione di un'istanza raggiunge il 90%, le prestazioni dell'istanza potrebbero essere ridotte. Valuta la possibilità di aumentare la capacità della tua istanza Managed Lustre. Prima dell'espansione, potresti dover richiedere una quota aggiuntiva.

Se visualizzi errori No space left on device, ma la tua istanza mostra la capacità rimanente, consulta Errori No space left on device.

Unità massima di trasmissione (MTU) della rete VPC

Quando crei la rete VPC, impostare il valore di mtu (unità massima di trasmissione o la dimensione del pacchetto IP più grande che può essere trasmesso su questa rete) sul valore massimo consentito di 8896 migliora le prestazioni fino al 10% rispetto al valore predefinito di 1460 byte.

Puoi visualizzare il valore MTU corrente della tua rete con il seguente comando:

gcloud compute networks describe NETWORK_NAME --format="value(mtu)"

Il valore MTU di una rete può essere aggiornato dopo la creazione della rete, ma ci sono considerazioni importanti. Per maggiori dettagli, consulta Modificare la MTU di una rete.

Tipi di macchine Compute Engine

La velocità effettiva di rete può essere influenzata dalla scelta del tipo di macchina. In generale, per ottenere la migliore velocità effettiva:

  • Aumenta il numero di vCPU. La larghezza di banda in uscita massima per istanza è generalmente di 2 Gbps per vCPU, fino al massimo del tipo di macchina.
  • Seleziona una serie di macchine che supporti limiti di ingresso e uscita più elevati. Ad esempio, le istanze C2 con rete Tier_1 supportano una larghezza di banda in uscita fino a 100 Gbps. Le istanze C3 con networking Tier_1 supportano fino a 200 Gbps.
  • Attiva le prestazioni di rete Tier_1 per VM con tipi di macchine più grandi.
  • Utilizza Google Virtual NIC (gVNIC). gVNIC è l'unica opzione per i tipi di macchina di terza generazione e successivi. gVNIC è obbligatorio quando si utilizza il networking Tier_1.

Per informazioni dettagliate, consulta Larghezza di banda di rete.

Configurazione di più NIC

Utilizzando la funzionalità multi-rail integrata di Lustre, i client possono distribuire il traffico di rete su più schede di interfaccia di rete (multi-NIC). Aggrega la larghezza di banda per saturare le istanze Managed Lustre ad alta capacità.

Per configurare più NIC, devi:

  • Seleziona un tipo di macchina con più NIC fisiche.
  • Crea una subnet per ogni NIC e assegna ogni NIC alla relativa subnet.
  • Segui i passaggi per più NIC quando ti connetti da Compute Engine o GKE.

Verifica il bilanciamento del traffico

Dopo aver configurato più NIC, verifica che il bilanciamento dei dati sia corretto.

Compute Engine

Verifica il bilanciamento dei dati direttamente sulla VM monitorando le interfacce di rete configurate (ad esempio eth0 e eth1) utilizzando nload durante la generazione di traffico verso il backend Managed Lustre:

nload -m eth0 eth1

In una configurazione multi-NIC riuscita, i bit rate in uscita devono essere più o meno equivalenti su tutte le interfacce configurate.

GKE

Verifica che il traffico di rete del tuo carico di lavoro sia bilanciato su più NIC eseguendo il deployment di un pod network-debugger temporaneo sul nodo in cui è pianificato il tuo carico di lavoro:

  1. Identifica il nodo in cui è pianificato il workload:

    kubectl get pod POD_NAME -o wide

    Sostituisci POD_NAME con il nome del tuo pod. Nell'output comando, prendi nota del nome nella colonna NODE.

  2. Avvia il debugger di rete su quel nodo:

    kubectl run multi-nic-debug --rm -i --tty --image=nicolaka/netshoot \
  --overrides='{"spec": {"hostNetwork": true, "nodeSelector": {"kubernetes.io/hostname": "NODE_NAME"}, "tolerations": [{"key": "nvidia.com/gpu", "operator": "Exists", "effect": "NoSchedule"}]}}' \
  -- /bin/bash -c "apk update && apk add nload && nload -m eth0 eth1"

    Sostituisci NODE_NAME con il nome del nodo del passaggio precedente.

  3. Nell'output, analizza i bit rate della colonna In uscita per eth0 e eth1. Se la configurazione va a buon fine, i bit rate sono più o meno equivalenti. L'output è simile al seguente:

    Device eth0 [10.1.0.50] (1/2):
==========================================================================
Incoming:                               Outgoing:
Curr: 1.63 MBit/s                       Curr: 1.46 GBit/s
Avg: 1.60 MBit/s                        Avg: 1.44 GBit/s
Min: 1.40 MBit/s                        Min: 1.25 GBit/s
Max: 1.64 MBit/s                        Max: 1.47 GBit/s
Ttl: 590.94 GByte                       Ttl: 405.19 GByte

Device eth1 [172.16.15.5] (2/2):
==========================================================================
Incoming:                               Outgoing:
Curr: 1.64 MBit/s                       Curr: 1.47 GBit/s
Avg: 1.62 MBit/s                        Avg: 1.44 GBit/s
Min: 1.42 MBit/s                        Min: 1.26 GBit/s
Max: 1.66 MBit/s                        Max: 1.47 GBit/s
Ttl: 587.68 GByte                       Ttl: 406.36 GByte

  4. Esci dal debugger premendo Ctrl+C.

Risoluzione dei problemi comuni di colli di bottiglia

Se il rendimento del tuo workload è significativamente inferiore a quanto previsto per il tuo livello di rendimento di Managed Lustre, controlla i seguenti problemi comuni:

  • Numero insufficiente di macchine client: Una singola macchina client è limitata dalla propria CPU virtuale (vCPU) e dai limiti di elaborazione di rete a collegamento singolo. Per saturare i livelli ad alta velocità effettiva, devi distribuire il carico. Ad esempio, per saturare un file system Managed Lustre da 100.000 MBps, in genere sono necessarie almeno 60 macchine client standard (o 12 macchine client configurate per utilizzare una rete a larghezza di banda elevata di livello 1) che scrivono in parallelo. Per le dimensioni massime dell'istanza di qualsiasi livello di prestazioni, potresti aver bisogno di oltre 2500 macchine client configurate per utilizzare il networking Tier 1 a larghezza di banda elevata.

  • MTU di Virtual Private Cloud (VPC) non ideale: per impostazione predefinita, le reti VPC utilizzano un MTU di 1460 (frame Ethernet standard). Per lo spazio di archiviazione ad alte prestazioni come Managed Lustre, devi configurare i frame jumbo con un MTU di 8896. L'esecuzione con un'MTU standard di 1460 costringe la CPU a elaborare più del doppio del numero di pacchetti di rete, aggiungendo overhead alla CPU e limitando la larghezza di banda massima.

  • Configurazione della larghezza di banda di rete Tier 1 mancante: Molti tipi di macchine ad alte prestazioni richiedono di attivare esplicitamente la larghezza di banda di rete Tier 1.

    • Nei node pool di Compute Engine e GKE Standard, utilizza il flag --network-performance-configs=total-egress-bandwidth-tier=TIER_1 durante la creazione. Senza questo flag, una VM o un nodo potrebbe essere limitato a un limite di uscita predefinito inferiore.
    • Su GKE Autopilot, non specificare questo flag direttamente. Seleziona invece una serie di macchine che supporti una larghezza di banda maggiore (ad esempio c3) utilizzando i selettori di nodi nelle specifiche del pod.

    Per saperne di più, consulta Tipi di macchine di Compute Engine.

  • Utilizzo non bilanciato della destinazione di archiviazione di oggetti (OST) Lustre:Managed Lustre suddivide i dati dei file in più destinazioni di archiviazione di oggetti (OST). Se il test o il carico di lavoro scrive in un singolo file non suddiviso in bande o se le attività client scrivono pattern che sovraccaricano un singolo OST, questo OST diventa un collo di bottiglia mentre il resto del file system rimane inattivo. Per evitare questo problema, assicurati di bilanciare il payload di scrittura in modo uniforme su tutti gli OST disponibili (ad esempio, utilizzando la modalità file per processo nei benchmark).

  • Contesa della larghezza di banda di rete condivisa:la larghezza di banda in uscita sulle macchine client (VM Compute Engine o nodi GKE) è condivisa tra tutte le operazioni di rete sulla macchina. Se le macchine client o i pod scaricano contemporaneamente pacchetti di grandi dimensioni, eseguono scansioni di logging pesanti o comunicano intensamente con altri nodi del cluster, le prestazioni di archiviazione saranno limitate alla larghezza di banda di rete rimanente.