Brzina pohrane prikladna za etcd? Pitajmo Fio

Kratka priča o fio i etcd

Izvedba klastera itd uvelike ovisi o izvedbi njegove pohrane. etcd izvozi neke metrike u Prometejza pružanje željenih informacija o performansama pohrane. Na primjer, metrika wal_fsync_duration_seconds. Dokumentacija za etcd kaže: Da bi se pohrana smatrala dovoljno brzom, 99. percentil ove metrike mora biti manji od 10 ms. Ako planirate pokrenuti etcd klaster na Linux strojevima i želite procijeniti je li vaša pohrana dovoljno brza (npr. SSD), možete koristiti Fio je popularan alat za testiranje I/O operacija. Pokrenite sljedeću naredbu, gdje su testni podaci direktorij ispod točke montiranja za pohranu:

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

Samo trebate pogledati rezultate i provjeriti 99. percentil trajanja fdatasync manje od 10 ms. Ako je tako, imate relativno brzu pohranu. Evo primjera rezultata:

  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]

Bilješke

• Prilagodili smo opcije --size i --bs za naš određeni scenarij. Da biste dobili koristan rezultat od fio, navedite vlastite vrijednosti. Gdje ih nabaviti? Čitati kako smo naučili konfigurirati fio.
• Tijekom testiranja, svo I/O opterećenje dolazi iz fio. U scenariju stvarnog života, vjerojatno će u pohranu stizati drugi zahtjevi za pisanje osim onih koji se odnose na wal_fsync_duration_seconds. Dodatno opterećenje će povećati vrijednost wal_fsync_duration_seconds. Dakle, ako je 99. percentil blizu 10 ms, vaša pohrana je na izmaku.
• Uzmi verziju Fio ne manje od 3.5 (prethodni ne pokazuju percentile trajanja fdatasync).
• Gore je samo isječak rezultata iz fio.

Duga priča o fio i itd

Što je WAL u itd

Obično baze podataka koriste zapisnik unaprijed; etcd ga također koristi. Ovdje nećemo detaljno raspravljati o dnevniku pisanja unaprijed (WAL). Dovoljno nam je znati da ga svaki član etcd klastera održava u trajnoj pohrani. etcd zapisuje svaku operaciju ključ-vrijednost (kao što je ažuriranje) u WAL prije nego što je primijeni na pohranu. Ako se jedan od članova pohrane sruši i ponovno pokrene između snimaka, može lokalno vratiti transakcije od zadnje snimke WAL sadržajem.

Kada klijent doda ključ u pohranu ključ-vrijednost ili ažurira vrijednost postojećeg ključa, etcd bilježi operaciju u WAL-u, što je obična datoteka u trajnoj pohrani. etcd MORA biti potpuno siguran da se WAL unos stvarno dogodio prije nastavka s obradom. Na Linuxu za to nije dovoljan jedan sistemski poziv. pisati, jer stvarno pisanje u fizičku pohranu može biti odgođeno. Na primjer, Linux može neko vrijeme pohraniti WAL unos u predmemoriju u memoriji kernela (kao što je predmemorija stranice). A kako bi podaci bili točno zapisani u trajnu pohranu, nakon pisanja potreban je sistemski poziv fdatasync, a etcd ga samo koristi (kao što možete vidjeti u rezultatu rada strace, gdje je 8 deskriptor WAL datoteke):

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, zapisivanje u trajnu pohranu ne događa se trenutno. Ako je fdatasync poziv spor, performanse etcd sustava će biti slabije. Dokumentacija za etcd kažeda se pohrana smatra dovoljno brzom ako, u 99. percentilu, fdatasync pozivima treba manje od 10 ms za pisanje u WAL datoteku. Postoje i druge korisne metrike za pohranu, ali u ovom postu govorimo samo o ovoj metrici.

Procjena pohrane s fio

Ako trebate procijeniti je li vaša pohrana prikladna za etcd, koristite fio, vrlo popularan I/O alat za testiranje opterećenja. Treba imati na umu da diskovne operacije mogu biti vrlo različite: sinkrone i asinkrone, mnoge klase sistemskih poziva itd. Kao rezultat toga, fio je prilično težak za korištenje. Ima mnogo parametara, a različite kombinacije njihovih vrijednosti proizvode vrlo različita I/O radna opterećenja. Da biste dobili odgovarajuće brojke za etcd, trebali biste se uvjeriti da je opterećenje probnog pisanja iz fio što bliže stvarnom opterećenju iz etcd-a prilikom pisanja WAL datoteka.

Prema tome, fio bi trebao, barem, stvoriti učitavanje niza sekvencijalnih pisanja u datoteku, svako pisanje će se sastojati od sistemskog poziva pisatinakon čega slijedi sistemski poziv fdatasync. Sekvencijalno pisanje u fio zahtijeva opciju --rw=write. Da biste koristili sistemski poziv write prilikom pisanja, umjesto pisati, trebate navesti parametar --ioengine=sync. Konačno, kako biste pozvali fdatasync nakon svakog pisanja, morate dodati --fdatasync=1 parametar. Druge dvije opcije u ovom primjeru (--size i -bs) specifične su za skriptu. U sljedećem odjeljku pokazat ćemo vam kako ih postaviti.

Zašto fio i kako smo ga naučili postaviti

U ovom postu opisujemo stvarni slučaj. Imamo klaster Kubernetes v1.13 koju smo pratili s Prometheusom. etcd v3.2.24 nalazio se na SSD-u. Etcd metrika pokazala je previsoke latencije fdatasync-a, čak i kada klaster nije radio ništa. Mjerni podaci su bili čudni i zapravo nismo znali što znače. Klaster se sastojao od virtualnih strojeva, bilo je potrebno razumjeti u čemu je problem: u fizičkim SSD-ovima ili u virtualizacijskom sloju. Osim toga, često smo mijenjali konfiguraciju hardvera i softvera i trebao nam je način za procjenu njihovih rezultata. Mogli bismo pokrenuti etcd u svakoj konfiguraciji i pogledati Prometheusove metrike, ali to je previše gnjavaže. Tražili smo prilično jednostavan način za procjenu specifične konfiguracije. Htjeli smo provjeriti razumijemo li ispravno Prometheusove metrike iz etcd-a.

Ali za to su se morala riješiti dva problema. Prvo, kako izgleda I/O opterećenje koje etcd stvara prilikom pisanja na WAL? Koji se sistemski pozivi koriste? Kolika je veličina zapisa? Drugo, ako odgovorimo na ova pitanja, kako možemo reproducirati slično radno opterećenje s fio? Ne zaboravite da je fio vrlo fleksibilan alat s mnogo opcija. Oba problema smo riješili jednim pristupom - pomoću naredbi Također и strace. lsof ispisuje sve deskriptore datoteka koje koristi proces i njihove pridružene datoteke. A pomoću strace možete ispitati već pokrenuti proces ili pokrenuti proces i ispitati ga. strace ispisuje sve sistemske pozive iz procesa koji se ispituje (i njegovih podređenih procesa). Ovo posljednje je vrlo važno, budući da etcd samo ima sličan pristup.

Prvo smo upotrijebili strace za istraživanje etcd poslužitelja za Kubernetes kada nije bilo opterećenja na klasteru. Vidjeli smo da su gotovo svi WAL zapisi približno iste veličine: 2200–2400 bajtova. Stoga smo u naredbi na početku posta naveli parametar -bs=2300 (bs označava veličinu u bajtovima za svaki fio unos). Imajte na umu da veličina etcd unosa ovisi o etcd verziji, distribuciji, vrijednostima parametara itd. i utječe na trajanje fdatasync. Ako imate sličan scenarij, ispitajte svoje etcd procese sa straceom da saznate točne brojke.

Zatim, da bismo dobili dobru predodžbu o tome što radi etcd datotečni sustav, pokrenuli smo ga s opcijama strace i -ffttT. Stoga smo pokušali ispitati podređene procese i zabilježiti izlaz svakog od njih u zasebnu datoteku, te također dobiti detaljna izvješća o početku i trajanju svakog poziva sustava. Koristili smo lsof da potvrdimo našu analizu izlaza strace i vidimo koji se deskriptor datoteke koristi za koju svrhu. Tako su uz pomoć stracea dobiveni gore prikazani rezultati. Statistika vremena sinkronizacije potvrdila je da je wal_fsync_duration_seconds iz etcd u skladu s fdatasync pozivima s WAL deskriptorima datoteka.

Prošli smo kroz dokumentaciju za fio i odabrali opcije za našu skriptu tako da bi fio generirao učitavanje slično etcd. Također smo provjerili sistemske pozive i njihovo trajanje pokretanjem fio iz strace, slično itd.

Pažljivo smo odabrali vrijednost parametra --size da predstavlja cjelokupno I/O opterećenje iz fio. U našem slučaju, ovo je ukupan broj bajtova zapisanih u memoriju. Ispostavilo se da je izravno proporcionalan broju pisanja (i fdatasync) sistemskih poziva. Za određenu vrijednost bs, broj fdatasync poziva = veličina/bs. Budući da nas je zanimao percentil, morali smo imati dovoljno uzoraka da bismo bili sigurni, a izračunali smo da će nam biti dovoljno 10^4 (to je 22 mebibajta). Ako je --size manji, mogu se pojaviti odstupanja (na primjer, nekoliko fdatasync poziva traje dulje nego inače i utječe na 99. percentil).

Pokušajte sami

Pokazali smo vam kako koristiti fio i vidjeti ima li pohrana dovoljno brzine za visoke performanse itd. Sada to možete sami isprobati koristeći, na primjer, virtualne strojeve sa SSD pohranom IBM Cloud.

Izvor: www.habr.com