Bevezetés
Recap: a Blog Episode-1 van szó RHCS, BlueStore bevezetés, lab hardver részletek, benchmarking módszertan és a teljesítmény összehasonlítása Az alapértelmezett Ceph konfiguráció vs hangolt Ceph konfiguráció
ez a második epizód A Performance blog sorozat Rhcs 3.2 BlueStore fut az All – Flash klaszter. Nincs ökölszabály a blokkméretek kis, közepes és nagy kategóriába sorolására. Mint ilyen, a 4K-t a kis blokkméret kategóriába, a 8K-64K-t a közepes és az 1M-4M-et a nagy blokkméret kategóriába soroltuk. Ebben az epizódban megtudhatja a teljesítmény jellemzése Ceph blokk tároló kis (4k), közepes (8K-32k) és nagy (1m-4m) blokk méretek között véletlenszerű olvasási, véletlenszerű írási és véletlenszerű olvasási-írási terhelés mintákat.
Vezetői összefoglaló
- kis blokk 4K munkaterhelés, 2-ig szállítva.2 millió véletlenszerű olvasás, 691k véletlenszerű írás-olvasás (70/30) és 463K véletlenszerű írás IOPS, amíg a CPU és a Média vitatja.
- a kis blokkterheléshez hasonlóan a közepes blokk teljesítményét is korlátozta a CPU és a Média vitatása.
- nagy blokk 4m munkaterhelés csúcsteljesítmény rögzített 10,9 GB/s mind a három vizsgálati minták, azaz véletlenszerű olvasási, írási és olvasási-írási (70/30) mix, amíg korlátozza a kliens hálózati sávszélesség.
1.rész: kis blokkméret (4KB) teljesítmény
kulcs elvihető
- véletlenszerű olvasási terhelés 2.2 millió IOPS@3ms átlagos késleltetés, amíg a Média telítettsége nem szűkíti.
- véletlenszerű írás-olvasás (70/30)mix munkaterhelés 691k IOPS@6MS átlagos késleltetést mutatott, amíg a Ceph csomópont CPU erőforrás-állítása nem szűkítette.
- véletlenszerű írás: 463K IOPS@11ms átlagos késleltetés, amíg a Ceph csomópont CPU erőforrás-állítása szűk keresztmetszetet nem okoz.
Összegzés
a tesztelés ezen részében a Ceph blokktároló interfészt kis blokkméret (4KB) terheléssel gyakoroltuk véletlenszerű olvasási, véletlenszerű írási és véletlenszerű olvasási-írási (70/30) keverési mintákon keresztül. A tesztelés során rögzített legfontosabb mutatók közé tartozik az IOPS, az átlag, a késleltetés, a Ceph csomópont CPU és a Média kihasználtsága.
a Graph-1 A 4K blokkméret csúcsteljesítményét mutatja a különböző hozzáférési mintákon keresztül, 5 Teljes flash csomóponttal. Mint ilyen, a maximális teljesítményt találták
- véletlenszerű olvasás: 2,2 millió IOPS@ 3ms átlagos késleltetés
- véletlenszerű írás-olvasás (70/30) keverék: 691K IOPS @6MS átlagos késleltetés
- véletlenszerű írás: 463K IOPS@11ms átlagos késleltetés
ha Graph-2-ben és graph-3-ban rögzített CPU-és médiafelhasználás segített megérteni a különböző munkaterhelési minták szűk keresztmetszeteit.
- a véletlenszerű olvasási teljesítményt a CPU-erőforrások vitatása szűk keresztmetszetnek találta, azonban a Média kihasználtsága is a magasabb oldalon volt. Mint ilyen, további Ceph csomópontokat (CPU és média) adtunk hozzá, a véletlenszerű olvasási teljesítmény nagyobb lett volna.
- mind a véletlenszerű írás, mind a véletlenszerű írás-olvasás (70/30) keverék esetében a teljesítményt a magasabb CPU-fogyasztás szűkítette. Érdekes módon ugyanakkor a Média volt elég tartalék áteresztőképesség, amely kihasználatlan maradt hiánya miatt a számítási teljesítmény. Mint ilyen, a magasabb CPU-mag-allokáció a Ceph OSDs-hez nagyobb teljesítményt nyújthatott volna véletlenszerű íráshoz & véletlenszerű írás-olvasás keverék munkaterhelések.
az OSD adateszköz (P4500 NVMe) kihasználtsága 50% alatt maradt, az Intel Optane P4800 eszköz, amely a BlueStore WAL és a Rocksdb metaadatokat tárolta, nagyon elfoglalt@90%. A bluestore_min_alloc_size_ssd paramétert 16KB-ra állítottuk, ezért az összes 16KB alatti írást elhalasztották, az írás először a WAL eszközbe kerül, majd aszinkron módon az OSD-adatokba kerül, ezért az Optane P4800 eszköz elnyelte a gazdagép összes OSD-jének írását. A RocksDB/WAL eszköz magas kihasználtsága ellenére a p4500 OSD adatkészüléken nem láttunk vita jeleit. De ezen tapasztalatok alapján nem javasoljuk, hogy több mint 7 x P4500 NVMe eszközt helyezzen el egyetlen Intel Optane P4800 mögött a WAL/RocksDB számára.
grafikon 2
grafikon 3
egy másik érdekes teszt, amelyet lefuttattunk, a client sweep test volt, ahol lineárisan növeltük a 20-tól 140-ig kezdődő ügyfelek számát. Ahogy növeltük az ügyfélterhelést, lineáris teljesítményjavulást figyeltünk meg, amíg el nem érjük a CPU torlódását a Ceph OSD-n. 100 ügyféllel ~445k összesített 4K írási IOPS-t figyeltünk meg. Ezen pont után a rendszer erőforrásainak torlódása magas farok késést eredményezett. A metaadatként használt Intel Optane nagy számú párhuzamos ügyféllel segített elnyelni a késleltetési csúcsot, mivel az ilyen átlagos késleltetés 40 ms alatt maradt.
G
2. rész: Közepes blokkméret teljesítmény
kulcs elvihető
- amíg a teljesítményt a CPU és a Média telítettsége nem akadályozta meg, 5 Teljes flash Ceph csomópont ~1,8 millió véletlenszerű olvasást, ~636k véletlenszerű olvasást (70/30) és ~410k véletlenszerű írási IOPS-t szállított.
- a teljesítmény skálázásához további Ceph OSD csomópontokat kellett hozzáadni a meglévő Ceph fürthöz.
Összegzés
a következő grafikonokban megpróbáltunk különböző adatpontokat ábrázolni, mint például az IOPS, az átlagos késleltetés, a farok késleltetés, a Ceph csomópont CPU és a Média kihasználtsága. És mindezek a blokkméret tartományában, azaz 4K-tól 64k-ig véletlenszerű íráshoz, véletlenszerű olvasáshoz és véletlenszerű íráshoz (70/30) keveréshez.
néhány érdekes adatpont a
- a várakozásoknak megfelelően a kis blokkméretek a legmagasabb IOPS-t, az átlagos és a farok késleltetését mutatták a közepes blokkméretekhez képest. Mint ilyen, ~1,8 millió, ~636k, ~410K IOPS-t figyeltünk meg véletlenszerű olvasás, véletlenszerű ReadWrite Mix és véletlenszerű írási munkaterhelés esetén.
- magas kihasználtságot figyeltek meg a CPU-n és a médiaeszközökön a Ceph OSD csomópontokon. A kihasználtság ~90%, illetve ~80% volt a CPU és a Média esetében. Mint ilyen, a teljesítmény növekedhetett volna, ha hozzáadtuk a Ceph OSD csomópontokat a meglévő Ceph fürthöz.
G
3. rész: nagy blokkméret teljesítmény
kulcs elvihető
- nagy blokk 4m teljesítmény tetőzött 10.9 GB/s véletlenszerű olvasási, írási és olvasási-írási (70/30) keveréshez.
- megállapították, hogy az Ügyfélhálózat a korlátozó tényező, amely a teljesítmény szűk keresztmetszetét okozza.
- a teljesítmény magasabb lehetett volna, ha több ügyfélcsomópont vagy nagyobb hálózati cső volt.
Összegzés
az általunk tesztelt különböző minták, azaz a véletlenszerű olvasás, írás és olvasás-írás (70/30) keverék a nagy blokkméret 4M munkaterheléshez, 10,9 GB/s összesített átviteli sebességgel. Megállapították, hogy az ügyfélhálózat a korlátozó tényező, amely a teljesítmény szűk keresztmetszetét okozza. A hálózaton kívül a második leggyakrabban használt erőforrás a Média volt, azonban elegendő hely állt rendelkezésre a nagyobb teljesítmény eléréséhez, ha nem a hálózat volt a szűk keresztmetszet.
G
következő
a benchmarking blog sorozat folytatása a következő részben elmagyarázza az RHCS 3.2 skálázhatósági teszteléssel kapcsolatos eredményeket. Néhány kulcsfontosságú kérdés megválaszolása, például: “hogyan változik a teljesítmény azáltal, hogy 3 csomópontfürtről 5 csomópontra megy”. Maradjanak Velünk.