🥇Paano suriin ang mga disk na may fio para sa sapat na pagganap para sa etcd

Tandaan. transl.: Ang artikulong ito ay resulta ng isang mini-research na isinagawa ng mga inhinyero ng IBM Cloud sa paghahanap ng solusyon sa isang tunay na problema na nauugnay sa pagpapatakbo ng etcd database. Ang isang katulad na gawain ay may kaugnayan para sa amin, gayunpaman, ang kurso ng mga pagmumuni-muni at pagkilos ng mga may-akda ay maaaring maging kawili-wili sa isang mas malawak na konteksto.

Maikling buod ng buong artikulo: fio at etcd

Ang pagganap ng isang etcd cluster ay lubos na nakadepende sa bilis ng pinagbabatayan na imbakan. etcd ay nag-e-export ng iba't ibang sukatan ng Prometheus upang subaybayan ang pagganap. Ang isa sa kanila ay wal_fsync_duration_seconds. Sa dokumentasyon para sa etcd sabi nitomaituturing na sapat na mabilis ang storage kung hindi lalampas sa 99 ms ang 10th percentile ng sukatang ito...

Kung isinasaalang-alang mo ang pag-set up ng etcd cluster sa mga Linux machine at gusto mong subukan kung ang mga drive (gaya ng mga SSD) ay sapat na mabilis, inirerekomenda namin ang paggamit ng sikat na I/O tester na tinatawag na sinulid. Ito ay sapat na upang patakbuhin ang sumusunod na command (directory test-data dapat na matatagpuan sa naka-mount na partition ng nasubok na drive):

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

Ito ay nananatiling lamang upang tingnan ang output at suriin kung ang 99th percentile ay akma fdatasync sa 10 ms. Kung gayon, kung gayon ang iyong drive ay gumagana nang mabilis. Narito ang isang halimbawang 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]

Ilang tala:

Sa halimbawa sa itaas, inayos namin ang mga parameter --size и --bs para sa isang partikular na kaso. Upang makakuha ng makabuluhang resulta mula sa fio, tukuyin ang mga halaga na naaangkop para sa iyong kaso ng paggamit. Kung paano pipiliin ang mga ito ay tatalakayin sa ibaba.
Sa panahon ng pagsubok lamang fio nilo-load ang disk subsystem. Sa totoong buhay, malamang na ang ibang mga proseso ay magsusulat sa disk (bukod sa mga nauugnay sa wal_fsync_duration_seconds). Maaaring tumaas ang karagdagang load na ito wal_fsync_duration_seconds. Sa madaling salita, kung ang 99th percentile mula sa pagsubok sa fio, mas mababa lang ng kaunti sa 10 ms, malaki ang posibilidad na hindi sapat ang performance ng storage.
Para sa pagsubok kakailanganin mo ang bersyon fio hindi mas mababa sa 3.5, dahil hindi pinagsasama-sama ng mga mas lumang bersyon ang mga resulta fdatasync sa anyo ng mga percentile.
Ang konklusyon sa itaas ay isang maliit na sipi lamang mula sa pangkalahatang konklusyon fio.

Higit pa tungkol sa fio at etcd

Ilang salita tungkol sa mga WAL atbp

Sa pangkalahatan, ginagamit ng mga database aktibong pag-log (write-ahead logging, WAL). etcd ay apektado din. Ang talakayan ng WAL ay lampas sa saklaw ng artikulong ito, ngunit para sa aming mga layunin, ang kailangan mong malaman ay ang bawat miyembro ng etcd cluster ay nag-iimbak ng WAL sa patuloy na imbakan. etcd ay nagsusulat ng ilang key-value storage operations (tulad ng mga update) sa WAL bago isagawa ang mga ito. Kung ang isang node ay nag-crash at nag-restart sa pagitan ng mga snapshot, etcd ay maaaring mabawi ang mga transaksyon mula noong nakaraang snapshot batay sa mga nilalaman ng WAL.

Kaya, sa bawat oras na ang isang kliyente ay nagdaragdag ng isang susi sa KV store o nag-a-update ng halaga ng isang umiiral na susi, atbp. etcd DAPAT 100% sigurado na ang WAL entry ay talagang na-save bago magpatuloy. Upang makamit ito sa Linux, hindi sapat na gamitin ang system call write, dahil ang write operation mismo sa pisikal na media ay maaaring maantala. Halimbawa, maaaring panatilihin ng Linux ang isang WAL entry sa isang in-memory na kernel cache (hal., sa page cache) nang ilang panahon. Upang matiyak na ang data ay isinulat sa media, ang isang tawag sa system ay dapat i-invoke pagkatapos ng pagsulat fdatasync - ito mismo ang ginagawa ng etcd (tulad ng makikita mo sa sumusunod na output strace; Dito 8 - Deskriptor ng WAL file):

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>

Sa kasamaang palad, ang pagsulat sa patuloy na imbakan ay tumatagal ng ilang oras. Ang matagal na pagpapatupad ng mga fdatasync na tawag ay maaaring makaapekto sa pagganap ng etcd. Sa dokumentasyon ng repositoryo ipinahiwatig, na para sa sapat na pagganap kinakailangan na ang ika-99 na porsyento ng tagal ng lahat ng mga tawag fdatasync kapag ang pagsulat sa isang WAL file ay mas mababa sa 10 ms. Mayroong iba pang mga sukatan na nauugnay sa storage, ngunit ang artikulong ito ay tututuon sa isang ito.

Pinahahalagahan ang imbakan gamit ang fio

Maaari mong suriin kung ang isang tiyak na imbakan ay angkop para sa paggamit sa etcd gamit ang utility sinulid — isang sikat na I/O tester. Tandaan na ang disk I/O ay maaaring mangyari sa maraming iba't ibang paraan: sync/async, maraming iba't ibang klase ng syscall, at iba pa. Ang kabilang panig ng barya ay iyon fio lubhang mahirap gamitin. Ang utility ay may maraming mga parameter, at ang iba't ibang mga kumbinasyon ng kanilang mga halaga ay humahantong sa ganap na magkakaibang mga resulta. Upang makakuha ng makatwirang pagtatantya para sa etcd, kailangan mong tiyakin na ang write load na nabuo ng fio ay mas malapit hangga't maaari sa WAL file write load ng etcd:

Nangangahulugan ito na ang nabuo fio ang pag-load ay dapat na hindi bababa sa isang serye ng magkakasunod na pagsusulat sa file, kung saan ang bawat pagsulat ay binubuo ng isang tawag sa system writesinundan ng fdatasync.
Upang paganahin ang sunud-sunod na pagsulat, dapat mong tukuyin ang bandila --rw=write.
Na fio nagsulat gamit ang mga tawag write (sa halip na iba pang mga tawag sa system - halimbawa, pwrite), gamitin ang watawat --ioengine=sync.
Sa wakas, ang bandila --fdatasync=1 sinisiguro na ang bawat write dapat fdatasync.
Ang iba pang dalawang parameter sa aming halimbawa ay: --size и --bs - maaaring mag-iba depende sa partikular na kaso ng paggamit. Ilalarawan ng susunod na seksyon ang kanilang pagsasaayos.

Bakit namin pinili ang fio at kung paano namin natutunan kung paano ito i-set up

Ang tala na ito ay nagmula sa isang tunay na kaso na aming nakatagpo. Nagkaroon kami ng cluster sa Kubernetes v1.13 na may pagsubaybay sa Prometheus. Ginamit ang mga SSD bilang imbakan para sa etcd v3.2.24. Ang mga sukatan ng etccd ay nagpakita ng masyadong mataas na mga latency fdatasync, kahit na ang cluster ay idle. Para sa amin, ang mga sukatan na ito ay tila napaka-duda, at hindi kami sigurado kung ano ang eksaktong kinakatawan ng mga ito. Bilang karagdagan, ang cluster ay binubuo ng mga virtual machine, kaya hindi posibleng sabihin kung ang pagkaantala ay dahil sa virtualization o ang SSD ang dapat sisihin.

Bilang karagdagan, isinasaalang-alang namin ang iba't ibang mga pagbabago sa configuration ng hardware at software, kaya kailangan namin ng paraan upang suriin ang mga ito. Siyempre, posibleng magpatakbo ng etcd sa bawat configuration at tingnan ang kaukulang mga sukatan ng Prometheus, ngunit mangangailangan iyon ng malaking pagsisikap. Ang kailangan namin ay isang simpleng paraan upang suriin ang isang partikular na configuration. Nais naming subukan ang aming pag-unawa sa mga sukatan ng Prometheus na nagmumula sa etcd.

Nangangailangan ito ng paglutas ng dalawang problema:

Una, ano ang hitsura ng I/O load na nabuo ng etcd kapag nagsusulat sa mga WAL file? Anong mga system call ang ginagamit? Ano ang sukat ng mga bloke ng rekord?
Pangalawa, sabihin nating mayroon tayong mga sagot sa mga tanong sa itaas. Paano i-reproduce ang kaukulang load sa fio? Kung tutuusin fio — lubhang nababaluktot na utility na may kasaganaan ng mga parameter (ito ay madaling i-verify, halimbawa, dito - tinatayang. transl.).

Nalutas namin ang parehong mga problema gamit ang parehong command-based na diskarte lsof и strace:

May lsof Maaari mong tingnan ang lahat ng mga deskriptor ng file na ginagamit ng isang proseso, pati na rin ang mga file na kanilang tinutukoy.
May strace maaari mong suriin ang isang tumatakbo nang proseso o magpatakbo ng isang proseso at panoorin ito. Ang utos ay nagpapakita ng lahat ng mga tawag sa system na ginawa ng prosesong ito at, kung kinakailangan, ang mga inapo nito. Ang huli ay mahalaga para sa mga proseso na nagsasawang, at ang etcd ay isa sa gayong proseso.

Ang una naming ginawa ay gumamit strace upang suriin ang etcd server sa Kubernetes cluster habang ito ay idle.

Kaya't napag-alaman na ang mga bloke ng rekord ng WAL ay napakakapal na nakapangkat, ang laki ng karamihan ay nasa hanay na 2200-2400 bytes. Kaya naman ang utos sa simula ng artikulong ito ay gumagamit ng bandila --bs=2300 (bs ay ang laki sa bytes ng bawat write block sa fio).

Pakitandaan na ang laki ng etcd write blocks ay maaaring mag-iba depende sa bersyon, deployment, mga value ng parameter, atbp. - ito ay nakakaapekto sa tagal fdatasync. Kung mayroon kang katulad na kaso ng paggamit, pag-aralan gamit ang strace ang iyong mga proseso ng etcd upang makakuha ng up-to-date na mga halaga.

Pagkatapos, upang makakuha ng malinaw at komprehensibong ideya kung paano gumagana ang etcd sa file system, sinimulan namin ito mula sa ilalim strace may mga watawat -ffttT. Ginawa nitong posible na makuha ang mga proseso ng bata at isulat ang output ng bawat isa sa isang hiwalay na file. Bilang karagdagan, nakuha ang detalyadong impormasyon tungkol sa oras ng pagsisimula at tagal ng bawat tawag sa system.

Ginamit din namin ang utos lsofupang kumpirmahin ang iyong pag-unawa sa output strace sa mga tuntunin kung aling file descriptor ang ginamit para sa kung anong layunin. Nakuha ko ang konklusyon strace, katulad ng nasa itaas. Ang mga pagmamanipula ng istatistika na may mga oras ng pag-synchronize ay nakumpirma na ang sukatan wal_fsync_duration_seconds mula sa etcd tumutugma sa mga tawag fdatasync may mga deskriptor ng WAL file.

Upang bumuo ng may fio isang workload na katulad ng mula sa etcd, pinag-aralan ang dokumentasyon ng utility at napili ang mga parameter na angkop para sa aming gawain. Na-verify namin na ang mga tamang tawag sa system ay isinasagawa at nakumpirma ang tagal ng mga ito sa pamamagitan ng pagtakbo fio ng strace (tulad ng ginawa sa kaso ng etcd).

Ang partikular na atensyon ay binayaran sa pagtukoy ng halaga ng parameter --size. Kinakatawan nito ang kabuuang I/O load na nabuo ng fio utility. Sa aming kaso, ito ang kabuuang bilang ng mga byte na isinulat sa media. Ito ay direktang proporsyonal sa bilang ng mga tawag write (at fdatasync). Para sa isang tiyak bs bilang ng mga tawag fdatasync katumbas ng size / bs.

Dahil interesado kami sa percentile, gusto namin na ang bilang ng mga sample ay sapat na malaki upang maging makabuluhan sa istatistika. At nagpasya iyon 10^4 (na tumutugma sa isang sukat na 22 MB) ay sapat na. Mas maliit na mga halaga ng parameter --size nagbigay ng mas malinaw na ingay (halimbawa, mga tawag fdatasync, na mas matagal kaysa karaniwan at nakakaapekto sa 99th percentile).

Bahala ka

Ipinapakita ng artikulo kung paano gamitin fio maaaring husgahan kung ang media na inilaan para sa paggamit sa etcd ay sapat na mabilis. Ngayon ikaw na ang bahala! Maaari mong galugarin ang mga virtual machine na may SSD-based na storage sa serbisyo IBM Cloud.

PS mula sa tagasalin

Sa mga handa na gamit na kaso fio Para sa iba pang mga gawain, tingnan dokumentasyon o direkta sa mga imbakan ng proyekto (marami pa sa kanila kaysa nabanggit sa dokumentasyon).

PPS mula sa tagasalin

Basahin din sa aming blog:

Pinagmulan: www.habr.com

Paano suriin ang mga disk na may fio para sa sapat na pagganap para sa etcd