Viteza de stocare potrivită pentru etcd? Să-l întrebăm pe fio

O scurtă poveste despre fio și etcd

Performanța clusterului etcd depinde în mare măsură de performanța stocării sale. etcd exportă unele valori către Prometeupentru a furniza informațiile de performanță de stocare dorite. De exemplu, valoarea wal_fsync_duration_seconds. Documentația pentru etcd spune: Pentru ca stocarea să fie considerată suficient de rapidă, percentila 99 a acestei valori trebuie să fie mai mică de 10 ms. Dacă intenționați să rulați un cluster etcd pe mașini Linux și doriți să evaluați dacă stocarea este suficient de rapidă (de exemplu, SSD), puteți utiliza fir este un instrument popular pentru testarea operațiunilor I/O. Rulați următoarea comandă, unde test-data este directorul de sub punctul de montare a stocării:

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

Trebuie doar să te uiți la rezultate și să verifici dacă percentila 99 a duratei fdatasync mai puțin de 10 ms. Dacă da, aveți o stocare destul de rapidă. Iată un exemplu de rezultate:

  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]

Notițe

• Am personalizat opțiunile --size și --bs pentru scenariul nostru particular. Pentru a obține un rezultat util de la fio, furnizați propriile valori. De unde să le iei? Citit cum am învățat să configuram fio.
• În timpul testării, toată sarcina I/O provine de la fio. Într-un scenariu din viața reală, probabil că vor veni și alte solicitări de scriere în stocare, în afară de cele legate de wal_fsync_duration_seconds. Încărcarea suplimentară va crește valoarea wal_fsync_duration_seconds. Deci, dacă percentila 99 este aproape de 10 ms, spațiul de stocare se epuizează.
• Luați versiunea fir nu mai mic de 3.5 (cele anterioare nu arată percentilele de durată fdatasync).
• Mai sus este doar un fragment din rezultatele de la fio.

Povestea lungă despre fio și etcd

Ce este WAL în etcd

De obicei se folosesc baze de date jurnal de scriere anticipată; etcd îl folosește și el. Nu vom discuta aici în detaliu despre jurnalul write-ahead (WAL). Este suficient să știm că fiecare membru al cluster-ului etcd îl menține în stocare persistentă. etcd scrie fiecare operație cheie-valoare (cum ar fi o actualizare) în WAL înainte de a o aplica în magazin. Dacă unul dintre membrii stocării se blochează și repornește între instantanee, acesta poate restabili local tranzacțiile de la ultimul instantaneu din conținutul WAL.

Când un client adaugă o cheie la magazinul de cheie-valoare sau actualizează valoarea unei chei existente, etcd înregistrează operația în WAL, care este un fișier obișnuit în stocare persistentă. etcd TREBUIE să fie complet sigur că intrarea WAL a avut loc de fapt înainte de a continua cu procesarea. Pe Linux, un apel de sistem nu este suficient pentru asta. scrie, deoarece scrierea efectivă pe stocarea fizică poate fi întârziată. De exemplu, Linux poate stoca o intrare WAL într-un cache din memoria kernelului (cum ar fi un cache al paginii) pentru ceva timp. Și pentru ca datele să fie scrise cu precizie pe stocarea persistentă, este nevoie de apelul de sistem fdatasync după scriere și etcd doar îl folosește (după cum puteți vedea în rezultatul lucrării strace, unde 8 este descriptorul fișierului WAL):

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>

Din păcate, scrierea în stocarea persistentă nu are loc instantaneu. Dacă apelul fdatasync este lent, performanța sistemului etcd va avea de suferit. Documentația pentru etcd spunecă stocarea este considerată suficient de rapidă dacă, în percentila 99, apelurile fdatasync durează mai puțin de 10 ms pentru a scrie în fișierul WAL. Există și alte valori utile pentru stocare, dar în această postare vorbim doar despre această măsurătoare.

Estimarea stocării cu fio

Dacă trebuie să evaluați dacă stocarea dvs. este potrivită pentru etcd, utilizați fio, un instrument foarte popular de testare a sarcinii I/O. Trebuie amintit că operațiunile pe disc pot fi foarte diferite: sincrone și asincrone, multe clase de apeluri de sistem etc. Ca urmare, fio este destul de dificil de utilizat. Are mulți parametri și diferite combinații ale valorilor acestora produc sarcini de lucru I/O foarte diferite. Pentru a obține cifre adecvate pentru etcd, ar trebui să vă asigurați că sarcina de scriere de test de la fio este cât mai aproape posibil de încărcarea reală de la etcd atunci când scrieți fișiere WAL.

Prin urmare, fio ar trebui, cel puțin, să creeze o încărcare a unei serii de scrieri secvențiale în fișier, fiecare scriere va consta dintr-un apel de sistem scrieurmat de apelul de sistem fdatasync. Scrierile secvențiale în fio necesită opțiunea --rw=write. Pentru ca fio să folosească apelul de sistem de scriere atunci când scrie, mai degrabă decât pscrie, ar trebui să specificați parametrul --ioengine=sync. În cele din urmă, pentru a apela fdatasync după fiecare scriere, trebuie să adăugați parametrul --fdatasync=1. Celelalte două opțiuni din acest exemplu (--size și -bs) sunt specifice scriptului. În secțiunea următoare, vă vom arăta cum să le configurați.

De ce fio și cum am învățat să o configuram

În această postare, descriem un caz real. Avem un cluster Kubernetes v1.13 pe care l-am monitorizat cu Prometheus. etcd v3.2.24 a fost găzduit pe un SSD. Valorile Etcd au arătat latențe fdatasync prea mari, chiar și atunci când clusterul nu făcea nimic. Valorile erau ciudate și nu știam cu adevărat ce înseamnă. Clusterul era format din mașini virtuale, era necesar să înțelegem care era problema: în SSD-urile fizice sau în stratul de virtualizare. În plus, am făcut adesea modificări la configurația hardware și software și aveam nevoie de o modalitate de a le evalua rezultatele. Am putea rula etcd în fiecare configurație și să ne uităm la valorile Prometheus, dar asta este o bătaie de cap. Căutăm o modalitate destul de simplă de a evalua o anumită configurație. Am vrut să verificăm dacă înțelegem corect valorile Prometheus din etcd.

Dar pentru aceasta trebuiau rezolvate două probleme. În primul rând, cum arată încărcarea I/O pe care etcd o creează atunci când scrie în WAL? Ce apeluri de sistem sunt folosite? Care este dimensiunea înregistrărilor? În al doilea rând, dacă răspundem la aceste întrebări, cum reproducem o sarcină de lucru similară cu fio? Nu uitați că fio este un instrument foarte flexibil, cu multe opțiuni. Am rezolvat ambele probleme cu o singură abordare - folosind comenzile lsof и strace. lsof listează toți descriptorii de fișier utilizați de proces și fișierele asociate acestora. Și cu strace, puteți examina un proces care rulează deja sau puteți începe un proces și îl examinați. strace tipărește toate apelurile de sistem din procesul examinat (și procesele sale secundare). Acesta din urmă este foarte important, deoarece etcd adoptă o abordare similară.

Am folosit mai întâi strace pentru a explora serverul etcd pentru Kubernetes când nu era încărcare pe cluster. Am văzut că aproape toate înregistrările WAL aveau aproximativ aceeași dimensiune: 2200–2400 de octeți. Prin urmare, în comanda de la începutul postării, am specificat parametrul -bs=2300 (bs înseamnă dimensiunea în octeți pentru fiecare intrare fio). Rețineți că dimensiunea intrării etcd depinde de versiunea etcd, distribuție, valorile parametrilor etc. și afectează durata fdatasync. Dacă aveți un scenariu similar, examinați-vă procesele etcd cu strace pentru a afla numerele exacte.

Apoi, pentru a ne face o idee bună despre ce face sistemul de fișiere etcd, l-am început cu opțiunile strace și -ffttT. Așa că am încercat să examinăm procesele secundare și să înregistrăm rezultatul fiecăruia dintre ele într-un fișier separat și, de asemenea, să obținem rapoarte detaliate despre începutul și durata fiecărui apel de sistem. Am folosit lsof pentru a confirma analiza noastră a ieșirii strace și pentru a vedea ce descriptor de fișier a fost folosit în ce scop. Deci, cu ajutorul strace, s-au obținut rezultatele prezentate mai sus. Statisticile privind timpul de sincronizare au confirmat că wal_fsync_duration_seconds de la etcd este în concordanță cu apelurile fdatasync cu descriptori de fișiere WAL.

Am parcurs documentația pentru fio și am ales opțiuni pentru scriptul nostru, astfel încât fio să genereze o încărcare similară cu etcd. De asemenea, am verificat apelurile de sistem și durata lor, rulând fio din strace, similar cu etcd.

Am ales cu atenție valoarea parametrului --size pentru a reprezenta întreaga sarcină I/O din fio. În cazul nostru, acesta este numărul total de octeți scriși în stocare. S-a dovedit a fi direct proporțional cu numărul de apeluri de sistem de scriere (și fdatasync). Pentru o anumită valoare a bs, numărul de apeluri fdatasync = size/bs. Deoarece eram interesați de percentilă, trebuia să avem suficiente mostre pentru a fi siguri și am calculat că 10^4 ne-ar fi de ajuns (adică 22 de mebibytes). Dacă --size este mai mic, pot apărea valori aberante (de exemplu, mai multe apeluri fdatasync durează mai mult decât de obicei și afectează percentila 99).

Incearca-l tu insuti

V-am arătat cum să utilizați fio și să vedeți dacă stocarea este suficient de rapidă pentru ca etcd să funcționeze bine. Acum îl puteți încerca singur, folosind, de exemplu, mașini virtuale cu stocare SSD IBM Cloud.

Sursa: www.habr.com