Brzina skladištenja pogodna za etcd? Hajde da pitamo fio

Kratka priča o fio i etcd

Performanse klastera itdd u velikoj mjeri zavisi od performansi njegovog skladištenja. etcd izvozi neke metrike u Prometejda pružite informacije o performansama skladištenja koje su vam potrebne. Na primjer, metrika wal_fsync_duration_seconds. U etcd dokumentaciji piše: Da bi se skladištenje smatralo dovoljno brzim, 99. percentil ove metrike mora biti manji od 10 ms. Ako planirate da pokrenete etcd klaster na Linux mašinama i želite da procenite da li je vaša pohrana (kao što je SSD) dovoljno brza, možete koristiti fio je popularan alat za testiranje I/O operacija. Pokrenite sljedeću naredbu, gdje je test-data direktorij ispod točke postavljanja memorije:

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

Samo trebate pogledati rezultate i provjeriti da li je 99. percentil trajanja fdatasync manje od 10 ms. Ako jeste, imate dovoljno brzu memoriju. 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]

Napomene

• Prilagodili smo vrijednosti parametara -size i -bs za naš specifični scenarij. Da biste dobili korisne rezultate od fio-a, unesite svoje vrijednosti. Gdje ih mogu nabaviti? čitaj, kako smo naučili da konfigurišemo fio.
• Tokom testiranja, svo I/O opterećenje dolazi od fio. U stvarnom scenariju, vjerovatno će doći do drugih zahtjeva za pisanje u skladište osim onih povezanih sa wal_fsync_duration_seconds. Dodatno opterećenje će povećati vrijednost wal_fsync_duration_seconds. Dakle, ako je 99. percentil skoro 10 ms, vaša pohrana nije dovoljno brza.
• Uzmi verziju fio ne manje od 3.5 (prethodni ne pokazuju percentile trajanja fdatasync).
• Iznad je samo isječak rezultata iz fio.

Duga priča o fio i etcd

Šta je WAL u itd

Obično se koriste baze podataka zapisnik unaprijed; etcd ga također koristi. Ovdje nećemo detaljno raspravljati o zapisniku unaprijed (WAL). Dovoljno je da znamo da ga svaki član etcd klastera održava u trajnoj memoriji. etcd upisuje svaku operaciju na parovima ključ/vrijednost (kao što je ažuriranje) u WAL prije nego što ih primijeni u spremište. Ako se jedan od članova skladišta sruši i ponovo pokrene između snimaka, može lokalno vratiti transakcije iz posljednje snimke koristeći sadržaj WAL-a.

Kada klijent dodaje ključ u skladište ključ/vrijednost ili ažurira vrijednost postojećeg ključa, etcd upisuje zapis ove operacije u WAL, što je obična datoteka u trajnoj memoriji. etcd MORA biti potpuno siguran da se WAL upisivanje zaista dogodilo prije nego što se obrada nastavi. U Linuxu jedan sistemski poziv nije dovoljan za ovo pisati, jer stvarno pisanje u fizičku memoriju može biti odgođeno. Na primjer, Linux može privremeno pohraniti WAL unos u keš memoriju kernela (kao što je keš stranica). A da bi podaci bili precizno upisani u trajno skladište, potreban je sistemski poziv fdatasync nakon snimanja, a etcd ga samo koristi (što se vidi kao rezultat 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, pisanje u trajnu pohranu nije trenutno. Ako je fdatasync poziv spor, performanse etcd sistema će se smanjiti. U etcd dokumentaciji pišeda se skladište smatra dovoljno brzom ako je 99. percentilu fdatasync poziva potrebno manje od 10 ms za pisanje u WAL datoteku. Postoje i druge korisne metrike za pohranu, ali ovo je jedina metrika o kojoj govorimo u ovom postu.

Procjena skladištenja pomoću fio

Ako trebate procijeniti da li je vaša pohrana pogodna za etcd, koristite fio, vrlo popularan alat za testiranje I/O opterećenja. Treba imati na umu da operacije diska mogu biti vrlo različite: sinhrone i asinhrone, mnoge klase sistemskih poziva, itd. Kao rezultat toga, fio je prilično teško koristiti. Ima mnogo parametara, a različite kombinacije njihovih vrijednosti proizvode vrlo različita I/O radna opterećenja. Da biste dobili adekvatne brojeve za etcd, trebali biste osigurati da je opterećenje testa pisanja iz fio što je moguće bliže stvarnom opterećenju iz etcd prilikom pisanja WAL datoteka.

Stoga, fio mora, u najmanju ruku, generirati učitavanje određenog broja uzastopnih upisa u datoteku, pri čemu se svako upisivanje sastoji od sistemskog poziva pisatinakon čega slijedi sistemski poziv fdatasync. Za sekvencijalno upisivanje fio-a potrebna je opcija --rw=write. Tako da fio koristi sistemski poziv write prilikom pisanja, a ne pwrite, vrijedi navesti parametar –ioengine=sync. Konačno, da biste pozvali fdatasync nakon svakog upisivanja, morate dodati opciju --fdatasync=1. Druge dvije opcije u ovom primjeru (--size i -bs) su specifične za scenarij. U sljedećem odjeljku ćemo vam pokazati kako ih postaviti.

Zašto fio i kako smo naučili da ga konfigurišemo

U ovom postu opisujemo pravi slučaj. Imali smo klaster Kubernet v1.13, koji smo pratili pomoću Prometheusa. etcd v3.2.24 je bio hostovan na SSD-u. Etcd metrike su pokazale preveliko kašnjenje za fdatasync, čak i kada klaster nije ništa radio. metrika je bila čudna i mi zapravo nismo znali šta znače. Klaster se sastojao od virtuelnih mašina, bilo je potrebno razumjeti u čemu je problem: u fizičkim SSD-ovima ili u virtuelizacijskom sloju. Osim toga, često smo pravili promjene u hardverskim i softverskim konfiguracijama i bio nam je potreban način da procijenimo njihove rezultate. Mogli bismo pokrenuti etcd u svakoj konfiguraciji i pogledati Prometheus metriku, ali ovo je prevelika gnjavaža. Tražili smo prilično jednostavan način za procjenu određene konfiguracije. Htjeli smo provjeriti da li smo ispravno razumjeli etcd-ove Prometheus metrike.

Ali za to je bilo potrebno riješiti dva problema. Prvo, kakvo je I/O opterećenje koje etcd stvara prilikom pisanja u WAL? Koji sistemski pozivi se koriste? Koje su veličine postova? Drugo, ako odgovorimo na ova pitanja, kako možemo reproducirati slično opterećenje sa fio-om? Ne zaboravite da je fio vrlo fleksibilan alat sa mnogo opcija. Oba problema smo riješili jednim pristupom - korištenjem komandi takođe и strace. lsof prikazuje sve deskriptore datoteka koje koristi proces i njihove pridružene datoteke. A sa strace možete proučavati već pokrenuti proces ili pokrenuti proces i proučavati ga. strace ispisuje sve sistemske pozive iz procesa koji se proučava (i njegovih podređenih procesa). Ovo posljednje je vrlo važno, jer etcd ima sličan pristup.

Prva stvar koju smo uradili je da smo koristili strace za proučavanje etcd servera za Kubernetes kada nije bilo opterećenja na klasteru. Videli smo da su skoro svi WAL zapisi bili približno iste veličine: 2200–2400 bajtova. Stoga smo u naredbi na početku posta naveli parametar -bs=2300 (bs znači veličinu u bajtovima za svaki fio unos). Imajte na umu da veličina etcd unosa ovisi o etcd verziji, otpremi, vrijednostima parametara itd. i utiče na trajanje fdatasync. Ako imate sličan scenarij, ispitajte svoje etcd procese koristeći strace da biste saznali točne brojeve.

Zatim, da bismo dobili dobru ideju o tome šta etcd sistem datoteka radi, pokrenuli smo ga sa strace i -ffttT opcijama. Zato smo pokušali da proučimo podređene procese i snimimo izlaz svakog od njih u zasebnu datoteku, kao i da dobijemo detaljne izveštaje o početku i trajanju svakog sistemskog poziva. Koristili smo lsof da potvrdimo našu analizu strace izlaza i vidimo koji je deskriptor datoteke korišten za koje svrhe. Dakle, koristeći strace, dobili smo gore prikazane rezultate. Statistika vremena sinhronizacije potvrdila je da metrika wal_fsync_duration_seconds iz etcd odgovara fdatasync pozivima sa WAL deskriptorima datoteke.

Pogledali smo fio dokumentaciju i odabrali parametre za našu skriptu tako da fio generiše opterećenje slično etcd. Također smo provjerili sistemske pozive i njihovo trajanje pokretanjem fio iz strace, slično kao etcd.

Pažljivo smo odabrali vrijednost parametra --size, koji predstavlja cjelokupno I/O opterećenje fio-a. U našem slučaju, ovo je ukupan broj bajtova upisanih u memoriju. Pokazalo se da je to direktno proporcionalno broju sistemskih poziva za pisanje (i fdatasync). Za određenu vrijednost bs, broj poziva fdatasync = size/bs. Pošto nas je zanimao procenat, morali smo imati dovoljno uzoraka da bismo bili pouzdani, i izračunali smo da bi nam bilo dovoljno 10^4 (to je 22 mebibajta). Ako je --size manji, mogu se pojaviti odstupanja (na primjer, nekoliko fdatasync poziva traje duže nego obično i utiče na 99. percentil).

Pokušajte sami

Pokazali smo kako koristiti fio i otkriti da li je skladište dovoljno brzo da etcd radi dobro. Sada to možete i sami isprobati u praksi, koristeći, na primjer, virtuelne mašine sa SSD memorijom IBM Cloud.

izvor: www.habr.com