Automatizzare i test sullo storage

Ciao a tutti, oggi parliamo di test molto utili da effettuare sul nostro storage che potrebbe ospitare applicazioni impegnative come SQL. L’articolo è scritto da Danilo Dominici che ringrazio e di cui riporto una breve descrizione.

danilodominici

Danilo Dominici lavora con SQL Server dalla versione 6.5, come sviluppatore ERP e sistemista. Dall'anno 2000, conseguite le principali certificazioni Microsoft (MCSE, MCAD, MCDBA, MCITP Database Administrator e MCT) si occupa per qualche anno di formazione presso i principali partner Microsoft in Italia, erogando corsi principalmente su SQL Server.  Dal 2004 è il database administrator SQL Server e amministratore/architect VMWare presso la Regione Marche, dove si è occupato anche di sviluppo di applicazioni ASP.NET.  Dal 2011 collabora attivamente con UGISS, lo User Group Italiano di SQL Server, come autore e speaker ai workshop su SQL Server 2012 e per l’attività di supporto alla community di SQL Server riceve il riconoscimento Microsoft Certified Community Contributor.  Dallo stesso anno inizia la collaborazione con SolidQ Italia, in cui ricopre il ruolo di Data Platform Specialist e per la quale ha contribuito alla stesura di alcuni capitoli della SQL Server 2012 Upgrade Technical Reference Guide.

 

Introduzione

Lo storage rappresenta uno dei fattori chiave per le prestazioni di un sistema destinato ad ospitare SQL Server. Conoscere a priori come si comportano i dischi, in termini di tempo di accesso e di capacità di I/O, consente di verificare se lo storage che abbiamo a disposizione è conforme a quanto richiesto dalle applicazioni che vi accedono.

In questo articolo, primo di tre, vedremo come si installa ed utilizza uno dei tool più utilizzati per l’analisi delle prestazioni di un disco, il SQLIO Disk Subsystem Benchmark Tool.

Come funziona

SQLIO utilizza uno o più files, creati in precedenza o attraverso il tool stesso, per effettuare dei test di lettura e/o scrittura, variando, attraverso i parametri di esecuzione, le caratteristiche dell’operazione di I/O (dimensione del blocco di bytes letti o scritti, numero di thread utilizzati in parallelo, etc).

Che cosa analizzare

Esistono molti articoli in rete che trattano di SQLIO e di come utilizzarlo per verificare le prestazioni di un disco, ma spesso si trovano indicazioni sulle tipologie di test da effettuare che in realtà poco si adattano a SQL Server.

Vediamo che cosa analizzare: SQL Server, infatti, accede allo storage utilizzando una serie di pattern ben noti.

Per questo motivo non è necessario effettuare i test con tutte le possibili varianti di parametri, ma è possibile concentrarsi solo su quelli specifici per SQL Server.

Nella tabella seguente una lista di test da effettuare con SQLIO per validare un workload tipico di un sistema misto OLTP/DW.

Tipo di I/O

Dimensione blocco

Threads/queue

Che cosa simula

Lettura/scrittura random

8K

# cores / files

File dati OLTP

Scrittura sequenziale

60K

1 / 32

Transaction log

Lettura sequenziale

512K

1 / 16

Table scan

Scrittura sequenziale

256K

1 / 16

Bulk load

Lettura random

32K

# cores / 1

SSAS workload

Lettura sequenziale

1MB

1 / 32

Backup

Scrittura random

64K-256K

# cores / files

Checkpoint

 

Che cosa serve

Per prima cosa occorre scaricare il tool SQLIO dal sito Microsoft (https://www.microsoft.com/en-us/download/details.aspx?id=20163).

Il tool è veramente “leggero”: occupa solo 176 KB e funziona su tutte le versioni di Windows, anche se tra i prerequisiti l’elenco dei sistemi operativi supportati è fermo a Windows 2003.

SQLIO non ha un’interfaccia grafica, perciò per utilizzarlo occorre eseguire sqlio.exe dal prompt dei comandi, dopo essersi posizionati nella cartella di installazione (Per default: C:\Program Files (x86)\SQLIO\), oppure automatizzarne l’esecuzione attraverso comandi batch o utilizzando scripts Powershell.

image

Dopo aver installato SQLIO, occorre creare un file di test, di dimensioni sufficientemente grandi. Se il file è di piccole dimensioni, infatti, lo spostamento delle testine del disco è ridotto e provocherebbe la restituzione di numeri estremamente elevati nei test di IO random, ovviamente poco realistici.

Inoltre la dimensione del file dovrebbe essere maggiore della capacità della cache del controller, altrimenti si misurerebbero le prestazioni del controller e non del disco!

Il modo più veloce per creare il file di test consiste nell’utilizzare il comando FSUTIL.EXE, incluso in tutte le versioni di Windows, ed in particolare due dei comandi accettati: createnew e setvaliddata.

Un esempio pratico: se si desidera creare un file di 1TB nel drive E: occorre digitare, al prompt di Powershell:

PS C:\> FSUTIL.EXE file createnew E:\testfile.dat (1TB)

PS C:\> FSUTIL.EXE file setvaliddata E:\testfile.dat (1TB)

Perché eseguirlo dal prompt di Powershell? Perché in questo modo possiamo usare la comoda forma “(1TB)” invece di dover indicare la dimensione in bytes come richiesto dal comando FSUTIL. Inoltre, il comando setvaliddata consente di “marcare” la fine del file alla dimensione specificata, senza dover attendere l’inizializzazione del file e quindi molto più velocemente rispetto ad altre tecniche.

Una volta creato il file, possiamo finalmente eseguire i test, indicando i parametri necessari.

Nella tabella sottostante sono elencati i parametri principalmente utilizzati:

Parametro

Significato

-kW o –kR

Specifica il tipo di operazione da eseguire: W(rite) o R(ead)

-frandom o –fsequential

Indica se l’operazione di I/O deve essere random o sequenziale

-t

Numero di threads in esecuzione contemporaneamente

-o

Numero di richieste contemporanee

-s

Durata, in secondi, del test

-b

Dimensione, in KB, del blocco di dati usato per leggere o scrivere

-LS

Indica a SQLIO di catturare i tempi di latenza per i dischi

-BN

Indica a SQLIO di non utilizzare il buffering

Vediamo un esempio pratico: facciamo un test di lettura random, per una durata di 10 secondi, utilizzando blocchi di 8KB, sfruttando 8 thread ed 8 richieste contemporanee.

Poiché il numero di I/O contemporanei è determinato dal prodotto del numero di thread per il numero di richieste contemporanee, chiederemo al sistema di effettuare 64 I/O.

Il comando da eseguire sarà:

C:\Program Files (x86)\SQLIO> sqlio.exe –s10 –kR –frandom –b8 –t8 –o16 –LS –BN E:\testfile.dat

Questo il risultato del test: nella prima parte vengono riportati i parametri di esecuzione, segue una sezione CUMULATIVE DATA contenente i risultati del test e per finire un istogramma che rappresenta, in forma testuale, la distribuzione dei valori percentuali dei campioni raccolti per i valori di tempo che vanno da 0 a 24 millisecondi.

image

Ma come si interpretano queste informazioni?

Ci sono tre valori che ci indicano quanto è performante il nostro storage:

- IOs/sec (i famosi IOPS – numero di operazioni di I/O al secondo), che in questo test sono pari a 23345.00 IOPS

- MBs/sec, che qui sono pari a 182.38 MB/sec

- Latenza min/media/massima, qui rispettivamente 0/4/14 ms.

L’istogramma indica come la maggior parte (18% x 5 valori = 90%) della durata delle operazioni di I/O è compresa tra i 3 ed i 7 ms.

La latenza ottimale è generalmente indicata in:

- 1-5 ms per il Transaction Log (valori ottimali = 1 ms per array con cache)

- 4-20 ms per i data files in un sistema OLTP (valori ottimali < 10 ms)

- 30 ms o meno per Data Warehouse

Bene, per ora ci fermiamo qui.

Nella prossima puntata vedremo come automatizzare l’esecuzione dei test utilizzando batch e Powershell.

Risorse

Di seguito alcuni link utili per approfondire la conoscenza di quanto descritto nel presente articolo:

§ SQLIO Disk Subsystem Benchmark Tool
https://www.microsoft.com/en-us/download/details.aspx?id=20163

§ Comando FSUTIL
https://technet.microsoft.com/en-us/library/cc753059(v=ws.10).aspx

§ SQL Server Best Practices
https://technet.microsoft.com/en-us/library/Cc966412

§ How it works: Bob Dorr’s SQL Server I/O presentation
Bob Dorr, Microsoft CSS Engineer
https://bit.ly/b7R1pX

§ SQLIO, PowerShell and storage performance: measuring IOPs, throughput and latency for both local disks and SMB file shares
Jose Barreto, Microsoft File Server Team member
https://bit.ly/14qKOzK