Introduction
Recap: in Blog Episode-1 We have covered RHCS, BlueStore introduction, lab hardware details, benchmarking methodology and performance comparison between Default Ceph configuration vs Tuned Ceph configuration
tämä on rhcs 3.2 bluestoren performance Blog-sarjan toinen jakso, joka pyörii All-Flash-klusterissa. Ei ole nyrkkisääntöä ryhmitellä lohkokokoja pieneen, keskisuureen ja suureen luokkaan. Sellaisenaan olemme nimenneet 4K pieneen lohkokoon luokkaan, 8K-64K keskikokoiseen ja 1M-4m suureen lohkokoon luokkaan. Tässä jaksossa opit Ceph-lohkon tallennustilan suorituskyvyn luonnehtimisesta pienille (4K), keskikokoisille (8K-32k) ja suurille (1M-4m) lohkokooille satunnaisissa luku -, satunnainen kirjoitus-ja satunnaisissa luku-kirjoitus-työmäärämalleissa.
tiivistelmä
- pieni 4K-työmäärä, toimitettu 2.2 miljoonaa satunnaista lukee, 691k satunnainen luku-kirjoittaa (70/30) ja 463K satunnainen kirjoittaa IOPS kunnes rajoittaa CPU ja media väite.
- pienlohkon työmäärän tapaan keskilohkon suorituskyvyn todettiin rajoittavan suoritin-ja mediakiistaa.
- Large block 4m workabase peak performance recorded at 10.9 GB/s for all three test patterns eli satunnainen luku -, kirjoitus-ja luku-kirjoitus (70/30) mix till until limited by the Client network bandwide.
Osa-1: pienen lohkon koko (4KB) suorituskyky
Key Takeaways
- Satunnainen lukumäärä osoitti 2.2 miljoonaa IOPS@3ms keskimääräinen latenssi, kunnes median kyllästyminen pullonkaulana.
- Random Read-Write (70/30) mix-työmäärä osoitti 691K IOPS@6ms: n keskimääräisen latenssin, kunnes Ceph node CPU resource contention pullonkaulasi.
- Random Write: 463K IOPS@11ms average latency until pullonkaulacked by Ceph node CPU resource contention.
Summary
tässä testauksen osassa Ceph block-tallennusliittymää käytettiin pienellä lohkokoolla (4KB) työmäärällä satunnaisissa luku -, satunnainen kirjoitus-ja satunnaiskirjoitusmalleissa (70/30). Testauksen aikana kerättyjä keskeisiä mittareita ovat IOPS, average, latency, Ceph node CPU ja median hyödyntäminen.
Graph-1 näyttää huippusuorituskyvyn 4K-lohkokoon eri kulkukuvioissa, joissa on 5 all-flash-solmua. Näin maksimisuoritus todettiin
- satunnainen luku: 2,2 miljoonaa IOPS@ 3ms keskimääräinen latenssi
- satunnainen luku-kirjoitus (70/30) Mix: 691K IOPS @6ms keskimääräinen latenssi
- Satunnainen kirjoitus: 463K IOPS@11ms keskimääräinen latenssi
h Graph-2: ssa ja graph-3: ssa kuvattu suorittimen ja median käyttö auttoi meitä ymmärtämään eri työmäärien pullonkauloja.
- satunnaisen lukusuorituksen todettiin olevan pullonkaulana CPU resource contentionissa, mutta myös median hyödyntämisen havaittiin olevan korkeammalla puolella. Sellaisenaan olemme lisänneet lisää Ceph solmut (CPU ja media) satunnainen lukea suorituskykyä olisi skaalautunut korkeammalle.
- sekä satunnaiskirjoituksessa että satunnaiskirjoituksessa (70/30) suorituskykyä pullonkaulasi suurempi suorittimen kulutus. Mielenkiintoista samaan aikaan media oli tarpeeksi vapaa läpimeno, joka jäi käyttämättömänä, koska puute laskentatehoa. Näin ollen suurempi suorittimen ytimen allokointi Ceph-OSD: ille olisi voinut tuottaa suuremman suorituskyvyn satunnaisille kirjoituslaitteille & satunnaisille luku-kirjoitus-mix-työkuormille.
OSD-datalaitteen (P4500 NVMe) käyttöaste jäi alle 50%, Bluestore WAL-ja Rocksdb-metatietoja isännöineen Intel Optane P4800-laitteen todettiin olevan erittäin kiireinen@90%. Bluestore_min_alloc_size_ssd parametri asetettiin 16KB, joten kaikki kirjoittaa alle 16KB lykättiin, kirjoittaa ensin menee WAL-laitteen ja sitten asynkronisesti saa kirjoitettu OSD tiedot, joten Optane P4800 laite oli absorboinut kirjoittaa kaikkien osds isäntä. Huolimatta korkea käyttöaste RocksDB / WAL laite, Emme ole nähneet mitään merkkejä kiistan p4500 OSD datalaite. Mutta tämän kokemuksen perusteella emme suosittele laittamaan yli 7 x P4500 NVMe-laitteita yhden Intel Optane P4800: n taakse Wal/RocksDB: lle.
Kaavio 2
kaavio 3
toinen mielenkiintoinen testi ajoimme oli client sweep test, jossa olemme lineaarisesti skaalattu-jopa määrä asiakkaita alkaen 20 ja jopa 140. Kun lisäsimme asiakaskuormaa, havaitsimme lineaarisen suorituskyvyn paranemisen, kunnes saimme keskusyksikön ruuhkautumisen Ceph OSD: ssä. Kanssa 100 asiakkaita olemme havainneet ~445K aggregoitu 4K kirjoittaa IOPS. Tämän jälkeen pistejärjestelmän resurssien ruuhkautuminen johti korkeisiin peräviiveisiin. Metatietoina käytetty Intel Optane auttoi absorboimaan latenssipiikin suurella määrällä rinnakkaisia asiakkaita, koska keskimääräinen latenssi pysyi alle 40ms.
G
Osa 2: Medium Block Size Performance
Key Takeaways
- Until the performance was bottlecked by CPU and media saturation, 5 all-flash Ceph nodes delivered ~1,8 Million random ReadWrite (70/30) and ~410K random write IOPS.
- suorituskyvyn skaalaamiseksi nykyiseen Ceph-klusteriin oli lisättävä lisää Ceph-OSD-solmuja.
Yhteenveto
seuraavissa kuvioissa on pyritty esittämään erilaisia datapisteitä, kuten IOPS, keskimääräinen latenssi, hännän latenssi, Ceph-solmun suoritin ja median käyttöaste. Ja kaikki nämä koko alueella lohkon koko eli 4K jopa 64K satunnainen kirjoittaa, satunnainen lukea ja satunnainen luku-kirjoittaa (70/30) sekoitus.
muutamia mielenkiintoisia datapisteitä ovat
- odotetusti pienet lohkokoot osoittivat korkeimmat IOPS-arvot ja matalammat keskiarvo-ja pyrstöviivat verrattuna keskisuuriin lohkokokoihin. Sellaisenaan havaitsimme ~1,8 miljoonaa, ~636k, ~410K IOPS satunnaiselle lukemiselle, satunnaiselle ReadWrite-sekoitukselle ja satunnaiselle kirjoitustyömäärälle vastaavasti.
- korkea käyttöaste havaittiin suoritin-ja medialaitteilla Ceph OSD-solmuissa. Käyttöaste todettiin olevan niin korkea kuin ~90% ja ~80% vastaavasti CPU ja media vastaavasti. Sinänsä suorituskyky olisi voinut kasvaa, jos olisimme lisänneet Ceph OSD-solmut olemassa olevaan Ceph-klusteriin.
G
Osa 3: suuren lohkon koko suorituskyky
Key Takeaways
- suuren lohkon 4m suorituskyky oli korkeimmillaan 10.9 GB/s satunnaiselle luku -, kirjoitus-ja luku-kirjoitussekoitukselle (70/30).
- asiakasverkon todettiin rajoittavan ja aiheuttavan suorituskyvyn pullonkaulan.
- suorituskyky olisi voinut olla korkeampi, meillä olisi ollut joko enemmän asiakassolmuja tai isompia verkkoputkia.
Yhteenveto
kaikki testaamamme erilaiset kuviot eli satunnaiset luku -, kirjoitus-ja luku-kirjoitusmallit (70/30) sekoittavat suuren lohkokoon 4M työmäärän päälle 10,9 GB/s aggregoidulla läpimenokyvyllä. Asiakasverkko todettiin rajoittavaksi tekijäksi, joka aiheuttaa suorituskyvyn pullonkaulan. Muu kuin verkko toiseksi eniten käytetty resurssi oli media, mutta se oli tarpeeksi liikkumavaraa tarjota enemmän suorituskykyä, jos verkko ei ollut pullonkaula.
G
Up Next
benchmarking-blogisarjan jatkaminen seuraavassa jaksossa kertoo RHCS 3.2-skaalautuvuustestaukseen liittyvistä tuloksista. Vastaamalla joihinkin keskeisiin kysymyksiin, kuten ”miten suorituskyky muuttuu menemällä 3 solmun klusterista 5 solmuun”. Pysykää Kanavalla.