Isang maikling kwento tungkol sa fio at etcd
Pagganap ng cluster higit sa lahat ay nakasalalay sa pagganap ng imbakan nito. etcd ay nag-export ng ilang sukatan sa upang maibigay ang nais na impormasyon sa pagganap ng imbakan. Halimbawa, ang sukatan ng wal_fsync_duration_seconds. : Para maituring na sapat na mabilis ang storage, dapat na mas mababa sa 99ms ang 10th percentile ng sukatang ito. Kung nagpaplano kang magpatakbo ng etcd cluster sa mga Linux machine at gusto mong suriin kung sapat na mabilis ang iyong storage (hal. SSD), maaari mong gamitin ay isang sikat na tool para sa pagsubok ng mga operasyon ng I/O. Patakbuhin ang sumusunod na command, kung saan ang test-data ay ang direktoryo sa ilalim ng storage mount point:
fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytestKailangan mo lang tingnan ang mga resulta at suriin kung ang ika-99 na porsyento ng tagal wala pang 10 ms. Kung gayon, mayroon kang makatuwirang mabilis na storage. Narito ang isang halimbawa ng mga resulta:
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]Mga Tala
- Na-customize namin ang --size at --bs na mga opsyon para sa aming partikular na senaryo. Upang makakuha ng kapaki-pakinabang na resulta mula sa fio, ibigay ang iyong sariling mga halaga. Saan makukuha ang mga ito? Basahin .
- Sa panahon ng pagsubok, ang lahat ng I/O load ay nagmumula sa fio. Sa totoong buhay na senaryo, malamang na may iba pang mga kahilingan sa pagsulat na darating sa storage bukod sa mga nauugnay sa wal_fsync_duration_seconds. Ang dagdag na load ay tataas ang halaga ng wal_fsync_duration_seconds. Kaya kung ang 99th percentile ay malapit sa 10ms, ang iyong storage ay nauubusan ng bilis.
- Kunin ang bersyon hindi mas mababa sa 3.5 (ang mga nauna ay hindi nagpapakita ng mga porsyento ng tagal ng fdatasync).
- Sa itaas ay isang snippet lamang ng mga resulta mula sa fio.
Mahabang kwento tungkol kay fio at etcd
Ano ang WAL sa etcd
Karaniwang ginagamit ng mga database ; ginagamit din ito ng etcd. Hindi namin tatalakayin nang detalyado ang write-ahead log (WAL) dito. Sapat na para sa amin na malaman na ang bawat miyembro ng etcd cluster ay nagpapanatili nito sa patuloy na imbakan. Ang etcd ay nagsusulat ng bawat key-value na operasyon (tulad ng isang update) sa WAL bago ito ilapat sa tindahan. Kung ang isa sa mga miyembro ng storage ay nag-crash at nag-restart sa pagitan ng mga snapshot, maaari nitong i-restore ang mga transaksyon mula noong huling snapshot ng WAL na nilalaman.
Kapag ang isang kliyente ay nagdagdag ng isang susi sa key-value store o nag-update ng halaga ng isang umiiral na key, etcd ay nagtatala ng operasyon sa WAL, na isang regular na file sa patuloy na imbakan. etcd DAPAT ganap na siguraduhin na ang WAL entry ay aktwal na nangyari bago magpatuloy sa pagproseso. Sa Linux, hindi sapat ang isang system call para dito. , dahil ang aktwal na pagsulat sa pisikal na imbakan ay maaaring maantala. Halimbawa, ang Linux ay maaaring mag-imbak ng WAL entry sa isang cache sa kernel memory (tulad ng isang page cache) nang ilang panahon. At para tumpak na maisulat ang data sa patuloy na imbakan, kailangan ang fdatasync system call pagkatapos ng pagsulat, at ginagamit lang ito ng etcd (tulad ng makikita mo sa resulta ng trabaho , kung saan ang 8 ay ang WAL file descriptor):
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>Sa kasamaang palad, ang pagsulat sa patuloy na imbakan ay hindi nangyayari kaagad. Kung ang fdatasync na tawag ay mabagal, ang pagganap ng etcd system ay magdurusa. na ang storage ay itinuturing na sapat na mabilis kung, sa ika-99 na percentile, ang mga fdatasync na tawag ay tumatagal ng mas mababa sa 10ms upang magsulat sa WAL file. Mayroong iba pang mga kapaki-pakinabang na sukatan para sa imbakan, ngunit sa post na ito ay pinag-uusapan lang natin ang sukatang ito.
Pagtatantya ng imbakan gamit ang fio
Kung kailangan mong suriin kung ang iyong storage ay angkop para sa etcd, gumamit ng fio, isang napakasikat na I/O load testing tool. Dapat tandaan na ang mga pagpapatakbo ng disk ay maaaring ibang-iba: kasabay at asynchronous, maraming klase ng mga tawag sa system, atbp. Bilang resulta, ang fio ay medyo mahirap gamitin. Mayroon itong maraming mga parameter, at ang iba't ibang mga kumbinasyon ng kanilang mga halaga ay gumagawa ng iba't ibang mga I/O workload. Upang makakuha ng sapat na mga numero para sa etcd, dapat mong tiyakin na ang test write load mula sa fio ay mas malapit hangga't maaari sa aktwal na load mula sa etcd kapag nagsusulat ng mga WAL file.
Samakatuwid, ang fio ay dapat, sa pinakamababa, lumikha ng isang load sa anyo ng isang serye ng magkakasunod na pagsusulat sa file, ang bawat pagsusulat ay binubuo ng isang tawag sa system na sinusundan ng fdatasync system call. Ang sequential writes to fio ay nangangailangan ng --rw=write na opsyon. Para magamit ni fio ang write system call kapag nagsusulat, sa halip na , dapat mong tukuyin ang --ioengine=sync parameter. Panghuli, para matawagan ang fdatasync pagkatapos ng bawat pagsusulat, kailangan mong idagdag ang --fdatasync=1 parameter. Ang iba pang dalawang opsyon sa halimbawang ito (--size at -bs) ay script-specific. Sa susunod na seksyon, ipapakita namin sa iyo kung paano i-set up ang mga ito.
Bakit eksaktong fio at kung paano namin natutunang i-set up ito
Sa post na ito, inilalarawan namin ang isang tunay na kaso. Mayroon kaming isang kumpol v1.13 na sinusubaybayan namin sa Prometheus. etcd v3.2.24 ay naka-host sa isang SSD. Ang mga sukatan ng Etcd ay nagpakita ng mga latency ng fdatasync na masyadong mataas, kahit na walang ginagawa ang cluster. Ang mga sukatan ay kakaiba at hindi namin talaga alam kung ano ang ibig sabihin ng mga ito. Ang kumpol ay binubuo ng mga virtual machine, ito ay kinakailangan upang maunawaan kung ano ang problema ay: sa pisikal na SSDs o sa virtualization layer. Bilang karagdagan, madalas kaming gumawa ng mga pagbabago sa configuration ng hardware at software, at kailangan namin ng paraan upang suriin ang kanilang mga resulta. Maaari kaming magpatakbo ng etcd sa bawat configuration at tumingin sa mga sukatan ng Prometheus, ngunit iyon ay masyadong abala. Naghahanap kami ng medyo simpleng paraan upang suriin ang isang partikular na configuration. Gusto naming suriin kung naiintindihan namin nang tama ang mga sukatan ng Prometheus mula sa etcd.
Ngunit para dito, dalawang problema ang kailangang lutasin. Una, ano ang hitsura ng I/O load na nalilikha ng etcd kapag nagsusulat sa WAL? Anong mga system call ang ginagamit? Ano ang sukat ng mga talaan? Pangalawa, kung sasagutin natin ang mga tanong na ito, paano tayo magpaparami ng katulad na workload sa fio? Huwag kalimutan na ang fio ay isang napaka-flexible na tool na may maraming mga pagpipilian. Nalutas namin ang parehong mga problema sa isang diskarte - gamit ang mga utos ΠΈ . Inililista ng lsof ang lahat ng mga deskriptor ng file na ginagamit ng proseso at ang mga nauugnay na file nito. At sa pamamagitan ng strace, maaari mong suriin ang isang tumatakbo nang proseso, o simulan ang isang proseso at suriin ito. Ini-print ng strace ang lahat ng mga tawag sa system mula sa prosesong sinusuri (at ang mga proseso ng bata nito). Ang huli ay napakahalaga, dahil ang etcd ay kumukuha lamang ng katulad na diskarte.
Una naming ginamit ang strace para i-explore ang etcd server para sa Kubernetes kapag walang load sa cluster. Nakita namin na halos lahat ng mga tala ng WAL ay halos magkapareho ang laki: 2200-2400 bytes. Samakatuwid, sa utos sa simula ng post, tinukoy namin ang parameter -bs=2300 (nangangahulugang ang bs ay ang laki sa bytes para sa bawat fio entry). Tandaan na ang laki ng etcd entry ay nakasalalay sa etcd na bersyon, pamamahagi, mga halaga ng parameter, atbp., at makakaapekto sa tagal ng fdatasync. Kung mayroon kang katulad na senaryo, suriin ang iyong mga proseso ng etcd na may strace upang malaman ang eksaktong mga numero.
Pagkatapos, upang makakuha ng isang magandang ideya kung ano ang ginagawa ng etcd file system, sinimulan namin ito sa strace at ang -ffttT na mga pagpipilian. Kaya sinubukan naming suriin ang mga proseso ng bata at itala ang output ng bawat isa sa kanila sa isang hiwalay na file, at kumuha din ng mga detalyadong ulat tungkol sa pagsisimula at tagal ng bawat tawag sa system. Ginamit namin ang lsof upang kumpirmahin ang aming pagsusuri sa strace output at makita kung aling file descriptor ang ginagamit para sa kung anong layunin. Kaya sa tulong ng strace, nakuha ang mga resultang ipinakita sa itaas. Kinumpirma ng mga istatistika ng oras ng pag-synchronize na ang wal_fsync_duration_seconds mula sa etcd ay pare-pareho sa mga fdatasync na tawag na may mga WAL file descriptor.
Dumaan kami sa dokumentasyon para sa fio at pumili ng mga opsyon para sa aming script upang ang fio ay makabuo ng load na katulad ng etcd. Sinuri din namin ang mga tawag sa system at ang tagal ng mga ito sa pamamagitan ng pagpapatakbo ng fio mula sa strace, katulad ng etcd.
Maingat naming pinili ang halaga ng --size na parameter upang kumatawan sa buong I/O load mula sa fio. Sa aming kaso, ito ang kabuuang bilang ng mga byte na nakasulat sa storage. Ito ay naging direktang proporsyonal sa bilang ng mga write (at fdatasync) na tawag sa system. Para sa isang tiyak na halaga ng bs, ang bilang ng mga fdatasync na tawag = laki/bs. Dahil interesado kami sa percentile, kailangan naming magkaroon ng sapat na sample para makasigurado, at kinalkula namin na 10^4 ang magiging sapat para sa amin (22 mebibytes iyon). Kung mas maliit ang --size, maaaring magkaroon ng mga outlier (halimbawa, mas matagal ang ilang fdatasync na tawag kaysa karaniwan at makakaapekto sa 99th percentile).
Subukan ito sa iyong sarili
Ipinakita namin sa iyo kung paano gamitin ang fio at tingnan kung sapat na mabilis ang storage para gumanap nang maayos ang etcd. Ngayon ay maaari mo na itong subukan para sa iyong sarili gamit, halimbawa, mga virtual machine na may SSD storage in .
Pinagmulan: www.habr.com