PowerStore: tecniche efficaci per valutare le prestazioni degli array di storage

Nota: il benchmarking è valido solo se tutto è configurato secondo le best practice di PowerStore e non ci sono problemi di connettività o di configurazione. In caso contrario, il test potrebbe produrre dati irrilevanti.

• Testare utilizzando variabili che si avvicinano a quello che sarà il carico di lavoro/ambiente reale. Ricorda che la maggior parte degli strumenti sono simulatori e non raggiungono mai il 100% di un vero carico di lavoro di produzione simulato.
• Se il carico di lavoro varia notevolmente, prendere in considerazione l'esecuzione di più iterazioni di test di lettura/scrittura con dimensioni di blocchi e modelli di accesso variabili.
• Utilizzare operazioni o test multithreading e asincroni per garantire funzionalità di prestazioni parallele o simultanee e garantire che venga esercitato il potenziale di throughput aggregato complessivo. 
• Valutare ed esaminare i benchmark standard di settore per le apparecchiature considerate in relazione al carico di lavoro di produzione della propria azienda.
• Evitare di eseguire test su file system e/o volumi vuoti o con utilizzo di spazio ridotto. Se non si prealloca spazio nei carichi di lavoro di scrittura, è possibile visualizzare la latenza dovuta all'allocazione immediata dello spazio durante il test.
• Non dimenticare di testare l'I/O di lettura, in quanto è solitamente l'operazione prevalente nella maggior parte degli ambienti. Prestare attenzione alla perdita di pacchetti/frame nell'infrastruttura di rete durante il test.
• Verificare che si stia eseguendo il test su più dispositivi per simulare un ambiente tipico con molti host o client. Ad esempio, in PowerStore, un numero valido è 16 volumi. Il conteggio dei volumi in genere corrisponde al numero di host o client utilizzati (fisici o virtuali); È qui che si ottiene la concorrenza.

 

Simulatori e strumenti di
benchmarkingTieni presente che la maggior parte degli strumenti sono simulatori e probabilmente non riusciranno mai a simulare il 100% di un carico di lavoro di produzione reale. Questi strumenti di benchmarking vengono utilizzati per farsi un'idea di come le prestazioni potrebbero o dovrebbero essere in determinate situazioni. Dell non è proprietaria di questi strumenti e non è responsabile di eventuali problemi che potrebbero essere associati ad essi.

In qualsiasi situazione di test delle prestazioni, assicurarsi che vengano utilizzati strumenti con funzionalità asincrone e multithreading. Ecco alcuni esempi di questi strumenti:

• Flexible I/O Tester (FIO)
• IOmeter
• Vdbench (richiede un account Oracle)
• NFSometer  (solo Fedora/NFS)
• Intel NAS Performance Checklist

 

Evitare i seguenti tipi di test:

• Copia e incolla
• Trascinamento
• Backup su disco di un singolo file system
• Test DD
• Rlarge
• Wlarge
• Mkfile
• Decompressione, estrazione e compressione

Nella maggior parte degli scenari di benchmarking, è necessario essere consapevoli di alcuni aspetti. Questa sezione non riguarda la comprensione delle dimensioni e delle caratteristiche dei carichi di lavoro. Tuttavia, se non si dispone di dati precedenti e occorre una stima approssimativa del comportamento dell'applicazione per eseguire il benchmarking delle le funzionalità di PowerStore (non delle prestazioni di carichi di lavoro specifici), considerare i seguenti fattori:

 

 

IODepth (profondità della coda)
Una profondità di I/O bassa (o non sufficientemente elevata) può limitare il throughput potenziale a seconda della situazione. Pertanto, verificare sempre che il valore IOdepth sia sufficientemente alto da riflettere o emulare i requisiti di concorrenza di un carico di lavoro. Un valore IOdepth troppo basso potrebbe non utilizzare correttamente il dispositivo al suo massimo potenziale. Inoltre, prestare attenzione a un valore IOdepth troppo alto, in quanto può causare un accodamento notevole sul dispositivo e, a seconda del tempo di servizio del dispositivo, i tempi di risposta potrebbero essere di conseguenza più elevati. Questo può riflettere l'aspetto che potrebbe avere un sistema sovraccarico.

Per questo test, i numeri sono significativamente inferiori quando c'è una IOdepth di uno rispetto a una IOdepth di qualcosa di più reale, come 64. Tenete presente che questo avviene con un array All-Flash e quindi questo concetto viene visto nella sua forma estrema, ma sempre più comune."

IOdepth=1" si tratta di circa ~30.000 operazioni di input e output al secondo (IOPS) in media per il test.

 

"IOdepth=64" equivale a una media di circa ~107.000 IOPS per il test.

 

 

"IOdepth=256" equivale a una media di circa ~142.000 IOPS per il test.

 

 

Come menzionato in precedenza, nella maggior parte delle configurazioni le prestazioni si livellano a una certa profondità IOdepth. Qui c'è una profondità della coda pari a 512 con solo un piccolo aumento di IOPS rispetto a una profondità IOdepth di 64.

"IOdepth=512" equivale a una media di circa ~146.000 IOPS per il test.

 

 


Asincrona e sincronizzazione
a confrontoVengono utilizzati due motori principali. I più diffusi e di gran lunga i più efficienti in termini di prestazioni sono con I/O asincrono. Il tipo di engine meno efficiente e con prestazioni inferiori è con I/O sincrono e viene solitamente utilizzato con applicazioni che presentano rigidi requisiti di integrità e di garanzia dei dati. L'I/O sincrono può anche trovarsi nelle tecnologie di replica con RPO (Recovery Point Objective) vicino allo zero. Nei test e nel benchmarking delle prestazioni, dal punto di vista dell'host, "asincrono" significa che non è necessario un acknowledgment di un singolo I/O per richiedere l'I/O successivo. Nei carichi di lavoro sincroni, è necessaria un acknowledgment di un I/O prima dell'emissione del successivo e di un acknowledgment (ACK) per ogni I/O successivo richiesto. Pertanto, l'I/O sincrono di solito ha una coda di 1 o inferiore e non utilizza mai completamente la risorsa al suo massimo potenziale. L'accoppiamento di operazioni sincrone con un numero di thread basso o singolo può limitare notevolmente il potenziale di prestazioni, quindi verificare sempre che si stiano eseguendo test asincroni e, se si utilizzano test sincroni, assicurarsi di utilizzare più thread, a meno che l'ambiente dell'applicazione non indichi esplicitamente di non farlo.

Async (Libaio - asincrona nativa di Linux) = sincrona a 1 thread



(I/O sincrono):  

 

 

Numero di
threadLe filettature sono importanti. I test devono sempre essere eseguiti utilizzando più thread, in particolare nei test/carichi di lavoro sincroni. Si tenta di simulare più iterazioni di un processo/test in base al comportamento del processo di un'applicazione aziendale. Più thread abbinati a un'attività simultanea consentono di ottenere il throughput aggregato di un sistema. La maggior parte dei motori asincroni utilizza più thread, pertanto non è necessario preoccuparsi del conteggio dei thread. Senza disporre di un numero sufficiente di thread durante i carichi di lavoro sincroni, è possibile limitare notevolmente il throughput potenziale totale di un test di carico rispetto a un sistema.

"Multithreaded" indica più thread che lavorano in parallelo. Ad esempio, se si dispone di un singolo dispositivo in grado di eseguire 1.000 operazioni di I/O al secondo in un carico di lavoro sincrono, il dispositivo ha un tempo di risposta di 1 ms senza coda (quindi senza coda, tempo di servizio e tempo di risposta devono essere sinonimi). Ovviamente, i dispositivi con tempi di risposta di 1 ms possono svolgere molto più lavoro di 1.000 IOPS e questo si ottiene impilando più thread o flussi paralleli dello stesso carico di lavoro. Quindi, se si aumentano i thread (o "cose che eseguono questo lavoro specifico") a 10, ora si hanno 10 singoli thread che eseguono I/O su un dispositivo a 1 ms. Ogni singolo thread del carico di lavoro continua a ricevere 1 ms, il che significa che ogni thread raggiunge ancora solo 1.000 IOPS, ma ora l'intero "processo" o "processo" eseguito da questi thread multipli riceve 10.000 IOPS.

Esistono strumenti e carichi di lavoro in grado di raggiungere adeguatamente i limiti di un dispositivo con un singolo thread e alcuni hanno bisogno di più spazio. In sintesi, quando si simula un carico sincrono, si desidera avere il maggior numero possibile di thread/worker/flussi senza influire sul tempo di risposta complessivo. Esiste un punto in cui l'aumento del numero di thread smette di avere un effetto positivo (quando il dispositivo è occupato al 100%). In genere, con i carichi di lavoro asincroni, il numero di thread è gestito per impostazione predefinita. Ad esempio, di seguito è comunque possibile notare una differenza tra 1 thread e 10 per un carico di lavoro asincrono, anche se non significativa. La morale è che con i carichi di lavoro asincroni non occorre preoccuparsi dei thread. 

In questo caso, un singolo thread può raggiungere 68.000 IOPS utilizzando l'engine "libaio" (asincrono). 

 

Se si aumentano i thread (numjob) a 10, è comunque possibile notare un aumento degli IOPS.

 

Quando si tratta di carichi di lavoro sincroni, anche se questo è un caso estremo, potrebbero essere presenti due fattori principali che causano un test con prestazioni non buone, data la natura sincrona. 

inviare I/O-1, attendere ACK, inviare I/O-2, attendere ACK e così via.

 E non potendo eseguire lo stack di più thread per lo stesso scopo. 

job1=invia I/O-1 - job2=invia I/O-1 - job3=invia I/O-1..... job1=get ack, invia I/O-2 - job2=ottieni ack, invia I/O-2 - job3= ottieni ack, invia I/O-2 e così via

Flag diretto

Con alcuni strumenti, in particolare strumenti/sistemi operativi basati su *nix, è possibile che sia visualizzata un'opzione per "Direct I/O." È possibile utilizzarla con engine "asincroni" da non confondere con I/O "sincrono". In alcuni strumenti senza questo flag specificato, è possibile scrivere nella cache del server e non direttamente sul disco. Ciò che l'host deve fare è bypassare la propria cache e scrivere direttamente su disco. Questo è un fattore essenziale quando si esegue un test dello storage. Quando è impostato il flag "direct", tecnicamente la scrittura avviene sul disco, sebbene il disco in questo caso sia in realtà la cache di storage. Questo è ancora accettabile per scopi di test perché anche con il carico di lavoro corretto si sta comunque simulando e imitando accuratamente il comportamento di questo carico di lavoro in un ambiente reale, poiché anche il carico di produzione raggiungerà la cache prima di inviare nuovamente la conferma. (Non sentirti imbrogliato solo perché stai ottenendo numeri di prestazioni della cache coinvolti e non solo gli spindle back-end.)

 

Larghezza di banda (MB/s) e throughput (IOPS)

Esistono due prospettive principali per cui eseguire un test. Il throughput nel campo delle prestazioni e del networking in genere si riferisce al trasferimento dei dati, tuttavia in un ambiente SAN/a blocchi è comune utilizzare il "throughput" per rappresentare gli IOPS. Pertanto, è necessario prima comprendere le caratteristiche del carico di lavoro per le quali si sta eseguendo il test.

Larghezza di banda (MB/s): la larghezza di banda è la misura dei dati che è possibile inserire in una sola volta (o entro un intervallo X, di solito "al secondo") in una pipe o in un sistema. Ciò significa che misura la quantità di dati trasferiti in un determinato periodo di tempo. Anche se la larghezza di banda e gli IOPS non si escludono a vicenda, è possibile avere numeri di larghezza di banda superiori o inferiori con la stessa quantità di IOPS: tutto dipende dalle dimensioni dei blocchi. Ricordare che non si sta misurando la velocità con la larghezza di banda. La velocità è qualcosa di completamente diverso e, sebbene influisca sulla larghezza di banda, è in genere un elemento che non è possibile controllare con carichi di lavoro a elevato utilizzo della larghezza di banda. Pertanto, in caso di test per la larghezza di banda, utilizzare sempre blocchi più grandi (entro limiti ragionevoli) in modo che i dati per I/O siano maggiori rispetto a quando si esegue il test per gli IOPS, poiché i blocchi più grandi richiederanno naturalmente più tempo per la manutenzione. Se, ad esempio, si desidera raggiungere 1 MB/s ma si utilizzano blocchi da 8 KB, è necessario eseguire il push di circa 125 IOPS per raggiungere questo obiettivo. Tuttavia, se si utilizzassero blocchi da 512 KB, sarebbero necessari solo due (2) IOPS.
(Se si mantengono i 125 IOPS e si aumenta comunque la dimensione del blocco da 8 KB a 512 KB, si arriva a 64 MB/s).

Tuttavia, poiché sono presenti più dati all'interno di un singolo I/O, in genere è necessario più tempo per "impacchettare" tale I/O (trovare, mettere insieme e così via). Pertanto, i tempi di servizio possono essere naturalmente più elevati. A volte la coda è più ridotta e di conseguenza i tempi di risposta, sebbene naturalmente più elevati, dovrebbero essere piuttosto ravvicinati. Tenere presente che, anche se il tempo di risposta svolge un ruolo nella quantità di larghezza di banda che è possibile raggiungere, l'aumento della quantità di dati presenti per I/O solitamente ha maggior peso di un eventuale lieve aumento del tempo di risposta (RT) per tale tipo di I/O. Poiché i tempi di risposta sono più elevati, non si desidera che i carichi di lavoro a blocchi di grandi dimensioni debbano essere casuali. Pertanto, i carichi di lavoro della larghezza di banda tendono a essere sequenziali. Quando si introduce una natura casuale in un carico di lavoro a blocchi di grandi dimensioni, la velocità di trasferimento dei dati costante viene costantemente interrotta e si iniziano a sentire gli effetti dei tempi di risposta leggermente più elevati per I/O.

Throughput (IOPS): throughput/IOPS è la prospettiva più comune con i carichi di lavoro di blocchi di piccole dimensioni, soprattutto quando diventano più casuali. Qualsiasi valore superiore a 32 KB-64 KB può essere considerato un blocco di grandi dimensioni. Con il throughput, i fattori sopra menzionati sono più importanti (ad esempio numero di thread, sincronia, asincronia, profondità della coda e così via). In questo caso si sta tentando di misurare non la quantità di dati complessivi che è possibile trasferire durante l'intervallo X, ma piuttosto quanti singoli pacchetti (richieste di I/O) che contengono tali dati che si sta tentando di servire (a ogni intervallo x). Gli ambienti di tipo OLTP (settore bancario) si preoccupano poco della quantità di dati che è possibile trasferire, poiché il footprint dei loro dati è solitamente ridotto. Tuttavia, questi set di dati di piccole dimensioni possono essere e sono in genere occupati. Questi set di dati presentano un'elevata asimmetria (si fa riferimento a una piccola quantità di spazio ma con una variazione notevole e costante). I pacchetti di dati di piccole dimensioni contengono in genere solo richieste di modifica/aggiornamento di blocchi con valori stringa più ridotti o numerici e pertanto non sono necessari pacchetti di I/O di grandi dimensioni. Tuttavia, a causa della natura delle transazioni e del loro numero elevato, dobbiamo verificare di poter stare al passo con ogni singola domanda. In genere, quanto più ridotte sono le dimensioni dei blocchi, tanti più IOPS è possibile raggiungere in un dato scenario e, sebbene i carichi di lavoro a blocchi di piccole dimensioni siano principalmente associati all'accesso casuale, è possibile raggiungere un throughput ancora maggiore con carichi di lavoro sequenziali a blocchi di piccole dimensioni. Tuttavia, i carichi di lavoro sequenziali a blocchi di piccole dimensioni sono specifici e non comuni, quindi è possibile testare questi scenari solo se l'ambiente lo richiede.