🥇Analisi delle prestazioni delle VM in VMware vSphere. Parte 3: Storage

Parte 1. Riguardo alla CPU
Parte 2. Su Memory

Oggi analizzeremo le metriche del sottosistema di archiviazione in vSphere. Il problema con lo storage è la causa più comune di lentezza nelle macchine virtuali. Mentre per CPU e RAM il troubleshooting si ferma a livello di hypervisor, nel caso di problemi con il disco, potrebbe essere necessario esaminare la rete di trasmissione dati e il sistema di archiviazione condivisa.

Tratterò l'argomento utilizzando l'esempio dell'accesso a blocchi nel sistema di archiviazione condivisa, sebbene con l'accesso a file le metriche siano sostanzialmente le stesse.

Un po' di teoria

Quando si parla delle prestazioni del sottosistema di archiviazione delle macchine virtuali, di solito si fa riferimento a tre parametri correlati tra loro:

il numero di operazioni di input/output (Input/Output Operations Per Second, IOPS);
la larghezza di banda (Throughput);
la latenza delle operazioni di input/output (Latency).

Numero di IOPS è generalmente importante per i carichi di lavoro casuali (random): accesso a blocchi sul disco situati in posizioni diverse. Un esempio di tale carico può essere costituito da database, applicazioni business (ERP, CRM), ecc.

Larghezza di banda è importante per i carichi di lavoro sequenziali: accesso a blocchi situati uno dopo l'altro. Ad esempio, questo tipo di carico può essere generato da server di file (ma non sempre) e sistemi di videosorveglianza.

La larghezza di banda è collegata al numero di operazioni di input/output nel seguente modo:

Throughput = IOPS * Dimensione del blocco, dove Dimensione del blocco è la dimensione del blocco.

La dimensione del blocco è una caratteristica piuttosto importante. Le versioni moderne di ESXi supportano blocchi fino a 32.767 KB. Se il blocco è ancora più grande, viene diviso in più parti. Non tutti i sistemi di archiviazione condivisa possono lavorare in modo efficiente con blocchi così grandi, quindi nelle Impostazioni avanzate di ESXi c'è il parametro DiskMaxIOSize. Questo parametro permette di ridurre la dimensione massima del blocco supportato dall'hypervisor (maggiori dettagli qui). Ti consiglio di consultare il produttore del sistema di archiviazione condivisa prima di modificare questo parametro, o almeno di testare le modifiche su un banco di prova.

Una grande dimensione del blocco può avere un impatto negativo sulle prestazioni del sistema di archiviazione condivisa. Anche se il numero di IOPS e throughput è relativamente basso, con una grande dimensione del blocco possono verificarsi alte latenze. Pertanto, presta attenzione a questo parametro.

Latenza è il parametro di prestazione più interessante. La latenza delle operazioni di input/output per la macchina virtuale è composta da:

latenza all'interno dell'hypervisor (KAVG, Average Kernel MilliSec/Read);
ritardi che la rete di trasmissione dati e lo storage (DAVG, Millisecondo medio del driver/Comando) possono causare.

Il ritardo totale visibile nel sistema operativo guest (GAVG, Millisecondo medio del guest/Comando) è la somma di KAVG e DAVG.

GAVG e DAVG vengono misurati, mentre KAVG viene calcolato: GAVG–DAVG.

Fonte

Approfondiamo KAVG. In condizioni normali, KAVG dovrebbe tendere verso zero o, almeno, essere significativamente inferiore a DAVG. L'unico caso noto in cui KAVG è atteso alto è il vincolo sugli IOPS del disco della VM. In tal caso, al tentativo di superare il limite, KAVG aumenterà.

La componente più significativa di KAVG è QAVG, ovvero il tempo in coda per l'elaborazione all'interno dell'ipervisor. Le altre componenti di KAVG sono trascurabili.

La coda nel driver dell'adattatore disco e le code ai lun hanno una dimensione fissa. Per ambienti ad alta intensità di carico, può essere utile aumentare questa dimensione. Qui descritto come aumentare le code nel driver dell'adattatore (con l'aumento della coda ai lun). Questa impostazione funziona quando solo una VM interagisce con il lun, il che è raro. Se ci sono più VM sul lun, è necessario anche aumentare il parametro Disk.SchedNumReqOutstanding (istruzione qui). Aumentando la coda, si riducono QAVG e KAVG di conseguenza.

Ma, ancora una volta, è consigliabile prima consultare la documentazione del fornitore HBA e testare le modifiche su una configurazione di laboratorio.

La dimensione della coda ai lun può essere influenzata dall'attivazione del meccanismo SIOC (Storage I/O Control). Questo garantisce un accesso equo ai lun da parte di tutti i server del cluster, modificando dinamicamente la coda ai lun sui server. Cioè, se su uno dei host opera una VM che richiede sproporzionalmente molte risorse (noisy neighbor VM), SIOC riduce la lunghezza della coda ai lun su quel host (DQLEN). Maggiori dettagli qui.

Abbiamo chiarito KAVG, ora parliamo un po' di DAVG. Qui è semplice: DAVG è il ritardo causato dall'ambiente esterno (rete di trasmissione dati e storage). In un moderno storage, ci sono indicatori di prestazioni. Per analizzare i problemi con DAVG ha senso guardarli. Se da parte di ESXi e dello storage tutto va bene, controlla la rete di trasmissione dati.

Per evitare problemi di prestazioni, scegli la giusta Path Selection Policy (PSP) per il tuo storage area network (SAN). Quasi tutti i moderni SAN supportano la PSP Round-Robin (con ALUA, Asymmetric Logical Unit Access, o senza). Questa politica consente di utilizzare tutti i percorsi disponibili verso il SAN. Nel caso di ALUA, si utilizzano solo i percorsi verso il controller che possiede il LUN. Non tutte le SAN su ESXi hanno regole predefinite che stabiliscono la politica Round-Robin. Se non hai regole per il tuo SAN, utilizza il plugin del produttore del SAN, che creerà la regola corrispondente su tutti gli host del cluster, oppure crea tu stesso la regola. Maggiori dettagli qui.

Inoltre, alcuni produttori di SAN raccomandano di cambiare il numero di IOPS per percorso dal valore standard di 1000 a 1. Nella nostra pratica, ciò ha permesso di "estrarre" più prestazioni dal SAN e ridurre significativamente il tempo necessario per il failover in caso di guasto o aggiornamento dei controller. Consulenza con le raccomandazioni del fornitore e, se non ci sono controindicazioni, prova a modificare questo parametro. Maggiori dettagli qui.

I principali contatori di prestazioni del sottosistema di archiviazione della macchina virtuale

I contatori di prestazioni del sottosistema di archiviazione in vCenter sono raggruppati nelle sezioni Datastore, Disk, Virtual Disk:

Nella sezione Datastore si trovano le metriche relative agli storage vSphere (datastore) su cui risiedono i dischi delle VM. Qui troverai i contatori standard relativi a:

IOPS (richieste di lettura/scrittura per secondo in media),
larghezza di banda (tasso di lettura/scrittura),
latenze (latenza massima di lettura/scrittura).

Dai nomi dei contatori, in linea di principio, è tutto chiaro. Vorrei sottolineare che questa statistica non si riferisce a una specifica VM (o disco VM), ma è generale per l'intero datastore. A mio avviso, è più comodo visualizzare queste statistiche in ESXTOP, dato che il periodo minimo di misurazione lì è di 2 secondi.

Nella sezione Disco si trovano le metriche dei dispositivi a blocchi utilizzati dalla VM. Qui ci sono contatori sugli IOPS di tipo sommatoria (numero di operazioni di input/output nel periodo di misurazione) e diversi contatori relativi all'accesso a blocchi (comandi abortiti, ripristini del bus). Questa informazione, a mio avviso, è anche più comoda da visualizzare in ESXTOP.

La sezione Virtual Disk – il modo più utile per diagnosticare i problemi di prestazioni del sottosistema di archiviazione delle VM. Qui puoi monitorare le prestazioni di ciascun disco virtuale. Queste informazioni sono necessarie per capire se ci sono problemi con una specifica macchina virtuale. Oltre ai contatori standard delle operazioni di input/output, del volume di lettura/scrittura e dei ritardi, in questa sezione ci sono utili contatori che mostrano la dimensione del blocco: dimensione della richiesta di lettura/scrittura.

Nell'immagine sottostante, il grafico delle prestazioni del disco VM, dove puoi vedere il numero di IOPS, i ritardi e la dimensione del blocco.

Puoi anche visualizzare le metriche di prestazione per l'intero datastore se SIOC è abilitato. Qui è presentata una panoramica delle metriche di Latency e IOPS medie. Di default, queste informazioni possono essere visualizzate solo in tempo reale.

ESXTOP

In ESXTOP ci sono diversi schermi che mostrano informazioni sul sottosistema di archiviazione dell'host nel suo insieme, sui singoli macchine virtuali e sui loro dischi.

Iniziamo con le informazioni sulle macchine virtuali. Lo schermo 'Disk VM' si attiva premendo il tasto 'v':

NVDISK – indica il numero di dischi VM. Per visualizzare informazioni su ciascun disco, premi 'e' e inserisci il GID della VM di tuo interesse.

Il significato degli altri parametri su questo schermo è chiaro dai loro nomi.

Un altro schermo utile nella ricerca di problemi è il Disk adapter. Si attiva premendo il tasto 'd' (nell'immagine sottostante sono selezionati i campi A, B, C, D, E, G):

NPTH – il numero di percorsi verso le LUN visibili da questo adattatore. Per ottenere informazioni su ciascun percorso sull'adattatore, premi 'e' e inserisci il nome dell'adattatore:

AQLEN – la dimensione massima della coda sull'adattatore.

Inoltre, su questo schermo ci sono i contatori di latenza di cui ho parlato sopra: KAVG/cmd, GAVG/cmd, DAVG/cmd, QAVG/cmd.

Nello schermo Disk device, che si attiva premendo il tasto 'u', sono presentate informazioni sui singoli dispositivi di blocco – LUN (nell'immagine sottostante sono scelti i campi A, B, F, G, I). Qui puoi vedere lo stato della coda alle LUN.

DQLEN – la dimensione della coda per il dispositivo di blocco.
ACTV – il numero di comandi di input/output nel kernel ESXi.
QUED – il numero di comandi di input/output in coda.
%USD – ACTV / DQLEN × 100%.
LOAD – (ACTV + QUED) / DQLEN.

Se %USD è elevato, è consigliabile considerare l'aumento della coda. Più comandi sono in coda, maggiore è il QAVG e, di conseguenza, il KAVG.

Nella schermata del dispositivo disco è possibile vedere se VAAI (vStorage API for Array Integration) è attivo sul sistema di storage. Per farlo, occorre selezionare i campi A e O.

Il meccanismo VAAI consente di trasferire parte del lavoro dall'hypervisor direttamente allo storage, ad esempio, azzeramento, copia dei blocchi o gestione dei blocchi.

Come mostrato nell'immagine sopra, su questo sistema di storage VAAI è attivo: vengono utilizzati attivamente i primitivi Zero e ATS.