Kelajuan penyimpanan sesuai untuk etcd? Jom tanya fio

Cerita pendek tentang fio dan etcd

Prestasi kluster dll sebahagian besarnya bergantung pada prestasi penyimpanannya. etcd mengeksport beberapa metrik ke Prometheusuntuk menyediakan maklumat prestasi storan yang dikehendaki. Contohnya, metrik wal_fsync_duration_seconds. Dokumentasi untuk etcd berkata: Untuk storan dianggap cukup pantas, persentil ke-99 metrik ini mestilah kurang daripada 10ms. Jika anda merancang untuk menjalankan kluster etcd pada mesin Linux dan ingin menilai sama ada storan anda cukup pantas (cth. SSD), anda boleh menggunakan fio ialah alat yang popular untuk menguji operasi I/O. Jalankan arahan berikut, dengan data ujian ialah direktori di bawah titik lekap storan:

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

Anda hanya perlu melihat keputusan dan semak bahawa persentil ke-99 tempoh fdatasync kurang daripada 10 ms. Jika ya, anda mempunyai storan yang agak pantas. Berikut adalah contoh hasil:

  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]

Nota

• Kami telah memperibadikan pilihan --size dan --bs untuk senario tertentu kami. Untuk mendapatkan hasil yang berguna daripada fio, berikan nilai anda sendiri. Di mana untuk mendapatkannya? Baca bagaimana kami belajar mengkonfigurasi fio.
• Semasa ujian, semua beban I/O datang daripada fio. Dalam senario kehidupan sebenar, kemungkinan akan terdapat permintaan tulis lain yang masuk ke dalam storan selain yang berkaitan dengan wal_fsync_duration_seconds. Beban tambahan akan meningkatkan nilai wal_fsync_duration_seconds. Jadi jika persentil ke-99 hampir 10ms, storan anda kehabisan kelajuan.
• Ambil versi fio tidak lebih rendah daripada 3.5 (yang sebelumnya tidak menunjukkan persentil tempoh fdatasync).
• Di atas hanyalah coretan hasil daripada fio.

Panjang cerita tentang fio and etcd

Apakah WAL dalam etcd

Biasanya pangkalan data menggunakan log tulis ke hadapan; etcd menggunakannya juga. Kami tidak akan membincangkan log tulis ke hadapan (WAL) secara terperinci di sini. Cukuplah untuk kita mengetahui bahawa setiap ahli kluster etcd mengekalkannya dalam simpanan berterusan. etcd menulis setiap operasi nilai kunci (seperti kemas kini) ke WAL sebelum menggunakannya ke kedai. Jika salah satu ahli storan ranap dan dimulakan semula antara syot kilat, ia boleh memulihkan transaksi secara setempat sejak syot kilat terakhir oleh kandungan WAL.

Apabila pelanggan menambah kunci pada stor nilai kunci atau mengemas kini nilai kunci sedia ada, dll merekodkan operasi dalam WAL, yang merupakan fail biasa dalam storan berterusan. etcd MESTI benar-benar yakin bahawa kemasukan WAL benar-benar berlaku sebelum meneruskan pemprosesan. Di Linux, satu panggilan sistem tidak mencukupi untuk ini. menulis, kerana penulisan sebenar ke storan fizikal mungkin tertunda. Sebagai contoh, Linux mungkin menyimpan entri WAL dalam cache dalam memori kernel (seperti cache halaman) untuk beberapa lama. Dan agar data ditulis dengan tepat ke storan berterusan, panggilan sistem fdatasync diperlukan selepas penulisan, dan etcd hanya menggunakannya (seperti yang anda lihat dalam hasil kerja helai, di mana 8 ialah deskriptor fail 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>

Malangnya, menulis ke storan berterusan tidak berlaku serta-merta. Jika panggilan fdatasync lambat, prestasi sistem etcd akan terjejas. Dokumentasi untuk etcd berkatabahawa storan dianggap cukup pantas jika, dalam persentil ke-99, panggilan fdatasync mengambil masa kurang daripada 10ms untuk menulis ke fail WAL. Terdapat metrik lain yang berguna untuk penyimpanan, tetapi dalam siaran ini kita hanya bercakap tentang metrik ini.

Menganggarkan storan dengan fio

Jika anda perlu menilai sama ada storan anda sesuai untuk etcd, gunakan fio, alat ujian beban I/O yang sangat popular. Harus diingat bahawa operasi cakera boleh sangat berbeza: segerak dan tak segerak, banyak kelas panggilan sistem, dll. Akibatnya, fio agak sukar untuk digunakan. Ia mempunyai banyak parameter, dan kombinasi berbeza nilainya menghasilkan beban kerja I/O yang sangat berbeza. Untuk mendapatkan angka yang mencukupi untuk etcd, anda harus memastikan bahawa beban tulis ujian dari fio adalah sedekat mungkin dengan beban sebenar dari etcd semasa menulis fail WAL.

Oleh itu, fio harus, sekurang-kurangnya, membuat beban satu siri penulisan berurutan pada fail, setiap penulisan akan terdiri daripada panggilan sistem menulisdiikuti dengan panggilan sistem fdatasync. Tulisan berurutan ke fio memerlukan pilihan --rw=write. Untuk fio menggunakan panggilan sistem tulis semasa menulis, bukannya menulis, anda harus menentukan parameter --ioengine=sync. Akhir sekali, untuk memanggil fdatasync selepas setiap penulisan, anda perlu menambah parameter --fdatasync=1. Dua pilihan lain dalam contoh ini (--size dan -bs) adalah khusus skrip. Dalam bahagian seterusnya, kami akan menunjukkan kepada anda cara untuk menyediakannya.

Mengapa fio dan cara kami belajar untuk menyediakannya

Dalam siaran ini, kami menerangkan kes sebenar. Kami mempunyai kluster Kubernetes v1.13 yang kami pantau dengan Prometheus. etcd v3.2.24 telah dihoskan pada SSD. Metrik Etcd menunjukkan kependaman fdatasync terlalu tinggi, walaupun ketika kluster tidak melakukan apa-apa. Metriknya adalah pelik dan kami tidak tahu apa maksudnya. Kelompok itu terdiri daripada mesin maya, adalah perlu untuk memahami masalahnya: dalam SSD fizikal atau dalam lapisan virtualisasi. Di samping itu, kami sering membuat perubahan pada konfigurasi perkakasan dan perisian, dan kami memerlukan cara untuk menilai keputusannya. Kami boleh menjalankan etcd dalam setiap konfigurasi dan melihat metrik Prometheus, tetapi itu terlalu menyusahkan. Kami sedang mencari cara yang agak mudah untuk menilai konfigurasi tertentu. Kami ingin menyemak sama ada kami memahami metrik Prometheus dari etcd dengan betul.

Tetapi untuk ini, dua masalah terpaksa diselesaikan. Pertama, apakah rupa beban I/O yang etcd buat semasa menulis kepada WAL? Apakah panggilan sistem yang digunakan? Apakah saiz rekod? Kedua, jika kita menjawab soalan ini, bagaimana kita menghasilkan semula beban kerja yang serupa dengan fio? Jangan lupa bahawa fio ialah alat yang sangat fleksibel dengan banyak pilihan. Kami menyelesaikan kedua-dua masalah dengan satu pendekatan - menggunakan arahan lsof и helai. lsof menyenaraikan semua deskriptor fail yang digunakan oleh proses dan fail berkaitannya. Dan dengan strace, anda boleh memeriksa proses yang sudah berjalan, atau memulakan proses dan memeriksanya. strace mencetak semua panggilan sistem daripada proses yang sedang diperiksa (dan proses anaknya). Yang terakhir ini sangat penting, kerana etcd hanya mengambil pendekatan yang sama.

Kami mula-mula menggunakan strace untuk meneroka pelayan etcd untuk Kubernetes apabila tiada beban pada kluster. Kami melihat bahawa hampir semua rekod WAL adalah kira-kira saiz yang sama: 2200–2400 bait. Oleh itu, dalam arahan pada permulaan siaran, kami menentukan parameter -bs=2300 (bs bermaksud saiz dalam bait untuk setiap entri fio). Ambil perhatian bahawa saiz entri etcd bergantung pada versi etcd, pengedaran, nilai parameter, dsb., dan mempengaruhi tempoh fdatasync. Jika anda mempunyai senario yang serupa, periksa proses dsb anda dengan strace untuk mengetahui nombor yang tepat.

Kemudian, untuk mendapatkan idea yang baik tentang apa yang dilakukan oleh sistem fail etcd, kami memulakannya dengan strace dan pilihan -ffttT. Oleh itu, kami cuba memeriksa proses kanak-kanak dan merekodkan output setiap daripada mereka dalam fail yang berasingan, dan juga mendapatkan laporan terperinci tentang permulaan dan tempoh setiap panggilan sistem. Kami menggunakan lsof untuk mengesahkan analisis kami terhadap output strace dan melihat deskriptor fail yang digunakan untuk tujuan tersebut. Jadi dengan bantuan strace, keputusan yang ditunjukkan di atas diperolehi. Statistik masa penyegerakan mengesahkan bahawa wal_fsync_duration_seconds dari etcd adalah konsisten dengan panggilan fdatasync dengan deskriptor fail WAL.

Kami meneliti dokumentasi untuk fio dan memilih pilihan untuk skrip kami supaya fio akan menghasilkan beban yang serupa dengan etcd. Kami juga menyemak panggilan sistem dan tempohnya dengan menjalankan fio dari strace, serupa dengan etcd.

Kami telah memilih nilai parameter --size dengan teliti untuk mewakili keseluruhan beban I/O daripada fio. Dalam kes kami, ini ialah jumlah bilangan bait yang ditulis ke storan. Ia ternyata berkadar terus dengan bilangan panggilan sistem tulis (dan fdatasync). Untuk nilai bs tertentu, bilangan panggilan fdatasync = saiz/bs. Memandangkan kami berminat dengan persentil, kami perlu mempunyai sampel yang mencukupi untuk memastikan, dan kami mengira bahawa 10^4 akan mencukupi untuk kami (iaitu 22 mebibait). Jika --size lebih kecil, outlier mungkin berlaku (contohnya, beberapa panggilan fdatasync mengambil masa lebih lama daripada biasa dan menjejaskan persentil ke-99).

Cuba sendiri

Kami menunjukkan kepada anda cara menggunakan fio dan melihat sama ada storan mempunyai kelajuan yang mencukupi untuk prestasi tinggi dll. Kini anda boleh mencubanya sendiri menggunakan, contohnya, mesin maya dengan storan SSD masuk IBM Cloud.

Sumber: www.habr.com