Ottimizza le prestazioni di Hyperdisk

Dopo aver eseguito il provisioning dei volumi Google Cloud Hyperdisk, l'applicazione e il sistema operativo potrebbero richiedere l'ottimizzazione delle prestazioni per soddisfare le tue esigenze.

Nelle sezioni seguenti descriviamo alcuni elementi chiave che possono essere ottimizzati per prestazioni migliori e come puoi applicare alcuni di questi elementi a tipi specifici di workload.

Per una panoramica del funzionamento delle prestazioni di Google Cloud Hyperdisk, consulta Informazioni sulle prestazioni di Hyperdisk.

Utilizza una profondità di coda I/O elevata

I volumi Hyperdisk hanno una latenza più elevata rispetto ai dischi collegati localmente, come le SSD locali, perché sono dispositivi collegati alla rete. Possono fornire un numero molto elevato di IOPS e di throughput, ma devi assicurarti che vengano eseguite richieste I/O sufficienti in parallelo. Il numero di richieste I/O eseguite in parallelo è chiamato profondità della coda I/O.

Le tabelle seguenti mostrano la profondità della coda I/O consigliata per assicurarti di poter ottenere un determinato livello di prestazioni. Le tabelle utilizzano una leggera sovrastima della latenza tipica per mostrare consigli prudenti. L'esempio presuppone che tu stia utilizzando una dimensione I/O di 16 KB.

IOPS desiderati Profondità coda
500 1
1000 2
2000 4
4000 8
8000 16
16.000 32
32.000 64
64.000 128
100.000 200
200.000 400
320.000 640
Throughput desiderato (MB/s) Profondità coda
8 1
16 2
32 4
64 8
128 16
256 32
512 64
1000 128
1200 153

Assicurati di avere CPU libere

La lettura e la scrittura nei volumi Hyperdisk richiedono cicli CPU dalla VM. Se la tua istanza VM non dispone di CPU sufficiente, l'applicazione non potrà gestire le IOPS descritte in precedenza. Per ottenere livelli di IOPS molto elevati e coerenti, devi avere CPU libere per elaborare l'I/O.

Disabilita la protezione da scritture incomplete a livello di database per ottimizzare le scritture

Poiché Google Cloud Hyperdisk fornisce una protezione integrata da scritture incomplete, puoi disattivare le funzionalità di protezione a livello di database per ridurre il sovraccarico I/O e aumentare il throughput di scrittura del database fino al 25%. Per saperne di più su questa funzionalità, consulta Protezione da scritture incomplete nella pagina di panoramica di Hyperdisk.

Requisiti di configurazione dell'ambiente

Affinché la protezione da scritture incomplete di Hyperdisk sia efficace, le scritture del database non devono essere frammentate prima di raggiungere il livello di archiviazione. A seconda del database, puoi ottenere questo risultato utilizzando una delle seguenti opzioni di configurazione:

Opzione 1: allinea i livelli ai limiti dei blocchi di 16 KiB (consigliata per MySQL e PostgreSQL)

Configura il sistema operativo, il file system e i livelli software intermedi in modo da mantenere il limite di 16 KiB. Quando utilizzi questa opzione, devi mantenere questa configurazione specifica:

  • File system: utilizza un ext4 file system. Devi creare il file system con l'opzione bigalloc e configurare le dimensioni del cluster del file system su 16 KiB (16.384 byte) o su un multiplo di 16 KiB che sia una potenza di due più grande:

    mkfs.ext4 -O bigalloc -C 16384 /dev/<var>DEVICE_NAME</var>

    Sostituisci DEVICE_NAME con il nome del dispositivo di archiviazione.

  • Configurazioni non supportate: evita le configurazioni che possono introdurre scritture incomplete sopra il livello di archiviazione a blocchi, ad esempio:

    • Esecuzione di database containerizzati su Google Kubernetes Engine o Kubernetes self-hosted.
    • Archiviazione dei file di database su un file system xfs, che in genere non supporta dimensioni dei blocchi sufficienti sulla maggior parte delle distribuzioni Linux.
    • Utilizzo di configurazioni RAID (Redundant Arrays of Independent Disks) o di gestori di volumi logici (LVM) che rimuovono l'I/O.
    • Utilizzo di Hyperdisk con cache SSD locali, inclusi lvmcache, dm-cache o bcache.
    • Utilizzo della virtualizzazione nidificata per la VM del database.

Opzione 2: utilizza l'I/O atomico a blocchi Linux (consigliata per MariaDB)

Se il database o l'applicazione supporta l'I/O atomico a blocchi Linux e accede ai file utilizzando l'I/O diretto (O_DIRECT), puoi ignorare le regole di configurazione elencate in opzione 1 a condizione che siano soddisfatte le seguenti condizioni:

  • Flag RWF_ATOMIC: l'applicazione deve utilizzare la chiamata di sistema pwritev2() con il flag RWF_ATOMIC. Quando utilizzi questo flag, il kernel Linux garantisce che un'operazione di scrittura venga elaborata come un singolo blocco contiguo dal dispositivo Hyperdisk sottostante. Se il kernel non può garantire l'atomicità, la chiamata di scrittura non riesce immediatamente per evitare il danneggiamento dei dati.
  • Sistema operativo: deve essere Linux versione kernel 6.11 o successive.
  • File system: deve essere ext4 o xfs su Linux versione kernel 6.13 o successive.
  • Accesso ai file: l'applicazione deve aprire i file di database utilizzando l'I/O diretto (O_DIRECT).
  • Database supportati: consigliamo questa opzione solo per MariaDB versione 11.x o successive (per il supporto RWF_ATOMIC Linux generico). MySQL e PostgreSQL non supportano questa funzionalità.

Per istruzioni dettagliate sull'ottimizzazione specifica del database, consulta Configurare MySQL su Compute Engine.

Esamina le metriche relative alle prestazioni di Hyperdisk

Puoi esaminare le metriche sul rendimento del disco in Cloud Monitoring, la soluzione di monitoraggio integrata diGoogle Cloud. Puoi utilizzare queste metriche per osservare le prestazioni dei dischi e di altre risorse VM sotto diversi workload delle applicazioni.

Per scoprire di più, consulta Verifica delle metriche sulle prestazioni del disco.

Puoi anche utilizzare la pagina Osservabilità nella console per visualizzare le metriche sul rendimento del disco.

Passaggi successivi