ProHoster > Blog > Administrimi > Si të kontrolloni diskët me fio për performancë të mjaftueshme për etcd

Si të kontrolloni diskët me fio për performancë të mjaftueshme për etcd

ShĂ«n. pĂ«rk.: ky kjo artikull — pĂ«rmbledhja e njĂ« mini-hetimi tĂ« kryer nga inxhinierĂ«t e IBM Cloud pĂ«r tĂ« gjetur njĂ« zgjidhje pĂ«r njĂ« problem real qĂ« lidhet me operimin e bazĂ«s sĂ« tĂ« dhĂ«nave etcd. PĂ«r ne, njĂ« detyrĂ« e ngjashme ishte e rĂ«ndĂ«sishme, por mĂ«nyra e mendimit dhe veprimeve tĂ« autorĂ«ve mund tĂ« jetĂ« interesante edhe nĂ« njĂ« kontekst mĂ« tĂ« gjerĂ«.

Si të kontrolloni diskët me fio për performancë të mjaftueshme për etcd

Përmbledhje e shkurtër e gjithë artikullit: fio dhe etcd

Performanca e klasterit etcd varet shumë nga shpejtësia e depozitës që ndodhet në bazën e tij. 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 thuhet, depozita mund të konsiderohet mjaft e shpejtë nëse 99 përqind e kësaj metrike nuk e kalon 10 ms


Nëse po mendoni për mundësinë e organizimit të një klasteri etcd në makina të drejtuara nga Linux dhe dëshironi të verifikoni nëse depozitat janë mjaft të shpejta (p.sh., SSD), rekomandojmë të përdorni testuesin popullor të I/O i quajtur fio. Mjafton të ekzekutoni këtë komandë (direktorja test-data duhet të jetë e vendosur në partitionin e montuar të depozitës që po testoni):

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

Mjafton të shihni rezultatin dhe të kontrolloni nëse 99 përqind e fdatasync ndodhet brenda 10 ms. Nëse po, atëherë depozita juaj funksionon mjaft shpejt. Ja një shembull rezultati:

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:

  1. Në shembullin e mësipërm ne përshtatëm parametrat --size dhe --bs për rastin specifik. Për të marrë një rezultat përmbajtësor nga fio, jepni vlerat që përshtaten me skenarin tuaj të përdorimit. Si t'i zgjidhni ato do të diskutohet më poshtë.
  2. Gjatë testimit, vetëm fio ngarkon sistemin e dyshemesë. Në jetën reale, është mjaft e mundshme që disku të shkruajë edhe procese të tjera (përveç atyre që lidhen me wal_fsync_duration_seconds). Kjo ngarkesë shtesë mund të çojë në rritjen e wal_fsync_duration_seconds. Në të tjera fjalë, nëse 99 përqind e marrë nga testimi me fio, është vetëm pak më poshtë 10 ms, ka një shans të madh që performanca e depozitës të jetë e pamjaftueshme.
  3. Për testin, do t'ju duhet një version fio jo më i ulët se 3.5, sepse versionet më të vjetra nuk agregojnë rezultatet fdatasync në formën e përqindjeve.
  4. Rezultati më sipër është vetëm një fraksion i rezultatit total fio.

Detajet mbi fio dhe etcd

Disa fjalë rreth WAL-eve të etcd

Si rregull, bazat e të dhënave përdorin shkrimin e përparshëm (write-ahead logging, WAL). Kjo vlen edhe për etcd. Diskutimi mbi WAL-i del jashtë kësaj artikulli, por për qëllimet tona duhet të dimë se: çdo anëtar i klasterit etcd ruan WAL në një depo të përhershme. etcd regjistron disa operacione me magazinën key-value (p.sh., përditësimet) në WAL, para se t'i kryejë ato. Nëse një nyje rrëzohet dhe riaktivizohet midis snapshot-eve, etcd mund të rikuperojë transaksionet e kryera nga snapshot-i i mëparshëm, duke u orientuar nga përmbajtja e WAL.

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, i cili Ă«shtĂ« njĂ« skedĂ« e zakonshme nĂ« shpĂ«rndarjen e pĂ«rhershme. Para se tĂ« vazhdojĂ« me punĂ«n, etcd DUHET tĂ« jetĂ« 100% e sigurt se shkrimi nĂ« WAL nĂ« tĂ« vĂ«rtetĂ« Ă«shtĂ« ruajtur. PĂ«r ta siguruar kĂ«tĂ« nĂ« Linux, nuk mjafton tĂ« pĂ«rdorni thirrjen e sistemit shkruaj, sepse operacioni i vetĂ« shkrimit nĂ« mbajtĂ«s fizik mund tĂ« jetĂ« i vonuar. PĂ«r shembull, Linux mund tĂ« mbajĂ« regjistrimin e WAL nĂ« memorjen e kernelit pĂ«r njĂ« kohĂ« (p.sh., nĂ« cache-n e faqeve). PĂ«r tĂ« garantuar qĂ« tĂ« dhĂ«nat e shkruara i janĂ« dĂ«rguar mbajtĂ«sit, pas shkrimit Ă«shtĂ« e nevojshme tĂ« aktivizoni thirrjen e sistemit fdatasync — kĂ«shtu vepron etcd (siç shihet nĂ« shembullin mĂ« poshtĂ« strace; kĂ«tu 8 — deshifruesi i skedĂ«s 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ë mbajtësin e përhershëm kërkon disa kohë. Vonesat në ekzekutimin e thirrjes fdatasync mund të ndikojnë në performancën e etcd. Në dokumentacionin e depozitës shkruhet, për të pasur performancë të mjaftueshme, është e domosdoshme që 99 përqind e kohës së të gjitha thirrjeve fdatasync në shkrimin në skedën WAL të jetë më e vogël se 10 ms. Ekzistojnë edhe metrika të tjera që lidhen me depozitën, por në këtë artikull do të bisedohet veçanërisht për këtë.

Vlerësimi i depozitës me fio

PĂ«r tĂ« vlerĂ«suar nĂ«se njĂ« depo Ă«shtĂ« e pĂ«rshtatshme pĂ«r pĂ«rdorim me etcd, mund tĂ« pĂ«rdorni utilitarin fio — testues i njohur I/O. Mbani parasysh se hyrja-dalja e diskut mund tĂ« ndodhĂ« nĂ« mĂ«nyra tĂ« ndryshme: sync/asynchronous, shumĂ« klasa tĂ« ndryshme thirrjesh sistemore, etj. AnĂ« tjetĂ«r e medaljes Ă«shtĂ« se fio shumĂ« e komplikuar pĂ«r t'u pĂ«rdorur. NjĂ« mjet ka shumĂ« parametra, dhe kombinime tĂ« ndryshme tĂ« vlerave tĂ« tyre japin rezultate krejtĂ«sisht tĂ« ndryshme. PĂ«r tĂ« marrĂ« njĂ« vlerĂ«sim tĂ« arsyeshĂ«m nĂ« rastin e etcd, duhet tĂ« siguroheni qĂ« ngarkesa e shkrimit e gjeneruar nga fio, tĂ« jetĂ« sa mĂ« afĂ«r ngarkesĂ«s sĂ« etcd kur shkruan nĂ« skedarĂ«t WAL:

  • Kjo do tĂ« thotĂ« se ngarkesa e fio duhet tĂ« pĂ«rbĂ«het tĂ« paktĂ«n nga njĂ« seri shkrimesh tĂ« njĂ«pasnjĂ«shme nĂ« skedarin, ku çdo operacion shkrimi pĂ«rbĂ«het nga njĂ« thirrje sistemore shkruaj, e ndjekur nga fdatasync.
  • PĂ«r tĂ« aktivizuar shkrimin e njĂ«pasnjĂ«shĂ«m, nevojitet tĂ« pĂ«rcaktohet flamuri --rw=write.
  • PĂ«r fio shkruante me thirrje shkruaj (dhe jo thirrje tĂ« tjera sistemore — pĂ«r shembull, pwrite), pĂ«rdorni flamurin --ioengine=sync.
  • MĂ« nĂ« fund, flamuri --fdatasync=1 garanton qĂ« pas çdo shkruaj duhet fdatasync.
  • Dy parametrat e tjerĂ« nĂ« shembullin tonĂ«: --size dhe --bs — mund tĂ« ndryshojnĂ« nĂ« varĂ«si tĂ« skenarit tĂ« veçantĂ« tĂ« pĂ«rdorimit. NĂ« seksionin nĂ« vijim do tĂ« pĂ«rshkruhet konfigurimi i tyre.

Pse zgjodhëm fio dhe nga mësuam si ta konfigurojmë

Ky shënim lindi nga një rast real me të cilin u përballëm. Kishim një klaster në Kubernetes v1.13 me monitorim nga Prometheus. Si depo për etcd v3.2.24 shërbenin disqe solid state. Metritë e etcd treguan vonesa shumë të larta fdatasync, edhe kur klasteri ishte i ndaluar. Këto metritë na dukej se ishin shumë të dyshimta, dhe nuk ishim të sigurt se çfarë përfaqësonin. Për më tepër, klasteri përbënte makineri virtuale, kështu që nuk ishte e mundur të thuhej nëse vonesa kishte të bënte me virtualizimin apo nëse SSD ishin fajtorët.

Për më tepër, ne shqyrtuam ndryshime të ndryshme në konfigurimin e harduerit dhe softuerit, prandaj ishte e nevojshme një mënyrë për t'i vlerësuar ato. Sigurisht, mund të ishte nisur etcd në çdo konfigurim dhe të shihnim metritë përkatëse të Prometheus-it, por kjo do të kërkonte përpjekje të mëdha. Na duhet një mënyrë e thjeshtë për të vlerësuar një konfigurim të veçantë. Dëshironim të testonim kuptimin tonë të metrisë së Prometheus-it që vijnë nga etcd.

Për këtë, duhej të zgjidheshin dy probleme:

  • SĂ« pari, si duket ngarkesa I/O e gjeneruar nga etcd kur shkruan nĂ« skedarĂ«t WAL? Cilat thirrje sistemore pĂ«rdoren? Cili Ă«shtĂ« madhĂ«sia e bllokut tĂ« shkrimit?
  • SĂ« dyti, le tĂ« thoni se kemi pĂ«rgjigje pĂ«r pyetjet e mĂ«sipĂ«rme. Si tĂ« riprodhojmĂ« ngarkesĂ«n pĂ«rkatĂ«se me fio? Đ’Đ”ĐŽŃŒ fio — njĂ« mjet shumĂ« fleksibĂ«l me njĂ« mori parametrash (e qartĂ« nĂ« kĂ«tĂ« mĂ«nyrĂ«, pĂ«r shembull, kĂ«tu ­— shĂ«n. pĂ«rkth.).

Ne solucionuam të dy problemet me një qasje të njëjtë, duke u mbështetur në komandat lsof dhe strace:

  • Me lsof mund tĂ« shikoni tĂ« gjitha deshkriptorĂ«t e skedarĂ«ve qĂ« pĂ«rdoren nga procesi, si dhe skedarĂ«t me tĂ« cilĂ«t janĂ« lidhur.
  • Me strace mund tĂ« analizoni njĂ« proces tĂ« ndaluar ose tĂ« nisni njĂ« proces dhe ta vĂ«shtroni atĂ«. Komanda nxjerr tĂ« gjitha thirrjet sistemore tĂ« kryera nga ky proces dhe, nĂ«se Ă«shtĂ« e nevojshme, pasardhĂ«sit e tij. E fundit Ă«shtĂ« e rĂ«ndĂ«sishme pĂ«r proceset qĂ« forkohen, dhe etcd Ă«shtĂ« njĂ« nga kĂ«to procese.

E para që bëmë ishte të përdorim strace për të hulumtuar serverin etcd në klasterin Kubernetes, për sa kohë që ai ishte i ndaluar.

U zbulua kĂ«shtu se blloqet e shkrimit nĂ« WAL janĂ« shumĂ« tĂ« grumbulluara ngushtĂ«, dhe madhĂ«sia e shumicĂ«s ishte nĂ« intervalin 2200-2400 byte. Kjo Ă«shtĂ« arsyeja pse nĂ« komandĂ«n nĂ« fillim tĂ« kĂ«tij artikulli ndodhet flamuri --bs=2300 (bs — madhĂ«sia nĂ« byte e secilit bllok shkrimi nĂ« fio).

Vini re se madhĂ«sia e bllokut tĂ« shkrimit nĂ« etcd mund tĂ« ndryshojĂ« nĂ« varĂ«si tĂ« versionit, deploy-it, vlerave tĂ« parametrave, etj. — kjo ndikon nĂ« gjatĂ«si fdatasync. NĂ«se keni njĂ« skenar tĂ« ngjashĂ«m pĂ«rdorimi, analizoni me ndihmĂ«n e strace proceset tuaja etcd pĂ«r tĂ« marrĂ« vlera aktuale.

Pastaj, për të marrë një pamje të qartë dhe gjithëpërfshirëse të punës së etcd me sistemin e skedarëve, e nisëm atë nga strace me flamujt -ffttT. Kjo lejoj që të mbuloheshin proceset pasardhëse dhe të shkruhej dalja e secilës në një skedar të veçantë. Për më tepër, u arritën informacione të detajuara mbi momentin e nismës dhe gjatësi e çdo thirrje sistemore.

Ishim gjithashtu të siguruar me komandën lsof, për të konfirmuar kuptimin tonë të daljes strace në lidhje me se cilin deshkriptor skedari është përdorur për cilin qëllim. U krijua një dalje strace, e ngjashme me atë që u paraqit më sipër. Manipulimet statistikore me kohët e sinkronizimit konfirmuan se metrika wal_fsync_duration_seconds nga etcd përputhet me thirrjet fdatasync me deshkriptorët e skedarëve WAL.

Për të gjeneruar me ndihmën e fio Ngarkesa e punës, e ngjashme me ngarkesën nga etcd, u studiuan dokumentet e utilitarit dhe u përcaktuan parametrat e përshtatshëm për detyrën tonë. Ne u siguruam që thirrjet sistemore të nevojshme ishin aktivizuar dhe konfirmuam kohëzgjatjen e tyre përmes ekzekutimit fio nga strace (siç u bë në rastin e etcd).

Vëmendje e veçantë iu kushtua përcaktimit të vlerës së parametrave --size. Ai përfaqëson ngarkesën totale I/O, e gjeneruar nga utilitari fio. Në rastin tonë, kjo është numri i plotë i byte-ve të shkruara në media. Ai është drejtpërdrejt proporcional me numrin e thirrjeve shkruaj (dhe fdatasync). Për një bs numër thirrjesh fdatasync është e barabartë me size / bs.

Pasi na interesonte percentili, ne kërkuam që numri i mostrave të ishte mjaft i madh për rëndësinë statistike. Dhe vendosëm se 10^4 ( që përkon me një madhësi prej 22 Mb) do të ishte e mjaftueshme. Vlerat më të vogla të parametrave --size jepnin më shumë zhurmë (p.sh., thirrjet fdatasync, që zënë më shumë kohë sesa zakonisht dhe ndikojnë në percentilin e 99-të).

Puna është e juaja

Artikulli tregon se si me ndihmën e fio mund të vlerësohet nëse media e destinuar për përdorim me etcd është mjaft e shpejtë. Tani puna është e juaja! Të eksploroni makinat virtuale me ruajtje të bazuar në SSD mund të bëhet në shërbimin IBM Cloud.

P.S. nga përkthyesi

Me shembuj të gatshëm të përdorimit fio për zgjidhjen e detyrave të tjera mund të njiheni në dokumentacion ose drejtpërdrejt në repozitorin e projektit (aty janë paraqitur shumë më tepër, sesa përmenden në dokumentacion).

P.P.S. nga përkthyesi

Lexoni gjithashtu në blogun tonë:

Burimi: habr.com

Bleni hostim tĂ« besueshĂ«m pĂ«r faqe me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Bleni hostim tĂ« besueshĂ«m pĂ«r faqe me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster