Le tecnologie per migliorare le prestazioni basate sull'uso degli SSD e ampiamente utilizzate negli storage SCS sono state inventate da tempo. Prima di tutto, si tratta dell'uso degli SSD come spazio di archiviazione, che è efficace al 100% ma costoso. Pertanto, vengono utilizzate tecnologie di tiering e caching, dove gli SSD vengono utilizzati solo per i dati più richiesti ("caldi"). Il tiering è adatto per scenari di utilizzo a lungo termine (giorni-settimane) di dati "caldi". Il caching, al contrario, è per l'uso a breve termine (minuti-ore). Entrambe queste opzioni sono implementate nello SCS. . In questo articolo esamineremo l'implementazione del secondo algoritmo – .
Il principio della tecnologia di caching SSD è utilizzare SSD come cache temporanea tra i dischi rigidi e la memoria RAM del controller. Le prestazioni degli SSD sono naturalmente inferiori rispetto a quelle della cache interna del controller, ma il loro volume è di gran lunga superiore. Pertanto, si ottiene un certo compromesso tra velocità e capacità.
Indicazioni per l'uso del caching SSD in lettura:
- L predominanza delle operazioni di lettura su quelle di scrittura (caratteristico più frequentemente per database e applicazioni web);
- La presenza di un collo di bottiglia nella prestazione dell'array di dischi rigidi;
- Il volume dei dati richiesti è inferiore a quello della cache SSD.
Le indicazioni per l'uso del caching SSD in lettura e scrittura sono le stesse, ad eccezione del tipo di operazioni – di tipo misto (ad esempio, server file).
La maggior parte dei fornitori di SCS utilizza il caching SSD nei propri prodotti solo per operazioni di lettura. La differenza fondamentale è la possibilità di utilizzare la cache anche per la scrittura. Per attivare la funzionalità di caching SSD nello SCS QSAN è richiesta l'acquisto di una licenza separata (fornita in formato elettronico).
La cache SSD in XCubeSAN è fisicamente realizzata sotto forma di pool di SSD cache separati. Nel sistema possono esserci fino a quattro pool. Ogni pool, ovviamente, utilizza il proprio set di SSD. E nelle proprietà del disco virtuale definiamo se utilizzerà il pool di cache e quale esattamente. L'attivazione e la disattivazione dell'uso della cache per i volumi possono essere effettuate online senza fermare l'input/output. Inoltre, è possibile aggiungere e rimuovere SSD dal pool anche a caldo. Durante la creazione del pool di cache SSD, è necessario scegliere in quale modalità opererà: solo lettura o lettura+scrittura. Questo influisce sulla sua organizzazione fisica. Poiché possono esserci più pool di cache, le loro funzionalità possono essere diverse (cioè nel sistema possono esserci contemporaneamente pool di cache per lettura e per lettura+scrittura).
Nel caso in cui il pool di cache venga utilizzato solo per la lettura, può essere composto da 1 a 8 SSD. I dischi non devono necessariamente avere la stessa capacità e lo stesso vendor, poiché vengono uniti in una struttura NRAID+. Tutti gli SSD nel pool sono utilizzati in modo congiunto. Il sistema cerca autonomamente di parallelizzare le richieste in arrivo tra tutti gli SSD per raggiungere la massima prestazione. In caso di guasto di uno degli SSD, non succederà nulla di grave: poiché la cache contiene solo una copia dei dati memorizzati nell'array di dischi rigidi. Semplicemente, il volume disponibile della cache SSD diminuirà (o diventerà nullo nel caso di utilizzo iniziale di una cache SSD da un solo dispositivo).
Se la cache è utilizzata per operazioni di lettura + scrittura, il numero di SSD nel pool deve essere un multiplo di due, poiché il contenuto è mirrorato su coppie di dispositivi (si utilizza la struttura NRAID 1+). La duplicazione della cache è necessaria perché può contenere dati che non sono stati ancora scritti sui dischi rigidi. In questo caso, il guasto di un SSD del pool di cache porterebbe alla perdita di informazioni. Tuttavia, in caso di NRAID 1+, il guasto di un SSD porterà semplicemente a cambiare la cache in uno stato di funzionamento "solo lettura" con il ripristino dei dati non scritti sull'array di dischi rigidi. Dopo la sostituzione dell'SSD guasto, la cache tornerà alla sua modalità operativa iniziale. A proposito, per una maggiore sicurezza della cache che opera in lettura + scrittura, si può assegnare un hot spare dedicato.
Nell'utilizzo della funzione di caching SSD in XCubeSAN ci sono una serie di requisiti relativi alla quantità di memoria dei controller SAN: maggiore è la memoria di sistema, maggiore sarà la capacità del pool di cache disponibile.
A differenza della maggior parte dei produttori di SAN, che offrono solo l'opzione di attivare/disattivare il caching SSD come impostazione, QSAN fornisce maggiori possibilità. In particolare, è possibile scegliere la modalità di funzionamento della cache in base alla natura del carico di lavoro. Sono disponibili tre modelli preimpostati, che operano in modo simile ai servizi corrispondenti: database, file system, servizio web. Inoltre, l'amministratore può creare il proprio profilo, impostando i valori richiesti dei parametri:
- Dimensione del blocco (Cache Block Size) – 1/2/4 MB
- Numero di richieste di lettura del blocco affinché venga copiato nella cache (Populate-on-Read Threshold) – 1..4
- Numero di richieste di scrittura del blocco affinché venga copiato nella cache (Populate-on-Write Threshold) – 0..4
I profili possono essere cambiati "al volo", ma naturalmente con l'azzeramento del contenuto della cache e il suo nuovo "riscaldamento".
Considerando il principio di funzionamento della cache SSD, si possono evidenziare le operazioni principali nella sua gestione:
Lettura dei dati quando non sono presenti nella cache
- La richiesta dall'host arriva al controller;
- Poiché i dati richiesti non sono nella cache SSD, vengono letti dai dischi rigidi;
- I dati letti vengono inviati all'host. Contemporaneamente, viene verificato se questi blocchi sono "caldi";
- Se sì, vengono copiati nella cache SSD per un utilizzo successivo.
Lettura dei dati quando sono presenti nella cache
- La richiesta dall'host arriva al controller;
- Poiché i dati richiesti sono nella cache SSD, vengono letti da lì;
- I dati letti vengono inviati all'host.
Scrittura dei dati utilizzando la cache per la lettura
- La richiesta di scrittura dall'host arriva al controller;
- I dati vengono scritti sui dischi rigidi;
- All'host viene restituita una risposta di avvenuta scrittura;
- Contemporaneamente, viene verificato se il blocco è "caldo" (viene confrontato il parametro Populate-on-Write Threshold). Se sì, viene copiato nella cache SSD per future utilizzi.
Scrittura dei dati utilizzando la cache per la lettura + scrittura
- La richiesta di scrittura dall'host arriva al controller;
- I dati vengono scritti nella cache SSD;
- All'host viene restituita una risposta di avvenuta scrittura;
- I dati della cache SSD vengono scritti in background sui dischi rigidi;
Verifica nel caso
Banchina di test
2 server (CPU: 2 x Xeon E5-2620v3 2.4Hz / RAM: 32GB) sono collegati tramite due porte tramite Fibre Channel 16G direttamente all'array XCubeSAN XS5224D (16GB RAM / controller).
Sono stati utilizzati 16 x Seagate Constellation ES, ST500NM0001, 500GB, SAS 6Gb/s, combinati in RAID5 (15+1), per l'array dati e 8 x HGST Ultrastar SSD800MH.B, HUSMH8010BSS200, 100GB, SAS 12Gb/s come cache
Sono stati creati 2 volumi: uno per ogni server.
Test 1. Cache SSD solo in lettura con 1-8 SSD
SSD Cache
- Tipo di I/O: Personalizzazione
- Dimensione del blocco cache: 4MB
- Soglia di popolazione in lettura: 1
- Soglia di popolazione in scrittura: 0
Modello di I/O
- Strumento: IOmeter V1.1.0
- Lavoratori: 1
- In attesa (Profondità della coda): 128
- Specifiche di accesso: 4KB, 100% Lettura, 100% Casuale
In teoria, più SSD ci sono nel pool di cache, maggiori saranno le prestazioni. In pratica, questo è stato confermato. L'unica nota, un aumento significativo del numero di SSD con un basso numero di volumi non porta a un effetto esplosivo.
Test 2. Cache SSD in modalità lettura + scrittura con 2-8 SSD
SSD Cache
- Tipo di I/O: Personalizzazione
- Dimensione del blocco cache: 4MB
- Soglia di popolazione in lettura: 1
- Soglia di popolazione in scrittura: 1
Modello di I/O
- Strumento: IOmeter V1.1.0
- Lavoratori: 1
- In attesa (Profondità della coda): 128
- Specifiche di accesso: 4KB, 100% Scrittura, 100% Casuale
Lo stesso risultato: crescita esplosiva delle prestazioni e scalabilità all'aumentare del numero di SSD.
In entrambi i test, il volume dei dati di lavoro era inferiore al volume totale della cache. Pertanto, nel tempo, tutti i blocchi sono stati copiati nella cache. E il lavoro si svolgeva già, di fatto, con gli SSD, senza coinvolgere praticamente i dischi rigidi. L'obiettivo di questi test era dimostrare chiaramente l'efficacia del preriscaldamento della cache e la scalabilità delle sue prestazioni a seconda del numero di SSD.
Ora torniamo con i piedi per terra e verifichiamo una situazione più realistica, in cui il volume dei dati è maggiore della dimensione della cache. Affinché il test si svolga in un tempo ragionevole (il periodo di "preriscaldamento" della cache aumenta notevolmente con l'aumento delle dimensioni del volume), limiteremo la dimensione del volume a 120GB.
Test 3. Simulazione del funzionamento di un database
SSD Cache
- Tipo di I/O: Database
- Dimensione del blocco cache: 1MB
- Soglia di popolazione in lettura: 2
- Soglia di popolazione in scrittura: 1
Modello di I/O
- Strumento: IOmeter V1.1.0
- Lavoratori: 1
- In attesa (Profondità della coda): 128
- Specifiche di accesso: 8KB, 67% Lettura, 100% Casuale
Verdetto
Come ovvio, si evince una buona efficacia nell'uso della cache SSD per migliorare le prestazioni di qualsiasi storage. questa affermazione si applica pienamente: la funzione di caching SSD è implementata in modo eccellente. Ciò riguarda il supporto per modalità di lettura e lettura + scrittura, la configurazione flessibile per qualsiasi scenario d'uso, oltre alle prestazioni complessive del sistema. Pertanto, per un costo molto ragionevole (il prezzo della licenza è comparabile al costo di 1-2 SSD) è possibile migliorare notevolmente le prestazioni globali.
Fonte: habr.com
