Impatto dei livelli RAID su IOPS [chiuso]


11

Per quanto riguarda lo IOPS, ho visto diverse fonti sul web che suggeriscono che lo IOPS di un dato numero di dischi è semplicemente lo IOPS di un singolo disco moltiplicato per il numero di dischi.

Se la mia comprensione di IOPS è corretta (e non ne sono affatto sicuro), avrei pensato che la realtà dipendesse - tra molti altri fattori - dal livello RAID. Con RAID 1/10, tutti i dati vengono duplicati su almeno due dischi, riducendo la contesa su un determinato disco per alcuni schemi di I / O. Tuttavia, nei livelli RAID con striping come RAID 0/5/6, i dati vengono distribuiti anziché duplicati, il che significa che le richieste di lettura consecutive potrebbero essere per lo stesso mandrino, causando il blocco mentre il precedente IO viene completato. Le scritture sono ancora più contese.

Devo aggiungere che apprezzo che la realtà sia molto più complessa a causa di varie ottimizzazioni e altri fattori. La mia domanda è davvero solo quella di stabilire se, a un livello molto elementare, la mia comprensione di cosa significhi IOPS è sulla buona strada. È possibile che la mia affermazione secondo cui IOPS potrebbe essere influenzato dai livelli RAID in modo tale da indicare un malinteso di base del concetto.


4
Lo stai semplificando al punto da escludere l'impatto della cache del controller RAID, del sistema operativo, del comportamento dell'applicazione, dell'I / O sincrono o asincrono e del tipo di disco. Allora cosa stai cercando?
ewwhite,

@ewwhite Mi dispiace, avrei dovuto essere più chiaro. Spero davvero di vedere se il principio di base del mio pensiero è corretto, piuttosto che fare previsioni nel mondo reale. Apprezzo che in realtà le cose siano fortemente influenzate da ogni sorta di ottimizzazione e altre complessità. C'è una situazione del mondo reale in background, ma come spesso accade quando stai cercando qualcosa con cui non hai molta familiarità, ho deciso di andare via e fare un po 'di apprendimento in background, quindi mi sento un po' più a proprio agio con i principi di base.
dal

Sono stato tentato di chiedere se qualcuno avesse qualche consiglio su letture di buona qualità in merito alla teoria e ai concetti relativi all'archiviazione e alle sue prestazioni, ma non l'ho fatto perché pensavo che potesse essere considerata una domanda inappropriata per ServerFault. Sembra che ci sia abbastanza poca scrittura di alta qualità sull'argomento là fuori sul web che ho trovato finora - forse perché è un argomento abbastanza complesso che pochi capiscono davvero pienamente.
dal

Le prestazioni RAID dipendono molto più dall'hardware del controller e dai limiti di implementazione che dal livello RAID. Ad esempio, RAID0, RAID1, RAID5 e RAID6 possono teoricamente impiegare tutti i dischi per letture lunghe, quindi possono avere la stessa identica velocità di lettura su un controller ideale.
Zac67,

Risposte:


12

Per l'HDD , gli IOPS sono generalmente dominati dal tempo di accesso al disco, che è la somma della latenza di ricerca + ritardo di rotazione + ritardo di trasferimento. Poiché queste variabili dipendono fortemente dai modelli di accesso e hanno interazioni non ovvie con il layout RAID specifico (ovvero: dimensione della striscia) e controller (cioè: sintonizzazione in anticipo), qualsiasi semplice risposta SARÀ SBAGLIATA.

Tuttavia, proviamo ad avere una figura da baseball. A una prima approssimazione, gli IOPS garantiti da un array n-disk dovrebbero essere n-volte gli IOPS di un singolo disco. Tuttavia, sia il livello RAID che il modello di accesso ai dati , spostando il peso tra latenza di ricerca / rotazione / trasferimento, cambiano radicalmente questa approssimazione del primo ordine.

Facciamo alcuni esempi, ipotizzando 100 IOPS per singolo disco (un valore tipico per i dischi a 7200 RPM) e array a 4 dischi (eccetto RAID1, spesso limitato solo a 2 vie):

  • un singolo disco è 100 IOPS, sia in lettura che in scrittura (nota: a causa della scrittura a coalescenza, la scrittura di IOPS è generalmente superiore a quella di IOPS di lettura, ma consente di ignorarlo per semplicità)
  • RAID0 (striping a 4 vie) ha fino a 4x gli IOPS casuali e fino a 4x gli IOPS sequenziali. La parola chiave qui è "fino a": a causa della natura dello striping e dell'allineamento dei dati, se i settori a accesso casuale risiedono prevalentemente su un singolo disco, si finirà con IOPS molto più bassi.
  • RAID1 (mirroring a 2 vie) è più complesso da profilare. Poiché diversi dischi possono cercare dati diversi, ha fino a 2 volte lo IOPS di lettura casuale ma lo stesso IOPS di scrittura casuale 1x (o leggermente inferiore, a causa dell'overhead). Se tutte le cose si allineano bene (cioè: letture sequenziali grandi ma non al 100%, un controller RAID che usa blocchi / concetto di blocchi / strisce anche in modalità mirroring, read-ahead funzionante correttamente, ecc.) A volte le letture sequenziali possono essere fino al doppio del singolo valore del disco, mentre le scritture sequenziali rimangono limitate a 1x il singolo disco (ovvero: nessuna velocità)
  • RAID10 (mirroring a 4 vie) è, per quanto riguarda le prestazioni, a metà strada tra lo striping RAID0 a 4 vie e il mirroring a 2 vie. Ha fino a 4 volte gli IOPS in lettura casuale e fino a 2 volte gli IOPS in scrittura casuale. Per i trasferimenti sequenziali, si applica l'avvertimento RAID1: a volte ha fino a 4x gli IOPS in lettura sequenziale, ma solo il doppio degli IOPS in scrittura sequenziale. Si noti che alcune implementazioni RAID10 (ovvero Linux MDRAID) offrono layout diversi per array RAID10, con profilo di prestazioni diverso .
  • RAID5 (parità a strisce) ha fino a 4 volte gli IOPS di lettura casuale, mentre gli IOPS di scrittura casuale, a seconda di una serie di fattori come la dimensione della scrittura rispetto alla dimensione dello striping, la disponibilità di una cache di striping di grandi dimensioni, l'algoritmo di ricostruzione dello stripe stesso (leggi-ricostruisci-scrivi vs leggi-modifica-scrivi), ecc., può essere ovunque tra 0,5x (o inferiore) e 2x gli IOPS di un singolo disco. I carichi di lavoro sequenziali sono più prevedibili, con 3 volte lo IOPS di un singolo disco (sia in lettura che in scrittura)
  • RAID6 (doppia parità con striping) si comporta in modo molto simile al fratello RAID5, ma con prestazioni di scrittura inferiori. Ha fino a 4x gli IOPS di lettura casuale di un singolo disco, ma le sue prestazioni di scrittura casuali sono persino inferiori a RAID5, con gli stessi valori assoluti (0,5x - 2x) ma con una media di parole reali inferiore. Letture e scritture sequenziali sono limitate a 2 volte l'IOPS di un singolo disco.

Lasciami ripetere: quanto sopra sono approssimazioni semplici e quasi rotte. Ad ogni modo, se vuoi giocare con un calcolatore IOPS RAID (gravemente incompleto), dai un'occhiata qui .

Ora torna al mondo reale. Sui carichi di lavoro reali, RAID10 è spesso la scelta più rapida e preferita , mantenendo alte prestazioni anche di fronte a un array degradato . RAID5 e RAID6 non devono essere utilizzati su carichi di lavoro sensibili alle prestazioni, a meno che non siano di natura centrata sulla lettura o sequenziale. Vale la pena notare che i controller RAID seri hanno una grande cache di writeback protetta da perdita di potenza principalmente per superare (con una pesante memorizzazione nella cache) le basse prestazioni casuali di scrittura RAID5 / 6. Non usare mai RAID5 / 6 con controller RAID senza cache , a meno che non ti interessi davvero alla velocità dell'array.

Gli SSD sono bestie diverse, pensato. Poiché hanno un tempo di accesso medio molto più basso dal punto di vista tecnico, i RAID basati su parità comportano un sovraccarico di prestazioni molto inferiore e sono un'opzione molto più praticabile rispetto agli HDD. Tuttavia, in un piccolo carico di lavoro incentrato sulla scrittura casuale, utilizzerei comunque una configurazione RAID10.


Non usare mai RAID5 / 6 con controller RAID senza cache, a meno che non ti interessi davvero alla velocità dell'array. Puoi cavartela se sai davvero cosa stai facendo e hai uno stretto controllo del tuo schema IO. Se non si sta eseguendo altro che IO sequenziale adattato alle dimensioni dello stripe dell'array, è possibile cavarsela utilizzando RAID5 / 6 senza cache. E la cache non può salvare le prestazioni se si eseguono abbastanza operazioni casuali di scrittura a blocchi piccoli su un array RAID5 / 6, anche se il valore di "sufficienti operazioni IO" che uccide le prestazioni può essere un numero enorme per un controller RAID davvero buono.
Andrew Henle,

@AndrewHenle Certo, se si emettono solo letture / scritture sequenziali allineate a strisce, anche un controller senza cache in modalità RAD5 / 6 può dare buoni risultati. Tuttavia, questo è un modello di utilizzo molto ristretto (ad esempio: streaming e backup). Per un carico di lavoro generico, un controller senza cache combinato con qualsiasi RAID di parità sarà veramente lento. Alcuni controller richiedono addirittura una cache di writeback protetta da powerloss per consentire la creazione di un RAID di parità.
shodanshok,

Stavo pensando di più sugli amministratori che si chiedono il motivo per cui la loro archiviazione elettronica aziendale 21-drive array di RAID6 con una dimensione di 19 MB-perché-grande-must-be-veloce striscia è lento ....
Andrew Henle

1

È solo una questione di definizioni. Puoi misurare IOPS a diversi livelli nel sistema e otterrai valori diversi. Ad esempio, supponiamo di avere due dischi con mirroring e di scrivere il più velocemente possibile. L'IOP che va sui dischi sarà il doppio del numero di IOP che un singolo disco può gestire con un carico di scrittura simile. Ma gli IOPS che entrano nel controller saranno uguali al numero di IOPS che un singolo disco può gestire.

Di solito ciò che ci interessa è il numero di IOPS logici che possiamo ottenere nell'array e non ci interessa particolarmente ciò che accade a livello del disco. In tal caso, l'utente ha ragione e l'IOP dipende dal livello RAID, dal numero di dischi, dalle prestazioni dei singoli dischi e, in alcuni casi, dalle caratteristiche specifiche delle operazioni.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.