Një histori e shkurtër rreth fio dhe etcd
Performanca e klastra varet nĂ« masĂ« tĂ« madhe nga performanca e depozitĂ«s sĂ« tij. etcd eksporton disa metrika nĂ« , pĂ«r tĂ« ofruar informacionet e nevojshme rreth performancĂ«s sĂ« depozitĂ«s. PĂ«r shembull, metrikĂ«n wal_fsync_duration_seconds. : qĂ« depozita duhet tĂ« konsiderohet mjaft e shpejtĂ«, percentili 99 i kĂ«saj metrike duhet tĂ« jetĂ« mĂ« pak se 10 ms. NĂ«se planifikoni tĂ« nisni njĂ« klaster etcd nĂ« makina Linux dhe dĂ«shironi tĂ« vlerĂ«soni nĂ«se depozita juaj Ă«shtĂ« mjaft e shpejtĂ« (pĂ«r shembull, SSD), mund tĂ« pĂ«rdorni â njĂ« kufi i njohur pĂ«r testimin e operacioneve tĂ« hyrjes/daljes. Ekzekutoni komandĂ«n e mĂ«poshtme, ku test-data Ă«shtĂ« direktoria nĂ«n pikĂ«n e lidhjes sĂ« depozitĂ«s:
fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytestThjesht duhet të shikoni rezultatet dhe të verifikoni që percentili 99 i kohës është më pak se 10 ms. Nëse po, depozita juaj është mjaft e shpejtë. Ja 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ënime
- Ne kemi konfiguruar vlerat e parametrave âsize dhe âbs pĂ«r skenarĂ«t tanĂ« tĂ« veçantĂ«. PĂ«r tĂ« marrĂ« njĂ« rezultat tĂ« dobishĂ«m nga fio, tregoni vlerat tuaja. Nga ku ti merrni? Lexoni, .
- Gjatë testimit, gjithë ngarkesa e hyrjes/daljes vjen nga fio. Në një skenar real, është shumë e mundur që në depozita të ketë edhe kërkesa të tjera për shk Write, përveç atyre që lidhen me wal_fsync_duration_seconds. Ngarkesa e shtuar do ta rrisë vlerën e wal_fsync_duration_seconds. Pra, nëse percentili 99 pothuajse ka arritur në 10 ms, depozita juaj nuk ka mjaft shpejtësi.
- Merrni versionin jo më pak se 3.5 (versionet e mëparshme nuk tregojnë percentilet e kohës së fdatasync).
- Më sipër tregohet vetëm një fragment i rezultateve nga fio.
Një histori e gjatë rreth fio dhe etcd
ĂfarĂ« Ă«shtĂ« WAL nĂ« etcd
Zakonisht bazat e të dhënave përdorin ; etcd e përdor atë. Këtu nuk do të diskutojmë në detaje regjistrin e shkallës parandalues (write-ahead log, WAL). Mjafton të dimë se çdo anëtar i klasës etcd e ruan atë në një ruajtje të përhershme. etcd regjistron çdo operacion me çiftet çelës-vlerë (p.sh., përditësimin) në WAL, para se t'i aplikojë ato në ruajtje. Nëse midis pamjeve, një nga anëtarët e ruajtjes dështoi dhe rifillojë, ai mund ta rikthejë lokalisht transaksionet nga momenti i fundit të pamjes sipas përmbajtjes së WAL.
Kur një klient shton një çelës në ruajtjen e çifteve çelës-vlerë ose përditëson vlerën e një çelësi ekzistues, etcd bën një regjistrim të këtij operacioni në WAL, i cili është një skedar i zakonshëm në ruajtjen e përhershme. Para se të vazhdojë përpunimi, etcd DUHET të jetë plotësisht i sigurt se regjistrimi në WAL ka ndodhur me të vërtetë. Në Linux, një thirrje e vetme sistematike nuk është e mjaftueshme , sepse në fakt regjistrimi në ruajtjen fizike mund të shtyhet. Për shembull, Linux mund ta mbajë regjistrimin WAL në cache për një kohë në memorien e bërthamës (p.sh., cache-n e faqeve). Dhe për të siguruar që të dhënat të shkruhen me saktësi në ruajtjen e përhershme, kërkohet një thirrje sistematike fdatasync pas regjistrimit, dhe etcd e përdor atë (siç mund të shihet në rezultatin e punës , ku 8 është identifikatori 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) = 0Fatkeqësisht, regjistrimi në ruajtjen e përhershme nuk ndodh menjëherë. Nëse thirrja fdatasync punon ngadalë, performanca e sistemit etcd bie. , se ruajtja konsiderohet mjaft e shpejtë nëse në percentilin 99 të thirrjeve fdatasync për regjistrimin në skedarin WAL, kohëzgjatja është më pak se 10 ms. Ka edhe matje të tjera të dobishme për ruajtjen, por në këtë post ne flasim vetëm për këtë matje.
Vlerësimi i ruajtjes me ndihmën e fio
Nëse dëshironi të vlerësoni nëse depoja juaj është e përshtatshme për etcd, përdorni fio - një mjet shumë të njohur për testimin e ngarkesës së hyrjes dhe daljes. Duhet të mbani mend se operacionet për disk mund të jenë shumë të ndryshme: sinchronike dhe asynkronike, shumë klasa të thirrjeve sistemike, etj. Si pasojë, fio është mjaft i vështirë për tu përdorur. Ai ka shumë parametra dhe kombinime të ndryshme të vlerave të tyre japin ngarkesa krejtësisht të ndryshme të hyrjes dhe daljes. Për të marrë numra adekuat për etcd, duhet të siguroheni që ngarkesa testuese e shkrimit nga fio është sa më afër mundësive reale të ngarkesës nga etcd gjatë shkrimit të skedarëve WAL.
Prandaj, fio duhet, tĂ« paktĂ«n, tĂ« krijojĂ« njĂ« ngarkesĂ« nĂ« formĂ«n e njĂ« sĂ«rĂ« operacioneve tĂ« radhĂ«s qĂ« shkruajnĂ« nĂ« skedarin, çdo shkrim do tĂ« pĂ«rbĂ«het nga thirrja sistemike , e ndjekur nga thirrja sistemike fdatasync. PĂ«r operacionet e radhĂ«s tĂ« shkrimit, fio ka nevojĂ« pĂ«r parametrin ârw=write. PĂ«r tĂ« pĂ«rdorur thirrjen sistemike write gjatĂ« shkrimit, fio duhet tĂ« ketĂ« parametrin âioengine=sync. SĂ« fundmi, pĂ«r tĂ« thirrur fdatasync pas çdo shkrimi, duhet tĂ« shtoni parametrin âfdatasync=1. Dy parametrat e tjerĂ« nĂ« kĂ«tĂ« shembull (âsize dhe âbs) varen nga skenari specifik. NĂ« seksionin e ardhshĂ«m ne do t'ju tregojmĂ« si t'i konfiguroni ata. Pse pikĂ«risht fio dhe si mĂ«suam ta konfiguroni atĂ«
Në këtë postim ne përshkruajmë një rast real. Ne kishim një klaster
v1.13, të cilin e monitoronim me Prometheus. etcd v3.2.24 ishte vendosur në SSD. Metrykët për etcd tregonin vonesa shumë të larta për fdatasync, edhe kur klasteri nuk bënte asgjë. Metrykët ishin të çuditshme dhe nuk dinim saktësisht se çfarë nënkuptonin. Klasteri përbëhej nga makina virutale, duhej të kuptonim se ku qëndronte problemi: në SSD-të fizike apo në katrin e virtualizimit. Po ashtu, herë pas here ndryshonim konfigurimin e harduerit dhe softuerit, dhe na duhej një mënyrë për të vlerësuar rezultatet e tyre. Ne mund të lançonim etcd në çdo konfigurim dhe të shikonim metrykët e Prometheus, por kjo do të ishte shumë e lodhshme. Ne po kërkonim një mënyrë mjaft të thjeshtë për të vlerësuar një konfigurim të veçantë. Do të donim të kontrollonim nëse e kuptonim siç duhet metrykët e Prometheus nga etcd. v1.13, të cilin e monitoruam me ndihmën e Prometheus. etcd v3.2.24 ishte instaluar në SSD. Metrikat për etcd treguan vonesa shumë të larta për fdatasync, madje kur klasteri nuk po bënte asgjë. Metrikat ishin të çuditshme dhe nuk dinim saktësisht se çfarë nënkuptonin. Klasteri përbëhej nga makina virtuale, dhe duhej të kuptonim se çfarë po ndodhte: te SSD-të fizike apo te shtresa e virtualizimit. Po ashtu, shpesh bënim ndërrime në konfigurimin e harduerit dhe softuerit, dhe na nevojitej një mënyrë për të vlerësuar rezultatet e tyre. Mund të startonim etcd në çdo konfigurim dhe të shikonim metrikat e Prometheus, por kjo ishte tepër e ndërlikuar. Kërkonim një mënyrë mjaft të thjeshtë për të vlerësuar një konfigurim të caktuar. Donim të verifikonim nëse po kuptonim saktësisht metrikat e Prometheus nga etcd.
Por kĂ«tĂ« ne duhej tĂ« zgjidhnim dy probleme. SĂ« pari, si Ă«shtĂ« ngarkesa e futjes-daljes qĂ« etcd krijon kur shkruan nĂ« WAL? Cilat thirrje sistemore pĂ«rdoren? Cila Ă«shtĂ« madhĂ«sia e regjistrimeve? SĂ« dyti, nĂ«se i pĂ«rgjigjemi kĂ«tyre pyetjeve, si mund ta riprodhojmĂ« njĂ« ngarkesĂ« pune tĂ« ngjashme me fio? Mos harroni se fio Ă«shtĂ« njĂ« mjet shumĂ« fleksibĂ«l me shumĂ« parametra. Ne e zgjidhĂ«m tĂ« dy problemet me njĂ« qasje â pĂ«rmes komandave dhe . lsof tregon tĂ« gjithĂ« descriptorĂ«t e skedarĂ«ve qĂ« pĂ«rdoren nga procesi dhe skedarĂ«t qĂ« janĂ« tĂ« lidhur me ta. NdĂ«rsa me strace mund tĂ« studiojmĂ« njĂ« proces tĂ« aktivizuar tashmĂ« ose tĂ« nisnim njĂ« proces dhe ta studiojmĂ« atĂ«. strace nxjerr tĂ« gjitha thirrjet sistemore nga procesi qĂ« studiojmĂ« (dhe proceset e tij tĂ« nxitura). Kjo e fundit Ă«shtĂ« shumĂ« e rĂ«ndĂ«sishme, pasi etcd saktĂ«sisht pĂ«rdor njĂ« qasje tĂ« tillĂ«.
SĂ« pari, ne pĂ«rdorĂ«m strace pĂ«r tĂ« studiuar serverin etcd pĂ«r Kubernetes, kur nuk kishte ngarkesĂ« nĂ« klaster. VĂ«shtruam se pothuajse tĂ« gjitha regjistrimet e WAL ishin rreth tĂ« njĂ«jtĂ«s madhĂ«si: 2200â2400 byte. Prandaj nĂ« komandĂ«n e fillimit tĂ« postit ne specifikuam parametrin âbs=2300 (bs do tĂ« thotĂ« madhĂ«sia nĂ« byte pĂ«r çdo regjistrim fio). Keni parasysh se madhĂ«sia e regjistrimit etcd varet nga versi etcd, shpĂ«rndarja, vlerat e parametrave etj., dhe ndikon nĂ« kohĂ«n e fdatasync. NĂ«se keni njĂ« skenar tĂ« ngjashĂ«m, studioni proceset tuaja etcd me strace pĂ«r tĂ« mĂ«suar shifrat e sakta.
Më pas, për ta përfaqësuar mirë veprimin në sistemin e skedarëve etcd, e nisëm atë me strace dhe me parametrat -ffttT. Kështu tentuam të studiojmë proceset e nxitura dhe të regjistrojmë të dhënat e daljes së secilit prej tyre në një skedar të veçantë, si dhe të marrim raporte të detajuara mbi fillimin dhe kohëzgjatjen e çdo thirrjeje sistemore. Përdorëm lsof për të konfirmuar analizën tonë të të dhënave të daljes nga strace dhe për të parë se cili descriptor skedari përdorej për cilat qëllime. Kështu, me strace, arritëm rezultatet e paraqitura më sipër. Statistikat mbi kohën e sinkronizimit konfirmuan se treguesi wal_fsync_duration_seconds nga etcd përputhet me thirrjet fdatasync me descriptorët e skedarëve WAL.
Studiuam dokumentacionin e fio dhe zgjodhëm parametrat për skenarin tonë që fio të gjeneronte një ngarkesë të ngjashme me etcd. Gjithashtu, kontrolluam thirrjet sistemore dhe kohën e tyre, duke nisur fio nga strace, ashtu si etcd.
Kemi pĂ«rzgjedhur me kujdes kuptimin e parametrin âsize, i cili pĂ«rfaqĂ«son gjithĂ« ngarkesĂ«n e hyrjes dhe daljes nga fio. NĂ« rastin tonĂ«, kjo Ă«shtĂ« shuma totale e bajtĂ«ve tĂ« shkruara nĂ« ruajtje. Kjo rezultoi tĂ« jetĂ« nĂ« proporcion tĂ« drejtpĂ«rdrejtĂ« me numrin e thirrjeve sistemike write (dhe fdatasync). PĂ«rdorimi i njĂ« vlerĂ« tĂ« caktuar bs numri i thirrjeve fdatasync = size/bs. Duke pasur parasysh se na interesonte percentili, duhej tĂ« kishim mjaft mostra pĂ«r saktĂ«sinĂ«, dhe llogaritĂ«m se 10^4 (pĂ«rkatĂ«sisht 22 mebibajt) do tĂ« ishte e mjaftueshme. NĂ«se âsize Ă«shtĂ« mĂ« e vogĂ«l, mund tĂ« ndodhin devijime (p.sh., disa thirrje fdatasync zgjatĂ«n mĂ« shumĂ« se zakonisht dhe ndikojnĂ« nĂ« percentilin 99).
Provoje vetë
Ne treguam se si të përdorni fio dhe të kuptoni nëse ruajtja ka mjaftueshëm shpejtësi për performancë të lartë në etcd. Tani mund ta provoni këtë praktikisht vetë, duke përdorur, për shembull, makineritë virtuale me ruajtje SSD në .
Burimi: habr.com
