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

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

Importante

Azure Stack HCI ora fa parte di Azure Locale. Tuttavia, le versioni precedenti di Azure Stack HCI, ad esempio 22H2 continueranno a fare riferimento Azure Stack HCI e non rifletteranno la modifica del nome. Altre informazioni.

Questo argomento fornisce indicazioni su come usare DISKSPD per testare le prestazioni dell'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 ottenere una conoscenza generale delle variabili che influiscono sulle prestazioni dell'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? Gli utenti che configurano un cluster HCI Azure Stack 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 viene fornito DISKSPD.

DISKSPD è uno strumento che è possibile personalizzare per creare carichi di lavoro sintetici personalizzati 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 eseguire prima della distribuzione. In sostanza, DISKSPD esegue semplicemente una serie di operazioni di lettura e scrittura.

Ora si sa che cos'è DISKSPD, ma quando è necessario usarlo? DISKSPD ha difficoltà a emulare carichi di lavoro complessi. Ma DISKSPD è ottimo quando il carico di lavoro non può essere approssimato fedelmente da una copia di file a thread singolo e hai bisogno di uno strumento semplice che fornisca risultati di riferimento accettabili.

Avvio rapido: installare ed eseguire DISKSPD

Per installare ed eseguire DISKSPD, aprire PowerShell come amministratore nel PC di gestione e quindi seguire questa procedura:

Per scaricare ed espandere il file ZIP per lo strumento DISKSPD, eseguire i comandi seguenti:

# Define the ZIP URL and the full path to save the file, including the filename
$zipName = "DiskSpd.zip"
$zipPath = "C:\DISKSPD"
$zipFullName = Join-Path $zipPath $zipName
$zipUrl = "https://github.com/microsoft/diskspd/releases/latest/download/" +$zipName

# Ensure the target directory exists, if not then create
if (-Not (Test-Path $zipPath)) {
New-Item -Path $zipPath -ItemType Directory | Out-Null
}
# Download and expand the ZIP file
Invoke-RestMethod -Uri $zipUrl -OutFile $zipFullName
Expand-Archive -Path $zipFullName -DestinationPath $zipPath

Per aggiungere la directory DISKSPD alla $PATH variabile di ambiente, eseguire il comando seguente:

$diskspdPath = Join-Path $zipPath $env:PROCESSOR_ARCHITECTURE
if ($env:path -split ';' -notcontains $diskspdPath) {
$env:path += ";" + $diskspdPath
}

Eseguire DISKSPD con il comando di PowerShell seguente. Sostituire le parentesi quadre con le impostazioni appropriate.
```
diskspd [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
```
Note

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? Sfortunatamente, c'è più di questo. Vediamo nel dettaglio cosa abbiamo fatto. Per prima cosa, ci sono vari parametri su cui è possibile intervenire e si può entrare nello specifico. Tuttavia, è stato usato il set di parametri di base seguente:

Note

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 thread. Questo è noto 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, è stata usata la dimensione del blocco 4K per simulare un test di I/O casuale.

-r4K: indica l'I/O casuale allineato alla dimensione specificata in byte, KiB, MiB, Gib o blocchi (sostituisce il 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 a 100% lettura). In questo caso, è stato utilizzato un valore di scritture pari allo 0% ai fini 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 cache di scrittura software e hardware (equivalente a -Sh).

-D: acquisisce statistiche sugli IOPS, come la deviazione standard, a 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 HCI Azure Stack 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. Pertanto, vengono mantenute tre copie di 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 IOPS pari a 5000. Infine, ogni unità SSD ha 1 TB di memoria.

Si genera il file di test nello spazio dei nomi unificato fornito dal Volume condiviso del cluster (CSV) (C:\ClusteredStorage) per utilizzare l'intero pool di unità.

Note

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

Come vedremo, è assolutamente possibile raggiungere separatamente il limite di IOPS o di larghezza di banda a livello di VM o di unità. È quindi importante comprendere le dimensioni della macchina virtuale e il tipo di unità, perché entrambi hanno un limite massimo di operazioni di I/O al secondo e un limite di larghezza di banda. Queste informazioni consentono di individuare i colli di bottiglia e comprendere i risultati in termini di prestazioni. Per altre informazioni sulle dimensioni appropriate per il carico di lavoro, vedere le risorse seguenti:

Comprendere l'output

Grazie alla comprensione dei parametri e dell'ambiente, si è pronti per interpretare l'output. Innanzitutto, l'obiettivo del test precedente era massimizzare gli IOPS senza alcun riguardo per la latenza. In questo modo, è possibile vedere visivamente se si raggiunge il limite di operazioni di I/O al secondo artificiali all'interno di Azure. Se vuoi visualizzare graficamente gli IOPS totali, usa Windows Admin Center o Gestione attività.

Il diagramma seguente mostra l'aspetto del processo DISKSPD nell'ambiente di esempio. Mostra un esempio di un'operazione di scrittura da 1 MiB da un nodo non coordinatore. La struttura di resilienza a tre percorsi, unitamente all'esecuzione 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 la macchina virtuale e i colli di bottiglia dell'unità.

Ora che hai un'idea visiva, esaminiamo 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 una media di circa 4,67% utilizzo.
I/O totale

In questa sezione sono presenti tre sottosezioni. La prima sezione evidenzia i dati generali sulle prestazioni, incluse le operazioni di lettura e scrittura. Le seconde e le terze sezioni suddivideno le operazioni di lettura e scrittura in categorie separate.

In questo esempio è possibile notare che il conteggio totale 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. Sulla base delle informazioni precedenti, sappiamo che i 1953,30 IOPS sono vicini al limite di 1920 IOPS della nostra VM Standard_B2ms. Non crederci? Se si esegue di nuovo questo test usando parametri diversi, ad esempio aumentando la profondità della coda, si scopre 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 può vedere che ha raggiunto il limite della VM di 1920 prima del limite dell'SSD di 5000. Se il limite fosse stato l'SSD anziché la VM, avresti potuto sfruttare fino a 20000 IOPS (4 dischi * 5000) distribuendo il file di test su più dischi.

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

La seconda relazione nella figura è importante, e a volte si fa riferimento a Little's Law. La legge introduce l'idea che ci sono 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 influenzarla. La legge di Little stabilisce che, nel nostro esempio, gli IOPS sono il "throughput" (operazioni di input/output al secondo), la latenza è il "tempo di accodamento" e la profondità della coda è l'"inventario".
Analisi dei percentili della latenza

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

Questa sezione è importante perché determina la “qualità” dei tuoi IOPS. Viene rivelato il numero di operazioni di I/O in grado di ottenere un determinato valore di latenza. Spetta all'utente decidere la latenza accettabile per il 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 quel percentile. Alla fine, si raggiungerà un punto in cui non è più opportuno prendere seriamente 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 dalle operazioni di 234408.

Alcune cose 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 la copia dei file.

DISKSPD rispetto alle condizioni reali

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 vuoi raccogliere dati aggiuntivi. Tuttavia, poiché l'obiettivo di questo argomento è avviare rapidamente DISKSPD, non entra nei dettagli di queste operazioni. Per altre informazioni, vedere Testare le prestazioni degli 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 vengono evidenziate alcune delle variabili che influiscono sulle prestazioni, anche se non è un elenco completo:

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

Proprietà del 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 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 file CSV. In caso contrario, potrebbe essere necessario modificare manualmente la proprietà del file CSV.

Per confermare la titolarità del 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 è proprietaria del file CSV), spostare il file CSV nel nodo corretto eseguendo il comando di PowerShell seguente:
```
 Get-ClusterSharedVolume <INSERT_CSV_NAME> | Move-ClusterSharedVolume <INSERT _NODE_NAME>
```

Copia di file vs. DISKSPD

Alcune persone ritengono che possano "testare le prestazioni di archiviazione" copiando e incollando un file gigantesco 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 del file come 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 effettuate con Esplora file sono a thread singolo, ma Robocopy è multithread. Per questi motivi, è importante comprendere se le implicazioni del test sono quelle che si stanno cercando.
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, è essenzialmente possibile misurare 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 che si sta testando non è proprietaria del volume condiviso cluster, si noterà un calo delle prestazioni (IOPS, velocità effettiva e latenza) anziché testarlo quando il nodo è proprietario del volume condiviso cluster. Ciò è dovuto al fatto che 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 configurazione a tre nodi con mirroring a tre vie, le operazioni di scrittura richiedono sempre un passaggio di rete, poiché è necessario memorizzare i dati su tutte le unità distribuite nei tre nodi. Pertanto, le operazioni di scrittura richiedono in ogni caso un passaggio di rete. Tuttavia, se si usa una struttura di resilienza diversa, questo potrebbe cambiare.

Ecco un esempio:

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

Da questo esempio, è possibile vedere chiaramente dai risultati mostrati nella figura seguente che la latenza è diminuita, gli IOPS sono aumentati e il throughput è aumentato quando il nodo coordinatore possiede il volume condiviso del cluster (CSV).

Carico di lavoro OLTP (Online Transaction Processing)

Le 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 dipende dalla latenza di archiviazione. Poiché ogni operazione genera un numero minimo di operazioni di I/O, ciò che è importante è 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 ridotte. In questi test, concentratevi su fino a che punto potete spingere il throughput mantenendo latenze accettabili.

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

dimensione del blocco di 8 KB => è simile alla dimensione della pagina che SQL Server usa per i file di dati
70% lettura, 30% scrittura => rispecchia il tipico comportamento OLTP

Carico di lavoro OLAP (Online Analytical 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. Contrariamente a OLTP, questi carichi di lavoro non sono sensibili alla latenza di archiviazione. Sottolineano l'importanza di mettere in coda molte operazioni senza prestare troppa attenzione alla 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.