Innledning
Oppsummering: I Blogg Episode-1 har vi dekket RHCS, BlueStore introduksjon, lab hardware detaljer, benchmarking metodikk og ytelse sammenligning Mellom Standard Ceph konfigurasjon vs Innstilt Ceph konfigurasjon
Dette Er Den Andre Episoden Av Performance Blog-Serien på rhcs 3.2 bluestore Som Kjører På All-Flash-Klyngen. Det er ingen tommelfingerregel å kategorisere blokkstørrelser i en liten, middels og stor kategori. Som sådan har vi utpekt 4K til liten blokkstørrelseskategori, 8K – 64k til middels og 1m-4M i stor blokkstørrelseskategori. I denne episoden vil du lære om ytelseskarakterisering Av Ceph – blokklagring for små (4K), mellomstore (8k-32K) og store (1m-4M) blokkstørrelser på tvers av tilfeldige lese -, tilfeldige skrive-og tilfeldige lese-skrivemønstre.
Sammendrag
- Liten blokk 4k arbeidsbelastning, levert opptil 2.2 Millioner tilfeldige leser, 691k tilfeldig lese-skrive (70/30) OG 463k tilfeldig skrive IOPS til begrenset AV CPU og media påstand.
- i Likhet med liten blokk arbeidsbelastning, ble middels blokk ytelse funnet å være begrenset AV CPU og media strid.
- Stor blokk 4m arbeidsbelastning topp ytelse registrert på 10,9 GB / s for alle tre testmønstre dvs. tilfeldig lese, skrive og lese-skrive (70/30) bland inntil begrenset Av Klientnettverksbåndbredden.
Del-1: Liten Blokkstørrelse (4kb) Ytelse
Nøkkel Takeaways
- Tilfeldig Lesearbeidsbelastning viste 2.2 Millioner IOPS@3ms gjennomsnittlig ventetid til flaskehalset av mediemetning.
- Tilfeldig Lese-Skrive (70/30) mix arbeidsbelastning viste 691k iops@6ms gjennomsnittlig ventetid til flaskehalset AV Ceph node CPU ressurs påstand.
- Tilfeldig Skriv: 463k iops@11ms gjennomsnittlig ventetid til flaskehalset AV Ceph node CPU ressurs påstand.
Sammendrag
i denne delen av testingen ble Ceph-blokklagringsgrensesnitt utøvd med liten blokkstørrelse (4KB) arbeidsbelastning på tvers av tilfeldig lese, tilfeldig skrive og tilfeldig lese-skrive (70/30) blandingsmønstre. Nøkkelberegningene som fanges opp under testingen inkluderer IOPS, gjennomsnitt, latens, Ceph node CPU og medieutnyttelse.
Graf-1 viser topplinjens ytelse FOR 4k-blokkstørrelse på tvers av forskjellige tilgangsmønstre med 5 all-flash-noder. Som sådan ble maksimal ytelse funnet å være
- Tilfeldig Lese: 2.2 Millioner iops@ 3ms gjennomsnittlig latens
- Tilfeldig Lese-Skrive (70/30) Mix: 691K iops @6ms gjennomsnittlig latens
- Tilfeldig Skrive: 463K iops@11ms gjennomsnittlig ventetid
cpu – OG medieutnyttelsen fanget i graph-2 og graph-3 hjalp oss med å forstå flaskehalsene for ulike arbeidsbelastningsmønstre.
- den tilfeldige leseytelsen ble funnet å være flaskehalset av CPU resource contention, men medieutnyttelsen ble også funnet å være på høyere side. Som sadan har vi lagt til flere Ceph noder (CPU og media) den tilfeldige leseytelsen kunne ha skalert hoyere.
- for både tilfeldig skrive og tilfeldig lese-skrive (70/30) blanding ble ytelsen flaskehalset av høyere CPU-forbruk. Interessant på samme tid hadde media nok ledig gjennomstrømning som forblev ubrukt på grunn av mangel på beregningskraft. Som sådan kunne høyere CPU – kjerneallokering Til Ceph OSDs ha levert høyere ytelse for tilfeldig skrive & tilfeldige lese-skrive-blandingsarbeidsbelastninger.
UTNYTTELSEN AV OSD-dataenheten (P4500 NVMe) holdt seg under 50% utnyttelse, Intel Optane P4800-enheten som var vert For BlueStore WAL og Rocksdb-metadata ble funnet å være veldig opptatt@90%. Bluestore_min_alloc_size_ssd-parameteren ble satt TIL 16KB, derfor ble alle skrivene under 16KB utsatt, skrivingen går først inn I wal-enheten og blir deretter asynkront skrevet TIL OSD-dataene, derfor hadde optane P4800-enheten absorbert skrivene for Alle OSDs på verten. Til tross for den høye utnyttelsen på RocksDB / WAL-enheten, har Vi ikke sett noen tegn på strid på P4500 OSD-dataenheten. Men basert på denne erfaringen vil vi ikke anbefale å sette mer enn 7 X P4500 nvme-enheter bak en Enkelt Intel Optane P4800 FOR WAL / RocksDB.
Graf 2
Graf 3
En annen interessant test vi kjørte var client sweep test, hvor vi har lineært oppskalert antall klienter som starter 20 og opp til 140. Da vi økte klientbelastningen, observerte vi lineær ytelsesforbedring til vi traff CPU-overbelastning På Ceph OSD. Med 100 klienter har vi observert ~445k aggregerte 4k skrive IOPS. Etter dette punkt systemressurser lunger resulterte i høy hale ventetider. Intel Optane brukt som metadata bidro til å absorbere latensspike med et høyt antall parallelle klienter, da gjennomsnittlig latens holdt seg under 40ms.
G
Del-2: Middels Blokkstørrelsesytelse
Viktige Takeaways
- Inntil ytelsen ble flaskehalset av CPU og mediemetning, leverte 5 all-flash Ceph noder ~1,8 Millioner tilfeldige leser, ~636k tilfeldig readwrite (70/30) og ~410k tilfeldig skrive IOPS.
- for å skalere ytelsen måtte flere CEPH OSD-noder legges til i den eksisterende ceph-klyngen.
Sammendrag
i de følgende grafene har vi forsøkt å representere ulike datapunkter som IOPS, gjennomsnittlig ventetid, hale ventetid, Ceph node CPU og media utnyttelse. Fra 4K opp TIL 64K for tilfeldig skrive, tilfeldig lese og tilfeldig lese-skrive (70/30) blanding.
noen interessante datapunkter inkluderer
- som forventet viste små blokkstørrelser høyeste IOPS og lavere gjennomsnitt og hale latenser, sammenlignet med mellomstore blokkstørrelser. Som sådan observerte vi ~1,8 Millioner, ~636k, ~410k iops for Henholdsvis Tilfeldig Les, Tilfeldig Lesemiks Og Tilfeldig skrivearbeidsbelastning.
- Høy utnyttelse ble observert PÅ CPU-og medieenheter på Ceph OSD-noder. Utnyttelsen ble funnet å være så høy som ~90% og ~80% for HENHOLDSVIS CPU og media. Som sådan kunne ytelsen ha økt, har vi lagt Til Ceph OSD-noder til den eksisterende Ceph-klyngen.
G
Del-3: Stor Blokkstørrelse Ytelse
Nøkkel Takeaways
- Stor blokk 4m ytelse toppet på 10.9 GB / s for tilfeldig lese, skrive og lese-skrive (70/30) blanding.
- Klientnettverk ble funnet å være begrensende faktor og forårsaker en flaskehals for ytelse.
- ytelsen kunne vært høyere, har vi hatt enten flere klientnoder eller større nettverksrør.
Sammendrag
alle de forskjellige mønstrene som vi har testet, dvs. tilfeldig lese -, skrive-og lese-skrive (70/30) blanding for stor blokkstørrelse 4M arbeidsbelastning toppet på 10,9 GB/s aggregert gjennomstrømning. Klientnettverk ble funnet å være den begrensende faktoren som forårsaker ytelsesflaskehalsen. Annet enn nettverk var den nest mest utnyttede ressursen media, men den hadde nok takhøyde tilgjengelig for å levere mer ytelse, hvis nettverket ikke var flaskehalsen.
G
Opp Neste
Fortsetter benchmarking blog serien, I neste avsnitt, vil forklare resultatene knyttet TIL RHCS 3.2 skalerbarhet testing. Svare på noen viktige spørsmål som «hvordan endrer ytelsen ved å gå fra 3 node klynge til 5 noder». Følg Med.