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

Parte 1. Sul CPU
Parte 2. Sulla Memoria

Oggi esamineremo le metriche del sottosistema di archiviazione in vSphere. I problemi di storage sono la causa più comune delle prestazioni lente delle macchine virtuali. Mentre nel caso di CPU e RAM il troubleshooting si ferma a livello di hypervisor, in caso di problemi con il disco, potrebbe essere necessario esaminare anche la rete di trasmissione dei dati e lo storage.

Tratterò l'argomento utilizzando l'accesso a blocchi allo storage, anche se con l'accesso ai file i contatori sono sostanzialmente gli stessi.

Un po' di teoria

Quando si parla delle prestazioni del sottosistema di archiviazione delle macchine virtuali, di solito ci si concentra su tre parametri interconnessi:

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 carichi di lavoro casuali (random): accesso a blocchi su disco situati in diverse posizioni. Esempi di tali carichi di lavoro includono database, applicazioni aziendali (ERP, CRM), ecc.

Larghezza di banda importante per carichi di lavoro sequenziali: accesso ai blocchi disposti in successione. Ad esempio, tale carico può essere generato da server di file (ma non sempre) e sistemi di videosorveglianza.

La larghezza di banda è correlata 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 suddiviso in più blocchi. Non tutte le SAN possono lavorare in modo efficiente con blocchi così grandi, quindi nelle Impostazioni avanzate di ESXi c'è un parametro chiamato DiskMaxIOSize. Con questo è possibile ridurre la dimensione massima del blocco che il hypervisor può gestire (maggiori dettagli qui). Ti consiglio di consultare il produttore della SAN prima di modificare questo parametro o almeno di testare le modifiche su un ambiente di laboratorio.

Una grande dimensione del blocco può avere un impatto negativo sulle prestazioni dello storage. Anche se il numero di IOPS e throughput è relativamente basso, dimensioni di blocco grandi possono comportare latenze elevate. Pertanto, fai attenzione a questo parametro.

Latenza è il parametro di prestazione più interessante. La latenza delle operazioni di I/O per una macchina virtuale è composta da:

latenza all'interno dell'iper-vizor (KAVG, Average Kernel MilliSec/Read);
latenza fornita dalla rete e dallo storage (DAVG, Average Driver MilliSec/Command).

La latenza totale, visibile nel sistema operativo guest (GAVG, Average Guest MilliSec/Command), è la somma di KAVG e DAVG.

GAVG e DAVG sono misurati, mentre KAVG è calcolato: GAVG–DAVG.

Fonte

Approfondiamo KAVG. Durante un funzionamento normale, KAVG dovrebbe tendere a zero o, perlomeno, essere significativamente inferiore a DAVG. L'unico caso noto in cui KAVG è atteso alto è la limitazione degli IOPS sul disco della VM. In tal caso, cercando di superare il limite, KAVG aumenterà.

La componente più significativa di KAVG è QAVG – tempo in coda per l'elaborazione all'interno dell'iper-vizor. Le altre componenti di KAVG sono trascurabili.

La coda nel driver dell'adattatore disco e le code alle lune hanno una dimensione fissa. Per ambienti ad alta intensità di carico, può essere utile aumentare questa dimensione. Qui Viene descritto come aumentare le code nel driver dell'adattatore (aumentando contemporaneamente anche la coda alle lune). Questa impostazione funziona quando una sola VM sta interagendo con la luna, il che è raro. Se sulla luna ci sono più VM, è necessario aumentare anche il parametro Disk.SchedNumReqOutstanding (istruzioni qui). Aumentando la coda, si riducono rispettivamente QAVG e KAVG.

Tuttavia, prima di procedere, consulta la documentazione del fornitore HBA e testa le modifiche in un ambiente di laboratorio.

La dimensione della coda alla luna può essere influenzata dall'attivazione del meccanismo SIOC (Storage I/O Control). Questo assicura un accesso equo alla luna da parte di tutti i server del cluster, grazie a un cambiamento dinamico della coda alla luna sui server. Quindi, se su uno degli host è attiva una VM che richiede prestazioni sproporzionate (noisy neighbor VM), SIOC riduce la lunghezza della coda alla luna su quell'host (DQLEN). Maggiori dettagli qui.

Abbiamo capito KAVG, ora parliamo un po' di DAVG. Qui è tutto semplice: DAVG è il ritardo introdotto dall'ambiente esterno (rete di trasmissione dati e SAN). Ogni SAN moderna, e anche quelle meno recenti, ha i propri contatori di prestazione. Per analizzare i problemi con il DAVG, è utile esaminarli. Se da parte di ESXi e della SAN tutto è in ordine, controlla la rete di trasmissione dati.

Per evitare problemi di prestazioni, scegli la giusta Politica di Selezione del Percorso (PSP) per la tua SAN. Praticamente tutte le SAN moderne supportano la PSP Round-Robin (con ALUA, Accesso Logico Asimmetrico alle Unità, o senza). Questa politica consente di utilizzare tutti i percorsi disponibili verso la SAN. Nel caso dell'ALUA, vengono utilizzati solo i percorsi fino al controller che possiede il LUN. Non tutte le SAN su ESXi hanno regole predefinite che impostano la politica Round-Robin. Se per la tua SAN non esistono regole, utilizza il plugin del produttore della SAN, che creerà la regola corrispondente su tutti gli host del cluster, oppure crea la regola tu stesso. Maggiori dettagli qui.

Anche alcuni produttori di storage raccomandano di impostare il numero di IOPS da 1000 a 1. Nella nostra esperienza, questo ha permesso di "estrarre" più performance dallo storage e di ridurre significativamente il tempo necessario per il failover in caso di guasto o aggiornamento dei controllori. Controlla le raccomandazioni del fornitore e, se non ci sono controindicazioni, prova a modificare questo parametro. Maggiori dettagli qui.

Contatori principali delle performance del sottosistema disco della macchina virtuale

I contatori delle performance del sottosistema disco in vCenter sono raccolti nelle sezioni Datastore, Disk, Virtual Disk:

Nella sezione Datastore si trovano le metriche per i datastore vSphere, sui quali sono memorizzati i dischi delle VM. Qui troverai i contatori standard per:

IOPS (richieste di lettura/scrittura per secondo medie),
larghezza di banda (tasso di lettura/scrittura),
latenza (latenza di lettura/scrittura/maggiore).

Dai nomi dei contatori, in linea di massima, è tutto chiaro. Vorrei sottolineare che qui le statistiche non si riferiscono a una specifica VM (o disco VM), ma sono generali per l'intero datastore. A mio parere, è più comodo visualizzare queste statistiche in ESXTOP, considerando che il periodo di misurazione minimo lì è di 2 secondi.

Nella sezione Disco ci sono metriche sui dispositivi di blocco utilizzati dalle VM. Qui ci sono contatori per IOPS di tipo summation (numero di operazioni di input/output in un periodo di misurazione) e diversi contatori relativi all'accesso a blocchi (Commands aborted, Bus resets). Questa informazione è, a mio avviso, più comoda da visualizzare in ESXTOP.

Sezione Virtual Disk è il più utile dal punto di vista della ricerca di problemi di prestazioni del subsistema di archiviazione delle VM. Qui è possibile vedere le prestazioni di ciascun disco virtuale. Questa informazione è necessaria per comprendere se ci sono problemi con una specifica macchina virtuale. Oltre ai contatori standard per il numero di operazioni di input/output, volume di lettura/scrittura e latenze, in questa sezione sono presenti utili contatori che mostrano la dimensione del blocco: Read/Write request size.

Nella figura sottostante, il grafico delle prestazioni del disco della VM, dove è possibile vedere il numero di IOPS, le latenze e la dimensione del blocco.

Inoltre, le metriche delle prestazioni possono essere visualizzate per l'intero datastore se SIOC è attivato. Qui sono fornite informazioni di base sulla Latency media e gli IOPS. Per impostazione predefinita, queste informazioni possono essere visualizzate solo in tempo reale.

ESXTOP

In ESXTOP ci sono diversi schermi che forniscono informazioni sul sistema di archiviazione del host in generale, su singole macchine virtuali e i loro dischi.

Iniziamo con le informazioni sulle macchine virtuali. Lo schermo “Disk VM” è chiamato premendo il tasto “v”:

NVDISK – è il numero di dischi VM. Per visualizzare le informazioni su ciascun disco, premere “e” e inserire il GID della VM di interesse.

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

Un altro schermo utile nella ricerca di problemi è – Disk adapter. Si attiva premendo il tasto “d” (nelle immagini sottostanti sono selezionati i campi A,B,C,D,E,G):

NPTH – il numero di percorsi verso gli LUN visibili da questo adattatore. Per ottenere informazioni su ciascun percorso nell'adattatore, premere “e” e inserire il nome dell'adattatore:

AQLEN – la dimensione massima della coda sull'adattatore.

Inoltre, su questo schermo vengono presentati i contatori di ritardo di cui ho parlato sopra: KAVG/cmd, GAVG/cmd, DAVG/cmd, QAVG/cmd.

Nella schermata Disco del dispositivo, accessibile tramite il tasto “u”, sono presentate informazioni sui singoli dispositivi a blocchi – lune (nelle immagini sottostanti sono selezionati i campi A, B, F, G, I). Qui è possibile vedere lo stato della coda per le lune.

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

Se il %USD è elevato, è opportuno considerare l’aumento della coda. Maggiore è il numero di comandi in coda, più alto sarà QAVG e, di conseguenza, KAVG.

Nella schermata Disco del dispositivo, è possibile anche controllare se VAAI (vStorage API for Array Integration) è attivo sullo storage. Per farlo, occorre selezionare i campi A e O.

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

Come si può vedere nell'immagine sopra, su questo storage VAAI è attivo: vengono utilizzati attivamente i primordiali Zero e ATS.