🥇Nola egiaztatu fio duten diskoak etcd

Ohar. itzul.: Artikulu hau IBM Cloud-eko ingeniariek etcd datu-basearen funtzionamenduarekin lotutako arazo erreal bati irtenbidea bilatzeko egindako mini-ikerketaren emaitza da. Antzeko zeregina garrantzitsua zen guretzat, hala ere, egileen hausnarketen eta ekintzen ibilbidea interesgarria izan daiteke testuinguru zabalago batean.

Artikulu osoaren laburpen laburra: fio eta etcd

Etcd kluster baten errendimendua azpiko biltegiratze abiaduraren menpe dago. etcd-ek Prometheus-en hainbat metrika esportatzen ditu errendimendua kontrolatzeko. Horietako bat da wal_fsync_duration_seconds. etabrako dokumentazioan diobiltegiratze hori nahikoa azkartzat har daiteke metrika honen 99. pertzentilak 10 ms gainditzen ez badu...

Linux makinetan etcd kluster bat konfiguratzea pentsatzen ari bazara eta unitateak (adibidez, SSDak) nahikoa azkarrak diren ala ez probatu nahi baduzu, I/O probatzaile ezaguna erabiltzea gomendatzen dugu. FIO. Nahikoa da hurrengo komandoa (direktorioa test-data probatutako diskoaren muntatutako partizioan kokatu behar da):

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

Irteera begiratu eta 99. pertzentilea egokitzen den egiaztatzea besterik ez da geratzen fdatasync 10 ms-tan. Hala bada, zure diskoa nahikoa azkar dabil. Hona hemen irteera adibide bat:

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]

Ohar batzuk:

Goiko adibidean, parametroak egokitu ditugu --size и --bs kasu zehatz baterako. Emaitza esanguratsu bat lortzeko fio, zehaztu zure erabilera kasurako egokiak diren balioak. Horiek nola aukeratu jarraian eztabaidatuko da.
Probetan soilik fio diskoaren azpisistema kargatzen du. Bizitza errealean, litekeena da beste prozesu batzuek diskoan idaztea (ekin zerikusia dutenez gain wal_fsync_duration_seconds). Karga gehigarri hori handitu daiteke wal_fsync_duration_seconds. Beste era batera esanda, 99. pertzentila bada probak fio, 10 ms baino apur bat gutxiago, aukera ona dago biltegiratze-errendimendua nahikoa ez izateko.
Proba egiteko bertsioa beharko duzu fio ez 3.5 baino gutxiago, bertsio zaharragoek ez dituztelako emaitzak biltzen fdatasync pertzentilen moduan.
Goiko ondorioa ondorio orokorraren zati txiki bat baino ez da fio.

Fio eta etcd-i buruz gehiago

WALei buruz hitz batzuk etab

Orokorrean, datu-baseak erabiltzen dira erregistro proaktiboa (idatzi aurretiko erregistroa, WAL). etcd-k ere eragiten du. WAL-en eztabaida artikulu honen esparrutik kanpo dago, baina gure helburuetarako, jakin behar duzuna da etcd klusterreko kide bakoitzak WAL biltegiratze iraunkor batean gordetzen duela. etcd-k gako-balioen biltegiratze-eragiketa batzuk (adibidez, eguneraketak) idazten ditu WALen exekutatu aurretik. Nodo bat huts egiten bada eta argazkien artean berrabiarazten bada, etcd-k aurreko argazkitik aurrera egindako transakzioak berreskura ditzake WAL-eko edukietan oinarrituta.

Horrela, bezero batek KV dendan gako bat gehitzen duen bakoitzean edo lehendik dagoen gako baten balioa eguneratzen duen bakoitzean, etcd-k eragiketaren deskribapena gehitzen du WAL-era, hau da, denda iraunkorreko fitxategi arrunta dena. etcd-k % 100 ziur egon behar du WAL sarrera benetan gorde dela aurrera jarraitu aurretik. Linux-en hori lortzeko, ez da nahikoa sistema-deia erabiltzea write, euskarri fisikoan idazteko eragiketa bera atzeratu daitekeelako. Adibidez, Linuxek WAL sarrera bat gorde dezake memoriako nukleoko cache batean (adibidez, orrialdeko cachean) denbora batez. Datuak euskarrietan idazten direla ziurtatzeko, sistema-dei bat deitu behar da idatzi ondoren fdatasync - hau da etcd-k egiten duena (ondoko irteeran ikus dezakezun bezala strace; Hemen 8 - WAL fitxategiaren deskribatzailea):

21:23:09.894875 lseek(8, 0, SEEK_CUR)   = 12808 <0.000012>
21:23:09.894911 write(8, ".20210220361223255266632$1020103026"34"rn3fo"..., 2296) = 2296 <0.000130>
21:23:09.895041 fdatasync(8)            = 0 <0.008314>

Zoritxarrez, biltegiratze iraunkorrean idazteak denbora pixka bat behar du. fdatasync deien exekuzio luzeak etcd-ren errendimenduan eragina izan dezake. Biltegiko dokumentazioan adierazi, nahikoa errendimendurako beharrezkoa dela deialdi guztien iraupenaren 99. pertzentilea fdatasync WAL fitxategi batean idaztean 10 ms baino gutxiagokoa izan zen. Biltegiratzearekin lotutako beste neurketa batzuk daude, baina artikulu hau horretan zentratuko da.

Biltegiratzea fio-rekin baloratuz

Biltegiratze jakin bat etcd-rekin erabiltzeko egokia den ebalua dezakezu utilitatearen bidez FIO - I/O probatzaile ezaguna. Kontuan izan diskoko I/O modu ezberdinetan gerta daitekeela: sinkronizazioa/async, syscall klase ezberdin asko eta abar. Txanponaren beste aldea hori da fio oso zaila da erabiltzeko. Erabilgarritasunak parametro asko ditu, eta haien balioen konbinazio ezberdinek emaitza guztiz desberdinak lortzen dituzte. Etcd-ren arrazoizko estimazioa lortzeko, fio-k sortutako idazketa-karga etcd-ren WAL fitxategiaren idazketa-kargatik ahalik eta hurbilen dagoela ziurtatu behar duzu:

Horrek esan nahi du sortutakoa dela fio kargak fitxategian jarraian idatzitako serie bat izan behar du gutxienez, non idazketa bakoitza sistema-dei batez osatuta dagoen writejarraitua fdatasync.
Idazketa sekuentziala gaitzeko, bandera zehaztu behar duzu --rw=write.
That fio deiak erabiliz idatzi zuen write (beste sistema-deiak baino - adibidez, pwrite), erabili bandera --ioengine=sync.
Azkenik, bandera --fdatasync=1 bakoitzak bermatzen du write beharko lukete fdatasync.
Gure adibideko beste bi parametroak hauek dira: --size и --bs - erabilera-kasu zehatzaren arabera alda daiteke. Hurrengo atalean haien konfigurazioa deskribatuko da.

Zergatik aukeratu genuen fio eta nola konfiguratzen ikasi genuen

Ohar hau aurkitu genuen kasu erreal batetik dator. Kubernetes v1.13-n kluster bat genuen Prometheus-en jarraipenarekin. SSDak biltegiratze gisa erabili ziren etcd v3.2.24. Etcd metrik latentzia handiegiak erakutsi zituzten fdatasync, nahiz eta klusterra inaktibo zegoenean. Guri, neurri horiek oso zalantzazkoak iruditu zitzaizkigun, eta ez genekien ziur zer adierazten zuten zehazki. Gainera, klusterrak makina birtualez osatuta zegoen, beraz, ezin izan zen esan atzerapena birtualizazioaren ondorioz izan zen edo SSDaren errua.

Horrez gain, hardwarearen eta softwarearen konfigurazioan hainbat aldaketa kontuan hartu genituen, beraz, horiek ebaluatzeko modu bat behar genuen. Jakina, posible izango litzateke etcd exekutatu konfigurazio bakoitzean eta dagozkion Prometheus-en neurketak aztertzea, baina horrek ahalegin handia eskatuko luke. Behar genuena konfigurazio zehatz bat ebaluatzeko modu erraz bat zen. Etcd-etik datozen Prometheus-en neurketen ulermena probatu nahi genuen.

Honek bi arazo ebaztea eskatzen zuen:

Lehenik eta behin, nolakoa da etcd-k sortutako I/O karga WAL fitxategietan idaztean? Zein sistema-dei erabiltzen dira? Zein da erregistro-blokeen tamaina?
Bigarrenik, demagun goiko galderei erantzunak ditugula. Nola erreproduzitu dagokion karga fio? Azken finean fio — Oso erabilgarritasun malgua, parametro ugarirekin (hau egiaztatzea erraza da, adibidez, Hemen - gutxi gorabehera. itzul.).

Arazo biak komandoetan oinarritutako ikuspegi berarekin konpondu ditugu lsof и strace:

With lsof prozesuak erabilitako fitxategi-deskribatzaile guztiak ikus ditzakezu, baita haiek aipatzen dituzten fitxategiak ere.
With strace dagoeneko martxan dagoen prozesu bat azter dezakezu edo prozesu bat exekutatu eta ikusi. Komandoak prozesu honek egindako sistema-dei guztiak eta, behar izanez gero, bere ondorengoak bistaratzen ditu. Azken hau garrantzitsua da bifurkazioa egiten duten prozesuetarako, eta etcd prozesu horietako bat da.

Egin genuen lehenengo gauza erabiltzea izan zen strace inaktibo zegoen bitartean Kubernetes klusterreko etcd zerbitzaria aztertzeko.

Beraz, WAL erregistro-blokeak oso trinko multzokatuta daudela aurkitu zen, gehiengoaren tamaina 2200-2400 byte artekoa zen. Horregatik, artikulu honen hasierako komandoak bandera erabiltzen du --bs=2300 (bs idazketa-bloke bakoitzaren byte-tamaina da fio).

Kontuan izan etcd idazteko blokeen tamaina alda daitekeela bertsioaren, hedapenaren, parametroen balioen eta abarren arabera. - iraupenari eragiten dio fdatasync. Antzeko erabilera kasu bat baduzu, aztertu honekin strace zure etcd prozesuak balio eguneratuak lortzeko.

Ondoren, fitxategi-sistemarekin etcd-ek nola funtzionatzen duen argi eta zabala izateko, azpitik hasi ginen. strace banderekin -ffttT. Honek prozesu umeak harrapatzea eta bakoitzaren irteera fitxategi bereizi batean idaztea posible egin zuen. Horrez gain, sistema-dei bakoitzaren hasiera-orduari eta iraupenari buruzko informazio zehatza lortu zen.

Komandoa ere erabili dugu lsofirteeraren ulermena berresteko strace zein fitxategi deskribatzailea zein helburutarako erabili den. Ondorioa lortu dut strace, goikoaren antzekoa. Sinkronizazio denborarekin egindako manipulazio estatistikoek metrika hori baieztatu zuten wal_fsync_duration_seconds etcd-tik dator bat deietatik fdatasync WAL fitxategi deskribatzaileekin.

Sortzeko fio etcd-ren antzeko lan-karga, utilitatearen dokumentazioa aztertu eta gure zereginerako egokiak diren parametroak hautatu ziren. Sistemaren dei zuzenak abian direla egiaztatu dugu eta haien iraupena exekutatzen hasita baieztatu dugu fio - strace (etcd kasuan egin zen bezala).

Arreta berezia jarri zen parametroaren balioa zehazteari --size. Fio utilitateak sortutako I/O karga osoa adierazten du. Gure kasuan, komunikabideetan idatzitako byte kopurua da. Dei kopuruarekin zuzenean proportzionala da write (eta fdatasync). Espezifiko baterako bs dei kopurua fdatasync dago size / bs.

Pertzentila interesatzen zitzaigunez, lagin kopurua estatistikoki esanguratsua izateko nahikoa handia izatea nahi genuen. Eta hori erabaki zuen 10^4 (22 MB-ko tamainari dagokiona) nahikoa izango da. Parametroen balio txikiagoak --size zarata nabarmenagoa eman zuen (adibidez, deiak fdatasync, ohi baino askoz gehiago irauten dutenak eta 99. pertzentilean eragiten dutenak).

Zure esku dago

Artikuluak nola erabili erakusten du fio etcd-rekin erabiltzeko pentsatutako komunikabidea nahikoa azkarra den epai daiteke. Orain zure esku dago! Zerbitzuan SSDn oinarritutako biltegiratzea duten makina birtualak arakatu ditzakezu IBM Cloud.

PS itzultzailetik

Prest egindako erabilera kasuekin fio Beste zeregin batzuetarako, ikus dokumentazioa edo zuzenean proiektuen biltegiak (dokumentazioan aipatzen direnak baino askoz gehiago daude).

PPS itzultzailearen eskutik

Irakurri ere gure blogean:

Iturria: www.habr.com

Nola egiaztatu fio duten diskoak etcd-ren errendimendu nahikoa izateko