🥇Kako provjeriti diskove sa fio za dovoljne performanse za etcd

Bilješka. transl.: Ovaj članak je rezultat mini istraživanja koje su sproveli IBM Cloud inženjeri u potrazi za rješenjem stvarnog problema vezanog za rad etcd baze podataka. Sličan zadatak nam je bio relevantan, ali tok razmišljanja i djelovanja autora može biti zanimljiv u širem kontekstu.

Kratak sažetak cijelog članka: fio i etcd

Performanse etcd klastera jako zavise od brzine osnovne memorije. Za praćenje performansi, etcd izvozi različite Prometheus metrike. Jedan od njih je wal_fsync_duration_seconds. U etcd dokumentaciji kaže, da se pohrana može smatrati dovoljno brzom ako 99. percentil ove metrike ne prelazi 10 ms...

Ako razmišljate o postavljanju etcd klastera na Linux mašinama i želite testirati jesu li diskovi za pohranu (kao što su SSD-ovi) dovoljno brzi, preporučujemo korištenje popularnog I/O testera tzv. fio. Samo pokrenite sljedeću naredbu (direktorij test-data mora se nalaziti u montiranoj particiji diska koji se testira):

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

Ostaje samo pogledati izlaz i provjeriti da li odgovara 99. percentilu fdatasync na 10 ms. Ako je tako, onda je vaš pogon dovoljno brz. Evo primjera izlaza:

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]

nekoliko napomena:

U gornjem primjeru smo podesili parametre --size и --bs za konkretan slučaj. Da dobijete značajne rezultate od fio, navedite vrijednosti koje su prikladne za vaš slučaj upotrebe. O tome kako ih odabrati bit će riječi u nastavku.
Samo tokom testiranja fio učitava podsistem diska. U stvarnom životu je vjerovatno da će drugi procesi (osim onih koji su povezani sa wal_fsync_duration_seconds). Takvo dodatno opterećenje može dovesti do povećanja wal_fsync_duration_seconds. Drugim riječima, ako je 99. percentil dobiven testiranjem sa fio, samo nešto manje od 10 ms, postoji velika šansa da performanse skladištenja nisu dovoljne.
Za test će vam trebati verzija fio ne manje od 3.5, budući da starije verzije ne agregiraju rezultate fdatasync u obliku percentila.
Gornji zaključak je samo mali izvod ukupnog zaključka fio.

Detalji o fio i etcd

Nekoliko riječi o WAL-ovima itd

Obično se koriste baze podataka proaktivno evidentiranje (zapisivanje unaprijed, WAL). itd. ovo takođe važi. Rasprava o WAL-u je izvan okvira ovog članka, ali za naše svrhe evo šta trebate znati: Svaki član etcd klastera pohranjuje WAL u trajno skladište. etcd upisuje neke operacije pohrane ključ/vrijednost (kao što su ažuriranja) u WAL prije nego što ih izvrši. Ako se čvor sruši i ponovo pokrene između snimaka, etcd može vratiti transakcije izvršene od prethodnog snimka na osnovu sadržaja WAL-a.

Stoga, svaki put kada klijent doda ključ u KV skladište ili ažurira vrijednost postojećeg ključa, etcd dodaje opis operacije u WAL, što je obična datoteka u trajnoj memoriji. etcd MORA biti 100% siguran da je WAL unos zaista pohranjen prije nego što nastavi. Da bi se to postiglo na Linuxu, nije dovoljno koristiti sistemski poziv write, budući da sama operacija pisanja na fizički medij može biti odgođena. Na primjer, Linux može neko vrijeme zadržati WAL unos u keš kernelu u memoriji (kao što je keš stranica). Da bi se osiguralo da su podaci upisani na medij, sistemski poziv se mora pozvati nakon pisanja fdatasync - to je upravo ono što etcd radi (kao što se može vidjeti u sljedećem izlazu strace; Evo 8 - WAL ručka datoteke):

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>

Nažalost, pisanje u trajnu pohranu traje neko vrijeme. Dugotrajno dovršavanje poziva fdatasync može uticati na performanse etcd-a. U dokumentaciji za spremište naznačenoda je za dovoljne performanse potrebno da 99. percentil trajanja svih poziva fdatasync prilikom pisanja u datoteku, WAL je bio manji od 10 ms. Postoje i druge metrike vezane za pohranu, ali ovaj članak će se fokusirati na ovu.

Procjena skladištenja pomoću fio

Pomoću uslužnog programa možete procijeniti da li je određena pohrana pogodna za korištenje s etcd-om fio - popularni I/O tester. Imajte na umu da se disk I/O može dogoditi na različite načine: sinhronizacija/asinhronizacija, mnoge različite klase sistemskih poziva itd. Druga strana medalje je to fio izuzetno teško koristiti. Uslužni program ima mnogo parametara, a različite kombinacije njihovih vrijednosti dovode do potpuno različitih rezultata. Da biste dobili razumnu procjenu za etcd, morate osigurati da je opterećenje pisanja koje generiše fio što je moguće sličnije opterećenju etcd pisanja u WAL datoteke:

To znači da generirani fio radno opterećenje mora biti barem niz uzastopnih upisa u datoteku, gdje se svaka operacija pisanja sastoji od sistemskog poziva writeslijedi fdatasync.
Da biste omogućili sekvencijalno snimanje, morate navesti zastavicu --rw=write.
da fio pisao koristeći pozive write (a ne drugi sistemski pozivi - na primjer, pwrite), koristite zastavu --ioengine=sync.
Konačno, zastava --fdatasync=1 garantuje da iza svakog write mora biti fdatasync.
Još dva parametra u našem primjeru: --size и --bs - može se razlikovati ovisno o specifičnom slučaju upotrebe. Sljedeći odjeljak će opisati kako ih konfigurirati.

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

Ova bilješka dolazi iz stvarnog slučaja s kojim smo se susreli. Imali smo klaster na Kubernetesu v1.13 sa praćenjem na Prometheusu. Solid State diskovi su korišteni kao skladište za etcd v3.2.24. etcd metrike su pokazale previsoke latencije fdatasync, čak i kada je klaster bio u stanju mirovanja. Smatrali smo da su ove metrike veoma upitne i nismo bili sigurni šta tačno predstavljaju. Pored toga, klaster se sastojao od virtuelnih mašina, tako da je bilo nemoguće reći da li je do kašnjenja došlo zbog virtuelizacije ili su krivi SSD-ovi.

Osim toga, gledali smo razne promjene hardverskih i softverskih konfiguracija, pa nam je bio potreban način da ih procijenimo. Naravno, bilo bi moguće pokrenuti etcd u svakoj konfiguraciji i pogledati odgovarajuće Prometheus metrike, ali to bi zahtijevalo značajan napor. Trebao nam je jednostavan način za procjenu određene konfiguracije. Htjeli smo testirati naše razumijevanje Prometheus metrike koja dolazi iz etcd.

Da bi se to postiglo, trebalo je riješiti dva problema:

Prvo, kako izgleda I/O opterećenje koje etcd generiše prilikom pisanja u WAL fajlove? Koji sistemski pozivi se koriste? Koja je veličina bloka za pisanje?
Drugo, recimo da imamo odgovore na gornja pitanja. Kako reproducirati odgovarajuće opterećenje sa fio? Nakon svega fio — izuzetno fleksibilan uslužni program sa dosta parametara (ovo je lako provjeriti, npr. ovdje — pribl. prevod).

Oba problema smo riješili koristeći isti pristup baziran na komandi lsof и strace:

Uz pomoć lsof Možete vidjeti sve deskriptore datoteka koje koristi proces, kao i datoteke na koje se odnose.
Uz pomoć strace možete analizirati već pokrenuti proces ili pokrenuti proces i promatrati ga. Naredba prikazuje sve sistemske pozive koje je izvršio ovaj proces i, opciono, njegove potomke. Ovo posljednje je važno za procese koji se račvaju, a etcd je jedan od takvih procesa.

Prva stvar koju smo uradili je bila upotreba strace za proučavanje etcd servera u Kubernetes klasteru dok je neaktivan.

Tako je otkriveno da su blokovi pisanja u WAL-u veoma gusto grupisani, a većina njih je u rasponu od 2200-2400 bajtova. Zbog toga naredba na početku ovog članka koristi zastavicu --bs=2300 (bs — veličina u bajtovima svakog bloka snimanja fio).

Imajte na umu da veličine blokova pisanja etcd mogu varirati ovisno o verziji, implementaciji, vrijednostima parametara itd. - ovo utiče na trajanje fdatasync. Ako imate sličan slučaj upotrebe, analizirajte s strace vaši etcd procesi da biste dobili najnovije vrijednosti.

Zatim, da bismo dobili jasno i sveobuhvatno razumijevanje kako etcd radi sa sistemom datoteka, pokrenuli smo ga ispod strace sa zastavama -ffttT. Ovo je omogućilo snimanje podređenih procesa i zapisivanje izlaza svakog u posebnu datoteku. Osim toga, dobijene su detaljne informacije o početnom trenutku i trajanju svakog sistemskog poziva.

Koristili smo i naredbu lsofda potvrdite svoje razumijevanje rezultata strace u smislu koji je deskriptor datoteke korišten za koju svrhu. Rezultat je bio strace, sličan onom iznad. Statističke manipulacije sa vremenima sinhronizacije potvrdile su da je metrika wal_fsync_duration_seconds iz etcd odgovara pozivima fdatasync sa WAL deskriptorima datoteka.

Za generiranje koristeći fio radno opterećenje slično opterećenju iz etcd-a, proučena je dokumentacija uslužnog programa i odabrani parametri pogodni za naš zadatak. Uvjerili smo se da su uključeni ispravni sistemski pozivi i potvrdili njihovo trajanje pokretanjem fio из strace (kao što je urađeno u slučaju etcd).

Posebna pažnja posvećena je određivanju vrijednosti parametra --size. Predstavlja ukupno I/O opterećenje koje generiše fio uslužni program. U našem slučaju, ovo je ukupan broj bajtova upisanih na medij. On je direktno proporcionalan broju poziva write (i fdatasync). Za izvesno bs broj poziva fdatasync jednako size / bs.

Budući da nas je zanimao procentil, nastojali smo osigurati da je broj uzoraka dovoljno velik za statističku značajnost. I oni su to odlučili 10^4 (što odgovara veličini od 22 MB) će biti dovoljno. Manje vrijednosti parametara --size proizvodilo izraženiju buku (na primjer, pozivi fdatasync, koji traju mnogo duže nego inače i utiču na 99. percentil).

Do tebe je

Članak pokazuje kako koristiti fio možete procijeniti da li je medij namijenjen upotrebi sa etcd-om dovoljno brz. Sada je na vama! Možete istražiti virtuelne mašine sa SSD memorijom u usluzi IBM Cloud.

PS od prevodioca

Sa gotovim primjerima korištenja fio za rješavanje drugih problema možete pronaći u dokumentaciju ili direktno na projektna spremišta (tamo ih ima mnogo više nego što je navedeno u dokumentaciji).

PPS od prevodioca

Pročitajte i na našem blogu:

izvor: www.habr.com

Kako provjeriti diskove sa fio za dovoljne performanse za etcd