Shën. përkth.: ky kjo artikull përmbledh rezultatet e një mini-hulumtimi të kryer nga inxhinierët e IBM Cloud në kërkim të një zgjidhjeje për një problem të vërtetë lidhur me operimin e bazës së të dhënave etcd. Për ne ishte një detyrë e ngjashme, megjithatë rrjedha e mendimeve dhe veprimeve të autorëve mund të jetë interesante edhe në një kontekst më të gjerë.
Përmbledhja e shkurtër e gjithë artikullit: fio dhe etcd
Përformanca e klasterit etcd varet shumë nga shpejtësia e ruajtjes që ndodhet në themel. Për të monitoruar performancën, etcd eksporton metrika të ndryshme Prometheus. Njëra prej tyre është wal_fsync_duration_seconds. Në dokumentacionin e etcd , se ruajtja mund të konsiderohet mjaft e shpejtë nëse percentili i 99-të i kësaj metrikë nuk e kalon 10 ms...
Nëse po mendoni të organizoni një klaster etcd në makina që funksionojnë me Linux dhe dëshironi të provoni nëse ruajtësit janë mjaft të shpejtë (për shembull, SSD), rekomandojmë të përdorni një testues të njohur I/O të quajtur . Mjafton të ekzekutoni komandën e mëposhtme (direktoria test-data duhet të jetë e vendosur në një pjesë të montuar të ruajtësit të testuar):
fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytestMë pas është vetëm për të parë daljen dhe të kontrolloni nëse percentili i 99-të është brenda 10 ms. Nëse kjo është e vërtetë, atëherë ruajtësi juaj po punon mjaft shpejt. Ja një shembull i daljes:
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]Disa vërejtje:
- Në shembullin e dhënë më sipër, ne e rregulluam parametrin
--sizedhe--bspër rastin specifik. Për të marrë një rezultat kuptimplotë ngafio, jepni vlera të përshtatshme për skenarin tuaj të përdorimit. Si t'i zgjidhni do të diskutohet më poshtë. - Gjatë testimit vetëm
fiongarkon nënstrukturen e diskut. Në jetën reale është e mundshme që disku të shkruajë edhe procese të tjera (përveç atyre që lidhen mewal_fsync_duration_seconds). Ky ngarkim shtesë mund të çojë në rritjen ewal_fsync_duration_seconds. Në fjalë të tjera, nëse percentili i 99-të, i marrë nga testi mefio, është pak më pak se 10 ms, ka një mundësi të madhe që performanca e ruajtësit të mos jetë e mjaftueshme. - Për testin do t'ju nevojitet një version
fiojo më pak se 3.5, pasi versionet më të vjetra nuk agregojnë rezultatetfdatasyncnë formë percentiles. - Doli i mësipërmi është vetëm një fragment i vogël nga dalja totale
fio.
Më shumë për fio dhe etcd
Disa fjalë mbi WAL-et e etcd
Zakonisht, bazat e të dhënave përdorin (write-ahead logging, WAL). Kjo vlen edhe për etcd. Diskutimi mbi WAL kalon përtej këtij artikulli, megjithatë për qëllimet tona duhet të dimë se: çdo anëtar i grupit etcd ruan WAL në ruajtjen e përhershme. etcd regjistron disa operacione në magazinën key-value (për shembull, përditësimet) në WAL, përpara se t'i ekzekutojë ato. Nëse një nyje dështon dhe riaktivizohet ndërmjet snapshot-eve, etcd mund të rikuperojë transaksionet e kryera nga snapshot-i i mëparshëm, duke u orientuar në përmbajtjen e WAL-it.
KĂ«shtu, çdo herĂ« qĂ« njĂ« klient shton njĂ« çelĂ«s nĂ« magazinĂ«n KV ose pĂ«rditĂ«son vlerĂ«n e njĂ« çelĂ«si ekzistues, etcd shton njĂ« pĂ«rshkrim tĂ« operacionit nĂ« WAL, qĂ« pĂ«rfaqĂ«son njĂ« skedar tĂ« zakonshĂ«m nĂ« ruajtjen e pĂ«rhershme. Para se tĂ« vazhdojĂ« punĂ«n, etcd DĂSHIRON tĂ« jetĂ« 100% e sigurt se regjistrimi nĂ« WAL Ă«shtĂ« vĂ«rtet i ruajtur. PĂ«r ta arritur kĂ«tĂ« nĂ« Linux, nuk mjafton tĂ« pĂ«rdorĂ«sh thirrjen nĂ« sistem , pasi vetĂ« operacioni i shkruar nĂ« mediumin fizik mund tĂ« vonohet. PĂ«r shembull, Linux pĂ«r njĂ« periudhĂ« tĂ« caktuar mund ta mbajĂ« regjistrimin e WAL-it nĂ« memorien e caches tĂ« bĂ«rthamĂ«s (pĂ«r shembull, nĂ« cache pĂ«r faqe). PĂ«r tĂ« garantuar qĂ« tĂ« dhĂ«nat janĂ« shkruar nĂ« medium, pas shkrimit duhet tĂ« angazhohet njĂ« thirrje nĂ« sistem fdatasync â kĂ«shtu vepron etcd (siç tregohet nĂ« shembullin e mĂ«poshtĂ«m ; kĂ«tu 8 â deshifrim i skedarit 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 Fatkeqësisht, shkrimi në ruajtjen e përhershme merr disa kohë. Vonimi i thirrjes fdatasync mund të ndikojë në performancën e etcd. Sipas dokumentacionit për magazinën , për performancë të mjaftueshme është e nevojshme që 99-ta percentili i kohës së të gjitha thirrjeve fdatasync në shkrimin e skedarit WAL të jetë më i vogël se 10 ms. Ka edhe metrika të tjera të lidhura me magazinën, por ky artikull do të flasë saktësisht për këtë.
Vlerësimi i magazinës me anë të fio
PĂ«r tĂ« vlerĂ«suar nĂ«se njĂ« magazinĂ« Ă«shtĂ« e pĂ«rshtatshme pĂ«r t'u pĂ«rdorur me etcd, mund tĂ« pĂ«rdoret utilitari â testuesi I/O mĂ« i popullarizuar. Kini parasysh se hyrja-dalja nĂ« disk mund tĂ« ndodhi nĂ« mĂ«nyra tĂ« ndryshme: sync/async, njĂ« sĂ«rĂ« klasash tĂ« ndryshme thirrjesh sistemike, etj. Ana tjetĂ«r e medaljes Ă«shtĂ« se fio Ă«shtĂ« jashtĂ«zakonisht e komplikuar pĂ«r t'u pĂ«rdorur. Avantazhi ka shumĂ« parametra dhe kombinime tĂ« ndryshme tĂ« vlerave tĂ« tyre japin rezultatet krejtĂ«sisht tĂ« ndryshme. PĂ«r tĂ« marrĂ« njĂ« vlerĂ«sim tĂ« arsyeshĂ«m nĂ« rastin e etcd, duhet tĂ« siguroheni qĂ« ngarkesa e shkruar nga fio tĂ« jetĂ« sa mĂ« afĂ«r ngarkesĂ«s tĂ« etcd gjatĂ« shkruarjes nĂ« skedarĂ«t WAL:
- Kjo do të thotë se ngarkesa e gjeneruar
fioduhet të përfaqësojë të paktën një seri shënimesh të rregullta në skedar, ku çdo operacion shënimi përbëhet nga një thirrje sistemike , e cila ndiqet ngafdatasync. - Për të aktivizuar shënimin e rregullt, duhet të specifikoni flamurin
--rw=write. - PĂ«r
fioshkruar me thirrjewrite(dhe jo thirrje tĂ« tjera sistemike â pĂ«r shembull, ), pĂ«rdorni flamurin--ioengine=sync. - MĂ« nĂ« fund, flamuri
--fdatasync=1garanton që pas çdowriteduhetfdatasync. - Dy parametrat e tjerë në shembullin tonë:
--sizedhe--bsâ mund tĂ« ndryshojnĂ« nĂ« varĂ«si tĂ« skenarit specifik tĂ« pĂ«rdorimit. NĂ« seksionin e ardhshĂ«m do tĂ« pĂ«rshkruhet konfigurimi i tyre.
Pse e zgjodhëm fio dhe nga e morëm informacionin për ta konfiguruar
Ky shënim u shfaq nga një rast real që u përballëm. Kishim një klaster në Kubernetes v1.13 me monitorim në Prometheus. Si një ruajtje për etcd v3.2.24 shërbenin diskët me gjendje të ngurtë. Të dhënat e etcd treguan vonesa shumë të larta fdatasync, edhe kur klasteri ishte i papunë. Këto metrika na dukeshin shumë të dyshimta, dhe nuk ishim të sigurt se çfarë përfaqësonin. Për më tepër, klasteri përbëhej nga makina virtuale, prandaj nuk ishte e qartë nëse vonesa ishte e lidhur me virtualizimin apo ishin fajtorët SSD.
Për më tepër, shqyrtuam ndryshime të ndryshme në konfigurimin e harduerit dhe softuerit, prandaj na nevojitej një mënyrë për t'i vlerësuar ato. Natyrisht, do të ishte e mundur të ekzekutohej etcd në çdo konfigurim dhe të shihnim metrikat përkatëse të Prometheus, por kjo do të kërkonte përpjekje të konsiderueshme. Ne kishim nevojë për një mënyrë të thjeshtë për të vlerësuar konfigurimin specifik. Donim të verifikonim kuptimin tonë për metrikat e Prometheus, që vinin nga etcd.
Për këtë, duhej të zgjidhnim dy probleme:
- Së pari, si duket ngarkesa I/O që krijohet nga etcd kur shkruan në skedarët WAL? Cilat thirrje sistemore përdoren? Cila është madhësia e blloqeve të shkruar?
- Së dyti, le të themi se kemi përgjigjet për pyetjet e lartëpërmendura. Si mund të riprodhojmë ngarkesën përkatëse me
fio? ĐДЎŃfioâ njĂ« mjet jashtĂ«zakonisht fleksibĂ«l me shumĂ« parametra (kjo Ă«shtĂ« e lehtĂ« pĂ«r tu parĂ«, pĂ«r shembull, Ââ shĂ«n. pĂ«rk.).
Ne zgjidhëm të dy problemet përmes së njëjtës qasje, duke u mbështetur në komandat dhe :
- Me ndihmën e
lsofmund të shikoni të gjitha deskriptorët e skedarëve që përdoren nga procesi, si dhe skedarët përkatës. - Me ndihmën e
stracemund të analizoni një proces të cilin e keni nisur tashmë, ose të nisni një proces dhe ta vëzhgoni atë. Komanda jep të gjitha thirrjet sistemore të kryera nga ky proces dhe, nëse nevojitet, nga pasardhësit e tij. Kjo është e rëndësishme për proceset që fork-ohen, dhe etcd është një prej atyre proceseve.
E para që bëmë, ishte të përdorim strace për të studiuar serverin etcd në grumbullin Kubernetes, ndërsa ai ishte në gjendje të papunë.
KĂ«shtu u zbulua se blloqet e shkruar nĂ« WAL ishin shumĂ« ngushtĂ«sisht tĂ« grupuara, madhĂ«sia e shumicĂ«s ishte nĂ« intervalin 2200-2400 bajt. Kjo Ă«shtĂ« arsyeja pse nĂ« komandĂ«n nĂ« fillim tĂ« kĂ«saj artikulli pĂ«rdoret flamuri --bs=2300 (bs â madhĂ«sia nĂ« bajt e secilit bllok tĂ« shkruar nĂ« fio).
Vini re se madhësia e blloqeve të shkruar nga etcd mund të variojë në varësi të versionit, deployment-it, vlerave të parametrave, etj. - kjo ndikon në kohëzgjatjen fdatasync. Nëse keni një skenar përdorimi të ngjashëm, analizoni me strace proceset tuaja etcd për të marrë vlera aktuale.
Më pas, për të marrë një pamje të qartë dhe gjithëpërfshirëse mbi punën e etcd me sistemin e skedarëve, ne e nisëm atë nga strace me flamurët -ffttT. Kjo lehtësoi mbulimin e proceseve pasardhëse dhe regjistrimin e daljes së secilit në një skedar të veçantë. Përveç kësaj, u morën të dhëna të detajuara për momentin e fillimit dhe kohëzgjatjen e secilës thirrje sistemore.
Ne gjithashtu shfrytëzuam komandën lsof, për të konfirmuar kuptimin tonë të daljes strace në lidhje me se cilin deskriptor skedari u përdor për çfarë qëllimi. Doli një dalie strace, e ngjashme me atë që është paraqitur më sipër. Manipulimet statistikore me kohët e sinkronizimit konfirmuan se metrika wal_fsync_duration_seconds nga etcd është në përputhje me thirrjet fdatasync me deskriptorët e skedarëve WAL.
Për të gjeneruar duke përdorur fio një ngarkesë e punës, e ngjashme me ngarkesën nga etcd, u studiuan dokumentacionin e mjetit dhe u përshtatën parametrat që përshtaten me detyrën tonë. Ne u siguruam që thirrjet sistemike të nevojshme ishin aktivizuar dhe konfirmuam qëndrueshmërinë e tyre, duke e nisur fio nga strace (siç u bë në rastin e etcd).
Vëmendje të veçantë iu kushtua përcaktimit të vlerës së parametrave --size. Ai përfaqëson ngarkesën totale I/O, e gjeneruar nga mjeti fio. Në rastin tonë, kjo është shuma totale e bajtëve të shkruar në mbajtës. Ajo është proporcional me numrin e thirrjeve write (dhe fdatasync). Për një numër të caktuar bs të thirrjeve fdatasync është e barabartë me size / bs.
Duke qenë se na interesonte persentili, ne synonim që numri i provave të ishte mjaft i madh për rëndësinë statistike. Dhe vendosëm që 10^4 (që përkon me madhësinë prej 22 Mb) do të ishte mjaftueshëm. Vlerat më të vogla të parametrave --size japnin një zhurmë më të theksuar (p.sh., thirrjet fdatasync, që zënë shumë më tepër kohë se zakonisht dhe ndikojnë në percentilin 99).
Tani është radha juaj
Në artikull tregohet si me anë të fio mund të vlerësohet nëse një mbajtës, i destinuar për përdorim me etcd, është mjaft i shpejtë. Tani është radha juaj! Mund të eksploroni makinat virtuale me ruajtje mbi bazën e SSD në shërbimin .
P.S. nga përkthyesi
Me shembuj të gatshëm të përdorimit fio për zgjidhjen e problemeve të tjera mund të njiheni në ose direkt në (aty janë të paraqitura shumë më tepër, se sa përmenden në dokumentacion).
P.P.S. nga përkthyesi
Lexoni gjithashtu në blogun tonë:
- «»;
- «»;
- «».
Burimi: habr.com
