introduktion
Recap: i Blog Episode-1 har vi dækket RHCS, BlueStore introduktion, lab udstyr detaljer, benchmarking metode og ydeevne sammenligning mellem standard Ceph konfiguration vs Tuned Ceph konfiguration
dette er den anden episode af performance blog-serien på rhcs 3.2 bluestore, der kører på All-Flash-klyngen. Der er ingen tommelfingerregel for at kategorisere blokstørrelser i en lille, mellemstor og stor kategori. Som sådan har vi udpeget 4K til lille blokstørrelseskategori, 8K-64k til medium og 1m-4m i stor blokstørrelseskategori. I denne episode lærer du om præstationskarakterisering af Ceph block storage til små (4k), mellemstore (8K-32k) og store (1m-4m) blokstørrelser på tværs af tilfældige læse -, tilfældige skrive-og tilfældige læse-skrive arbejdsbyrde mønstre.
sammendrag
- lille blok 4K arbejdsbyrde, leveret op til 2.2 millioner tilfældige læser, 691k tilfældig læse-skrive (70/30) og 463k tilfældig skrive IOPS indtil begrænset af CPU og medier påstand.
- svarende til lille blok arbejdsbyrde, medium blok ydeevne viste sig at være begrænset af CPU og medier påstand.
- stor blok 4m arbejdsbyrde peak performance registreret ved 10,9 GB/s for alle tre testmønstre, dvs.tilfældig læse, skrive og læse-skrive (70/30) bland indtil begrænset af klientens netværksbåndbredde.
Del-1: lille blokstørrelse (4 KB) ydeevne
nøgle grillbarer
- tilfældig læse arbejdsbyrde viste 2.2 millioner IOPS@3ms gennemsnitlig latenstid indtil flaskehalset af mediemætning.
- tilfældig læse-skrive (70/30) blandingsarbejdsbelastning viste 691k IOPS@6ms gennemsnitlig latenstid indtil flaskehalset af Ceph node CPU-ressourcekonflikt.
- tilfældig skrivning: 463k IOPS@11ms gennemsnitlig latenstid indtil flaskehalset af Ceph node CPU-ressourcekonflikt.
Resume
i denne del af testen blev Ceph-bloklagringsgrænsefladen udøvet med lille blokstørrelse (4 KB) arbejdsbyrde på tværs af tilfældige læse -, tilfældige skrive-og tilfældige læse-skrive (70/30) blandingsmønstre. De vigtigste målinger, der er fanget under testen, inkluderer IOPS, gennemsnit, latenstid, Ceph node CPU og medieudnyttelse.
Graph-1 viser toplinjens ydeevne for 4K-blokstørrelse på tværs af forskellige adgangsmønstre med 5 All-flash-noder. Som sådan blev den maksimale ydelse fundet at være
- tilfældig læsning: 2,2 millioner IOPS@ 3ms gennemsnitlig latenstid
- tilfældig læsning (70/30) blanding: 691K IOPS @6ms gennemsnitlig latenstid
- tilfældig skrivning: 463k IOPS@11ms gennemsnitlig latenstid
H CPU ‘ en og medieudnyttelsen fanget i graph-2 og graph-3 hjalp os med at forstå flaskehalsene for forskellige arbejdsbyrde mønstre.
- den tilfældige læseydelse viste sig at være flaskehalset af CPU-ressourcekonflikt, men medieudnyttelsen viste sig også at være på den højere side. Som sådan har vi tilføjet yderligere Ceph noder (CPU og medier) den tilfældige læse ydeevne kunne have skaleret højere.
- for både tilfældig skrive og tilfældig læse-skrive (70/30) blanding blev ydeevnen flaskehalset af højere CPU-forbrug. Interessant på samme tid havde medierne nok ekstra kapacitet, som forblev ubrugt på grund af manglen på beregningskraft. Som sådan kunne højere CPU-kernetildeling til Ceph OSDs have leveret højere ydelse til tilfældig skrivning & tilfældig læse-skrive blandingsarbejdsbelastning.
OSD data device (P4500 NVMe) udnyttelse forblev under 50% udnyttelse, Intel Optane P4800 enhed, som var vært for BlueStore og Rocksdb metadata viste sig at være meget travlt@90%. Parameteren bluestore_min_alloc_ssd blev indstillet til 16KB, derfor blev alle skrivninger under 16kb udskudt, skrivningen går først ind i enheden og bliver derefter asynkront skrevet til OSD-dataene, hvorfor Optane P4800-enheden havde absorberet skrivningerne for alle OSDs på værten. På trods af den høje udnyttelse på RocksDB/Val-enheden har vi ikke set nogen tegn på strid på P4500 OSD-dataenheden. Men baseret på denne oplevelse vil vi ikke anbefale at lægge mere end 7 P4500 NVMe-enheder bag en enkelt Intel Optane P4800 til Val/RocksDB.
graf 2
graf 3
en anden interessant test, vi kørte, var klientfejetest, hvor vi lineært har opskaleret antallet af klienter, der starter 20 og op til 140. Da vi øgede klientbelastningen, observerede vi lineær ydelsesforbedring, indtil vi ramte CPU-overbelastning på Ceph OSD. Med 100 klienter har vi observeret ~445k aggregerede 4K skrive IOPS. Efter dette punkt system ressourcer overbelastning resulterede i høje hale forsinkelser. Intel Optane brugt som metadata hjalp med at absorbere latensspidsen med et stort antal parallelle klienter, da sådan gennemsnitlig latenstid forblev under 40 ms.
G
Del-2: Medium blokstørrelse ydeevne
nøgle grillbarer
- indtil ydeevnen blev flaskehalset af CPU og mediemætning, leverede 5 All-flash Ceph-noder ~1,8 millioner tilfældige læsninger, ~636k tilfældig skrivebrev (70/30) og ~410k tilfældig skriv IOPS.
- for at skalere ydeevnen måtte der tilføjes yderligere Ceph OSD-noder i den eksisterende Ceph-klynge.
Resume
i de følgende grafer har vi forsøgt at repræsentere forskellige forskellige datapunkter såsom IOPS, gennemsnitlig latenstid, hale latenstid, Ceph node CPU og medieudnyttelse. Og alle disse på tværs af en række blokstørrelser, dvs. fra 4k op til 64k til tilfældig skrivning, tilfældig læsning og tilfældig læsning (70/30) blanding.
et par interessante datapunkter inkluderer
- som forventet viste små blokstørrelser højeste IOPS og lavere gennemsnits-og halelængder sammenlignet med mellemstore blokstørrelser. Som sådan observerede vi ~1,8 millioner, ~636k, ~410k IOPS til henholdsvis tilfældig læsning, tilfældig Læseblanding og tilfældig skrivebelastning.
- høj udnyttelse blev observeret på CPU-og medieenheder på Ceph OSD-noder. Udnyttelsen viste sig at være så høj som ~90% og ~80% for henholdsvis CPU og medier. Som sådan kunne ydeevnen være steget, hvis vi har tilføjet Ceph OSD-noder til den eksisterende Ceph-klynge.
G
Del-3: Stor blokstørrelse ydeevne
nøgle grillbarer
- stor blok 4m ydeevne toppede ved 10.9 GB / s for tilfældig læse, skrive og læse-skrive (70/30) blanding.
- Klientnetværk viste sig at være den begrænsende faktor og forårsage en ydelsesflaskehals.
- ydelsen kunne have været højere, har vi enten haft flere klientnoder eller større netværksrør.
Resume
alle de forskellige mønstre, som vi har testet, dvs.tilfældig læse, skrive og læse-skrive (70/30) blanding til stor blokstørrelse 4m arbejdsbyrde toppet ved 10,9 GB/s aggregeret gennemstrømning. Klientnetværk viste sig at være den begrænsende faktor, der forårsager præstationsflaskehalsen. Bortset fra netværk var den næstmest anvendte ressource medier, men den havde nok plads til rådighed til at levere mere ydeevne, hvis netværket ikke var flaskehalsen.
G
op næste
fortsættelse af benchmarking blog-serien, i næste afsnit, vil forklare resultaterne forbundet med RHCS 3.2 skalerbarhedstest. Besvarelse af nogle vigtige spørgsmål som”Hvordan ændres ydeevnen ved at gå fra 3 node cluster til 5 noder”. Stay Tuned.