Introduzione
Ricapitolando: Nel Blog Episodio-1 abbiamo coperto RHCS, BlueStore introduzione, di laboratorio, i dettagli hardware metodologia di benchmarking e confronto di prestazioni tra Default Ceph configurazione vs Sintonizzati Ceph configurazione
Questo è il secondo episodio della performance serie di blog su RHCS 3.2 BlueStore in esecuzione sul flash cluster. Non esiste una regola empirica per classificare le dimensioni dei blocchi in una categoria piccola, media e grande. Come tale abbiamo designato 4K alla categoria di piccole dimensioni del blocco, 8K-64K a medio e 1M-4M nella categoria di grandi dimensioni del blocco. In questo episodio imparerai a conoscere la caratterizzazione delle prestazioni dello storage a blocchi Ceph per blocchi di dimensioni piccole (4K), medie (8K-32K) e grandi (1M-4M) su modelli di carico di lavoro di lettura casuale, scrittura casuale e lettura-scrittura casuale.
Riepilogo esecutivo
- Carico di lavoro 4K a blocchi piccoli, consegnato fino a 2.2 Milioni di letture casuali, 691K random read-write (70/30) e 463K random write IOPS fino a quando non sono limitati dalla contesa CPU e media.
- Simile al carico di lavoro a blocchi piccoli, le prestazioni dei blocchi medi sono state limitate dalla contesa tra CPU e media.
- Grande carico di lavoro a blocchi 4M prestazioni di picco registrate a 10,9 GB / s per tutti e tre i modelli di test, ovvero mix di lettura, scrittura e lettura-scrittura casuali (70/30) fino a quando limitato dalla larghezza di banda della rete client.
Part-1: Small Block Size (4KB) Performance
Key Takeaways
- Random Read workload showed 2.2 Milioni di IOPS@3ms di latenza media fino a quando non viene controllata dalla saturazione dei media.
- Il carico di lavoro mix di lettura-scrittura casuale (70/30) ha mostrato 691K IOPS@6ms di latenza media fino a quando non è stato bloccato dalla contesa delle risorse della CPU del nodo Ceph.
- Scrittura casuale: 463K IOPS @ 11ms latenza media fino a quando non viene controllato dalla contesa delle risorse della CPU del nodo Ceph.
Sommario
In questa parte del test, l’interfaccia di archiviazione dei blocchi Ceph è stata esercitata con un carico di lavoro di piccole dimensioni (4KB) su pattern di mix random read, random write e random read-write (70/30). Le metriche chiave acquisite durante il test includono IOPS, media, latenza, CPU del nodo Ceph e utilizzo dei media.
Graph-1 mostra le migliori prestazioni per la dimensione del blocco 4K su diversi modelli di accesso con 5 nodi all-flash. Come tale la prestazione massima è risultata essere
- Lettura casuale: 2,2 milioni di IOPS@ 3ms latenza media
- Lettura-scrittura casuale (70/30) Mix: 691K IOPS @6ms latenza media
- Scrittura casuale: 463 K IOPS@11 ms latenza media
hThe CPU e l’utilizzo dei media catturati in graph – 2 e graph-3 ci ha aiutato a capire i colli di bottiglia per i diversi modelli di carico di lavoro.
- Si è riscontrato che le prestazioni di lettura casuale sono state bloccate dalla contesa delle risorse della CPU, tuttavia, l’utilizzo dei media è stato trovato anche sul lato più alto. Come tale abbiamo aggiunto ulteriori nodi Ceph (CPU e media) le prestazioni di lettura casuale avrebbero potuto scalare più in alto.
- Sia per la scrittura casuale che per il mix di lettura-scrittura casuale (70/30), le prestazioni sono state strozzate da un maggiore consumo di CPU. È interessante notare che allo stesso tempo i media avevano un throughput di riserva sufficiente che rimaneva inutilizzato a causa della mancanza di potenza computazionale. In quanto tale, una maggiore allocazione del core della CPU agli OSD Ceph avrebbe potuto fornire prestazioni più elevate per carichi di lavoro mix di scrittura casuale & lettura-scrittura casuale.
L’utilizzo del dispositivo dati OSD (P4500 NVMe) è rimasto sotto il 50% di utilizzo, il dispositivo Intel Optane P4800 che ospitava i metadati BlueStore WAL e Rocksdb è risultato molto occupato@90%. Il parametro bluestore_min_alloc_size_ssd è stato impostato su 16KB, quindi tutte le scritture sotto 16KB sono state posticipate, la scrittura prima va nel dispositivo WAL e quindi viene scritta in modo asincrono sui dati OSD, quindi il dispositivo Optane P4800 ha assorbito le scritture per tutti gli OSD sull’host. Nonostante l’elevato utilizzo sul dispositivo RocksDB / WAL, non abbiamo visto alcun segno di contesa sul dispositivo dati OSD P4500. Ma sulla base di questa esperienza non consigliamo di mettere più di 7 x P4500 NVMe dispositivi dietro un singolo Intel Optane P4800 per WAL/RocksDB.
Grafico 2
Grafico 3
un Altro interessante test che abbiamo eseguito è stato client sweep test, in cui ci sono linearmente in scala il numero di clienti a partire da 20 fino a 140. Aumentando il carico del client, abbiamo osservato un miglioramento lineare delle prestazioni fino a quando non abbiamo raggiunto la congestione della CPU su Ceph OSD. Con i clienti 100 abbiamo osservato IOPS di scrittura 4K aggregati ~445K. Dopo questo punto la congestione delle risorse di sistema ha provocato latenze di coda elevate. Intel Optane utilizzato come metadati ha contribuito ad assorbire picco di latenza con un elevato numero di client paralleli, come tale latenza media rimasta sotto 40ms.
G
Parte 2: Prestazioni di dimensione media del blocco
Take away chiave
- Fino a quando le prestazioni non sono state bloccate dalla saturazione della CPU e dei media, 5 nodi Ceph all-flash hanno consegnato ~1,8 milioni di letture casuali, ~636K readwrite casuale (70/30) e ~410K IOPS di scrittura casuale.
- Per scalare le prestazioni, è stato necessario aggiungere ulteriori nodi OSD Ceph nel cluster Ceph esistente.
Sommario
Nei seguenti grafici, abbiamo cercato di rappresentare vari punti dati diversi come IOPS, latenza media, latenza di coda, CPU del nodo Ceph e utilizzo dei media. E tutti questi in una gamma di dimensioni del blocco cioè da 4K fino a 64K per scrittura casuale, lettura casuale e lettura-scrittura casuale (70/30) mix.
Alcuni punti dati interessanti includono
- Come previsto, le dimensioni dei blocchi di piccole dimensioni hanno mostrato IOPS più alti e latenze medie e inferiori, rispetto alle dimensioni dei blocchi medi. Come tale abbiamo osservato ~1,8 milioni, ~636K, ~ 410K IOPS per lettura casuale, Mix di lettura casuale e carico di lavoro di scrittura casuale rispettivamente.
- È stato osservato un elevato utilizzo su CPU e dispositivi multimediali sui nodi OSD Ceph. L’utilizzo è risultato essere alto come ~90% e ~ 80% rispettivamente per CPU e media rispettivamente. Come tale, le prestazioni potrebbero essere aumentate se avessimo aggiunto i nodi OSD Ceph al cluster Ceph esistente.
G
Parte 3: Blocchi più Grandi Prestazioni
Takeaway Chiave
- Grande blocco di 4M di prestazioni di picco a 10.9 GB/s per lettura casuale, scrittura e lettura-scrittura (70/30) mix.
- La rete client è risultata essere il fattore limitante e causa un collo di bottiglia delle prestazioni.
- Le prestazioni avrebbero potuto essere più elevate, se avessimo avuto più nodi client o pipe di rete più grandi.
Sommario
Tutti i diversi modelli che abbiamo testato cioè random read, write e read-write (70/30) mix per grandi dimensioni del blocco 4M carico di lavoro superato a 10.9 GB/s throughput aggregato. La rete client è risultata essere il fattore limitante che causa il collo di bottiglia delle prestazioni. Oltre alla rete, la seconda risorsa più utilizzata era media, tuttavia, aveva abbastanza spazio disponibile per fornire maggiori prestazioni, se la rete non era il collo di bottiglia.
G
Avanti
Continuando la serie di blog di benchmarking, nella prossima sezione, spiegheremo i risultati associati al test di scalabilità RHCS 3.2. Rispondere ad alcune domande chiave come “come cambiano le prestazioni passando dal cluster a 3 nodi a 5 nodi”. Restate sintonizzati.