Biltegiratze-abiadura egokia etcd-erako? Galde diezaiogun fio

Biltegiratze-abiadura egokia etcd-erako? Galde diezaiogun fio

Fio eta etcd-ri buruzko istorio labur bat

Klusterraren errendimendua etab neurri handi batean, bere biltegiratzearen errendimenduaren araberakoa da. etcd-k metrika batzuk esportatzen ditu Prometeonahi duzun biltegiratze-errendimenduaren informazioa emateko. Adibidez, wal_fsync_duration_seconds metrika. Etcd-ren dokumentazioa dio: Biltegiratzea nahikoa bizkorra izan dadin, metrika honen 99. pertzentilak 10 ms baino txikiagoa izan behar du. Etcd kluster bat Linux makinetan exekutatzeko asmoa baduzu eta zure biltegiratzea nahikoa azkarra den (adibidez, SSD) ebaluatu nahi baduzu, erabil dezakezu FIO I/O eragiketak probatzeko tresna ezaguna da. Exekutatu komando hau, non test-data biltegiratze muntatze-puntuaren azpian dagoen direktorioa den:

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

Emaitzak begiratu eta iraupenaren 99. pertzentilea dela egiaztatu besterik ez duzu behar fdatasync 10 ms baino gutxiago. Hala bada, biltegiratze nahiko azkarra duzu. Hona hemen emaitzen adibide bat:

  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]

Oharrak

  • --size eta --bs aukerak pertsonalizatu ditugu gure eszenatoki zehatzerako. Fio-tik emaitza erabilgarria lortzeko, eman zure balioak. Non eskuratu? Irakurri nola ikasi genuen fio konfiguratzen.
  • Probetan zehar, I/O karga guztia fiotik dator. Bizitza errealeko eszenatoki batean, ziurrenik beste idazketa-eskaera batzuk sartuko dira biltegira, wal_fsync_duration_seconds-ekin lotutakoez gain. Karga gehigarriak wal_fsync_duration_seconds-en balioa handituko du. Beraz, 99. pertzentilea 10 ms-tik gertu badago, biltegiratzea abiadura agortzen ari da.
  • Hartu bertsioa FIO ez 3.5 baino gutxiago (aurrekoek ez dituzte fdatasync iraupen pertzentilak erakusten).
  • Goian fio-ren emaitzen zati bat besterik ez dago.

Fio eta abarri buruzko istorio luzea

Zer da WAL etcd-en

Normalean datu-baseak erabiltzen dira idazteko erregistroa; etcd-k ere erabiltzen du. Ez dugu hemen idazteko aurrerapenaren erregistroa (WAL) zehatz-mehatz eztabaidatuko. Nahikoa da jakitea etcd klusterreko kide bakoitzak biltegiratze iraunkor batean mantentzen duela. etcd-k gako-balioaren eragiketa bakoitza (adibidez, eguneraketa bat) WAL-en idazten du dendan aplikatu aurretik. Biltegiratze-kideetako bat huts egiten bada eta argazkien artean berrabiarazten bada, WAL edukiaren azken argazkitik aurrerako transakzioak lokalean leheneratu ditzake.

Bezero batek gako-balioen biltegian gako bat gehitzen duenean edo lehendik dagoen gako baten balioa eguneratzen duenean, etcd-k WAL-en grabatzen du eragiketa, hau da, biltegiratze iraunkorrean dagoen fitxategi arrunta. etcd-k guztiz ziurtatu behar du WAL sarrera benetan gertatu dela prozesatzen jarraitu aurretik. Linux-en, sistema-dei bat ez da nahikoa horretarako. idatzi, biltegiratze fisikoan benetako idazketa atzeratu egin daitekeenez. Adibidez, Linux-ek WAL sarrera bat gorde dezake nukleoko memoriako cache batean (adibidez, orrialdeko cache batean) denbora batez. Eta datuak biltegiratze iraunkorrean zehaztasunez idazteko, fdatasync sistema-deia behar da idatzi ondoren, eta etcd-k besterik ez du erabiltzen (lanaren emaitzan ikus dezakezun bezala). traza, non 8 WAL fitxategiaren deskribatzailea den):

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>

Zoritxarrez, biltegiratze iraunkorrean idaztea ez da berehala gertatzen. fdatasync deia motela bada, etcd sistemaren errendimendua kaltetuko da. Etcd-ren dokumentazioa diobiltegiratzea nahikoa azkartzat hartzen dela, 99. pertzentilean, fdatasync-en deiak 10 ms baino gutxiago behar badira WAL fitxategian idazteko. Biltegiratzeko beste neurri erabilgarriak daude, baina mezu honetan metrika honi buruz bakarrik hitz egiten ari gara.

Biltegiratzea fio-rekin kalkulatzea

Zure biltegiratzea etcd-rako egokia den ebaluatu behar baduzu, erabili fio, oso ezaguna den I/O karga probatzeko tresna. Gogoratu behar da diskoaren eragiketak oso desberdinak izan daitezkeela: sinkronoak eta asinkronoak, sistema-deien klase asko, etab. Ondorioz, fio nahiko zaila da erabiltzea. Parametro asko ditu, eta haien balioen konbinazio ezberdinek I/O lan-karga oso desberdinak sortzen dituzte. Etcd-ren zifra egokiak lortzeko, ziurtatu fio-ren probako idazketa-karga etcd-en benetako kargatik ahalik eta gertuen dagoela WAL fitxategiak idazterakoan.

Hori dela eta, fio-k, gutxienez, fitxategian idazketa sekuentzial batzuen karga sortu beharko luke; idazketa bakoitza sistema dei batez osatuko da. idatziondoren, fdatasync sistema-deia. Fio-rako idazketa sekuentzialak --rw=write aukera behar du. Fio-k idaztean idazteko sistema-deia erabiltzeko, baino idatzi, --ioengine=sync parametroa zehaztu beharko zenuke. Azkenik, idazketa bakoitzaren ondoren fdatasync deitzeko, --fdatasync=1 parametroa gehitu behar duzu. Adibide honetako beste bi aukerak (--size eta -bs) script-en espezifikoak dira. Hurrengo atalean, horiek nola konfiguratu erakutsiko dizugu.

Zergatik fio eta nola konfiguratzen ikasi genuen

Post honetan, kasu erreal bat deskribatzen dugu. Kluster bat dugu Kubernetes Prometheus-ekin monitorizatu genuen v1.13. etcd v3.2.24 SSD batean ostatatuta zegoen. Etcd metrik fdatasync latentzia altuegia erakutsi zuten, nahiz eta klusterrak ezer egiten ez zuenean. Neurri arraroak ziren eta ez genekien zer esan nahi zuten. Klusterra makina birtualez osatuta zegoen, arazoa zein zen ulertu behar zen: SSD fisikoetan edo birtualizazio geruzan. Horrez gain, askotan aldaketak egiten genituen hardware eta softwarearen konfigurazioan, eta haien emaitzak ebaluatzeko modu bat behar genuen. Etcd exekutatu genezake konfigurazio guztietan eta Prometheus-en neurketak begiratu, baina hori arazo handiegia da. Konfigurazio zehatz bat ebaluatzeko modu nahiko sinple bat bilatzen ari ginen. Prometheus-en neurketak etcd-tik ondo ulertzen ditugun egiaztatu nahi genuen.

Baina horretarako, bi arazo konpondu behar ziren. Lehenik eta behin, nolakoa da etcd-k WALen idaztean sortzen duen I/O karga? Zein sistema-dei erabiltzen dira? Zein da diskoen tamaina? Bigarrenik, galdera hauei erantzuten badiegu, nola erreproduzituko dugu antzeko lan-karga bat fio-rekin? Ez ahaztu fio aukera asko dituen tresna oso malgua dela. Bi problemak ikuspegi bakarrean konpondu ditugu, komandoak erabiliz lsof ΠΈ traza. lsof-ek prozesuak erabiltzen dituen fitxategi deskribatzaile guztiak eta haiei lotutako fitxategiak zerrendatzen ditu. Eta strace-rekin, dagoeneko martxan dagoen prozesu bat aztertu dezakezu edo prozesu bat hasi eta aztertu. strace-k aztertzen ari den prozesuko sistema-dei guztiak inprimatzen ditu (eta bere prozesu seme-alabak). Azken hau oso garrantzitsua da, etcd antzeko ikuspegia besterik ez baita egiten.

Lehenik strace erabili genuen Kubernetes-eko etcd zerbitzaria arakatzeko klusterrean kargarik ez zegoenean. Ikusi genuen ia WAL erregistro guztiak tamaina berekoak zirela: 2200–2400 byte. Hori dela eta, argitalpenaren hasierako komandoan, -bs=2300 parametroa zehaztu dugu (bs-ek fio sarrera bakoitzeko bytetan duen tamaina esan nahi du). Kontuan izan etcd sarreraren tamaina etcd bertsioaren, banaketaren, parametroen balioen eta abarren araberakoa dela eta fdatasync-en iraupenari eragiten diola. Antzeko eszenatoki bat baduzu, aztertu zure etcd prozesuak strace-rekin zenbaki zehatzak jakiteko.

Ondoren, etcd fitxategi-sistemak egiten ari dena ondo ezagutzeko, strace eta -ffttT aukerekin hasi ginen. Beraz, umeen prozesuak aztertzen eta horietako bakoitzaren irteera fitxategi bereizi batean grabatzen saiatu ginen, eta sistema-dei bakoitzaren hasierari eta iraupenari buruzko txosten zehatzak ere lortzen saiatu ginen. Lsof erabili dugu strace irteeraren azterketa baieztatzeko eta zein fitxategi deskribatzailea zein helburutarako erabiltzen ari zen ikusteko. Beraz, strace-ren laguntzaz, goian agertzen diren emaitzak lortu ziren. Sinkronizazio-denboraren estatistikek baieztatu dutenez, etcd-ren wal_fsync_duration_seconds koherentea da WAL fitxategi deskribatzaileekin fdatasync-en deiekin.

Fio-ren dokumentazioa aztertu genuen eta gure scripterako aukerak aukeratu genituen, fio-k etcd-ren antzeko karga bat sor zezan. Sistema-deiak eta haien iraupena ere egiaztatu ditugu strace-tik fio exekutatuz, etcd-en antzera.

Arreta handiz aukeratu dugu --size parametroaren balioa fio-tik I/O karga osoa irudikatzeko. Gure kasuan, biltegian idatzitako byte kopuru osoa da. Idazketa (eta fdatasync) sistema-deien kopuruarekin zuzenean proportzionala izan da. bs balio jakin baterako, fdatasync deien kopurua = size/bs. Pertzentila interesatzen zitzaigunez, ziur egoteko nahikoa lagin izan behar genituen eta 10^4 nahikoa izango zela kalkulatu genuen (22 mebibyte da). --size txikiagoa bada, outlier-ak gerta daitezke (adibidez, fdatasync-eko hainbat deiak ohi baino denbora gehiago behar dute eta 99. pertzentilean eragiten dute).

Saiatu zeure burua

Fio nola erabiltzen den erakutsi dizugu eta biltegiratzeak errendimendu handiko eta abarretarako nahikoa abiadura duen ikusi genuen. Orain zuk zeuk proba dezakezu, adibidez, SSD biltegiratzea duten makina birtualak erabiliz IBM Cloud.

Iturria: www.habr.com

Gehitu iruzkin berria