🥇Este viteza stocării potrivită pentru etcd? Întreabă fio

O scurtă poveste despre fio și etcd

Performanța clusterului etcd depinde în mare măsură de performanța stocării acestuia. etcd exportă unele metrici în Prometheus, pentru a oferi informațiile necesare despre performanța stocării. De exemplu, metrici precum wal_fsync_duration_seconds. În documentația etcd se menționează: pentru ca stocarea să fie considerată suficient de rapidă, percentila a 99-a a acestei metrici 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 dvs. este suficient de rapidă (de exemplu, SSD), puteți utiliza fio — un instrument popular pentru testarea operațiunilor de intrare-ieșire. Rulați următoarea comandă, unde test-data este directorul sub punctul de montare al stocării:

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

Trebuie doar să verificați rezultatele și să vă asigurați că percentila a 99-a a duratei fdatasync este mai mică de 10 ms. Dacă da, aveți o stocare suficient de rapidă. Iată un exemplu de rezultate:

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

Note

Am configurat valorile parametrilor —size și —bs pentru scenariul nostru specific. Pentru a obține un rezultat util de la fio, specificați valorile dvs. De unde le obțineți? Citiți, cum am învățat să configurăm fio.
În timpul testării, întreaga sarcină de intrare-ieșire provine de la fio. Într-un scenariu real, este foarte probabil ca stocarea să primească și alte solicitări de scriere, pe lângă cele legate de wal_fsync_duration_seconds. Sarcina suplimentară va crește valoarea wal_fsync_duration_seconds. Așadar, dacă percentila a 99-a este aproape de 10 ms, stocarea dvs. nu va avea suficientă viteză.
Utilizați versiunea fio de 3.5 sau mai recentă (versiunile anterioare nu arată percentilile duratei fdatasync).
Mai sus este prezentat doar un fragment de rezultate de la fio.

O poveste lungă despre fio și etcd

Ce este WAL în etcd

În mod obișnuit, bazele de date folosesc jurnalul de scriere anticipată; etcd îl folosește și el. Aici nu vom discuta în detaliu despre jurnalul scrierilor anticipate (write-ahead log, WAL). Este suficient să știm că fiecare membru al clusterului etcd îl menține într-un depozit permanent. etcd înregistrează fiecare operațiune cu perechi cheie-valoare (de exemplu, actualizări) în WAL înainte de a le aplica în depozit. Dacă între instantanee unul dintre membrii depozitului se oprește brusc și se repornește, el poate recupera local tranzacțiile de la ultima instantanee din conținutul WAL.

Atunci când un client adaugă o cheie în depozitul de perechi cheie-valoare sau actualizează valoarea unei chei existente, etcd face o înregistrare a acestei operațiuni în WAL, care este un fișier obișnuit în depozitul permanent. Înainte de a continua procesarea, etcd TREBUIE să fie complet sigur că înregistrarea în WAL s-a realizat cu adevărat. În Linux, o singură apelare a sistemului nu este suficientă. write, deoarece în mod efectiv, înregistrarea în depozitul fizic poate fi întârziată. De exemplu, Linux poate păstra o perioadă de timp înregistrarea WAL în cache-ul memoriei nucleului (de exemplu, în cache-ul paginilor). Iar pentru ca datele să fie cu adevărat scrise în depozitul permanent, este necesar un apel de sistem fdatasync după scriere, iar etcd tocmai folosește acest apel (așa cum se poate observa în rezultatul execuției strace, unde 8 este descriptorul fișierului 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

Din păcate, înregistrarea în depozitul permanent nu se realizează instantaneu. Dacă apelul fdatasync funcționează lent, performanța sistemului etcd scade. Documentația despre etcd afirmă, că depozitul este considerat suficient de rapid dacă în 99% din apeluri, fdatasync la scrierea în fișierul WAL durează mai puțin de 10 ms. Există și alte metrici utile pentru depozit, dar în această postare discutăm doar despre această metrică.

Evaluarea depozitului cu ajutorul fio

Dacă trebuie să evaluați dacă stocarea dvs. este potrivită pentru etcd, folosiți fio - un instrument de testare a încărcăturii de intrare-ieșire foarte popular. Este important să rețineți că operațiile pe disc pot fi foarte variate: sincrone și asincrone, cu numeroase clase de apeluri de sistem etc. Drept urmare, fio este destul de complicat de utilizat. Acesta are o mulțime de parametrii, iar combinațiile diferitelor valori pot produce încărcături de intrare-ieșire complet diferite. Pentru a obține cifre adecvat pentru etcd, asigurați-vă că încărcătura de test scrisă de fio este cât mai aproape de încărcătura reală a etcd la scrierea fișierelor WAL.

Prin urmare, fio ar trebui, cel puțin, să genereze o încărcătură sub formă de serie de operații de scriere în fișier, fiecare scriere constituind un apel de sistem write, urmat de un apel de sistem fdatasync. Pentru operațiile de scriere secvențiale, fio are nevoie de parametrul -rw=write. Pentru ca fio să folosească apelul de sistem write la scriere, nu pwrite, trebuie specificat parametrul -ioengine=sync. În cele din urmă, pentru ca fdatasync să fie apelat după fiecare scriere, trebuie adăugat parametrul -fdatasync=1. Celelalte două parameții din acest exemplu (-size și -bs) depind de scenariul specific. În secțiunea următoare, vom vorbi despre cum să le configurăm.

De ce anume fio și cum am învățat să-l configurăm

În această postare descriem un caz real. Am avut un cluster Kubernetes v1.13, pe care l-am monitorizat cu Prometheus. etcd v3.2.24 era găzduit pe SSD. Metricile pentru etcd arătau întârzieri prea mari pentru fdatasync, chiar și atunci când clusterul nu făcea nimic. Metricile erau ciudate și nu știam exact ce înseamnă. Clusterul era format din mașini virtuale, trebuia să înțelegem care era problema: în SSD-urile fizice sau în stratul de virtualizare. De asemenea, făceam frecvent modificări în configurația hardware și software, și aveam nevoie de o modalitate de a evalua rezultatul acestora. Puteam rula etcd în fiecare configurație și să ne uităm la metricile Prometheus, dar era prea complicat. Căutam o modalitate suficient de simplă de a evalua o configurație specifică. Voint să putem verifica dacă înțelegem corect metricile Prometheus de la etcd.

Dar pentru aceasta a fost necesar să rezolvăm două probleme. În primul rând, cum arată sarcina de intrare-ieșire pe care etcd o generează la scrierea în WAL? Ce apeluri de sistem sunt utilizate? Care este dimensiunea înregistrărilor? În al doilea rând, dacă vom răspunde la aceste întrebări, cum putem reproduce o sarcină de lucru similară cu fio? Nu uitați că fio este un instrument foarte flexibil cu multe parametrei. Am rezolvat ambele probleme printr-o abordare — folosind comenzi. lsof și strace. lsof afișează toate descriptorii de fișiere utilizați de proces și fișierele conexe. Iar cu ajutorul strace se poate studia un proces deja pornit sau să se pornească un proces și să se studieze. strace afișează toate apelurile de sistem din partea procesului studiat (și a proceselor sale fiice). Ultimul aspect este foarte important, deoarece etcd aplică exact acest tip de abordare.

Primul lucru pe care l-am folosit a fost strace pentru a studia serverul etcd pentru Kubernetes, când clusterul nu avea încărcare. Am observat că aproape toate înregistrările WAL erau de aproximativ aceeași dimensiune: 2200–2400 de biti. De aceea, în comanda din începutul articolului, am specificat parametrul —bs=2300 (bs înseamnă dimensiunea în biți pentru fiecare înregistrare fio). Rețineți că dimensiunea înregistrării etcd depinde de versiunea etcd, livrarea, valorile parametrilor etc. și influențează durata fdatasync. Dacă aveți un scenariu similar, analizați procesele dvs. etcd cu ajutorul strace pentru a obține cifrele exacte.

Apoi, pentru a avea o imagine mai clară a acțiunilor în sistemul de fișiere etcd, am pornit-o cu strace și cu parametrii -ffttT. Astfel, am încercat să studiem procesele fiice și să înregistrăm ieșirile fiecăruia în fișiere separate, dar și să obținem rapoarte detaliate despre începutul și durata fiecărui apel de sistem. Am folosit lsof pentru a confirma analiza ieșirilor strace și a vedea pentru ce scopuri a fost utilizat fiecare descriptor de fișier. Astfel, cu ajutorul strace, am obținut rezultatele prezentate mai sus. Statistica timpului de sincronizare a confirmat că indicatorul wal_fsync_duration_seconds din etcd corespunde apelurilor fdatasync cu descriptorii de fișiere WAL.

Am studiat documentația fio și am ales parametrii pentru scenariul nostru, astfel încât fio să genereze o sarcină similară cu etcd. De asemenea, am verificat apelurile de sistem și durata acestora, rulând fio din strace, la fel ca în cazul etcd.

Am selectat cu atenție semnificația parametrului —size, care reprezintă întreaga sarcină de intrare-ieșire de la fio. În cazul nostru, acest lucru se referă la numărul total de octeți scriși în stocare. A rezultat direct proporțional cu numărul de apeluri de sistem write (și fdatasync). Pentru o anumită valoare a bs, numărul de apeluri fdatasync = size/bs. Deoarece ne interesa percentilul, trebuia să avem suficiente mostre pentru validitate, iar noi am calculat că 10^4 (aproximativ 22 de mebibai) ar fi suficiente. Dacă —size este mai mic, pot apărea anomalii (de exemplu, câteva apeluri fdatasync durează mai mult decât de obicei și afectează percentilul 99).

Încercați singuri

Am arătat cum se folosește fio și cum să verifici dacă viteza stocării este suficientă pentru performanța ridicată a etcd. Acum poți încerca acest lucru în practică tu însuți, folosind, de exemplu, mașini virtuale cu stocare SSD în IBM Cloud.

Sursa: habr.com