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

Articolo
10/03/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 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 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 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. Al suo interno, DISKSPD emette semplicemente una serie di operazioni di lettura e scrittura.

Ora si sa che cos'è DISKSPD, ma quando è necessario usarlo? DISKSPD ha un tempo difficile emulando carichi di lavoro complessi. Ma DISKSPD è ideale quando il carico di lavoro non è strettamente approssimativo da una copia di file a thread singolo ed è necessario uno strumento semplice che produce risultati di base 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
```
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? Sfortunatamente, c'è più di questo. Disimballiamo quello che abbiamo fatto. In primo luogo, ci sono vari parametri con cui è possibile creare il tinker e può ottenere specifiche. 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 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 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 statistiche di I/O al secondo, ad esempio 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 con 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.

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 dispone di Hyper-V o di 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 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 vedere 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 mostra 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, porta a 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 si ha una comprensione visiva, esaminare 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.
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. 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 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 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 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. Little's Law stabilisce che, in questo esempio, le operazioni di I/O al secondo sono 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 ogni 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. 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 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.

Operazioni preliminari

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 è ottenere rapidamente l'esecuzione di DISKSPD, non analizza le specifiche di queste azioni. Per altre informazioni, vedere Testare Spazi di archiviazione prestazioni 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
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 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 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 è 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 file e 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 di file potrebbero non essere ottimizzate. Esistono due livelli di parallelismo che si verificano, 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 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 (operazioni di I/O al secondo, 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 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à nei tre nodi. Pertanto, le operazioni di scrittura fanno un hop di rete indipendentemente. 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 nei risultati della figura seguente che la latenza è diminuita, le operazioni di I/O al secondo sono aumentate e la velocità effettiva aumentata quando il nodo coordinatore è proprietario del volume condiviso cluster.

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. 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:

Dimensioni blocco di 8 KB => è simile alla dimensione della pagina usata da SQL Server per i file di dati
70% Lettura, 30% Scrittura => simile al comportamento OLTP tipico

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'inserimento in coda di molte operazioni senza preoccuparsi molto 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.