🥇Cumu cuntrollà i dischi cù fio per un rendimentu abbastanza per etcd

Nota. transl.: Questu articulu hè u risultatu di una mini-ricerca realizata da l'ingegneri IBM Cloud in cerca di una suluzione à un veru prublema liatu à l'operazione di a basa di dati etcd. Un compitu simili era pertinente per noi, però, u cursu di riflessioni è l'azzioni di l'autori pò esse interessanti in un cuntestu più largu.

Breve riassuntu di l'articulu sanu: fio è etcd

U rendiment di un cluster etcd hè assai dipendente da a velocità di l'almacenamiento sottostanti. etcd esporta diverse metriche Prometheus per monitorizà u rendiment. Unu di elli hè wal_fsync_duration_seconds. In a documentazione per etcd dicequellu almacenamentu pò esse cunsideratu abbastanza veloce se u percentile 99 di sta metrica ùn supera micca 10 ms ...

Se pensate di creà un cluster etcd in macchine Linux è vulete verificà se i dischi (cum'è SSD) sò abbastanza veloci, ricumandemu d'utilizà u famosu tester I / O chjamatu. fio. Hè abbastanza per eseguisce u cumandimu seguitu (directory test-data deve esse situatu in a partizione muntata di l'unità testata):

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

Resta solu à guardà l'output è verificate se u percentile 99 si adatta fdatasync in 10 ms. Sì cusì, allora a vostra unità funziona abbastanza veloce. Eccu un esempiu di output:

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]

Uni pochi note:

In l'esempiu sopra, avemu aghjustatu i paràmetri --size и --bs per un casu specificu. Per ottene un risultatu significativu da fio, specificate i valori adattati per u vostru casu d'usu. Cumu sceglie elli serà discutitu quì sottu.
Solu durante a prova fio carica u sottosistema di discu. In a vita reale, hè prubabile chì altri prucessi scriveranu à u discu (oltre quelli chì sò ligati à wal_fsync_duration_seconds). Questa carica supplementaria pò aumentà wal_fsync_duration_seconds. In altri palori, se u percentile 99 da a prova cù fio, solu un pocu menu di 10 ms, ci hè una bona chance chì u rendiment di almacenamiento ùn hè micca abbastanza.
Per a prova avete bisognu di a versione fio micca menu di 3.5perchè e versioni più vechje ùn aghjunghjenu micca risultati fdatasync in forma di percentili.
A cunclusione sopra hè solu una piccula parte di a cunclusione generale fio.

Più nantu à fio è etcd

Uni pochi parolle nantu à WALs etcd

In generale, a basa di dati usa logging proattivu (Logging in scrittura anticipata, WAL). etcd hè ancu affettatu. Una discussione di WAL hè fora di u scopu di questu articulu, ma per i nostri scopi, ciò chì avete bisognu di sapè hè chì ogni membru di u cluster etcd almacena WAL in un almacenamiento persistente. etcd scrive alcune operazioni di almacenamentu di u valore chjave (cum'è l'aghjurnamenti) à WAL prima di eseguisce. Se un node crashs and restarts between snapshots, etcd pò ricuperà e transazzione da a snapshot precedente basatu annantu à u cuntenutu di u WAL.

Cusì, ogni volta chì un cliente aghjunghje una chjave à a tenda KV o aghjurnà u valore di una chjave esistente, etcd aghjunghje a descrizzione di l'operazione à u WAL, chì hè un schedariu regulare in a tenda persistente. etcd DEVE esse 100% sicuru chì l'entrata WAL hè stata salvata prima di prucede. Per ottene questu in Linux, ùn hè micca abbastanza per utilizà a chjama di u sistema write, postu chì l'operazione di scrittura stessu à i media fisichi pò esse ritardata. Per esempiu, Linux pò mantene una entrata WAL in una cache di kernel in memoria (per esempiu, in a cache di pagina) per qualchì tempu. Per assicurà chì e dati sò scritti à i media, una chjama di u sistema deve esse invucata dopu a scrittura fdatasync - questu hè esattamente ciò chì etcd faci (cum'è pudete vede in a seguente output strace; Quì 8 - Descrizzione di u schedariu WAL):

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>

Sfurtunatamente, scrive à un almacenamentu persistente piglia un pocu di tempu. Esecuzione prolongata di e chjama di fdatasync pò influenzà u rendiment di etcd. In a documentazione di u repository indicatu, chì per un rendimentu abbastanza hè necessariu chì u percentile 99 di a durata di tutte e chjama fdatasync quandu scrive à un schedariu WAL era menu di 10 ms. Ci sò altre metriche relative à l'almacenamiento, ma questu articulu hà da fucalizza nantu à quellu.

Valorizà u almacenamentu cù fio

Pudete valutà se un certu almacenamentu hè adattatu per l'usu cù etcd usendu l'utilità fio - un tester I/O populari. Tenite in mente chì l'I / O di u discu pò accade in parechje manere diverse: sync / async, parechje classi syscall diffirenti, è cusì. L'altra parte di a munita hè quella fio estremamente difficiule à aduprà. L'utilità hà parechji paràmetri, è diverse cumminazzioni di i so valori portanu à risultati completamente differenti. Per ottene una stima raghjone per etcd, avete bisognu di assicurà chì a carica di scrittura generata da fio hè u più vicinu pussibule à a carica di scrittura di u file WAL di etcd:

Questu significa chì u generatu fio a carica deve esse almenu una seria di scrittura consecutiva à u schedariu, induve ogni scrittura hè custituita da una chjama di sistema writeseguita da fdatasync.
Per attivà a scrittura sequenziale, deve specificà a bandiera --rw=write.
chì fio hà scrittu cù e chjama write (piuttostu cà altre chjama di u sistema - per esempiu, pwrite), aduprà a bandiera --ioengine=sync.
Infine, a bandiera --fdatasync=1 assicura chì ogni write duverebbe fdatasync.
L'altri dui parametri in u nostru esempiu sò: --size и --bs - pò varià secondu u casu d'usu specificu. A prossima sezione descriverà a so cunfigurazione.

Perchè avemu sceltu fio è cumu avemu amparatu à mette in opera

Questa nota vene da un casu reale chì avemu scontru. Avemu avutu un cluster in Kubernetes v1.13 cù monitorizazione in Prometheus. I SSD sò stati usati cum'è almacenamiento per etcd v3.2.24. E metriche di Etcd anu mostratu latenze troppu elevate fdatasync, ancu quandu u cluster era inattivu. À noi, sti metrichi parevanu assai dubbiosi, è ùn eramu micca sicuri di ciò chì esattamente rapprisentanu. Inoltre, u cluster era custituitu di machini virtuali, cusì ùn era micca pussibule di dì chì u ritardu era duvuta à a virtualizazione o l'SSD era culpèvule.

Inoltre, avemu cunsideratu diversi cambiamenti in a cunfigurazione hardware è software, cusì avemu bisognu di un modu per evaluà. Di sicuru, saria pussibule di eseguisce etcd in ogni cunfigurazione è fighjate à e metriche Prometheus currispundenti, ma questu averebbe bisognu di un sforzu significativu. Ciò chì avemu bisognu era un modu simplice per valutà una cunfigurazione specifica. Vulemu pruvà a nostra cunniscenza di e metriche di Prometheus chì venenu da etcd.

Questu hà bisognu di risolve dui prublemi:

Prima, quale hè a carica I / O generata da etcd quandu si scrive à i schedari WAL? Chì chjamate sistema sò utilizati? Chì ghjè a dimensione di i blocchi di discu?
Siconda, dicemu chì avemu risposte à e dumande sopra. Cumu ripruduce a carica currispondente cù fio? Malgradu tuttu fio - utilità estremamente flessibile cù una bundanza di parametri (questu hè faciule di verificà, per esempiu, ccà - ca. trad.).

Avemu risoltu i dui prublemi cù u listessu approcciu basatu in cumandamenti lsof и strace:

Cù l'aiutu di lsof pudete vede tutti i descriptori di i schedari utilizati da u prucessu, è ancu i schedarii à quale si riferiscenu.
Cù l'aiutu di strace pudete analizà un prucessu digià in esecuzione o eseguite un prucessu è fighjate. U cumandamentu mostra tutte e chjama di u sistema fatta da stu prucessu è, se ne necessariu, i so discendenti. L'ultime hè impurtante per i prucessi chì sò forking, è etcd hè un tali prucessu.

A prima cosa chì avemu fattu era di utilizà strace per esaminà u servitore etcd in u cluster Kubernetes mentre era inattivu.

Cusì hè statu truvatu chì i blocchi di record WAL sò assai densamente raggruppati, a dimensione di a maiuranza era in a gamma di 2200-2400 bytes. Hè per quessa chì u cumandamentu à u principiu di stu articulu usa a bandiera --bs=2300 (bs hè a dimensione in byte di ogni bloccu di scrittura in fio).

Per piacè nutate chì a dimensione di i blocchi di scrittura etcd pò varià secondu a versione, implementazione, valori di parametri, etc. - influenza a durata fdatasync. Sè avete un casu d'usu simili, analizà cun strace i vostri prucessi etcd pè ottene valori up-to-date.

Dopu, per avè una idea chjara è cumpleta di cumu funziona etcd cù u sistema di fugliale, avemu principiatu da sottu. strace cù bandiere -ffttT. Questu hà permessu di catturà i prucessi di i zitelli è di scrive l'output di ognunu in un schedariu separatu. Inoltre, infurmazione dettagliata nantu à l'ora di iniziu è a durata di ogni chjama di u sistema hè stata ottenuta.

Avemu ancu usatu u cumandamentu lsofper cunfirmà a vostra cunniscenza di u output strace in quantu à quale descriptore di u schedariu hè stata utilizata per quale scopu. Aghju avutu a cunclusione strace, simile à quellu sopra. Manipulazioni statistiche cù i tempi di sincronizazione cunfirmatu chì a metrica wal_fsync_duration_seconds da etcd matchs calls fdatasync cù descrittori di file WAL.

Per generà cun fio una carica di travagliu simile à quella da etcd, a documentazione di l'utilità hè stata studiata è i paràmetri adattati per u nostru compitu sò stati scelti. Avemu verificatu chì i chjami di u sistema curretti sò in prugressu è cunfirmatu a so durata in esecuzione fio из strace (cum'è hè statu fattu in casu di etcd).

Una attenzione particulari hè stata pagata à determinà u valore di u paràmetru --size. Rapprisenta a carica totale I/O generata da l'utilità fio. In u nostru casu, questu hè u numeru tutale di bytes scritti à i media. Hè direttamente proporzionale à u numeru di chjama write (è fdatasync). Per un specificu bs numeru di chjama fdatasync ugguali size / bs.

Siccomu eramu interessatu in u percentile, vulemu chì u numeru di campioni sia abbastanza grande per esse statisticamente significativu. È decisu chì 10^4 (chì currisponde à una dimensione di 22 MB) basterà. Valori di parametri più chjuchi --size hà datu un sonu più forte (per esempiu, chjama fdatasync, chì piglianu assai più di l'abitudine è affettanu u percentile 99).

Tocca à tè

L'articulu mostra cumu utilizà fio unu pò ghjudicà s'ellu i media destinati à aduprà cù etcd hè abbastanza veloce. Avà tocca à voi ! Pudete scopre e macchine virtuali cù almacenamiento basatu in SSD in u serviziu IBM Cloud.

PS da u traduttore

Cù casi d'usu pronti fio Per altri compiti, vede ducumentazione o direttamente à repository di prughjettu (Ci sò assai più di quelli chì sò citati in a ducumentazione).

PPS da u traduttore

Leghjite puru nant'à u nostru blog:

Source: www.habr.com

Cumu verificà i dischi cù fio per un rendimentu sufficiente per etcd