Introducere
recapitulare: în Blog Episode-1 am acoperit RHCS, BlueStore introducere, detalii hardware de laborator, metodologia de benchmarking și compararea performanței între configurația implicită Ceph vs configurare Ceph reglată
acesta este al doilea episod al seriei de bloguri de performanță de pe rhcs 3.2 bluestore care rulează pe clusterul All-Flash. Nu există nicio regulă generală pentru a clasifica dimensiunile blocurilor într-o categorie mică, medie și mare. Ca atare, am desemnat 4K la categoria de dimensiuni mici a blocului, 8K-64K la mediu și 1M-4m în categoria de dimensiuni mari a blocului. În acest episod veți afla despre caracterizarea performanței de stocare bloc Ceph pentru mici (4k), mediu (8k-32k) și mari (1m-4M) dimensiuni bloc peste citire aleatoare, scriere aleatoare și modele de volum de Muncă Citire-Scriere aleatoare.
rezumat executiv
- volum mic de lucru 4K, livrat până la 2.2 milioane de citiri aleatorii, 691k citire-scriere aleatorie (70/30) și 463k scriere aleatorie IOPS până la limitarea conținutului CPU și media.
- Similar cu volumul de muncă bloc mic, performanța bloc mediu sa dovedit a fi limitată de CPU și mass-media dispută.
- bloc mare 4m volumul de muncă performanță de vârf înregistrate la 10.9 GB/s pentru toate cele trei modele de testare adică citire aleatoare, scrie și citire-scriere (70/30) se amestecă până la limitată de lățimea de bandă de rețea Client.
Partea-1: dimensiune bloc mic (4KB) performanță
Takeaways cheie
- volumul de Muncă Citire aleatoare a arătat 2.2 milioane IOPS@3ms latență medie până când este blocată de saturația media.
- Random Read-Write (70/30) mix volumul de muncă a arătat 691K IOPS@6ms latență medie până la bottlenecked de Ceph nod CPU conținut de resurse.
- scriere aleatorie: 463K IOPS@11ms latență medie până când este blocată de disputa resurselor procesorului nodului Ceph.
rezumat
în această parte a testării, interfața de stocare a blocului Ceph a fost exercitată cu volumul de lucru de dimensiuni mici (4KB) în citire aleatorie, scriere aleatorie și modele de mixare aleatorie de citire-scriere (70/30). Valorile cheie capturate în timpul testării includ IOPS, media, latența, CPU-ul nodului Ceph și utilizarea media.
Graph-1 prezinta performanta de top-line pentru dimensiunea blocului 4K pe diferite modele de acces cu 5 noduri all-flash. Ca atare, performanța maximă sa dovedit a fi
- citire aleatorie: 2,2 milioane IOPS@ 3ms latență medie
- citire-scriere aleatorie (70/30) Mix: 691k IOPS @ 6ms latență medie
- scriere aleatorie: 463k IOPS@11ms latență medie
htthe CPU și utilizarea mass-media capturate în graph-2 și graph-3 ne-a ajutat să înțelegem blocajele pentru diferite modele de încărcare de lucru.
- performanța de citire aleatorie s-a dovedit a fi blocată de disputa resurselor procesorului, cu toate acestea, utilizarea media s-a dovedit a fi și în partea superioară. Ca atare, am adăugat noduri Ceph suplimentare (CPU și media) performanța de citire aleatorie ar fi putut fi scalată mai mare.
- atât pentru scrierea aleatorie, cât și pentru mixarea aleatorie de citire-scriere (70/30), performanța a fost blocată de un consum mai mare de CPU. Interesant, în același timp, mass-media a avut suficient debit de rezervă, care a rămas neutilizat din cauza lipsei de putere de calcul. Ca atare, alocarea mai mare a nucleului procesorului către Ceph OSDs ar fi putut oferi performanțe mai mari pentru sarcini de lucru aleatorii de scriere & random read-write mix.
utilizarea dispozitivului de date OSD (P4500 NVMe) a rămas sub utilizarea 50%, dispozitivul Intel Optane P4800 care găzduia metadatele BlueStore WAL și Rocksdb s-a dovedit a fi foarte ocupat@90%. Parametrul bluestore_min_alloc_size_ssd a fost setat la 16KB, prin urmare, toate scrierile sub 16KB au fost amânate, scrierea intră mai întâi în dispozitivul WAL și apoi se scrie asincron la datele OSD, prin urmare, dispozitivul Optane P4800 a absorbit scrierile pentru toate OSD-urile de pe gazdă. În ciuda utilizării ridicate pe dispozitivul RocksDB / WAL, nu am văzut semne de dispută pe dispozitivul de date P4500 OSD. Dar, pe baza acestei experiențe, nu vă recomandăm să puneți mai mult de 7 dispozitive NVMe X P4500 în spatele unui singur Intel Optane P4800 pentru Wal/RocksDB.
Grafic 2
Grafic 3
un alt test interesant pe care l-am efectuat a fost testul de verificare a clienților, unde am mărit liniar numărul de clienți începând cu 20 și până la 140. Pe măsură ce am crescut sarcina clientului, am observat îmbunătățirea performanței liniare până când am lovit congestia procesorului pe Ceph OSD. Cu 100 de clienți am observat ~ 445k agregate 4K scrie IOPS. După acest punct, congestia resurselor sistemului a dus la latențe ridicate ale cozii. Intel Optane folosit ca metadate a ajutat la absorbția spike-ului de latență cu un număr mare de clienți paraleli, deoarece o astfel de latență medie a rămas sub 40ms.
G
Partea 2: Performanță dimensiune bloc Mediu
Takeaways cheie
- până când performanța a fost blocată de CPU și media saturație, 5 noduri Ceph all-flash livrate ~1,8 milioane de random citește, ~636K random readwrite (70/30) și ~410k aleatoare scrie IOPS.
- pentru a scala performanța, au trebuit adăugate noduri Ceph OSD suplimentare în clusterul Ceph existent.
rezumat
în graficele următoare, am încercat să reprezentăm diferite puncte de date diferite, cum ar fi IOPS, latență medie, latență coadă, CPU nod Ceph și utilizarea media. Și toate acestea într-o gamă de dimensiuni ale blocului, adică de la 4K până la 64K pentru scriere aleatorie, citire aleatorie și mixare aleatorie de citire-scriere (70/30).
câteva puncte de date interesante includ
- așa cum era de așteptat, dimensiunile blocurilor mici au prezentat cele mai mari IOPS și latențe medii și coadă mai mici, comparativ cu dimensiunile blocurilor medii. Ca atare, am observat ~1,8 milioane, ~636K, ~410K IOPS pentru citire aleatoare, Mix ReadWrite aleatoare și volumul de muncă de scriere aleatoare, respectiv.
- utilizarea ridicată a fost observată pe dispozitivele CPU și media pe nodurile Ceph OSD. Utilizarea sa dovedit a fi la fel de mare ca ~90% și ~80%, respectiv, pentru CPU și mass-media, respectiv. Ca atare, performanța ar fi putut crește dacă am adăugat noduri Ceph OSD la clusterul Ceph existent.
G
Partea 3: performanță mare dimensiune bloc
Takeaways cheie
- performanță mare bloc 4M a atins punctul culminant la 10.9 GB / s pentru citire aleatoare, scrie și read-write (70/30) amesteca.
- s-a constatat că rețeaua de clienți este factorul limitativ și provoacă un blocaj de performanță.
- performanța ar fi putut fi mai mare, dacă am fi avut mai multe noduri client sau conducte de rețea mai mari.
rezumat
toate modelele diferite pe care le-am testat, adică citire aleatorie, scriere și citire-scriere (70/30) se amestecă pentru volumul de muncă 4M de dimensiuni mari, acoperit la 10,9 GB/s agregat. Rețeaua Client sa dovedit a fi factorul limitativ care cauzează blocajul de performanță. În afară de rețea, a doua resursă cea mai utilizată a fost media, cu toate acestea, avea suficient spațiu disponibil pentru a oferi mai multă performanță, dacă rețeaua nu era blocajul.
G
Up Next
continuând seria blog benchmarking, în secțiunea următoare, va explica rezultatele asociate cu testarea RHCS 3.2 scalabilitate. Răspunzând la câteva întrebări cheie ,cum ar fi”cum se schimbă performanța trecând de la 3 noduri la 5 noduri”. Stay Tuned.