Bilješka. prev.: Ovaj je članak rezultat mini-istraživanja koje su proveli IBM Cloud inženjeri u potrazi za rješenjem stvarnog problema vezanog uz rad etcd baze podataka. Sličan zadatak bio je aktualan i za nas, no tijek promišljanja i djelovanja autora može biti zanimljiv u širem kontekstu.
Kratak sadržaj cijelog članka: fio i itd
Izvedba etcd klastera uvelike ovisi o brzini temeljne pohrane. etcd izvozi razne Prometheus metrike za praćenje performansi. Jedan od njih je wal_fsync_duration_seconds. U dokumentaciji za itd to se pohranjivanje može smatrati dovoljno brzim ako 99. percentil ove metrike ne prelazi 10 ms...
Ako razmišljate o postavljanju etcd klastera na Linux strojevima i želite testirati jesu li pogoni (kao što su SSD) dovoljno brzi, preporučujemo korištenje popularnog I/O testera pod nazivom . Dovoljno je pokrenuti sljedeću naredbu (direktorij test-data mora se nalaziti u montiranoj particiji testiranog pogona):
fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytestOstaje samo pogledati izlaz i provjeriti odgovara li 99. percentil za 10 ms. Ako je tako, onda vaš pogon radi dovoljno brzo. 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 prilagodili smo parametre
--sizeи--bsza konkretan slučaj. Da biste dobili značajan rezultatfio, navedite vrijednosti prikladne za vaš slučaj upotrebe. Kako ih odabrati, raspravljat ćemo u nastavku. - Samo tijekom testiranja
fioučitava diskovni podsustav. U stvarnom životu, vjerojatno je da će drugi procesi pisati na disk (osim onih koji se odnose nawal_fsync_duration_seconds). Ovo dodatno opterećenje može se povećatiwal_fsync_duration_seconds. Drugim riječima, ako 99. percentil iz testiranja safio, samo nešto manje od 10 ms, postoji dobra vjerojatnost da performanse pohrane nisu dovoljne. - Za test će vam trebati verzija
fione manje od 3.5jer starije verzije ne prikupljaju rezultatefdatasyncu obliku percentila. - Gornji zaključak samo je mali izvadak iz općeg zaključka
fio.
Više o fio i etcd
Nekoliko riječi o WAL-ovima itd
Općenito, baze podataka koriste (bilježenje unaprijed, WAL). etcd je također pogođen. Rasprava o WAL-u je izvan opsega ovog članka, ali za naše potrebe, ono što trebate znati je da svaki etcd član klastera pohranjuje WAL u trajnu pohranu. etcd zapisuje neke operacije pohrane ključ-vrijednosti (kao što su ažuriranja) u WAL prije nego ih izvrši. Ako se čvor sruši i ponovno pokrene između snimki, etcd može oporaviti transakcije od prethodne snimke na temelju sadržaja WAL-a.
Dakle, svaki put kada klijent doda ključ u KV pohranu ili ažurira vrijednost postojećeg ključa, etcd dodaje opis operacije u WAL, što je obična datoteka u trajnoj pohrani. etcd MORA biti 100% siguran da je WAL unos stvarno spremljen prije nastavka. Da biste to postigli na Linuxu, nije dovoljno koristiti sistemski poziv , budući da sama operacija pisanja na fizički medij može kasniti. Na primjer, Linux može zadržati WAL unos u predmemoriji kernela u memoriji (npr. u predmemoriji stranica) neko vrijeme. Kako bi se osiguralo da su podaci zapisani na medij, nakon pisanja mora se pozvati sistemski poziv fdatasync - to je upravo ono što etcd radi (kao što možete vidjeti u sljedećem izlazu ; Ovdje 8 - WAL deskriptor 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, zapisivanje u trajnu pohranu traje neko vrijeme. Dugotrajno izvršavanje fdatasync poziva može utjecati na performanse itd. U dokumentaciji repozitorija , da je za dovoljnu izvedbu potrebno 99. percentil trajanja svih poziva fdatasync kada je pisanje u WAL datoteku bilo manje od 10 ms. Postoje i druge metrike povezane s pohranom, ali ovaj će se članak usredotočiti na njih.
Vrednovanje pohrane s fio
Pomoću uslužnog programa možete procijeniti je li određena pohrana prikladna za korištenje s etcd — popularan I/O tester. Imajte na umu da se I/O diska može dogoditi na mnogo različitih načina: sinkronizacija/asinkronizacija, mnogo različitih klasa syscall-a i tako dalje. Druga strana medalje je ta fio izuzetno težak za korištenje. 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 biti sigurni da je opterećenje pisanja koje generira fio što je moguće bliže etcd-ovom WAL opterećenju pisanja:
- To znači da generirani
fioučitavanje bi trebalo biti barem niz uzastopnih pisanja u datoteku, gdje se svako pisanje sastoji od sistemskog poziva slijedifdatasync. - Da biste omogućili sekvencijalno pisanje, morate navesti oznaku
--rw=write. - Da
fionapisao pomoću pozivawrite(umjesto drugih poziva sustava - na primjer, ), koristite zastavu--ioengine=sync. - Na kraju, zastava
--fdatasync=1osigurava da svakiwritemora bitifdatasync. - Druga dva parametra u našem primjeru su:
--sizeи--bs- može varirati ovisno o konkretnom slučaju upotrebe. Sljedeći odjeljak opisat će njihovu konfiguraciju.
Zašto smo odabrali fio i kako smo naučili kako ga postaviti
Ova bilješka dolazi iz stvarnog slučaja na koji smo naišli. Imali smo klaster na Kubernetes v1.13 s praćenjem na Prometheusu. SSD-ovi su korišteni kao pohrana za etcd v3.2.24. Etcd metrika pokazala je previsoke latencije fdatasync, čak i kada je klaster bio u stanju mirovanja. Nama su se te metrike činile vrlo dvojbenim i nismo bili sigurni što točno predstavljaju. Osim toga, klaster se sastojao od virtualnih strojeva, pa se nije moglo reći je li do kašnjenja došlo zbog virtualizacije ili je za to kriv SSD.
Osim toga, razmotrili smo razne promjene u konfiguraciji hardvera i softvera, pa nam je trebao način da ih ocijenimo. Naravno, bilo bi moguće pokrenuti etcd u svakoj konfiguraciji i pogledati odgovarajuću Prometheus metriku, ali to bi zahtijevalo značajan napor. Ono što nam je trebalo je jednostavan način za procjenu specifične konfiguracije. Željeli smo testirati naše razumijevanje Prometheusove metrike koja dolazi iz etcd.
To je zahtijevalo rješavanje dva problema:
- Prvo, kako izgleda I/O opterećenje koje generira etcd prilikom pisanja u WAL datoteke? Koji se sistemski pozivi koriste? Koja je veličina blokova zapisa?
- Drugo, recimo da imamo odgovore na gornja pitanja. Kako reproducirati odgovarajuće opterećenje s
fio? Nakon svegafio— iznimno fleksibilan uslužni program s obiljem parametara (ovo je lako provjeriti, npr. - cca. prev.).
Oba smo problema riješili istim pristupom temeljenim na naredbama и :
- S
lsofmožete vidjeti sve deskriptore datoteka koje koristi proces, kao i datoteke na koje se odnose. - S
stracemožete analizirati već pokrenuti proces ili pokrenuti proces i gledati ga. Naredba prikazuje sve sistemske pozive koje je napravio ovaj proces i, ako je potrebno, njegove potomke. Potonje je važno za procese koji se račvaju, a etcd je jedan takav proces.
Prvo što smo učinili bilo je korištenje strace za ispitivanje etcd poslužitelja u Kubernetes klasteru dok je bio u stanju mirovanja.
Tako je utvrđeno da su WAL blokovi zapisa vrlo gusto grupirani, veličina većine bila je u rasponu od 2200-2400 bajtova. Zato naredba s početka ovog članka koristi zastavicu --bs=2300 (bs je veličina u bajtovima svakog bloka za upisivanje fio).
Imajte na umu da veličina etcd blokova pisanja može varirati ovisno o verziji, implementaciji, vrijednostima parametara itd. - to utječe na trajanje fdatasync. Ako imate sličan slučaj upotrebe, analizirajte s strace vaše etcd procese da biste dobili ažurne vrijednosti.
Zatim, kako bismo dobili jasnu i sveobuhvatnu ideju o tome kako etcd radi sa sustavom datoteka, pokrenuli smo ga odozdo strace sa zastavama -ffttT. To je omogućilo snimanje podređenih procesa i pisanje izlaza svakog u zasebnu datoteku. Osim toga, dobivene su detaljne informacije o vremenu početka i trajanju svakog poziva sustava.
Koristili smo i naredbu lsofkako biste potvrdili svoje razumijevanje izlaza strace u smislu koji je deskriptor datoteke korišten za koju svrhu. Zaključio sam strace, sličan onom gore. Statističke manipulacije s vremenima sinkronizacije potvrdile su da metrika wal_fsync_duration_seconds from etcd odgovara pozivima fdatasync s WAL deskriptorima datoteka.
Generirati sa fio radno opterećenje slično onome iz etcd-a, proučena je dokumentacija uslužnog programa i odabrani su parametri prikladni za naš zadatak. Provjerili smo da su ispravni sistemski pozivi u tijeku i potvrdili njihovo trajanje pokretanjem fio od strace (kao što je učinjeno u slučaju etcd).
Posebna pažnja posvećena je određivanju vrijednosti parametra --size. Predstavlja ukupno I/O opterećenje koje generira fio pomoćni program. U našem slučaju, ovo je ukupan broj bajtova zapisanih na medij. Direktno je proporcionalan broju poziva write (i fdatasync). Za određeni bs broj poziva fdatasync je size / bs.
Budući da nas je zanimao percentil, htjeli smo da broj uzoraka bude dovoljno velik da bude statistički značajan. I to odlučio 10^4 (što odgovara veličini od 22 MB) će biti dovoljno. Manje vrijednosti parametara --size davao izraženiju buku (na primjer, pozivi fdatasync, koji traju mnogo dulje nego inače i utječu na 99. percentil).
Na tebi je
Članak pokazuje kako koristiti fio može se procijeniti je li medij namijenjen za korištenje s etcd dovoljno brz. Sada je na vama! U usluzi možete istražiti virtualne strojeve s pohranom temeljenom na SSD-u .
PS od prevoditelja
S gotovim slučajevima upotrebe fio Za ostale zadatke vidi ili izravno na (ima ih puno više nego što je navedeno u dokumentaciji).
PPS od prevoditelja
Pročitajte i na našem blogu:
- «»;
- «»;
- «".
Izvor: www.habr.com