🥇Kako preveriti diske s fio za zadostno zmogljivost za etcd

Opomba. prevod: Ta članek je rezultat mini raziskave, ki so jo izvedli inženirji IBM Cloud v iskanju rešitve za resnično težavo, povezano z delovanjem baze podatkov etcd. Podobna naloga je bila za nas aktualna, vendar pa je potek razmišljanj in dejanj avtorjev lahko zanimiv v širšem kontekstu.

Kratek povzetek celotnega članka: fio in itd

Učinkovitost gruče etcd je močno odvisna od hitrosti osnovnega pomnilnika. etcd izvozi različne metrike Prometheus za spremljanje učinkovitosti. Eden izmed njih je wal_fsync_duration_seconds. V dokumentaciji za itd pravito shranjevanje se lahko šteje za dovolj hitro, če 99. percentil te metrike ne presega 10 ms ...

Če razmišljate o nastavitvi gruče etcd na strojih Linux in želite preizkusiti, ali so pogoni (kot so SSD) dovolj hitri, priporočamo uporabo priljubljenega I/O testerja, imenovanega fio. Dovolj je, da zaženete naslednji ukaz (imenik test-data mora biti v nameščeni particiji testiranega pogona):

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

Preostane le še pogled na rezultat in preverjanje, ali se 99. percentil ujema fdatasync v 10 ms. Če je tako, potem vaš pogon deluje dovolj hitro. Tukaj je primer izhoda:

fsync/fdatasync/sync_file_range:
  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]

Nekaj opomb:

V zgornjem primeru smo prilagodili parametre --size и --bs za konkreten primer. Da bi dobili pomemben rezultat fio, določite vrednosti, primerne za vaš primer uporabe. Kako jih izbrati, bomo razpravljali spodaj.
Samo med testiranjem fio naloži diskovni podsistem. V resničnem življenju je verjetno, da bodo drugi procesi pisali na disk (poleg tistih, ki so povezani z wal_fsync_duration_seconds). Ta dodatna obremenitev se lahko poveča wal_fsync_duration_seconds. Z drugimi besedami, če je 99. percentil iz testiranja z fio, le malo manj kot 10 ms, obstaja velika verjetnost, da zmogljivost shranjevanja ni zadostna.
Za preizkus boste potrebovali različico fio ne manj kot 3.5%, ker starejše različice ne združujejo rezultatov fdatasync v obliki percentilov.
Zgornji sklep je le majhen izsek iz splošnega zaključka fio.

Več o fio in itd

Nekaj besed o WAL-jih itd

Na splošno uporabljajo baze podatkov proaktivno beleženje (zapisovanje vnaprej, WAL). etcd je tudi prizadet. Razprava o WAL presega obseg tega članka, vendar morate za naše namene vedeti, da vsak član gruče etcd shrani WAL v trajni pomnilnik. etcd zapiše nekatere operacije shranjevanja ključa in vrednosti (kot so posodobitve) v WAL, preden jih izvede. Če se vozlišče zruši in znova zažene med posnetki, lahko etcd obnovi transakcije od prejšnjega posnetka na podlagi vsebine WAL.

Tako vsakič, ko odjemalec doda ključ v shrambo KV ali posodobi vrednost obstoječega ključa, etcd doda opis operacije v WAL, ki je običajna datoteka v trajni shrambi. etcd MORA biti 100 % prepričan, da je bil vnos WAL dejansko shranjen, preden nadaljuje. Da bi to dosegli v Linuxu, ni dovolj, da uporabite sistemski klic write, saj lahko sama operacija pisanja na fizični medij zamuja. Na primer, Linux lahko nekaj časa hrani vnos WAL v predpomnilniku jedra v pomnilniku (kot je predpomnilnik strani). Da bi zagotovili, da so podatki zapisani na medij, je treba po pisanju poklicati sistemski klic fdatasync - točno to počne etcd (kot lahko vidite v naslednjem izhodu strace; tukaj 8 - deskriptor datoteke WAL):

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

Zapisovanje v trajni pomnilnik žal traja nekaj časa. Dolgotrajno izvajanje klicev fdatasync lahko vpliva na zmogljivost etcd. V dokumentaciji repozitorija označeno, da je za zadostno delovanje potrebno 99. percentil trajanja vseh klicev fdatasync ko je bilo pisanje v datoteko WAL krajše od 10 ms. Obstajajo še druge meritve, povezane s shranjevanjem, vendar se bo ta članek osredotočil na to.

Vrednotenje shranjevanja s fio

S pomočjo pripomočka lahko ocenite, ali je določen pomnilnik primeren za uporabo z etcd fio — priljubljen V/I tester. Upoštevajte, da se diskovni V/I lahko zgodi na veliko različnih načinov: sinhronizacija/asinhronizacija, veliko različnih sistemskih razredov itd. Druga plat medalje je, da fio zelo težko uporabljati. Pripomoček ima veliko parametrov, različne kombinacije njihovih vrednosti pa vodijo do popolnoma različnih rezultatov. Da bi dobili razumno oceno za etcd, se morate prepričati, da je pisalna obremenitev, ki jo ustvari fio, čim bližja pisalni obremenitvi datoteke WAL etcd:

To pomeni, da ustvarjeni fio obremenitev mora biti vsaj serija zaporednih zapisov v datoteko, kjer je vsak zapis sestavljen iz sistemskega klica writesledi fdatasync.
Če želite omogočiti zaporedno pisanje, morate določiti zastavico --rw=write.
To fio pisal z uporabo klicev write (namesto drugih sistemskih klicev – npr. pwrite), uporabite zastavico --ioengine=sync.
Na koncu še zastava --fdatasync=1 zagotavlja, da vsak write mora biti fdatasync.
Druga dva parametra v našem primeru sta: --size и --bs - se lahko razlikujejo glede na poseben primer uporabe. V naslednjem razdelku bo opisana njihova konfiguracija.

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

Ta opomba izhaja iz resničnega primera, na katerega smo naleteli. Imeli smo gručo na Kubernetes v1.13 z nadzorom na Prometheusu. SSD-ji so bili uporabljeni kot shramba za etcd v3.2.24. Meritve Etcd so pokazale previsoke zakasnitve fdatasync, tudi ko je bila gruča v mirovanju. Nam so se te metrike zdele zelo dvomljive in nismo bili prepričani, kaj točno predstavljajo. Poleg tega je bila gruča sestavljena iz virtualnih strojev, zato ni bilo mogoče reči, ali je bila zamuda posledica virtualizacije ali je bil kriv SSD.

Poleg tega smo upoštevali različne spremembe v konfiguraciji strojne in programske opreme, zato smo potrebovali način, kako jih ovrednotiti. Seveda bi bilo mogoče zagnati etcd v vsaki konfiguraciji in si ogledati ustrezne metrike Prometheus, vendar bi to zahtevalo veliko truda. Potrebovali smo preprost način za oceno specifične konfiguracije. Želeli smo preizkusiti naše razumevanje metrike Prometheus, ki prihaja iz etcd.

To je zahtevalo rešitev dveh težav:

Prvič, kakšna je V/I obremenitev, ki jo ustvari etcd pri pisanju v datoteke WAL? Kateri sistemski klici se uporabljajo? Kakšna je velikost snemalnih blokov?
Drugič, recimo, da imamo odgovore na zgornja vprašanja. Kako reproducirati ustrezno obremenitev z fio? Konec koncev fio — izjemno prilagodljiv pripomoček z obilico parametrov (to je enostavno preveriti, npr. tukaj - pribl. prev.).

Oba problema smo rešili z istim pristopom, ki temelji na ukazih lsof и strace:

Z lsof si lahko ogledate vse deskriptorje datotek, ki jih uporablja proces, kot tudi datoteke, na katere se nanašajo.
Z strace lahko analizirate že zagnan proces ali zaženete proces in ga opazujete. Ukaz prikaže vse sistemske klice, ki jih izvede ta proces, in po potrebi njegove potomce. Slednje je pomembno za procese, ki se razcepijo, in etcd je eden takih procesov.

Prva stvar, ki smo jo naredili, je bila uporaba strace za pregled strežnika etcd v gruči Kubernetes, ko je bil nedejaven.

Tako je bilo ugotovljeno, da so zapisni bloki WAL zelo gosto združeni, velikost večine je bila v območju 2200-2400 bajtov. Zato ukaz na začetku tega članka uporablja zastavico --bs=2300 (bs je velikost v bajtih vsakega pisnega bloka v fio).

Upoštevajte, da se lahko velikost pisalnih blokov etcd razlikuje glede na različico, namestitev, vrednosti parametrov itd. - vpliva na trajanje fdatasync. Če imate podoben primer uporabe, analizirajte z strace vaše etcd procese, da dobite posodobljene vrednosti.

Potem, da bi dobili jasno in celovito predstavo o tem, kako etcd deluje z datotečnim sistemom, smo ga začeli od spodaj strace z zastavami -ffttT. To je omogočilo zajem podrejenih procesov in zapisovanje izhoda vsakega v ločeno datoteko. Poleg tega so bili pridobljeni podrobni podatki o času začetka in trajanju vsakega sistemskega klica.

Uporabili smo tudi ukaz lsofda potrdite svoje razumevanje izhoda strace glede na to, kateri deskriptor datoteke je bil uporabljen za kateri namen. Dobil sem sklep strace, podoben zgornjemu. Statistične manipulacije s časi sinhronizacije so potrdile, da metrika wal_fsync_duration_seconds iz etcd se ujema s klici fdatasync z deskriptorji datotek WAL.

Za ustvarjanje z fio obremenitev, podobna tisti iz etcd, smo preučili dokumentacijo pripomočka in izbrali parametre, primerne za našo nalogo. Preverili smo, ali potekajo pravilni sistemski klici, in z izvajanjem potrdili njihovo trajanje fio z dne strace (kot je bilo storjeno v primeru etcd).

Posebna pozornost je bila namenjena določanju vrednosti parametra --size. Predstavlja skupno V/I obremenitev, ki jo ustvari pripomoček fio. V našem primeru je to skupno število bajtov, zapisanih na medij. Premosorazmeren je s številom klicev write (in fdatasync). Za določeno bs število klicev fdatasync enako size / bs.

Ker nas je zanimal percentil, smo želeli, da je število vzorcev dovolj veliko, da je statistično pomembno. In se tako odločil 10^4 (kar ustreza velikosti 22 MB) zadostuje. Manjše vrednosti parametrov --size povzročal izrazitejši hrup (na primer klici fdatasync, ki traja veliko dlje kot običajno in vpliva na 99. percentil).

Odvisno je od tebe

Članek prikazuje, kako uporabljati fio lahko presodite, ali je medij, namenjen uporabi z etcd, dovolj hiter. Zdaj je odvisno od vas! V storitvi lahko raziskujete virtualne stroje s pomnilnikom na osnovi SSD IBM Cloud.

PS od prevajalca

Z že pripravljenimi primeri uporabe fio Za druga opravila glej dokumentacijo ali neposredno na repozitorije projektov (teh je veliko več kot je omenjeno v dokumentaciji).

PPS od prevajalca

Preberite tudi na našem blogu:

Vir: www.habr.com

Kako preveriti diske s fio za zadostno zmogljivost za etcd