Giunsa pagsusi ang mga disk nga adunay fio alang sa igo nga pasundayag alang sa etcd

Nota. transl.: Kini nga artikulo mao ang mga resulta sa usa ka mini-research nga gihimo sa IBM Cloud engineers sa pagpangita sa usa ka solusyon sa usa ka tinuod nga problema nga may kalabutan sa operasyon sa etcd database. Ang susama nga buluhaton may kalabutan alang kanamo, apan ang dagan sa mga hunahuna ug mga aksyon sa mga tagsulat mahimong makapaikag sa usa ka mas lapad nga konteksto.

Mubo nga summary sa tibuok artikulo: fio ug etcd

Ang pasundayag sa usa ka etcd cluster nagsalig kaayo sa katulin sa nagpahiping pagtipig. Aron mamonitor ang performance, etcd exports lain-laing Prometheus metrics. Usa niini mao ang wal_fsync_duration_seconds. Sa etcd dokumentasyon kini nag-ingon, kana nga pagtipig mahimong makonsiderar nga paspas kung ang ika-99 nga porsyento sa kini nga sukatan dili molapas sa 10 ms...

Kung naghunahuna ka nga magbutang usa ka etcd cluster sa mga makina sa Linux ug gusto nimo nga sulayan kung ang mga drive sa pagtipig (sama sa mga SSD) kusog ba, girekomenda namon ang paggamit sa usa ka sikat nga I/O tester nga gitawag. fio. Pagdalagan lang ang mosunod nga sugo (directory test-data kinahanglan nga mahimutang sa gitaod nga partition sa drive nga gisulayan):

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

Ang nahabilin mao ang pagtan-aw sa output ug susihon kung mohaum ba kini sa ika-99 nga porsyento fdatasync sa 10 ms. Kon mao, ang imong pagdrayb dali ra kaayo. Ania ang usa ka pananglitan nga output:

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]

Pipila ka mga nota:

1. Sa panig-ingnan sa ibabaw among gi-adjust ang mga parameter --size и --bs alang sa usa ka piho nga kaso. Aron makuha ang makahuluganon nga mga resulta gikan sa fio, ipiho ang mga kantidad nga angay alang sa imong kaso sa paggamit. Sa unsa nga paagi sa pagpili kanila hisgotan sa ubos.
2. Atol sa pagsulay lamang fio nagkarga sa disk subsystem. Sa tinuud nga kinabuhi, lagmit nga ang ubang mga proseso (gawas sa mga kauban sa wal_fsync_duration_seconds). Ang ingon nga dugang nga load mahimong mosangpot sa pagtaas sa wal_fsync_duration_seconds. Sa laing pagkasulti, kung ang ika-99 nga porsyento nga nakuha gikan sa pagsulay sa fio, gamay ra nga ubos sa 10 ms, adunay usa ka maayo nga higayon nga ang pasundayag sa pagtipig dili igo.
3. Alang sa pagsulay kinahanglan nimo ang bersyon fio dili moubus sa 3.5, tungod kay ang daan nga mga bersyon wala maghiusa sa mga resulta fdatasync sa porma sa mga porsyento.
4. Ang konklusyon sa ibabaw gamay ra nga kinutlo sa kinatibuk-ang konklusyon fio.

Mga detalye bahin sa fio ug etcd

Pipila ka mga pulong mahitungod sa WALs etcd

Kasagaran, gigamit ang mga database proactive logging (write-ahead logging, WAL). etcd kini magamit usab. Ang diskusyon sa WAL kay lapas pa sa sakup niini nga artikulo, apan para sa among mga katuyoan ania ang kinahanglan nimong masayran: Ang matag miyembro sa cluster sa etcd nagtipig sa WAL sa padayon nga pagtipig. etcd nagsulat sa pipila ka importante nga bili nga mga operasyon sa tindahan (sama sa mga update) ngadto sa WAL sa dili pa kini ipatuman. Kung ang usa ka node nahagsa ug nagsugod pag-usab tali sa mga snapshot, etcd mahimong ibalik ang mga transaksyon nga gihimo sukad sa miaging snapshot base sa mga sulod sa WAL.

Sa ingon, sa matag higayon nga ang usa ka kliyente magdugang usa ka yawe sa tindahan sa KV o mag-update sa kantidad sa usa ka naglungtad nga yawe, etcd nagdugang usa ka paghulagway sa operasyon sa WAL, nga usa ka regular nga file sa padayon nga pagtipig. etcd KINAHANGLANG 100% sigurado nga ang WAL entry aktuwal nga na-save sa dili pa magpadayon. Aron makab-ot kini sa Linux, dili igo ang paggamit sa usa ka tawag sa sistema write, tungod kay ang pagsulat nga operasyon mismo sa pisikal nga medium mahimong malangan. Pananglitan, ang Linux mahimong magtipig og WAL entry sa kernel cache sa memorya (sama sa page cache) sulod sa pipila ka panahon. Aron masiguro nga ang datos gisulat sa media, ang usa ka tawag sa sistema kinahanglan nga tawagan pagkahuman sa pagsulat fdatasync - mao gayud kini ang gibuhat sa etcd (ingon sa makita sa mosunod nga output strace; Dinhi 8 - WAL file handle):

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>

Ikasubo, ang pagsulat sa padayon nga pagtipig nagkinahanglag panahon. Ang pagdugay sa pagkompleto sa fdatasync nga tawag mahimong makaapekto sa etcd performance. Sa dokumentasyon para sa repositoryo gipakitanga alang sa igo nga performance gikinahanglan nga ang 99th percentile sa gidugayon sa tanan nga mga tawag fdatasync kung nagsulat sa usa ka file, ang WAL wala’y 10 ms. Adunay uban pang mga sukatan nga may kalabutan sa pagtipig, apan kini nga artikulo magpunting niini.

Pag-evaluate sa storage gamit ang fio

Mahimo nimo mahibal-an kung ang usa ka piho nga pagtipig angay ba gamiton uban ang etcd gamit ang utility fio - usa ka sikat nga I/O tester. Hinumdomi nga ang disk I/O mahimong mahitabo sa lain-laing mga paagi: pag-sync/async, daghang lain-laing klase sa mga tawag sa sistema, ug uban pa. Ang pikas bahin sa sensilyo mao kana fio lisod kaayo gamiton. Ang utility adunay daghang mga parameter, ug ang lainlaing mga kombinasyon sa ilang mga kantidad nagdala sa hingpit nga lainlaing mga sangputanan. Aron makakuha usa ka makatarunganon nga pagbanabana alang sa etcd, kinahanglan nimo nga sigurohon nga ang pag-load sa pagsulat nga namugna sa fio parehas kutob sa mahimo sa pagkarga sa pagsulat sa etcd sa mga file sa WAL:

• Kini nagpasabot nga ang namugna fio ang workload kinahanglan nga labing menos usa ka serye sa mga sunud-sunod nga pagsulat sa usa ka file, diin ang matag operasyon sa pagsulat naglangkob sa usa ka tawag sa sistema writegisundan sa fdatasync.
• Aron mahimo ang sunud-sunod nga pagrekord, kinahanglan nimong ipiho ang bandila --rw=write.
• nga fio nagsulat gamit ang mga tawag write (ug dili sa ubang mga tawag sa sistema - pananglitan, pwrite), gamita ang bandera --ioengine=sync.
• Sa katapusan, ang bandila --fdatasync=1 garantiya nga luyo sa matag write kinahanglan fdatasync.
• Duha pa ka mga parameter sa among pananglitan: --size и --bs - mahimong magkalainlain depende sa piho nga kaso sa paggamit. Ang sunod nga seksyon maghulagway kung giunsa kini i-configure.

Nganong gipili namo ang fio ug giunsa namo pagkat-on unsaon pag-set up niini

Kini nga nota gikan sa tinuod nga kaso nga among nasugatan. Kami adunay usa ka cluster sa Kubernetes v1.13 uban sa pagmonitor sa Prometheus. Ang mga solid state drive gigamit isip storage alang sa etcd v3.2.24. etcd metrics nagpakita ug taas kaayo nga latency fdatasync, bisan kung ang cluster walay trabaho. Nakit-an namon nga kini nga mga sukatan kwestyonable kaayo ug dili kami sigurado kung unsa gyud ang girepresentahan niini. Dugang pa, ang cluster naglangkob sa mga virtual machine, mao nga imposible nga mahibal-an kung ang paglangan tungod sa virtualization o ang mga SSD ang mabasol.

Dugang pa, nagtan-aw kami sa lainlaing mga pagbag-o sa mga pag-configure sa hardware ug software, mao nga nanginahanglan kami usa ka paagi aron masusi kini. Siyempre, posible nga modagan etcd sa matag configuration ug tan-awon ang katugbang nga Prometheus metrics, pero magkinahanglan kini og dakong paningkamot. Nagkinahanglan kami og usa ka yano nga paagi sa pagtimbang-timbang sa usa ka piho nga configuration. Gusto namong sulayan ang among pagsabot sa Prometheus metrics gikan sa etcd.

Aron mahimo kini, duha ka mga problema ang kinahanglan masulbad:

• Una, unsa ang hitsura sa I/O load nga etcd sa pagsulat sa WAL files? Unsa nga mga tawag sa sistema ang gigamit? Unsa ang gidak-on sa pagsulat block?
• Ikaduha, ingnon ta nga kita adunay mga tubag sa mga pangutana sa ibabaw. Sa unsa nga paagi sa pag-reproduce sa katugbang nga load sa fio? Human sa tanan fio - hilabihan ka flexible utility nga adunay daghang mga parameter (kini sayon ​​​​sa pag-verify, pananglitan, dinhi — gibanabana. transl.).

Nasulbad namo ang duha ka problema gamit ang parehas nga command-based approach lsof и strace:

• Uban sa tabang sa lsof Mahimo nimong tan-awon ang tanan nga mga deskriptor sa file nga gigamit sa usa ka proseso, ingon man ang mga file nga ilang gitumong.
• Uban sa tabang sa strace mahimo nimong analisahon ang usa na nga nagdagan nga proseso o magpadagan sa usa ka proseso ug obserbahan kini. Gipakita sa command ang tanang tawag sa sistema nga gihimo niini nga proseso ug, opsyonal, ang mga kaliwat niini. Ang ulahi hinungdanon alang sa mga proseso nga nag-forking, ug ang etcd usa sa mga proseso.

Ang una namong gibuhat mao ang paggamit strace aron tun-an ang etcd server sa Kubernetes cluster samtang kini walay pulos.

Busa, nadiskobrehan nga ang mga bloke sa pagsulat sa WAL hilabihan ka dense nga grupo, ang kadaghanan niini anaa sa han-ay sa 2200-2400 bytes. Mao kini ang hinungdan nga ang sugo sa sinugdanan niini nga artikulo naggamit sa bandila --bs=2300 (bs - gidak-on sa bytes sa matag recording block sa fio).

Palihug timan-i nga ang etcd write block sizes mahimong magkalahi depende sa version, deployment, parameter values, etc. - kini makaapekto sa gidugayon fdatasync. Kung adunay ka parehas nga kaso sa paggamit, analisa gamit ang strace imong etcd nga mga proseso aron makuha ang pinakabag-o nga mga kantidad.

Pagkahuman, aron makakuha usa ka tin-aw ug komprehensibo nga pagsabut kung giunsa ang etcd nagtrabaho sa file system, gipadagan namon kini gikan sa ilawom strace uban sa mga bandera -ffttT. Kini nagpaposible nga makuha ang mga proseso sa bata ug isulat ang output sa matag usa sa usa ka lahi nga file. Dugang pa, nakuha ang detalyado nga kasayuran bahin sa pagsugod sa oras ug gidugayon sa matag tawag sa sistema.

Gigamit usab namo ang sugo lsofaron makumpirma ang imong pagsabut sa output strace sa mga termino kung unsang file descriptor ang gigamit alang sa unsang katuyoan. Ang resulta mao strace, susama sa usa sa ibabaw. Ang mga pagmaniobra sa istatistika nga adunay mga oras sa pag-synchronize nagpamatuod nga ang sukatan wal_fsync_duration_seconds gikan sa etcd matches nga mga tawag fdatasync uban sa WAL file descriptors.

Aron makamugna gamit fio workload nga susama sa load gikan sa etcd, ang utility documentation gitun-an ug mga parameter nga angay sa among buluhaton gipili. Among gisiguro nga ang husto nga mga tawag sa sistema nahilambigit ug gikumpirma ang ilang gidugayon pinaagi sa pagdagan fio gikan sa strace (sama sa gibuhat sa kaso sa etcd).

Ang partikular nga pagtagad gihatag sa pagtino sa bili sa parameter --size. Kini nagrepresentar sa kinatibuk-ang I/O load nga namugna sa fio utility. Sa among kaso, kini ang kinatibuk-ang gidaghanon sa mga byte nga gisulat sa media. Kini direkta nga proporsyonal sa gidaghanon sa mga tawag write (ug fdatasync). Alang sa usa ka piho bs gidaghanon sa mga tawag fdatasync managsama size / bs.

Tungod kay kami interesado sa percentile, among gitinguha nga masiguro nga ang gidaghanon sa mga sample igo nga dako alang sa statistical significance. Ug nakahukom sila niana 10^4 (nga katumbas sa gidak-on nga 22 MB) igo na. Gamay nga mga kantidad sa parameter --size naghimo og mas klaro nga kasaba (pananglitan, mga tawag fdatasync, nga mas dugay kay sa naandan ug makaapekto sa 99th percentile).

Bahala na nimo

Gipakita sa artikulo kung giunsa paggamit fio mahimo nimong susihon kung ang media nga gituyo alang sa paggamit sa etcd igo nga kusog. Karon naa na sa imoha! Mahimo nimong susihon ang mga virtual nga makina nga adunay pagtipig nga nakabase sa SSD sa serbisyo IBM Cloud.

PS gikan sa tighubad

Uban ang andam nga mga pananglitan sa paggamit fio para sa pagsulbad sa ubang mga problema makita sa dokumentasyon o direkta sa mga repositoryo sa proyekto (adunay daghan pa kanila didto kay sa gihisgutan sa dokumentasyon).

PPS gikan sa tighubad

Basaha usab sa among blog:

• «etcd 3.4.3: pagtuon sa kasaligan ug seguridad sa pagtipig";
• «Ang among kasinatian nga nagtrabaho sa datos sa etcd Kubernetes cluster direkta (walay K8s API)";
• «6 makapaikag nga mga bug sa sistema kung gigamit ang Kubernetes [ug ilang mga solusyon]".

Source: www.habr.com