Usare DISKSPD per testare le prestazioni di archiviazione del carico di lavoro

Articolo
02/26/2024

Si applica a: Azure Stack HCI, versioni 22H2 e 21H2; Windows Server 2022, Windows Server 2019

Questo argomento fornisce indicazioni su come usare DISKSPD per testare le prestazioni di archiviazione del carico di lavoro. Si dispone di un cluster Azure Stack HCI configurato e pronto all'uso. Tuttavia, come è possibile sapere se si stanno ottenendo le metriche delle prestazioni promesse, che si tratti di latenza, velocità effettiva o operazioni di I/O al secondo? Questo è il momento in cui può essere necessario usare DISKSPD. Dopo aver letto questo argomento, si saprà come eseguire DISKSPD, comprendere un subset di parametri, interpretare l'output e acquisire una conoscenza generale delle variabili che influiscono sulle prestazioni di archiviazione del carico di lavoro.

Che cos'è DISKSPD?

DISKSPD è uno strumento da riga di comando per la generazione di I/O per il micro-benchmarking. Ottimo, quindi cosa significano tutti questi termini? Tutti gli utenti che configurano un cluster Azure Stack HCI o un server fisico hanno un motivo. Potrebbe essere configurare un ambiente di hosting Web o eseguire desktop virtuali per i dipendenti. Indipendentemente dal caso d'uso reale, è probabile che si voglia simulare un test prima di distribuire l'applicazione effettiva. Tuttavia, il test dell'applicazione in uno scenario reale è spesso difficile: questo è il punto in cui entra in gioco DISKSPD.

DISKSPD è uno strumento che è possibile personalizzare per creare carichi di lavoro sintetici e testare l'applicazione prima della distribuzione. L'aspetto interessante dello strumento è che offre la libertà di configurare e modificare i parametri per creare uno scenario specifico simile al carico di lavoro reale. DISKSPD può dare un'occhiata a ciò che il sistema è in grado di prima della distribuzione. Al suo centro, DISKSPD rilascia semplicemente una serie di operazioni di lettura e scrittura.

Ora si sa che cos'è DISKSPD, ma quando è necessario usarlo? DISKSPD ha un tempo difficile per emulare carichi di lavoro complessi. DISKSPD è tuttavia ideale quando il carico di lavoro non è strettamente approssimativo da una copia di file a thread singolo ed è necessario un semplice strumento che produce risultati di base accettabili.

Guida introduttiva: installare ed eseguire DISKSPD

Senza ulteriori informazioni, iniziamo a:

Dal PC di gestione aprire PowerShell come amministratore per connettersi al computer di destinazione che si vuole testare usando DISKSPD, quindi digitare il comando seguente e premere INVIO.
```
Enter-PSSession -ComputerName <TARGET_COMPUTER_NAME>
```
In questo esempio viene eseguita una macchina virtuale denominata "node1".

Per scaricare lo strumento DISKSPD, digitare i comandi seguenti e premere INVIO:

$client = new-object System.Net.WebClient

$client.DownloadFile("https://github.com/microsoft/diskspd/releases/download/v2.1/DiskSpd.zip","<ENTER_PATH>\DiskSpd-2.1.zip")

Usare il comando seguente per decomprimere il file scaricato:

Expand-Archive -LiteralPath <ENTERPATH>\DiskSpd-2.1.zip -DestinationPath C:\DISKSPD

Passare alla directory DISKSPD e individuare il file eseguibile appropriato per il sistema operativo Windows in cui è in esecuzione il computer di destinazione.

In questo esempio viene usata la versione amd64.

Nota

È anche possibile scaricare lo strumento DISKSPD direttamente dal repository GitHub che contiene il codice open source e una pagina wiki che descrive in dettaglio tutti i parametri e le specifiche. Nel repository, in Versioni selezionare il collegamento per scaricare automaticamente il file ZIP.

Nel file ZIP verranno visualizzate tre sottocartelle: amd64 (sistemi a 64 bit), x86 (sistemi a 32 bit) e ARM64 (sistemi ARM). Queste opzioni consentono di eseguire lo strumento in ogni versione del client o del server Windows.
Eseguire DISKSPD con il comando di PowerShell seguente. Sostituire tutto all'interno delle parentesi quadre, incluse le parentesi quadre con le impostazioni appropriate.
```
 .\[INSERT_DISKSPD_PATH] [INSERT_SET_OF_PARAMETERS] [INSERT_CSV_PATH_FOR_TEST_FILE] > [INSERT_OUTPUT_FILE.txt]
```
Ecco un comando di esempio che è possibile eseguire:
```
 .\diskspd -t2 -o32 -b4k -r4k -w0 -d120 -Sh -D -L -c5G C:\ClusterStorage\test01\targetfile\IO.dat > test01.txt
```
Nota

Se non si dispone di un file di test, usare il parametro -c per crearne uno. Se si usa questo parametro, assicurarsi di includere il nome del file di test quando si definisce il percorso. Ad esempio: [INSERT_CSV_PATH_FOR_TEST_FILE] = C:\ClusterStorage\CSV01\IO.dat. Nel comando di esempio IO.dat è il nome del file di test e test01.txt è il nome del file di output DISKSPD.

Specificare i parametri chiave

Beh, è stato semplice? Purtroppo, c'è più di questo. Disimballiamo quello che abbiamo fatto. In primo luogo, sono disponibili vari parametri con cui è possibile eseguire il tinker e può essere specifico. Tuttavia, è stato usato il set di parametri di base seguente:

Nota

I parametri DISKSPD fanno distinzione tra maiuscole e minuscole.

-t2: indica il numero di thread per ogni file di destinazione/test. Questo numero è spesso basato sul numero di core CPU. In questo caso, sono stati usati due thread per stressare tutti i core CPU.

-o32: indica il numero di richieste di I/O in sospeso per ogni destinazione per ogni thread. Questa operazione è nota anche come profondità della coda e, in questo caso, 32 sono stati usati per stressare la CPU.

-b4K: indica le dimensioni del blocco in byte, KiB, MiB o GiB. In questo caso, per simulare un test di I/O casuale è stata usata la dimensione del blocco 4K.

-r4K: indica l'I/O casuale allineato alle dimensioni specificate in byte, KiB, MiB, Gib o blocchi (esegue l'override del parametro -s ). La dimensione comune dei byte 4K è stata usata per allinearsi correttamente alle dimensioni del blocco.

-w0: specifica la percentuale di operazioni che sono richieste di scrittura (-w0 equivale al 100% di lettura). In questo caso, il 0% delle scritture è stato usato allo scopo di un semplice test.

-d120: specifica la durata del test, senza includere il raffreddamento o il riscaldamento. Il valore predefinito è 10 secondi, ma è consigliabile usare almeno 60 secondi per qualsiasi carico di lavoro serio. In questo caso, sono stati usati 120 secondi per ridurre al minimo gli outlier.

-Suw: disabilita la memorizzazione nella cache di scrittura hardware e software (equivalente a -Sh).

-D: acquisisce le statistiche delle operazioni di I/O al secondo, ad esempio la deviazione standard, in intervalli di millisecondi (per thread, per destinazione).

-L: misura le statistiche di latenza.

-c5g: imposta le dimensioni del file di esempio usate nel test. Può essere impostato in byte, KiB, MiB, GiB o blocchi. In questo caso è stato usato un file di destinazione di 5 GB.

Per un elenco completo dei parametri, vedere il repository GitHub.

Comprendere l'ambiente

Le prestazioni dipendono principalmente dall'ambiente in uso. Allora, qual è il nostro ambiente? La specifica prevede un cluster Azure Stack HCI con pool di archiviazione e Spazi di archiviazione diretta (S2D). In particolare, sono disponibili cinque macchine virtuali: DC, node1, node2, node3 e il nodo di gestione. Il cluster stesso è un cluster a tre nodi con una struttura di resilienza con mirroring a tre vie. Di conseguenza, vengono mantenute tre copie dei dati. Ogni "nodo" nel cluster è una macchina virtuale Standard_B2ms con un limite massimo di operazioni di I/O al secondo pari a 1920. All'interno di ogni nodo sono presenti quattro unità SSD P30 Premium con un limite massimo di operazioni di I/O al secondo pari a 5000. Infine, ogni unità SSD ha 1 TB di memoria.

Il file di test viene generato nello spazio dei nomi unificato fornito dal volume condiviso cluster (CSV) (C:\ClusteredStorage) per usare l'intero pool di unità.

Nota

L'ambiente di esempio non ha Hyper-V o una struttura di virtualizzazione annidata.

Come si vedrà, è possibile raggiungere in modo indipendente il limite di operazioni di I/O al secondo o larghezza di banda alla macchina virtuale o al limite di unità. È quindi importante comprendere le dimensioni e il tipo di unità della macchina virtuale, perché entrambi hanno un limite massimo di operazioni di I/O al secondo e un limite massimo di larghezza di banda. Questa conoscenza consente di individuare colli di bottiglia e comprendere i risultati delle prestazioni. Per altre informazioni sulle dimensioni appropriate per il carico di lavoro, vedere le risorse seguenti:

Informazioni sull'output

Grazie alla comprensione dei parametri e dell'ambiente, si è pronti per interpretare l'output. In primo luogo, l'obiettivo del test precedente era quello di max out le operazioni di I/O al secondo senza considerare la latenza. In questo modo, è possibile verificare visivamente se si raggiunge il limite di operazioni di I/O al secondo artificiali all'interno di Azure. Per visualizzare graficamente le operazioni di I/O al secondo totali, usare Windows Admin Center o Gestione attività.

Il diagramma seguente illustra l'aspetto del processo DISKSPD nell'ambiente di esempio. Mostra un esempio di un'operazione di scrittura miB da un nodo non coordinatore. La struttura di resilienza a tre vie, insieme all'operazione da un nodo non coordinatore, comporta due hop di rete, riducendo le prestazioni. Se ti stai chiedendo cos'è un nodo coordinatore, non preoccuparti! Verranno fornite informazioni nella sezione Cose da considerare . I quadrati rossi rappresentano i colli di bottiglia della macchina virtuale e dell'unità.

Ora che si ha una comprensione visiva, verranno esaminate le quattro sezioni principali dell'output del file .txt:

Impostazioni di input

Questa sezione descrive il comando eseguito, i parametri di input e altri dettagli sull'esecuzione del test.
Dettagli sull'utilizzo della CPU

In questa sezione vengono evidenziate informazioni quali il tempo di test, il numero di thread, il numero di processori disponibili e l'utilizzo medio di ogni core CPU durante il test. In questo caso, ci sono due core CPU che hanno mediato circa il 4,67% di utilizzo.
Totale I/O

In questa sezione sono presenti tre sottosezioni. La prima sezione evidenzia i dati generali sulle prestazioni, incluse le operazioni di lettura e scrittura. La seconda e la terza sezione suddividono le operazioni di lettura e scrittura in categorie separate.

In questo esempio è possibile notare che il numero totale di operazioni di I/O è stato 234408 durante la durata di 120 secondi. Pertanto, IOPS = 234408 /120 = 1953.30. La latenza media era di 32,763 millisecondi e la velocità effettiva era di 7,63 MiB/s. Dalle informazioni precedenti, si sa che le operazioni di I/O al secondo 1953.30 si avvicinano alla limitazione delle operazioni di I/O al secondo 1920 per la macchina virtuale Standard_B2ms. Non credete? Se si esegue di nuovo questo test usando parametri diversi, ad esempio aumentando la profondità della coda, si scoprirà che i risultati sono ancora limitati a questo numero.

Le ultime tre colonne mostrano la deviazione standard delle operazioni di I/O al secondo a 17,72 (dal parametro -D), la deviazione standard della latenza a 20,994 millisecondi (dal parametro -L) e il percorso del file.

Dai risultati è possibile determinare rapidamente che la configurazione del cluster è terribile. Si noterà che ha raggiunto la limitazione della macchina virtuale 1920 prima della limitazione ssd di 5000. Se l'unità SSD non è stata limitata, è possibile sfruttare fino a 20000 operazioni di I/O al secondo (4 unità * 5000) estendendo il file di test tra più unità.

Alla fine, è necessario decidere quali valori sono accettabili per il carico di lavoro specifico. La figura seguente illustra alcune relazioni importanti che consentono di considerare i compromessi:

La seconda relazione nella figura è importante, e a volte viene definita Little's Law. La legge introduce l'idea che ci siano tre caratteristiche che regolano il comportamento del processo e che è sufficiente modificare uno per influenzare gli altri due, e quindi l'intero processo. E così, se sei infelice con le prestazioni del tuo sistema, hai tre dimensioni di libertà per influenzarlo. Little's Law impone che nel nostro esempio IOPS è la "velocità effettiva" (operazioni di output di input al secondo), la latenza è il "tempo di coda" e la profondità della coda è l'"inventario".
Analisi percentile della latenza

Questa ultima sezione descrive in dettaglio le latenze percentile per tipo di operazione delle prestazioni di archiviazione dal valore minimo al valore massimo.

Questa sezione è importante perché determina la "qualità" delle operazioni di I/O al secondo. Mostra quanti operazioni di I/O sono stati in grado di ottenere un determinato valore di latenza. Spetta all'utente decidere la latenza accettabile per tale percentile.

Inoltre, i "nove" si riferiscono al numero di nove. Ad esempio, "3-noves" equivale al 99° percentile. Il numero di nove espone il numero di operazioni di I/O eseguite in tale percentile. Alla fine, si raggiungerà un punto in cui non è più opportuno prendere sul serio i valori di latenza. In questo caso, è possibile notare che i valori di latenza rimangono costanti dopo "4-nove". A questo punto, il valore di latenza si basa su una sola operazione di I/O all'esterno delle operazioni di 234408.

Aspetti da considerare

Dopo aver iniziato a usare DISKSPD, è necessario prendere in considerazione diversi aspetti per ottenere risultati di test reali. Questi includono prestare particolare attenzione ai parametri impostati, all'integrità dello spazio di archiviazione e alle variabili, alla proprietà CSV e alla differenza tra DISKSPD e copia file.

DISKSPD e real-world

Il test artificiale di DISKSPD offre risultati relativamente confrontabili per il carico di lavoro reale. Tuttavia, è necessario prestare particolare attenzione ai parametri impostati e se corrispondono allo scenario reale. È importante comprendere che i carichi di lavoro sintetici non rappresenteranno mai perfettamente il carico di lavoro reale dell'applicazione durante la distribuzione.

Preparazione

Prima di eseguire un test DISKSPD, sono disponibili alcune azioni consigliate. Questi includono la verifica dell'integrità dello spazio di archiviazione, il controllo dell'utilizzo delle risorse in modo che un altro programma non interferisca con il test e prepari il gestore delle prestazioni se si vogliono raccogliere dati aggiuntivi. Tuttavia, poiché l'obiettivo di questo argomento è quello di eseguire rapidamente DISKSPD, non illustra le specifiche di queste azioni. Per altre informazioni, vedere Testare le prestazioni Spazi di archiviazione usando carichi di lavoro sintetici in Windows Server.

Variabili che influiscono sulle prestazioni

Le prestazioni di archiviazione sono un aspetto delicato. Ciò significa che esistono molte variabili che possono influire sulle prestazioni. È quindi probabile che si verifichi un numero incoerente con le aspettative. Di seguito sono evidenziate alcune delle variabili che influiscono sulle prestazioni, anche se non è un elenco completo:

Larghezza di banda di rete
Scelta della resilienza
Configurazione del disco di archiviazione: NVME, SSD, HDD
Buffer di I/O
Cache
Configurazione RAID
Hop di rete
Velocità di rotazione del disco rigido

Proprietà CSV

Un nodo è noto come proprietario del volume o nodo coordinatore (un nodo non coordinatore è il nodo che non possiede un volume specifico). A ogni volume standard viene assegnato un nodo e gli altri nodi possono accedere a questo volume standard tramite hop di rete, con prestazioni più lente (latenza più elevata).

Analogamente, un volume condiviso cluster (CSV) ha anche un "proprietario". Tuttavia, un file CSV è "dinamico" nel senso che salterà intorno e cambierà la proprietà ogni volta che si riavvia il sistema (RDP). Di conseguenza, è importante verificare che DISKSPD venga eseguito dal nodo coordinatore proprietario del volume condiviso cluster. In caso contrario, potrebbe essere necessario modificare manualmente la proprietà del volume condiviso cluster.

Per confermare la proprietà csv:

Controllare la proprietà eseguendo il comando di PowerShell seguente:
```
 Get-ClusterSharedVolume
```
Se la proprietà CSV non è corretta (ad esempio, si è in Node1 ma Node2 è proprietario del volume condiviso cluster), spostare il file CSV nel nodo corretto eseguendo il comando di PowerShell seguente:
```
 Get-ClusterSharedVolume <INSERT_CSV_NAME> | Move-ClusterSharedVolume <INSERT _NODE_NAME>
```

Copia file e DISKSPD

Alcune persone ritengono che possano "testare le prestazioni di archiviazione" copiando e incollando un gigantesco file e misurando il tempo necessario per tale processo. Il motivo principale di questo approccio è molto probabile perché è semplice e veloce. L'idea non è sbagliata nel senso che testa un carico di lavoro specifico, ma è difficile classificare questo metodo come "test delle prestazioni di archiviazione".

Se l'obiettivo reale è testare le prestazioni di copia dei file, questo potrebbe essere un motivo perfettamente valido per usare questo metodo. Tuttavia, se l'obiettivo è misurare le prestazioni di archiviazione, è consigliabile non usare questo metodo. È possibile considerare il processo di copia file come l'uso di un set diverso di "parametri", ad esempio coda, parallelizzazione e così via, specifico per i servizi file.

Il breve riepilogo seguente spiega perché l'uso della copia file per misurare le prestazioni di archiviazione potrebbe non fornire i risultati che si sta cercando:

Le copie dei file potrebbero non essere ottimizzate, Esistono due livelli di parallelismo, uno interno e l'altro esterno. Internamente, se la copia del file è destinata a una destinazione remota, il motore CopyFileEx applica alcune parallelizzazioni. Esternamente, esistono diversi modi per richiamare il motore CopyFileEx. Ad esempio, le copie di Esplora file sono a thread singolo, ma Robocopy è multithreading. Per questi motivi, è importante comprendere se le implicazioni del test sono quelle desiderate.
Ogni copia ha due lati. Quando si copia e incolla un file, è possibile usare due dischi: il disco di origine e il disco di destinazione. Se uno è più lento rispetto all'altro, si misurano essenzialmente le prestazioni del disco più lento. Esistono altri casi in cui la comunicazione tra l'origine, la destinazione e il motore di copia possono influire sulle prestazioni in modi univoci.

Per altre informazioni, vedere Uso della copia di file per misurare le prestazioni di archiviazione.

Esperimenti e carichi di lavoro comuni

Questa sezione include alcuni altri esempi, esperimenti e tipi di carico di lavoro.

Conferma del nodo coordinatore

Come accennato in precedenza, se la macchina virtuale attualmente non è proprietaria del file CSV, verrà visualizzato un calo delle prestazioni (operazioni di I/O al secondo, velocità effettiva e latenza) anziché testarlo quando il nodo possiede il file CSV. Questo perché ogni volta che si esegue un'operazione di I/O, il sistema esegue un hop di rete al nodo coordinatore per eseguire tale operazione.

Per una situazione con mirroring a tre nodi, le operazioni di scrittura fanno sempre un hop di rete perché devono archiviare i dati in tutte le unità tra i tre nodi. Pertanto, le operazioni di scrittura fanno un hop di rete indipendentemente dal fatto che le operazioni di scrittura. Tuttavia, se si usa una struttura di resilienza diversa, ciò potrebbe cambiare.

Esempio:

Esecuzione nel nodo locale: .\DiskSpd-2.0.21a\amd64\diskspd.exe -t4 -o32 -b4k -r4k -w0 -Sh -D -L:\ClusterStorage\test01\targetfile\IO.dat
Esecuzione nel nodo non locale: .\DiskSpd-2.0.21a\amd64\diskspd.exe -t4 -o32 -b4k -r4k -w0 -Sh -D -L C:\ClusterStorage\test01\targetfile\IO.dat

In questo esempio è possibile visualizzare chiaramente i risultati della figura seguente che la latenza è diminuita, l'aumento delle operazioni di I/O al secondo e la velocità effettiva aumentano quando il nodo coordinatore possiede il file CSV.

Carico di lavoro OLTP (Online Transaction Processing)

Query del carico di lavoro OLTP (Online Transactional Processing) (Update, Insert, Delete) sono incentrate sulle attività orientate alle transazioni. Rispetto all'elaborazione analitica online (OLAP), OLTP è dipendente dalla latenza di archiviazione. Poiché ogni operazione genera un numero minimo di I/O, ciò che si preoccupa è il numero di operazioni al secondo che è possibile sostenere.

È possibile progettare un test del carico di lavoro OLTP per concentrarsi sulle prestazioni di I/O casuali e piccole. Per questi test, concentrarsi su quanto è possibile eseguire il push della velocità effettiva mantenendo latenze accettabili.

La scelta di progettazione di base per questo test del carico di lavoro deve includere almeno:

8 KB block size => è simile alla dimensione della pagina usata SQL Server per i file di dati
70% Lettura, 30% Write => è simile al comportamento OLTP tipico

Carico di lavoro OLAP (Online Analytics Processing)

I carichi di lavoro OLAP si concentrano sul recupero e l'analisi dei dati, consentendo agli utenti di eseguire query complesse per estrarre dati multidimensionali. Al contrario di OLTP, questi carichi di lavoro non sono sensibili alla latenza di archiviazione. Sottolineano la coda di molte operazioni senza preoccuparsi della larghezza di banda. Di conseguenza, i carichi di lavoro OLAP spesso comportano tempi di elaborazione più lunghi.

È possibile progettare un test del carico di lavoro OLAP per concentrarsi sulle prestazioni di I/O sequenziali e di grandi dimensioni. Per questi test, concentrarsi sul volume di dati elaborati al secondo anziché sul numero di operazioni di I/O al secondo. I requisiti di latenza sono anche meno importanti, ma questo è soggettivo.