Úvod
Rekapitulace: v Blog Episode-1 jsme se zabývali RHCS, BlueStore Úvod, detaily laboratorního hardwaru, metodikou benchmarkingu a porovnáním výkonu mezi výchozí konfigurací Ceph vs naladěnou konfigurací Ceph
Toto je druhá epizoda série performance blog na rhcs 3.2 Bluestore běží na All-Flash clusteru. Neexistuje žádné pravidlo pro kategorizaci velikostí bloků do malé, střední a velké kategorie. Jako takový jsme určili 4K do kategorie malých bloků, 8K-64K do střední a 1M-4M do kategorie velkých bloků. V této epizodě se dozvíte o charakteristice výkonu úložiště bloků Ceph pro malé (4K), střední (8K-32K) a velké (1M-4M) velikosti bloků napříč náhodným čtením, náhodným zápisem a náhodným vzorcem zatížení při čtení a zápisu.
shrnutí
- small block 4K workload, dodáno do 2.2 miliony náhodných čtení, 691K random read-write (70/30) a 463K random write IOPS, dokud nejsou omezeny CPU a mediálním svárem.
- podobně jako u malého zatížení bloku bylo zjištěno, že výkon středního bloku je omezen tvrzením CPU a médií.
- velký blok 4m pracovní zátěž špičkový výkon zaznamenaný při 10,9 GB / s pro všechny tři testovací vzory, tj. náhodné čtení, zápis a čtení-zápis (70/30) mix, dokud není omezen šířkou pásma klientské sítě.
Část-1: Malá velikost bloku (4KB) výkon
Klíčové Takeaways
- náhodné čtení pracovní zátěž ukázala 2.2 miliony IOPS@3ms průměrná latence až do zúžení saturací médií.
- náhodný Read-Write (70/30) mix pracovní zátěž ukázala 691K IOPS@6ms průměrná latence až do zúžení Ceph uzlu CPU zdroje tvrzení.
- náhodný zápis: 463K IOPS@11ms průměrná latence, dokud nebude zúžena tvrzením o zdrojích CPU uzlu Ceph.
shrnutí
v této části testování bylo Ceph block storage interface vykonáváno s malým zatížením velikosti bloku (4KB) napříč náhodným čtením, náhodným zápisem a náhodným čtením a zápisem (70/30). Klíčové metriky zachycené během testování zahrnují IOPS, průměr, latenci, CPU uzlu Ceph a využití médií.
Graph-1 zobrazuje špičkový výkon pro velikost bloku 4K napříč různými přístupovými vzory s uzly 5 all-flash. Bylo zjištěno, že maximální výkon je
- náhodné čtení: 2,2 milionu IOPS@ 3ms průměrná latence
- náhodné čtení-zápis (70/30) Mix: 691K IOPS @6ms průměrná latence
- náhodný zápis: 463K IOPS@11ms průměrná latence
hThe využití CPU a médií zachycené v graph-2 a graph-3 nám pomohlo pochopit úzká místa pro různé vzory pracovní zátěže.
- bylo zjištěno, že náhodný výkon čtení je zúžen tvrzením o zdrojích CPU, bylo však také zjištěno, že využití médií je na vyšší straně. Jako takový jsme přidali další uzly Ceph (CPU a média), výkon náhodného čtení by mohl být vyšší.
- pro kombinaci náhodného zápisu a náhodného čtení a zápisu (70/30) byl výkon omezen vyšší spotřebou CPU. Zajímavé je, že ve stejné době média měla dostatek náhradní propustnost, která zůstala nevyužita z důvodu nedostatku výpočetního výkonu. Jako takový, vyšší alokace jádra CPU na Ceph OSDs by mohla přinést vyšší výkon pro náhodný zápis & náhodné čtení a zápis mix pracovní zátěže.
využití datového zařízení OSD (P4500 NVMe) zůstalo pod 50% využití, bylo zjištěno, že zařízení Intel Optane P4800, které hostovalo metadata BlueStore WAL a Rocksdb, bylo velmi zaneprázdněno@90%. Parametr bluestore_min_alloc_size_ssd byl nastaven na 16KB, proto byly všechny zápisy pod 16KB odloženy, zápis nejprve přejde do zařízení WAL a poté se asynchronně zapíše do dat OSD, proto zařízení Optane P4800 absorbovalo zápisy pro všechny OSD na hostiteli. Navzdory vysokému využití zařízení RocksDB / WAL jsme na datovém zařízení P4500 OSD neviděli žádné známky sváru. Ale na základě této zkušenosti bychom nedoporučovali dávat více než 7 x P4500 NVMe zařízení za jediný Intel Optane P4800 pro WAL / RocksDB.
Graf 2
graf 3
dalším zajímavým testem, který jsme provedli, byl client sweep test, kde jsme lineárně rozšířili počet klientů od 20 do 140. Jak jsme zvýšili zatížení klienta, Pozorovali jsme lineární zlepšení výkonu, dokud jsme nenarazili na přetížení CPU na Ceph OSD. Se 100 klienty jsme pozorovali ~ 445k agregované 4K write IOPS. Po tomto bodě přetížení systémových prostředků vedlo k vysokým latencím ocasu. Intel Optane použitý jako metadata pomohl absorbovat latenci spike s vysokým počtem paralelních klientů, jako taková průměrná latence zůstala pod 40ms.
G
Část 2: Výkon střední velikosti bloku
Klíčové Takeaways
- dokud výkon nebyl zúžen CPU a saturací médií, 5 All-flash Ceph uzly dodány ~1.8 milionů náhodných čtení, ~636K random readwrite (70/30) a ~410K random write IOPS.
- aby bylo možné škálovat výkon, musely být do existujícího clusteru Ceph přidány další uzly Ceph OSD.
shrnutí
v následujících grafech jsme se pokusili reprezentovat různé datové body, jako je IOPS, průměrná latence, latence ocasu, CPU uzlu Ceph a využití médií. Od 4K až 64K pro náhodný zápis, náhodné čtení a náhodné čtení-zápis (70/30) mix.
mezi zajímavé datové body patří
- jak se očekávalo, malé velikosti bloků vykazovaly nejvyšší IOPS a nižší průměrné a ocasní latence ve srovnání se středními velikostmi bloků. Jako takový jsme pozorovali ~1.8 milionů, ~636K, ~410K IOPS pro náhodné čtení, náhodný mix čtení a náhodný zápis.
- vysoké využití bylo pozorováno na CPU a mediálních zařízeních na uzlech Ceph OSD. Bylo zjištěno, že využití je až ~90% a ~80% pro CPU a média. Jako takový by se výkon mohl zvýšit, kdybychom přidali uzly Ceph OSD do existujícího clusteru Ceph.
G
Část 3: velký výkon velikosti bloku
Klíčové Takeaways
- velký výkon bloku 4M dosáhl vrcholu 10.9 GB / s pro náhodné čtení, zápis a čtení-zápis (70/30) mix.
- klientská síť byla zjištěna jako omezující faktor a způsobující překážku výkonu.
- výkon mohl být vyšší, měli jsme buď více klientských uzlů nebo větší síťové potrubí.
shrnutí
všechny různé vzory, které jsme testovali, tj. náhodné čtení, zápis a čtení-zápis (70/30) mix pro velké velikosti bloku 4m pracovní zátěž na 10.9 GB/s agregované propustnosti. Bylo zjištěno, že klientská síť je omezujícím faktorem způsobujícím překážku výkonu. Jiné než síť druhým nejpoužívanějším zdrojem byla média, nicméně, měl k dispozici dostatek prostoru pro výkon, pokud síť nebyla úzkým hrdlem.
G
Up další
pokračování benchmarking blog série, v další části, vysvětlí výsledky spojené s rhcs 3.2 škálovatelnost testování. Odpovědi na některé klíčové otázky, jako je „jak se mění výkon přechodem z clusteru uzlů 3 na uzly 5“. Zůstaňte S Námi.