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 scrittura incompleta a livello di database per ottimizzare le scritture

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

Requisiti di configurazione dell'ambiente

Affinché la protezione da scrittura interrotta di Hyperdisk sia efficace, le scritture del database non devono essere frammentate prima di raggiungere il livello di archiviazione. A seconda del database, puoi farlo 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 per preservare il limite di 16 KiB. Quando utilizzi questa opzione, devi mantenere questa configurazione specifica:

  • File system: utilizza un file system ext4. 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 un multiplo di 16 KiB che sia una potenza di 2 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 configurazioni che possono introdurre scritture interrotte sopra il livello di archiviazione a blocchi, ad esempio:

    • Esecuzione di database containerizzati su Google Kubernetes Engine o Kubernetes autogestito.
    • Archiviazione di file di database su un file system xfs, che in genere non supporta dimensioni dei blocchi sufficienti nella maggior parte delle distribuzioni Linux.
    • Utilizzo di configurazioni di array ridondanti di dischi indipendenti (RAID) o di gestori di volumi logici (LVM) che rimuovono l'I/O.
    • Utilizzo di Hyperdisk con cache SSD locali, tra cui lvmcache, dm-cache o bcache.
    • Utilizzo della virtualizzazione nidificata per la VM del database.

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

Se il tuo database o la tua applicazione supporta I/O atomico a blocchi Linux e accede ai file utilizzando I/O diretto (O_DIRECT), puoi ignorare le regole di configurazione elencate nell'opzione 1 a condizione che tu soddisfi 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 sul kernel Linux versione 6.13 o successive.
  • Accesso ai file: l'applicazione deve aprire i file di database utilizzando I/O diretto (O_DIRECT).
  • Database supportati: consigliamo questa opzione solo per MariaDB versione 11.x o successive (per il supporto generico di RWF_ATOMIC di Linux). MySQL e PostgreSQL non supportano questa funzionalità.

Per istruzioni dettagliate sull'ottimizzazione specifica del database, vedi 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 diCloud de Confiance. 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