🥇Hoe kinne jo disks mei fio kontrolearje op genôch prestaasjes foar etcd

Noat. transl.: Dit artikel is de resultaten fan in mini-ûndersyk útfierd troch IBM Cloud-yngenieurs op syk nei in oplossing foar in echte probleem yn ferbân mei de wurking fan 'e etcd-database. In soartgelikense taak wie foar ús relevant, mar de gong fan gedachten en hanneljen fan de skriuwers kin ynteressant wêze yn in bredere kontekst.

Koarte gearfetting fan it hiele artikel: fio en ensfh

De prestaasjes fan in etcd-kluster is tige ôfhinklik fan de snelheid fan 'e ûnderlizzende opslach. Om prestaasjes te kontrolearjen, eksportearret etcd ferskate Prometheus-metriken. Ien fan harren is wal_fsync_duration_seconds. Yn de etcd dokumintaasje der stiet, dat opslach rap genôch beskôge wurde kin as it 99e percentile fan dizze metrike net mear as 10 ms is ...

As jo beskôgje it ynstellen fan in etcd-kluster op Linux-masines en wolle testen oft opslachskiven (lykas SSD's) fluch genôch binne, riede wy oan om in populêre I/O-tester te brûken mei de namme fio. Rin gewoan it folgjende kommando (directory test-data moat lizze yn 'e monteare partysje fan' e drive dy't wurdt hifke):

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

It bliuwt allinich om nei de útfier te sjen en te kontrolearjen oft it past by de 99e percentile fdatasync op 10 ms. As dat sa is, dan is jo ryd rap genôch. Hjir is in foarbyldútfier:

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]

In pear notysjes:

Yn it boppesteande foarbyld hawwe wy de parameters oanpast --size и --bs foar in spesifyk gefal. Om sinfolle resultaten te krijen fan fio, spesifisearje wearden dy't passend binne foar jo gebrûk. Hoe't se kieze sille hjirûnder besprutsen wurde.
Allinich tidens testen fio laadt it skiif subsysteem. Yn it echte libben is it wierskynlik dat oare prosessen (njonken dyjingen dy't ferbûn binne mei wal_fsync_duration_seconds). Sa'n ekstra lading kin liede ta in tanimming fan wal_fsync_duration_seconds. Mei oare wurden, as de 99e percentile krigen fan testen mei fio, mar in bytsje minder as 10 ms, der is in goede kâns dat de opslach prestaasjes is net genôch.
Foar de test sille jo de ferzje nedich hawwe fio net minder as 3.5, om't âldere ferzjes gjin resultaten sammelje fdatasync yn 'e foarm fan percentiles.
De boppesteande konklúzje is mar in lyts úttreksel fan 'e algemiene konklúzje fio.

Details oer fio en ensfh

In pear wurden oer WALs ensfh

Typysk brûke databases proaktyf logging (Write-ahead logging, WAL). etcd dat jildt ek. In diskusje oer WAL is bûten it berik fan dit artikel, mar foar ús doelen is hjir wat jo witte moatte: Elk lid fan it etcd-kluster bewarret WAL yn persistente opslach. etcd skriuwt guon kaai-wearde winkel operaasjes (lykas updates) nei WAL foardat se útfiere. As in knooppunt crasht en opnij begjint tusken snapshots, kin etcd transaksjes weromsette útfierd sûnt de foarige snapshot basearre op de ynhâld fan 'e WAL.

Sa foeget elke kear in kliïnt in kaai ta oan 'e KV-winkel of fernijt de wearde fan in besteande kaai, ensfh. etcd MOET 100% wis wêze dat de WAL-yngong feitlik bewarre is foardat jo trochgean. Om dit op Linux te berikken, is it net genôch om in systeemoprop te brûken write, sûnt de skriuwoperaasje sels nei it fysike medium kin fertrage wurde. Linux kin bygelyks in WAL-yngong yn in kernel-cache yn it ûnthâld hâlde (lykas de side-cache) foar in skoft. Om te soargjen dat gegevens nei de media skreaun wurde, moat in systeemoprop nei it skriuwen oproppen wurde fdatasync - dit is krekt wat etcd docht (lykas kin wurde sjoen yn 'e folgjende útfier strace; Hjir 8 - WAL-bestânhandtak):

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>

Spitigernôch nimt it skriuwen nei persistente opslach wat tiid. In lange tiid nimme om de fdatasync-oprop te foltôgjen kin ynfloed hawwe op etcd-prestaasjes. Yn de dokumintaasje foar de repository oanjûndat foar genôch prestaasjes is it nedich dat de 99e percentile fan 'e doer fan alle oproppen fdatasync by it skriuwen nei in bestân wie WAL minder dan 10 ms. D'r binne oare metriken yn ferbân mei opslach, mar dit artikel sil rjochtsje op dizze.

Evaluearje opslach mei help fan fio

Jo kinne evaluearje oft in bepaalde opslach is geskikt foar gebrûk mei etcd mei help fan it nut fio - in populêre I/O-tester. Hâld der rekken mei dat skiif I / O kin barre op ferskate manieren: syngronisaasje / async, in protte ferskillende klassen fan systeem calls, etc. De oare kant fan 'e munt is dat fio ekstreem lestich te brûken. It nut hat in protte parameters, en ferskate kombinaasjes fan har wearden liede ta folslein oare resultaten. Om in ridlike skatting foar etcd te krijen, moatte jo derfoar soargje dat de skriuwlading generearre troch fio sa ferlykber is as de skriuwlading fan etcd nei WAL-bestannen:

Dit betsjut dat de generearre fio de wurkdruk moat op syn minst in searje sekwinsjele skriuwwizen nei in bestân wêze, wêrby't elke skriuwoperaasje bestiet út in systeemoprop writefolge troch fdatasync.
Om sekwinsjele opname yn te skeakeljen, moatte jo de flagge opjaan --rw=write.
dat fio skreau mei help fan oproppen write (en net oare systeemoproppen - bygelyks, pwrite), brûk de flagge --ioengine=sync.
As lêste, de flagge --fdatasync=1 garandearret dat efter eltse write moat wêze fdatasync.
Twa oare parameters yn ús foarbyld: --size и --bs - kin fariearje ôfhinklik fan it spesifike gebrûk gefal. De folgjende paragraaf sil beskriuwe hoe't jo se konfigurearje.

Wêrom hawwe wy foar fio keazen en hoe't wy learden hoe't wy it ynstelle

Dizze notysje komt út in echte saak dy't wy tsjinkamen. Wy hiene in kluster op Kubernetes v1.13 mei tafersjoch op Prometheus. Solid state driuwfearren waarden brûkt as opslach foar etcd v3.2.24. etcd metriken lieten te hege latencies sjen fdatasync, sels as it kluster idle wie. Wy fûnen dizze metriken heul twifelich en wy wiene net wis wat se krekt fertsjintwurdige. Dêrnjonken bestie it kluster út firtuele masines, sadat it ûnmooglik wie om te fertellen oft de fertraging troch virtualisaasje wie of de SSD's skuldich wiene.

Derneist sochten wy ferskate feroarings oan hardware- en softwarekonfiguraasjes, dus wy hiene in manier nedich om se te evaluearjen. Fansels soe it mooglik wêze om te rinnen etcd yn elke konfiguraasje en sjoch op de oerienkommende Prometheus metrics, mar dit soe easkje wichtige ynspannings . Wy hiene in ienfâldige manier nedich om in spesifike konfiguraasje te evaluearjen. Wy woenen ús begryp testen fan Prometheus-metriken dy't komme fan etcd.

Om dit te dwaan, moasten twa problemen oplost wurde:

Earst, wat sjocht de I/O-lading dy't ensfh genereart by it skriuwen nei WAL-bestannen derút? Hokker systeemoproppen wurde brûkt? Wat is de skriuwblokgrutte?
As twadde, lit ús sizze dat wy antwurden hawwe op 'e boppesteande fragen. Hoe reprodusearje de oerienkommende lading mei fio? Einsluten fio - ekstreem fleksibel nut mei in protte parameters (dit is maklik te ferifiearjen, bygelyks, hjir — ca. oerset.).

Wy hawwe beide problemen oplost mei deselde kommando-basearre oanpak lsof и strace:

Mei help fan lsof Jo kinne alle triembeskriuwers besjen dy't brûkt wurde troch in proses, lykas de bestannen wêr't se nei ferwize.
Mei help fan strace jo kinne in al rinnend proses analysearje of in proses útfiere en it observearje. It kommando toant alle systeemoproppen makke troch dit proses en, opsjoneel, syn neiteam. Dat lêste is wichtich foar prosessen dy't forking, en etcd is ien fan sokke prosessen.

It earste wat wy diene wie gebrûk strace om de etcd-tsjinner yn it Kubernetes-kluster te studearjen wylst it idle wie.

Sa waard ûntdutsen dat de skriuwblokken yn WAL tige ticht groepearre binne, de mearderheid dêrfan is yn it berik fan 2200-2400 bytes. Dit is de reden dat it kommando oan it begjin fan dit artikel de flagge brûkt --bs=2300 (bs - grutte yn bytes fan elk opnameblok yn fio).

Tink derom dat etcd-skriuwblokgrutte kin ferskille ôfhinklik fan ferzje, ynset, parameterwearden, ensfh. - dit hat ynfloed op de doer fdatasync. As jo in ferlykbere gebrûk gefal, analysearje mei strace jo etcd-prosessen om de lêste wearden te krijen.

Dan, om in dúdlik en wiidweidich begryp te krijen fan hoe't etcd wurket mei it bestânsysteem, rûnen wy it fan ûnder strace mei flaggen -ffttT. Dit makke it mooglik om de bernprosessen te fangen en de útfier fan elk te skriuwen nei in apart bestân. Derneist waard detaillearre ynformaasje krigen oer it begjinmomint en de doer fan elke systeemoprop.

Wy hawwe ek it kommando brûkt lsofom jo begryp fan 'e útfier te befêstigjen strace yn termen fan hokker triem descriptor waard brûkt foar hokker doel. It resultaat wie strace, fergelykber mei de hjirboppe. Statistyske manipulaasjes mei syngronisaasje kear befêstige dat de metryske wal_fsync_duration_seconds út etcd matches calls fdatasync mei WAL triem descriptors.

Om te generearjen mei help fio wurkdruk fergelykber mei de lading fan etcd, de nutsdokumintaasje waard bestudearre en parameters geskikt foar ús taak waarden selektearre. Wy hawwe derfoar soarge dat de juste systeemoproppen belutsen wiene en befêstige har doer troch te rinnen fio fan strace (lykas dien waard yn it gefal fan ensfh).

Bysûnder omtinken waard bestege oan it bepalen fan de wearde fan de parameter --size. It fertsjintwurdiget de totale I/O-load generearre troch it fio-hulpprogramma. Yn ús gefal is dit it totale oantal bytes skreaun nei de media. It is direkt evenredich mei it oantal oproppen write (en fdatasync). Foar in bepaalde bs oantal oproppen fdatasync lykweardich size / bs.

Om't wy ynteressearre wiene yn percentile, sochten wy derfoar te soargjen dat it oantal samples grut genôch wie foar statistyske betsjutting. En dat besletten se 10^4 (dat komt oerien mei in grutte fan 22 MB) sil genôch wêze. Lytsere parameter wearden --size produsearre mear útsprutsen lûd (bygelyks oproppen fdatasync, dy't folle langer duorje dan normaal en beynfloedzje de 99e percentile).

It is oan dy

It artikel lit sjen hoe te brûken fio jo kinne evaluearje oft de media bedoeld foar gebrûk mei etcd is fluch genôch. No is it oan dy! Jo kinne firtuele masines ferkenne mei SSD-basearre opslach yn 'e tsjinst IBM Cloud.

PS fan oersetter

Mei klearmakke foarbylden fan gebrûk fio foar it oplossen fan oare problemen kinne fûn wurde yn dokumintaasje of direkt oan projekt repositories (dêr binne der folle mear fan dan yn de dokumintaasje neamd wurde).

PPS fan oersetter

Lês ek op ús blog:

Boarne: www.habr.com

Hoe te kontrolearjen skiven mei fio foar genôch prestaasjes foar etcd