Kacepetan panyimpenan cocok kanggo etcd? Ayo takon fio

Crita cekak babagan fio lan etc

Kinerja kluster lsp umumé gumantung ing kinerja panyimpenan sawijining. etcd ngekspor sawetara metrik kanggo Prometheuskanggo nyedhiyakake informasi kinerja panyimpenan sing dikarepake. Contone, metrik wal_fsync_duration_seconds. Dokumentasi kanggo etcd ngandika: Supaya panyimpenan dianggep cukup cepet, persentil 99 saka metrik iki kudu kurang saka 10ms. Yen sampeyan planning kanggo mbukak kluster etcd ing mesin Linux lan pengin ngevaluasi yen panyimpenan cukup cepet (eg SSD), sampeyan bisa nggunakake fio minangka alat populer kanggo nguji operasi I/O. Jalanake printah ing ngisor iki, ing ngendi test-data minangka direktori ing sangisore titik panyimpenan:

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

Sampeyan mung perlu kanggo katon ing asil lan mriksa sing persentil 99th saka durasi fdatasync kurang saka 10 ms. Yen mangkono, sampeyan duwe panyimpenan sing cukup cepet. Punika conto asil:

  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]

Cathetan

• Kita wis ngatur pilihan --size lan --bs kanggo skenario tartamtu. Kanggo entuk asil sing migunani saka fio, nyedhiyakake nilai sampeyan dhewe. Where kanggo njaluk wong? maca carane kita sinau kanggo ngatur fio.
• Sajrone testing, kabeh I / O mbukak asalé saka fio. Ing skenario nyata, bakal ana panjaluk nulis liyane sing bakal teka ing panyimpenan kajaba sing ana gandhengane karo wal_fsync_duration_seconds. Beban ekstra bakal nambah nilai wal_fsync_duration_seconds. Dadi yen persentil kaping 99 cedhak karo 10ms, panyimpenan sampeyan bakal entek.
• Njupuk versi fio ora kurang saka 3.5 (sing sadurunge ora nuduhake persentil durasi fdatasync).
• Ndhuwur mung cuplikan asil saka fio.

Crita dawa babagan fio lan etc

Apa WAL ing etcd

Biasane nggunakake database nulis-ahead log; etcd uga nggunakake. Kita ora bakal ngrembug babagan nulis-ahead log (WAL) kanthi rinci ing kene. Iku cukup kanggo kita ngerti sing saben anggota kluster etcd njaga ing panyimpenan ngengkel. etcd nulis saben operasi kunci-nilai (kayata nganyari) menyang WAL sadurunge nglamar menyang toko. Yen salah siji saka anggota panyimpenan tubrukan lan miwiti maneh antarane jepretan, bisa lokal mulihake transaksi wiwit gambar asli seko pungkasan dening isi WAL.

Nalika klien nambah tombol kanggo nyimpen tombol-nilai utawa nganyari Nilai saka tombol ana, etcd ngrekam operasi ing WAL, kang file biasa ing panyimpenan ngengkel. etcd kudu yakin manawa entri WAL bener-bener kedadeyan sadurunge nerusake proses. Ing Linux, siji panggilan sistem ora cukup kanggo iki. nulis, wiwit nulis nyata kanggo panyimpenan fisik bisa telat. Contone, Linux bisa nyimpen entri WAL ing cache ing memori kernel (kayata cache kaca) kanggo sawetara wektu. Lan supaya data bisa ditulis kanthi akurat menyang panyimpenan sing terus-terusan, telpon sistem fdatasync dibutuhake sawise nulis, lan etcd mung nggunakake (kaya sing sampeyan deleng ing asil karya. strace, ing ngendi 8 minangka deskriptor file WAL):

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>

Sayange, nulis menyang panyimpenan terus-terusan ora kedadeyan langsung. Yen telpon fdatasync alon, kinerja sistem etcd bakal nandhang sangsara. Dokumentasi kanggo etcd ngandikasing panyimpenan dianggep cukup cepet yen, ing persentil 99th, fdatasync telpon njupuk kurang saka 10ms kanggo nulis menyang file WAL. Ana metrik liyane sing migunani kanggo panyimpenan, nanging ing kirim iki kita mung ngomong babagan metrik iki.

Ngira-ngira panyimpenan karo fio

Yen sampeyan kudu ngevaluasi yen panyimpenan sampeyan cocok kanggo etcd, gunakake fio, alat uji beban I/O sing populer banget. Sampeyan kudu eling yen operasi disk bisa beda banget: sinkron lan asinkron, akeh kelas panggilan sistem, lan liya-liyane. Akibate, fio cukup angel digunakake. Nduwe akeh parameter, lan kombinasi sing beda-beda saka nilai kasebut ngasilake beban kerja I / O sing beda banget. Kanggo entuk angka sing cukup kanggo etcd, sampeyan kudu nggawe manawa beban nulis tes saka fio cedhak karo beban nyata saka etcd nalika nulis file WAL.

Mulane, fio kudu, paling ora, nggawe beban saka seri nulis urutan menyang file, saben nulis bakal kalebu panggilan sistem nulisngiring dening telpon sistem fdatasync. Sequential writes to fio mbutuhake pilihan --rw=write. Kanggo fio nggunakake telpon sistem nulis nalika nulis, tinimbang nulis, sampeyan kudu nemtokake parameter --ioengine=sync. Pungkasan, kanggo nelpon fdatasync sawise saben nulis, sampeyan kudu nambah parameter --fdatasync=1. Rong opsi liyane ing conto iki (--size lan -bs) khusus skrip. Ing bagean sabanjure, kita bakal nuduhake sampeyan carane nyetel.

Apa persis fio lan carane kita sinau kanggo nyetel

Ing kirim iki, kita njlèntrèhaké kasus nyata. Kita duwe kluster Kubernetes v1.13 kang kita teliti karo Prometheus. etcd v3.2.24 iki tuan rumah ing SSD. Metrik Etcd nuduhake latensi fdatasync dhuwur banget, sanajan kluster ora nindakake apa-apa. Metrik kasebut aneh lan kita ora ngerti apa tegese. Kluster kasebut kalebu mesin virtual, kudu ngerti apa masalahe: ing SSD fisik utawa ing lapisan virtualisasi. Kajaba iku, kita kerep ngowahi konfigurasi hardware lan piranti lunak, lan kita butuh cara kanggo ngevaluasi asile. Kita bisa mbukak etcd ing saben konfigurasi lan katon ing Prometheus metrik, nanging kakehan alangan. Kita padha nggoleki cara sing cukup prasaja kanggo ngevaluasi konfigurasi tartamtu. Kita pengin mriksa yen kita ngerti metrik Prometheus saka etcd kanthi bener.

Nanging kanggo iki, rong masalah kudu ditanggulangi. Pisanan, apa beban I / O sing digawe etcd nalika nulis menyang WAL katon kaya? Panggilan sistem apa sing digunakake? Apa ukuran cathetan? Kapindho, yen kita mangsuli pitakon kasebut, kepiye carane ngasilake beban kerja sing padha karo fio? Aja lali yen fio minangka alat sing fleksibel kanthi akeh pilihan. Kita ngrampungake loro masalah ing siji pendekatan - nggunakake printah lsof и strace. lsof nampilake kabeh deskriptor file sing digunakake dening proses lan file sing ana gandhengane. Lan kanthi strace, sampeyan bisa mriksa proses sing wis mlaku, utawa miwiti proses lan mriksa. strace nyithak kabeh telpon sistem saka proses sing ditliti (lan proses anak). Sing terakhir penting banget, amarga etcd mung njupuk pendekatan sing padha.

Kita pisanan nggunakake strace kanggo njelajah server etcd kanggo Kubernetes nalika ora ana beban ing kluster. Kita weruh manawa meh kabeh cathetan WAL ukurane padha: 2200–2400 bita. Mulane, ing printah ing awal kirim, kita nemtokake parameter -bs = 2300 (bs tegese ukuran ing bita kanggo saben entri fio). Elinga yen ukuran entri etcd gumantung ing versi etcd, distribusi, nilai parameter, etc., lan mengaruhi durasi fdatasync. Yen sampeyan duwe skenario sing padha, priksa proses etcd sampeyan kanthi strace kanggo ngerteni nomer sing tepat.

Banjur, kanggo ngerteni apa sing ditindakake sistem file etcd, kita miwiti kanthi strace lan opsi -ffttT. Dadi, kita nyoba mriksa proses bocah lan ngrekam output saben wong ing file sing kapisah, lan uga entuk laporan rinci babagan wiwitan lan durasi saben telpon sistem. Kita nggunakake lsof kanggo konfirmasi analisis output strace lan ndeleng deskriptor file sing digunakake kanggo tujuane. Dadi kanthi bantuan strace, asil sing dituduhake ing ndhuwur dipikolehi. Statistik wektu sinkronisasi dikonfirmasi manawa wal_fsync_duration_seconds saka etcd konsisten karo telpon fdatasync karo deskriptor file WAL.

Kita lunga liwat dokumentasi kanggo fio lan milih opsi kanggo script kita supaya fio bakal generate mbukak padha etcd. Kita uga mriksa telpon sistem lan durasi kanthi mbukak fio saka strace, padha karo etcd.

Kita wis kasebut kanthi teliti, milih Nilai saka parameter --ukuran kanggo makili kabeh I / O mbukak saka fio. Ing kasus kita, iki minangka jumlah total bita sing ditulis ing panyimpenan. Ternyata dadi proporsional langsung karo jumlah panggilan sistem nulis (lan fdatasync). Kanggo nilai bs tartamtu, jumlah panggilan fdatasync = ukuran / bs. Awit kita padha kasengsem ing persentil, kita kudu sampel cukup kanggo mesthekake, lan kita ngetung sing 10 ^ 4 bakal cukup kanggo kita (iku 22 mebibyte). Yen --size luwih cilik, outlier bisa kedadeyan (contone, sawetara panggilan fdatasync luwih suwe tinimbang biasane lan mengaruhi persentil kaping 99).

Coba dhewe

We nuduhake sampeyan carane nggunakake fio lan ndeleng yen panyimpenan wis cukup kacepetan kanggo kinerja dhuwur etcd. Saiki sampeyan bisa nyoba dhewe nggunakake, contone, mesin virtual karo panyimpenan SSD ing IBM Cloud.

Source: www.habr.com