🥇Je li brzina pohrane pogodna za etcd? Pitamo fio

Kratka priča o fio i etcd

Performanse klastera etcd u velikoj mjeri ovise o performansama njegovog skladišta. etcd izvozi neke metrike u Prometheus, kako bi pružio potrebne informacije o performansama skladišta. Na primjer, metriku wal_fsync_duration_seconds. U dokumentaciji za etcd se kaže: da bi skladište bilo dovoljno brzo, 99. percentil ove metrike mora biti manji od 10 ms. Ako planirate pokrenuti etcd klaster na Linux strojevima i želite procijeniti je li vaše skladište dovoljno brzo (npr. SSD), možete koristiti fio — popularni alat za testiranje ulazno-izlaznih operacija. Pokrenite sljedeću naredbu, gdje je test-data mapa ispod točke pristupanja skladištu:

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

Samo trebate pogledati rezultate i provjeriti da 99. percentil trajanja fdatasync je manji od 10 ms. Ako jest, vaše skladište je dovoljno brzo. Evo primjer rezultata:

  sync (usec): min=534, max=15766, avg=1273.08, stdev=1084.70
  sync percentili (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

Postavili smo vrijednosti parametara —size i —bs za naš specifični scenarij. Da biste dobili korisne rezultate iz fio-a, unesite svoje vrijednosti. Gdje ih pronaći? Čitajte, kako smo naučili optimizirati fio.
Tijekom testiranja, sav ulazno-izlazni teret dolazi od fio-a. U stvarnom scenariju, vjerojatno će skladištu biti upućeni i drugi zapisi, osim onih povezanih s wal_fsync_duration_seconds. Dodatno opterećenje povećat će vrijednost wal_fsync_duration_seconds. Dakle, ako je 99. percentil gotovo dosegao 10 ms, vašem skladištu nedostaje brzine.
Koristite verziju fio ne manju od 3.5 (prethodne ne prikazuju percentile trajanja fdatasync).
Iznad je prikazan samo dio rezultata od fio.

Dugoročna priča o fio i etcd

Što je WAL u etcd

Obično baze podataka koriste prednapredni zapis; etcd također koristi. Ovdje nećemo detaljno raspravljati o dnevniku unaprijed zapisivanja (write-ahead log, WAL). Dovoljno je znati da svaki član etcd klastera vodi vlastiti trajni pohranu. etcd bilježi svaku operaciju s parovima ključ-vrijednost (npr. ažuriranje) u WAL prije nego što ih primijeni u pohranu. Ako jedan od članova pohrane neočekivano završi s radom i ponovno se pokrene između snimaka, može lokalno obnoviti transakcije od posljednje snimke koristeći sadržaj WAL-a.

Kada klijent dodaje ključ u pohranu parova ključ-vrijednost ili ažurira vrijednost postojećeg ključa, etcd bilježi ovu operaciju u WAL, koji je obična datoteka u trajnoj pohrani. Prije nego što nastavi s obradom, etcd MORA biti potpuno siguran da je zapis u WAL zaista napravljen. U Linuxu to nije dovoljno samo jedan sustavni poziv. write, s obzirom na to da se zapis u fizičku pohranu može odgoditi. Na primjer, Linux može neko vrijeme zadržati zapis WAL u predmemoriji jezgre (npr. predmemorija stranica). A da bi se podaci sigurno zapisali u trajnu pohranu, potreban je sustavni poziv fdatasync nakon zapisivanja, a etcd upravo to koristi (kao što se može vidjeti iz rezultata rada strace, gdje je 8 - deskriptor datoteke WAL):

21:23:09.894875 lseek(8, 0, SEEK_CUR)   = 12808 
21:23:09.894911 write(8, ". 20210220361223255266632$10 20103026"34"rn3fo"..., 2296) = 2296 
21:23:09.895041 fdatasync(8)            = 0

Nažalost, zapis u trajnu pohranu ne prolazi trenutno. Ako poziv fdatasync radi sporo, performanse sustava etcd padaju. U dokumentaciji za etcd navedeno je, da se pohrana smatra dovoljno brzim ako u 99. percentilu poziva fdatasync pri zapisivanju u datoteku WAL traje manje od 10 ms. Postoje i druge korisne metrike za pohranu, ali u ovoj objavi govorimo samo o ovoj metriki.

Ocjenjivanje pohrane pomoću fio

Ako trebate procijeniti odgovara li vaše pohranjivanje za etcd, upotrijebite fio — vrlo popularni alat za testiranje opterećenja ulaza-izlaza. Treba imati na umu da operacije s diskom mogu biti vrlo raznolike: sinhrone i asinhrone, razne klase sistemskih poziva itd. Kao posljedica — fio se dovoljno teško koristi. Ima mnogo parametara, a različite kombinacije njihovih vrijednosti daju potpuno neslična opterećenja ulaza-izlaza. Da biste dobili adekvatne brojke za etcd, trebate osigurati da testno opterećenje pisanja iz fio-a bude što bliže stvarnom opterećenju od etcd prilikom zapisivanja WAL datoteka.

Stoga, fio mora, barem, generirati opterećenje u obliku niza uzastopnih operacija pisanja u datoteku, pri čemu će svaki zapis biti sastavljen od sistemskog poziva write, nakon kojeg slijedi sistemski poziv fdatasync. Za uzastopne operacije pisanja fio-u je potreban parametar —rw=write. Da bi prilikom pisanja fio koristio sistemski poziv write, a ne pwrite, potrebno je postaviti parametar —ioengine=sync. Na kraju, kako bi se nakon svake operacije pisanja pozvao fdatasync, potrebno je dodati parametar —fdatasync=1. Dva druga parametra u ovom primjeru (—size i —bs) ovise o konkretnoj situaciji. U sljedećem dijelu ćemo objasniti kako ih postaviti.

Zašto baš fio i kako smo ga naučili prilagoditi

U ovoj objavi opisujemo stvarni slučaj. Imali smo klaster Kubernetes v1.13, koji smo nadzirali putem Prometheusa. etcd v3.2.24 bio je smješten na SSD-u. Metrički podaci za etcd pokazivali su prevelike latencije za fdatasync, čak i kada klaster nije radio. Metrički podaci su bili čudni, a nismo do kraja znali što znače. Klaster se sastojao od virtualnih mašina, trebali smo shvatiti gdje je problem: u fizičkim SSD-ima ili u sloju virtualizacije. Osim toga, često smo mijenjali konfiguraciju hardvera i softvera, a trebali smo način da procijenimo njihove rezultate. Mogli smo pokretati etcd u svakoj konfiguraciji i gledati na metrike Prometheusa, ali to je previše komplicirano. Tražili smo dovoljno jednostavan način da procijenimo specifičnu konfiguraciju. Željeli smo provjeriti je li naše razumijevanje metrika Prometheusa od etcd-a ispravno.

No, kako bismo to postigli, trebali smo riješiti dva problema. Prvo, kakvo opterećenje ulaza/izlaza stvara etcd prilikom zapisivanja u WAL? Koji se sistemski pozivi koriste? Kolika je veličina zapisa? Drugo, ako odgovorimo na ova pitanja, kako reproducirati slično opterećenje s fio? Ne zaboravite, fio je vrlo fleksibilan alat s mnoštvom parametara. Riješili smo oba problema jednim pristupom - pomoću naredbi lsof i strace. lsof prikazuje sve deskriptore datoteka koje koristi proces, te povezane datoteke. Uz pomoć strace možemo istražiti već pokrenuti proces ili pokrenuti proces i proučiti ga. strace prikazuje sve sistemske pozive analiziranog procesa (i njegovih podprocesa). Ovo je vrlo važno jer etcd koristi sličan pristup.

Prvo smo koristili strace da bismo proučili etcd poslužitelj za Kubernetes kada na klasteru nije bilo opterećenja. Vidjeli smo da su skoro svi WAL zapisi bili otprilike jednake veličine: 2200–2400 bajtova. Stoga smo u timu na početku posta naveli parametar —bs=2300 (bs označava veličinu u bajtovima za svaki zapis fio). Imajte na umu da veličina zapisa etcd ovisi o verziji etcd, isporuci, vrijednostima parametara itd. i utječe na trajanje fdatasync. Ako imate sličan scenarij, istražite svoje etcd procese pomoću strace kako biste saznali točne brojke.

Zatim, kako bismo dobro predstavili akcije u datotečnom sustavu etcd, pokrenuli smo ga sa strace i s parametrima -ffttT. Tako smo pokušali istražiti podprocese i zabilježiti izlazne podatke svakog od njih u zasebnom datoteci, a također dobiti detaljna izvješća o početku i trajanju svakog sistemskog poziva. Koristili smo lsof kako bismo potvrdili našu analizu izlaznih podataka strace i vidjeli koji se deskriptor datoteke koristio za koje svrhe. Tako su s pomoću strace dobiveni rezultati prikazani iznad. Statistika vremena sinhronizacije potvrdila je da se pokazatelj wal_fsync_duration_seconds iz etcd podudara s pozivima fdatasync s datotečnim deskriptorima WAL.

Proučili smo dokumentaciju za fio i odabrali parametre za naš scenarij kako bi fio generirao opterećenje slično etcd. Također smo provjerili sistemske pozive i njihovo trajanje pokrećući fio iz strace, slično kao i etcd.

Pažljivo smo odabrali značenje parametra —size, koji predstavlja ukupno opterećenje ulaza-izlaza od fio. U našem slučaju to je ukupni broj bajtova zapisanih u pohranu. Ispostavilo se da je to direktno proporcionalno broju sistemskih poziva write (i fdatasync). Za određenu vrijednost bs, broj poziva fdatasync = size/bs. Budući da nas je zanimala percentila, trebali smo imati dovoljno uzoraka za pouzdanost, te smo izračunali da će nam biti dovoljno 10^4 (to je 22 mebibajta). Ako je —size manji, mogu se pojaviti izleti (na primjer, nekoliko poziva fdatasync traje dulje nego inače i utječe na 99. percentilu).

Pokušajte sami

P pokazali smo kako koristiti fio i provjeriti je li brzina pohrane dovoljna za visoke performanse etcd. Sada to možete isprobati sami, koristeći, na primjer, virtualne mašine s SSD pohranom u IBM Cloud.

Izvor: habr.com