Oggi analizzeremo le metriche del sottosistema disco in vSphere. Un problema di archiviazione è il motivo più comune di una macchina virtuale lenta. Se, nel caso di CPU e RAM, la risoluzione dei problemi termina a livello di hypervisor, se si verificano problemi con il disco, potrebbe essere necessario occuparsi della rete dati e del sistema di archiviazione.
Discuterò l'argomento utilizzando l'esempio del blocco dell'accesso ai sistemi di archiviazione, sebbene per l'accesso ai file i contatori siano più o meno gli stessi.
Un po 'di teoria
Quando si parla delle prestazioni del sottosistema disco delle macchine virtuali, le persone solitamente prestano attenzione a tre parametri correlati:
- numero di operazioni di input/output (Operazioni di input/output al secondo, IOPS);
- portata;
- ritardo delle operazioni di input/output (Latency).
Numero di IOPS solitamente importante per carichi di lavoro casuali: accesso a blocchi del disco situati in luoghi diversi. Un esempio di tale carico potrebbe essere quello dei database, delle applicazioni aziendali (ERP, CRM), ecc.
capacità importante per carichi sequenziali: accesso ai blocchi posti uno dopo l'altro. Ad esempio, i file server (ma non sempre) e i sistemi di videosorveglianza possono generare un tale carico.
La produttività è correlata al numero di operazioni I/O come segue:
Throughput = IOPS * Dimensione del blocco, dove Dimensione blocco è la dimensione del blocco.
La dimensione del blocco è una caratteristica abbastanza importante. Le versioni moderne di ESXi consentono blocchi di dimensioni fino a 32 KB. Se il blocco è ancora più grande, viene diviso in più blocchi. Non tutti i sistemi di storage possono funzionare in modo efficiente con blocchi così grandi, quindi è presente un parametro DiskMaxIOSize nelle Impostazioni avanzate di ESXi. Usandolo, puoi ridurre la dimensione massima del blocco saltato dall'hypervisor (maggiori dettagli ). Prima di modificare questo parametro, ti consiglio di consultare il produttore del sistema di accumulo o almeno di testare le modifiche su un banco da laboratorio.
Una dimensione di blocco elevata può avere un effetto dannoso sulle prestazioni di archiviazione. Anche se il numero di IOPS e il throughput sono relativamente piccoli, è possibile osservare latenze elevate con blocchi di grandi dimensioni. Pertanto, prestare attenzione a questo parametro.
Latenza – il parametro prestazionale più interessante. La latenza I/O per una macchina virtuale è composta da:
- ritardi all'interno dell'hypervisor (KAVG, Average Kernel MilliSec/Read);
- ritardo fornito dalla rete dati e dal sistema di archiviazione (DAVG, Average Driver MilliSec/Command).
La latenza totale visibile nel sistema operativo guest (GAVG, Average Guest MilliSec/Command) è la somma di KAVG e DAVG.
Vengono misurati GAVG e DAVG e viene calcolato KAVG: GAVG–DAVG.
Diamo uno sguardo più da vicino KAVG. Durante il normale funzionamento il KAVG dovrebbe tendere a zero o comunque essere molto inferiore al DAVG. L'unico caso che conosco in cui KAVG è presumibilmente elevato è il limite IOPS sul disco della VM. In questo caso, quando si tenta di superare il limite, il KAVG aumenterà.
Il componente più significativo di KAVG è QAVG: il tempo di coda di elaborazione all'interno dell'hypervisor. I restanti componenti di KAVG sono trascurabili.
La coda nel driver dell'adattatore del disco e la coda sulle lune hanno una dimensione fissa. Per ambienti con carichi elevati, potrebbe essere utile aumentare questa dimensione. descrive come aumentare le code nel driver dell'adattatore (allo stesso tempo aumenterà la coda verso le lune). Questa impostazione funziona quando solo una VM funziona con la luna, il che è raro. Se sulla Luna sono presenti più VM, è necessario aumentare anche il parametro Disk.SchedNumReqOutstanding (Istruzioni ). Aumentando la coda si diminuiscono rispettivamente QAVG e KAVG.
Ma ancora una volta, leggi prima la documentazione del fornitore dell'HBA e testa le modifiche su un banco da laboratorio.
La dimensione della coda verso la luna può essere influenzata dall'inclusione del meccanismo SIOC (Storage I/O Control). Fornisce un accesso uniforme alla Luna da tutti i server nel cluster modificando dinamicamente la coda alla Luna sui server. Cioè, se uno degli host esegue una VM che richiede una quantità sproporzionata di prestazioni (VM vicina rumorosa), SIOC riduce la lunghezza della coda alla luna su questo host (DQLEN). Più dettagli .
Abbiamo risolto KAVG, ora un po' DAVG. Qui tutto è semplice: DAVG è il ritardo introdotto dall'ambiente esterno (rete dati e sistema di storage). Ogni sistema di storage moderno e meno moderno ha i propri contatori delle prestazioni. Per analizzare i problemi con DAVG, ha senso esaminarli. Se tutto va bene sul lato ESXi e storage, controlla la rete dati.
Per evitare problemi di prestazioni, scegli la Path Selection Policy (PSP) corretta per il tuo sistema di storage. Quasi tutti i moderni sistemi di archiviazione supportano PSP Round-Robin (con o senza ALUA, Asymmetric Logical Unit Access). Questa policy consente di utilizzare tutti i percorsi disponibili per il sistema di storage. Nel caso di ALUA vengono utilizzati solo i percorsi verso il controller che possiede la luna. Non tutti i sistemi di storage su ESXi dispongono di regole predefinite che impostano la policy Round-Robin. Se non esiste una regola per il tuo sistema di storage, utilizza un plug-in del produttore del sistema di storage, che creerà una regola corrispondente su tutti gli host nel cluster, oppure crea tu stesso una regola. Dettagli .
Inoltre, alcuni produttori di sistemi di storage consigliano di modificare il numero di IOPS per percorso dal valore standard di 1000 a 1. Nella nostra pratica, ciò ha consentito di "spremere" più prestazioni dal sistema di storage e di ridurre significativamente il tempo necessario per il failover. in caso di guasto o aggiornamento del controller. Controlla i consigli del venditore e, se non ci sono controindicazioni, prova a modificare questo parametro. Dettagli .
Contatori delle prestazioni del sottosistema disco della macchina virtuale di base
I contatori delle prestazioni del sottosistema disco in vCenter sono raccolti nelle sezioni Datastore, Disco, Disco virtuale:
Nella sezione Datastore esistono metriche per gli archivi disco vSphere (datastore) su cui si trovano i dischi VM. Qui troverai contatori standard per:
- IOPS (richieste medie di lettura/scrittura al secondo),
- throughput (velocità di lettura/scrittura),
- ritardi (lettura/scrittura/latenza massima).
In linea di principio, tutto è chiaro dai nomi degli sportelli. Vorrei attirare ancora una volta la vostra attenzione sul fatto che le statistiche qui non riguardano una VM specifica (o un disco VM), ma statistiche generali per l'intero archivio dati. A mio parere, è più conveniente guardare queste statistiche in ESXTOP, almeno in base al fatto che il periodo minimo di misurazione è di 2 secondi.
Nella sezione Disco ci sono metriche sui dispositivi a blocchi utilizzati dalla VM. Sono presenti contatori per gli IOPS di tipo sommatoria (il numero di operazioni di ingresso/uscita durante il periodo di misurazione) e diversi contatori relativi agli accessi ai blocchi (comandi interrotti, reset del bus). Secondo me è anche più conveniente visualizzare queste informazioni in ESXTOP.
Sezione Disco virtuale – il più utile dal punto di vista della ricerca di problemi di prestazioni del sottosistema del disco della VM. Qui puoi vedere le prestazioni di ciascun disco virtuale. Sono queste informazioni che sono necessarie per capire se una particolare macchina virtuale ha un problema. Oltre ai contatori standard per il numero di operazioni I/O, volume di lettura/scrittura e ritardi, questa sezione contiene contatori utili che mostrano la dimensione del blocco: Dimensione della richiesta di lettura/scrittura.
Nell'immagine seguente è riportato un grafico delle prestazioni del disco della VM, in cui è possibile vedere il numero di IOPS, la latenza e la dimensione del blocco.
Puoi anche visualizzare i parametri delle prestazioni per l'intero datastore se SIOC è abilitato. Ecco le informazioni di base sulla latenza media e sugli IOPS. Per impostazione predefinita, queste informazioni possono essere visualizzate solo in tempo reale.
ESXTOP
ESXTOP dispone di diverse schermate che forniscono informazioni sul sottosistema del disco host nel suo insieme, sulle singole macchine virtuali e sui relativi dischi.
Cominciamo con le informazioni sulle macchine virtuali. La schermata “Disco VM” si richiama con il tasto “v”:
DISCO NV è il numero di dischi VM. Per visualizzare le informazioni per ciascun disco, premere “e” e inserire il GID della VM di interesse.
Il significato dei rimanenti parametri in questa schermata è chiaro dai loro nomi.
Un'altra schermata utile durante la risoluzione dei problemi è Adattatore disco. Richiamato con il tasto “d” (i campi A,B,C,D,E,G sono selezionati nella figura sotto):
NPTH – il numero di percorsi verso le lune visibili da questo adattatore. Per ottenere informazioni per ciascun percorso sull'adattatore, premere "e" e inserire il nome dell'adattatore:
AQLEN – dimensione massima della coda sull'adattatore.
Sempre in questa schermata ci sono i contatori di ritardo di cui ho parlato sopra: KAVG/cmd, GAVG/cmd, DAVG/cmd, QAVG/cmd.
La schermata Dispositivo disco, richiamata premendo il tasto “u”, fornisce informazioni sui singoli dispositivi a blocco: lune (i campi A, B, F, G, I sono selezionati nell'immagine seguente). Qui puoi vedere lo stato della coda per le lune.
DQLEN – dimensione della coda per un dispositivo a blocchi.
ACTV – numero di comandi I/O nel kernel ESXi.
QUED – numero di comandi I/O in coda.
%DOLLARO STATUNITENSE – ACTV/DQLEN × 100%.
CARICARE – (ACTV + QUED) / DQLEN.
Se %USD è elevato, dovresti considerare di aumentare la coda. Maggiore è il numero di comandi in coda, maggiore è il QAVG e, di conseguenza, il KAVG.
È inoltre possibile vedere nella schermata del dispositivo disco se VAAI (vStorage API for Array Integration) è in esecuzione sul sistema di storage. Per fare ciò, seleziona i campi A e O.
Il meccanismo VAAI consente di trasferire parte del lavoro dall'hypervisor direttamente al sistema di storage, ad esempio azzerando, copiando blocchi o bloccando.
Come puoi vedere nell'immagine sopra, VAAI funziona su questo sistema di archiviazione: le primitive Zero e ATS vengono utilizzate attivamente.
Suggerimenti per ottimizzare il lavoro con il sottosistema disco su ESXi
- Prestare attenzione alla dimensione del blocco.
- Imposta la dimensione ottimale della coda sull'HBA.
- Non dimenticare di abilitare SIOC sui datastore.
- Scegli una PSP in conformità con le raccomandazioni del produttore del sistema di archiviazione.
- Assicurati che VAAI funzioni.
Articoli utili sull'argomento:
Fonte: habr.com