Hitrost shranjevanja primerna za etcd? Vprašajmo Fio

Kratka zgodba o fio in itd

Zmogljivost grozda itdd v veliki meri odvisna od zmogljivosti njegovega shranjevanja. etcd izvozi nekaj meritev v Prometejza zagotavljanje želenih informacij o zmogljivosti shranjevanja. Na primer metrika wal_fsync_duration_seconds. V dokumentaciji za etcd piše: Da se shranjevanje šteje za dovolj hitro, mora biti 99. percentil te metrike manjši od 10 ms. Če nameravate zagnati gručo etcd na strojih Linux in želite oceniti, ali je vaš pomnilnik dovolj hiter (npr. SSD), lahko uporabite fio je priljubljeno orodje za testiranje V/I operacij. Zaženite naslednji ukaz, kjer so testni-podatki imenik pod točko vpetja pomnilnika:

fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytest

Samo pogledati morate rezultate in preveriti, ali je 99. percentil trajanja fdatasync manj kot 10 ms. Če je tako, imate razmeroma hitro shranjevanje. Tukaj je primer rezultatov:

  sync (usec): min=534, max=15766, avg=1273.08, stdev=1084.70
  sync percentiles (usec):
   | 1.00th=[ 553], 5.00th=[ 578], 10.00th=[ 594], 20.00th=[ 627],
   | 30.00th=[ 709], 40.00th=[ 750], 50.00th=[ 783], 60.00th=[ 1549],
   | 70.00th=[ 1729], 80.00th=[ 1991], 90.00th=[ 2180], 95.00th=[ 2278],
   | 99.00th=[ 2376], 99.50th=[ 9634], 99.90th=[15795], 99.95th=[15795],
   | 99.99th=[15795]

Opombe

• Za naš poseben scenarij smo prilagodili možnosti --size in --bs. Če želite dobiti uporaben rezultat od fio, navedite svoje vrednosti. Kje jih dobiti? Preberi kako smo se naučili konfigurirati fio.
• Med testiranjem vsa V/I obremenitev prihaja iz fio. V resničnem scenariju bodo v shrambo verjetno prihajale še druge zahteve za pisanje poleg tistih, ki so povezane z wal_fsync_duration_seconds. Dodatna obremenitev bo povečala vrednost wal_fsync_duration_seconds. Torej, če je 99. percentil blizu 10 ms, vašemu pomnilniku zmanjkuje hitrosti.
• Vzemite različico fio ne manj kot 3.5% (prejšnji ne prikazujejo percentilov trajanja fdatasync).
• Zgoraj je le delček rezultatov iz fio.

Dolga zgodba o fio in itd

Kaj je WAL v itd

Običajno uporabljajo baze podatkov dnevnik vnaprejšnjega pisanja; uporablja ga tudi etcd. Tukaj ne bomo podrobno razpravljali o dnevniku vnaprejšnjega pisanja (WAL). Dovolj je, da vemo, da ga vsak član gruče etcd vzdržuje v trajni shrambi. etcd zapiše vsako operacijo ključ-vrednost (kot je posodobitev) v WAL, preden jo uporabi v trgovini. Če se eden od članov pomnilnika zruši in znova zažene med posnetki, lahko lokalno obnovi transakcije od zadnjega posnetka z vsebino WAL.

Ko odjemalec doda ključ v shrambo ključ-vrednost ali posodobi vrednost obstoječega ključa, etcd zabeleži operacijo v WAL, ki je običajna datoteka v trajni shrambi. etcd MORA biti popolnoma prepričan, da se je vnos WAL dejansko zgodil, preden nadaljuje z obdelavo. V Linuxu en sistemski klic za to ni dovolj. pisati, saj lahko dejansko pisanje v fizični pomnilnik zamuja. Na primer, Linux lahko nekaj časa shrani vnos WAL v predpomnilnik v pomnilniku jedra (kot je predpomnilnik strani). In da se podatki natančno zapišejo v trajno shrambo, je po pisanju potreben sistemski klic fdatasync, etcd pa ga samo uporabi (kot lahko vidite v rezultatu dela strace, kjer je 8 deskriptor datoteke WAL):

21:23:09.894875 lseek(8, 0, SEEK_CUR)   = 12808 <0.000012>
21:23:09.894911 write(8, ". 20210220361223255266632$10 20103026"34"rn3fo"..., 2296) = 2296 <0.000130>
21:23:09.895041 fdatasync(8)            = 0 <0.008314>

Na žalost se pisanje v trajni pomnilnik ne zgodi takoj. Če je klic fdatasync počasen, bo delovanje sistema etcd prizadeto. V dokumentaciji za etcd pišeda se shranjevanje šteje za dovolj hitro, če v 99. percentilu klici fdatasync zapisovanje v datoteko WAL trajajo manj kot 10 ms. Obstajajo še druge uporabne metrike za shranjevanje, vendar v tej objavi govorimo samo o tej metriki.

Ocena shranjevanja s fio

Če morate oceniti, ali je vaš pomnilnik primeren za etcd, uporabite fio, zelo priljubljeno orodje za testiranje obremenitve V/I. Ne smemo pozabiti, da so lahko diskovne operacije zelo različne: sinhrone in asinhrone, številni razredi sistemskih klicev itd. Posledično je fio precej težko uporabljati. Ima veliko parametrov in različne kombinacije njihovih vrednosti proizvajajo zelo različne V/I delovne obremenitve. Če želite dobiti ustrezne številke za etcd, se morate prepričati, da je obremenitev testnega pisanja iz fio čim bližja dejanski obremenitvi iz etcd pri pisanju datotek WAL.

Zato bi moral fio vsaj ustvariti obremenitev v obliki niza zaporednih zapisov v datoteko, vsako pisanje bo sestavljeno iz sistemskega klica pisatisledi sistemski klic fdatasync. Zaporedna pisanja v fio zahtevajo možnost --rw=write. Da fio pri pisanju uporablja sistemski klic write, namesto pisati, morate podati parameter --ioengine=sync. Nazadnje, če želite po vsakem pisanju poklicati fdatasync, morate dodati parameter --fdatasync=1. Drugi dve možnosti v tem primeru (--size in -bs) sta specifični za skript. V naslednjem razdelku vam bomo pokazali, kako jih nastavite.

Zakaj ravno fio in kako smo se ga naučili nastaviti

V tej objavi opisujemo resničen primer. Imamo grozd Kubernetes v1.13, ki smo ga spremljali s Prometheusom. etcd v3.2.24 je gostoval na SSD. Meritve Etcd so pokazale previsoke zakasnitve fdatasync, tudi ko gruča ni delala ničesar. Meritve so bile čudne in pravzaprav nismo vedeli, kaj pomenijo. Grozd je bil sestavljen iz virtualnih strojev, bilo je treba razumeti, v čem je težava: v fizičnih SSD-jih ali v virtualizacijski plasti. Poleg tega smo pogosto spreminjali konfiguracijo strojne in programske opreme in potrebovali smo način za ovrednotenje njihovih rezultatov. Lahko bi zagnali etcd v vsaki konfiguraciji in pogledali metrike Prometheus, vendar je to preveč težav. Iskali smo dokaj preprost način za oceno specifične konfiguracije. Želeli smo preveriti, ali pravilno razumemo metriko Prometheus iz etcd.

Toda za to je bilo treba rešiti dva problema. Prvič, kako izgleda V/I obremenitev, ki jo etcd ustvari pri pisanju v WAL? Kateri sistemski klici se uporabljajo? Kakšna je velikost zapisov? Drugič, če odgovorimo na ta vprašanja, kako lahko reproduciramo podobno delovno obremenitev s fio? Ne pozabite, da je fio zelo prilagodljivo orodje s številnimi možnostmi. Oba problema smo rešili z enim pristopom – z uporabo ukazov tudi и strace. lsof navaja vse deskriptorje datotek, ki jih uporablja proces, in z njimi povezane datoteke. In s strace lahko pregledate proces, ki se že izvaja, ali začnete proces in ga pregledate. strace natisne vse sistemske klice iz pregledanega procesa (in njegovih podrejenih procesov). Slednje je zelo pomembno, saj etcd uporablja podoben pristop.

Najprej smo uporabili strace za raziskovanje strežnika etcd za Kubernetes, ko gruča ni bila obremenjena. Videli smo, da so bili skoraj vsi zapisi WAL približno enake velikosti: 2200–2400 bajtov. Zato smo v ukazu na začetku objave določili parameter -bs=2300 (bs pomeni velikost v bajtih za vsak vnos fio). Upoštevajte, da je velikost vnosa etcd odvisna od različice etcd, distribucije, vrednosti parametrov itd. in vpliva na trajanje fdatasync. Če imate podoben scenarij, preglejte svoje etcd procese s strace, da ugotovite natančne številke.

Da bi dobili dobro predstavo o tem, kaj počne datotečni sistem etcd, smo ga zagnali z možnostma strace in -ffttT. Zato smo poskušali pregledati podrejene procese in zabeležiti izhod vsakega od njih v ločeni datoteki ter pridobiti podrobna poročila o začetku in trajanju vsakega sistemskega klica. Uporabili smo lsof za potrditev naše analize izhoda strace in videli, kateri deskriptor datoteke je bil uporabljen za kateri namen. Tako so bili s pomočjo strace doseženi zgoraj prikazani rezultati. Statistični podatki o času sinhronizacije so potrdili, da je wal_fsync_duration_seconds iz etcd skladen s klici fdatasync z deskriptorji datotek WAL.

Pregledali smo dokumentacijo za fio in izbrali možnosti za naš skript, tako da bo fio ustvaril nalaganje, podobno etcd. Preverili smo tudi sistemske klice in njihovo trajanje z zagonom fio iz strace, podobno kot etcd.

Previdno smo izbrali vrednost parametra --size, ki predstavlja celotno V/I obremenitev iz fio. V našem primeru je to skupno število bajtov, zapisanih v shrambo. Izkazalo se je, da je premosorazmeren s številom sistemskih klicev pisanja (in fdatasync). Za določeno vrednost bs je število klicev fdatasync = size/bs. Ker nas je zanimal percentil, smo morali imeti dovolj vzorcev, da smo bili prepričani, in izračunali smo, da nam bo zadostovalo 10^4 (to je 22 mebibajtov). Če je --size manjša, se lahko pojavijo odstopanja (na primer, več klicev fdatasync traja dlje kot običajno in vpliva na 99. percentil).

Poskusite sami

Pokazali smo vam, kako uporabljati fio in preveriti, ali je shramba dovolj hitra, da etcd dobro deluje. Zdaj lahko to preizkusite sami z uporabo na primer virtualnih strojev s pomnilnikom SSD IBM Cloud.

Vir: www.habr.com