Shpejtësia e ruajtjes e përshtatshme për etcd? Le të pyesim fio

Një histori e shkurtër për fio dhe etj

Performanca e grupit etj në masë të madhe varet nga performanca e ruajtjes së tij. etjd eksporton disa metrika në Prometeupër të siguruar informacionin e dëshiruar të performancës së ruajtjes. Për shembull, metrika wal_fsync_duration_seconds. Dokumentacioni për etcd thotë: Që ruajtja të konsiderohet mjaft e shpejtë, përqindja e 99-të e kësaj metrike duhet të jetë më e vogël se 10 ms. Nëse po planifikoni të ekzekutoni një grup etcd në makinat Linux dhe dëshironi të vlerësoni nëse ruajtja juaj është mjaft e shpejtë (si një SSD), mund të përdorni Fio është një mjet popullor për testimin e operacioneve I/O. Ekzekutoni komandën e mëposhtme, ku të dhënat e testit janë drejtoria nën pikën e montimit të ruajtjes:

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

Thjesht duhet të shikoni rezultatet dhe të kontrolloni se përqindja e 99-të e kohëzgjatjes fdatasync më pak se 10 ms. Nëse po, ju keni ruajtje mjaft të shpejtë. Këtu është një shembull i rezultateve:

  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]

Shënimet

• Ne kemi përshtatur opsionet --size dhe --bs për skenarin tonë të veçantë. Për të marrë një rezultat të dobishëm nga fio, jepni vlerat tuaja. Ku t'i merrni ato? Lexoni si kemi mësuar të konfigurojmë fio.
• Gjatë testimit, e gjithë ngarkesa I/O vjen nga fio. Në një skenar të jetës reale, ka të ngjarë të ketë kërkesa të tjera për shkrim që vijnë në ruajtje përveç atyre që lidhen me wal_fsync_duration_seconds. Ngarkesa shtesë do të rrisë vlerën e wal_fsync_duration_seconds. Pra, nëse përqindja e 99-të është afër 10 ms, ruajtja juaj po mbaron shpejtësinë.
• Merrni versionin Fio jo më pak se 3.5 (të mëparshmet nuk tregojnë përqindjet e kohëzgjatjes së fdatasync).
• Më sipër është vetëm një pjesë e rezultateve nga fio.

Histori e gjatë për fio dhe etj

Çfarë është WAL në etj

Zakonisht përdoren bazat e të dhënave regjistri i parashkrimit; etcd gjithashtu e përdor atë. Ne nuk do të diskutojmë në detaje regjistrin e parashkrimit (WAL) këtu. Mjafton të dimë se çdo anëtar i grupit etcd e mban atë në ruajtje të vazhdueshme. etcd shkruan çdo operacion me vlerë kyçe (siç është një përditësim) në WAL përpara se ta aplikojë atë në dyqan. Nëse njëri nga anëtarët e ruajtjes rrëzohet dhe rinis midis fotografive, ai mund të rivendosë në mënyrë lokale transaksionet që nga fotografia e fundit nga përmbajtja WAL.

Kur një klient shton një çelës në ruajtjen e vlerës së çelësit ose përditëson vlerën e një çelësi ekzistues, etjd regjistron operacionin në WAL, i cili është një skedar i rregullt në ruajtje të vazhdueshme. etjd DUHET të jetë plotësisht i sigurt se hyrja WAL ka ndodhur në të vërtetë përpara se të vazhdoni me përpunimin. Në Linux, një thirrje sistemi nuk mjafton për këtë. shkruaj, pasi shkrimi aktual në ruajtje fizike mund të vonohet. Për shembull, Linux mund të ruajë një hyrje të WAL në një memorie të fshehtë në memorien e kernelit (siç është cache e faqeve) për ca kohë. Dhe në mënyrë që të dhënat të shkruhen me saktësi në ruajtje të vazhdueshme, thirrja e sistemit fdatasync nevojitet pas shkrimit, dhe etcd thjesht e përdor atë (siç mund ta shihni në rezultatin e punës shtrëngoj, ku 8 është përshkruesi i skedarit 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>

Fatkeqësisht, shkrimi në ruajtje të vazhdueshme nuk ndodh menjëherë. Nëse thirrja fdatasync është e ngadaltë, performanca e sistemit etcd do të vuajë. Dokumentacioni për etcd thotëse ruajtja konsiderohet mjaft e shpejtë nëse, në përqindjen e 99-të, thirrjet fdatasync kërkojnë më pak se 10 ms për t'u shkruar në skedarin WAL. Ka metrika të tjera të dobishme për ruajtjen, por në këtë postim po flasim vetëm për këtë metrikë.

Vlerësimi i ruajtjes me fio

Nëse keni nevojë të vlerësoni nëse ruajtja juaj është e përshtatshme për etcd, përdorni fio, një mjet shumë i njohur për testimin e ngarkesës I/O. Duhet mbajtur mend se operacionet e diskut mund të jenë shumë të ndryshme: sinkron dhe asinkron, shumë klasa të thirrjeve të sistemit, etj. Si rezultat, fio është mjaft e vështirë për t'u përdorur. Ka shumë parametra, dhe kombinime të ndryshme të vlerave të tyre prodhojnë ngarkesa pune shumë të ndryshme I/O. Për të marrë shifra adekuate për etcd, duhet të siguroheni që ngarkesa e testit të shkrimit nga fio të jetë sa më afër ngarkesës aktuale nga etcd kur shkruani skedarë WAL.

Prandaj, fio duhet, të paktën, të krijojë një ngarkesë me një seri shkrimesh të njëpasnjëshme në skedar, çdo shkrim do të përbëhet nga një thirrje sistemi shkruaje ndjekur nga thirrja e sistemit fdatasync. Shkrimet sekuenciale në fio kërkojnë opsionin --rw=write. Që fio të përdorë sistemin e shkrimit telefononi kur shkruani, në vend të shkruaj, duhet të specifikoni parametrin --ioengine=sync. Së fundi, për të thirrur fdatasync pas çdo shkrimi, duhet të shtoni parametrin --fdatasync=1. Dy opsionet e tjera në këtë shembull (--size dhe -bs) janë specifike për skriptin. Në pjesën tjetër, ne do t'ju tregojmë se si t'i vendosni ato.

Pse pikërisht fio dhe si mësuam ta vendosim

Në këtë postim, ne përshkruajmë një rast të vërtetë. Ne kemi një grup Kubernetes v1.13 të cilin e monitoruam me Prometheun. etcd v3.2.24 u mbajt në një SSD. Metrikat Etcd treguan vonesa të fdatasync shumë të larta, edhe kur grupi nuk po bënte asgjë. Metrikat ishin të çuditshme dhe ne nuk e dinim vërtet se çfarë nënkuptonin. Grupi përbëhej nga makina virtuale, ishte e nevojshme të kuptonim se cili ishte problemi: në SSD-të fizike ose në shtresën e virtualizimit. Përveç kësaj, ne shpesh bënim ndryshime në konfigurimin e harduerit dhe softuerit dhe na duhej një mënyrë për të vlerësuar rezultatet e tyre. Ne mund të ekzekutojmë etcd në çdo konfigurim dhe të shikojmë matjet e Prometheus, por kjo është shumë e vështirë. Ne po kërkonim një mënyrë mjaft të thjeshtë për të vlerësuar një konfigurim specifik. Ne donim të kontrollonim nëse e kuptojmë saktë metrikën e Prometeut nga etcd.

Por për këtë duheshin zgjidhur dy probleme. Së pari, si duket ngarkesa hyrëse/dalëse që krijon etjd kur shkruan në WAL? Cilat thirrje sistemore përdoren? Sa është madhësia e të dhënave? Së dyti, nëse u përgjigjemi këtyre pyetjeve, si mund të riprodhojmë një ngarkesë të ngjashme pune me fio? Mos harroni se fio është një mjet shumë fleksibël me shumë opsione. Ne i zgjidhëm të dy problemet me një qasje - duke përdorur komandat lsof и shtrëngoj. lsof liston të gjithë përshkruesit e skedarëve të përdorur nga procesi dhe skedarët e tyre të lidhur. Dhe me strace, ju mund të ekzaminoni një proces tashmë në proces, ose të filloni një proces dhe ta ekzaminoni atë. strace printon të gjitha thirrjet e sistemit nga procesi që ekzaminohet (dhe proceset e tij fëmijë). Kjo e fundit është shumë e rëndësishme, pasi etcd thjesht po merr një qasje të ngjashme.

Ne përdorëm fillimisht strace për të eksploruar serverin etcd për Kubernetes kur nuk kishte ngarkesë në grup. Ne pamë që pothuajse të gjitha rekordet WAL ishin afërsisht të njëjtën madhësi: 2200–2400 byte. Prandaj, në komandën në fillim të postimit, ne specifikuam parametrin -bs=2300 (bs do të thotë madhësia në bajt për çdo hyrje fio). Vini re se madhësia e hyrjes etcd varet nga versioni etcd, shpërndarja, vlerat e parametrave, etj., dhe ndikon në kohëzgjatjen e fdatasync. Nëse keni një skenar të ngjashëm, shqyrtoni proceset tuaja etcd me strace për të gjetur numrat e saktë.

Më pas, për të pasur një ide të mirë se çfarë po bën sistemi i skedarëve etcd, ne e filluam atë me strace dhe opsionet -ffttT. Kështu që ne u përpoqëm të shqyrtojmë proceset e fëmijëve dhe të regjistrojmë daljen e secilit prej tyre në një skedar të veçantë, si dhe të marrim raporte të detajuara për fillimin dhe kohëzgjatjen e secilës thirrje të sistemit. Ne përdorëm lsof për të konfirmuar analizën tonë të prodhimit të shtrirjes dhe për të parë se cili përshkrues skedari po përdorej për cilin qëllim. Pra, me ndihmën e strace, u morën rezultatet e treguara më sipër. Statistikat e kohës së sinkronizimit konfirmuan se wal_fsync_duration_seconds nga etcd është në përputhje me thirrjet fdatasync me përshkruesit e skedarëve WAL.

Ne kaluam dokumentacionin për fio dhe zgjodhëm opsionet për skenarin tonë në mënyrë që fio të gjeneronte një ngarkesë të ngjashme me etcd. Ne kontrolluam gjithashtu thirrjet e sistemit dhe kohëzgjatjen e tyre duke ekzekutuar fio nga strace, ngjashëm me etcd.

Ne kemi zgjedhur me kujdes vlerën e parametrit --size për të përfaqësuar të gjithë ngarkesën I/O nga fio. Në rastin tonë, ky është numri i përgjithshëm i bajteve të shkruara në ruajtje. Doli të ishte drejtpërdrejt proporcionale me numrin e thirrjeve të sistemit të shkrimit (dhe fdatasync). Për një vlerë të caktuar të bs, numri i thirrjeve fdatasync = madhësia/bs. Meqenëse ishim të interesuar për përqindjen, duhej të kishim mostra të mjaftueshme për të qenë të sigurt, dhe llogaritëm se do të na mjaftonin 10^4 (që janë 22 mebibajt). Nëse --size është më e vogël, mund të ndodhin vlera të jashtme (për shembull, disa thirrje fdatasync zgjasin më shumë se zakonisht dhe ndikojnë në përqindjen e 99-të).

Provojeni vetë

Ne ju treguam se si të përdorni fio dhe të shihni nëse ruajtja është mjaft e shpejtë që etcd të funksionojë mirë. Tani mund ta provoni vetë duke përdorur, për shembull, makina virtuale me ruajtje SSD IBM Cloud.

Burimi: www.habr.com