🥇Cara menyemak cakera dengan fio untuk prestasi yang mencukupi untuk etcd

Catatan. terjemah: Artikel ini adalah hasil penyelidikan mini yang dijalankan oleh jurutera IBM Cloud untuk mencari penyelesaian kepada masalah sebenar yang berkaitan dengan operasi pangkalan data etcd. Tugas yang sama adalah relevan untuk kami, tetapi perjalanan pemikiran dan tindakan pengarang mungkin menarik dalam konteks yang lebih luas.

Ringkasan ringkas keseluruhan artikel: fio dan etcd

Prestasi kluster etcd sangat bergantung pada kelajuan storan asas. Untuk memantau prestasi, etcd mengeksport pelbagai metrik Prometheus. Salah satunya ialah wal_fsync_duration_seconds. Dalam dokumentasi etcd ia berkata, storan itu boleh dianggap cukup pantas jika persentil ke-99 metrik ini tidak melebihi 10 ms...

Jika anda mempertimbangkan untuk menyediakan kluster etcd pada mesin Linux dan ingin menguji sama ada pemacu storan (seperti SSD) cukup pantas, kami mengesyorkan menggunakan penguji I/O popular yang dipanggil fio. Jalankan sahaja arahan berikut (directory test-data mesti terletak dalam partition yang dipasang pada pemacu yang sedang diuji):

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

Apa yang tinggal ialah melihat output dan semak sama ada ia sesuai dengan persentil ke-99 fdatasync pada 10 ms. Jika ya, maka pemacu anda cukup laju. Berikut adalah contoh 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]

Sedikit nota:

Dalam contoh di atas kami telah melaraskan parameter --size и --bs untuk kes tertentu. Untuk mendapatkan hasil yang bermakna daripada fio, nyatakan nilai yang sesuai untuk kes penggunaan anda. Cara memilihnya akan dibincangkan di bawah.
Semasa ujian sahaja fio memuatkan subsistem cakera. Dalam kehidupan sebenar, kemungkinan proses lain (selain yang berkaitan dengan wal_fsync_duration_seconds). Beban tambahan sedemikian boleh membawa kepada peningkatan dalam wal_fsync_duration_seconds. Dalam erti kata lain, jika persentil ke-99 diperoleh daripada ujian dengan fio, hanya kurang sedikit daripada 10 ms, terdapat kemungkinan besar prestasi storan tidak mencukupi.
Untuk ujian, anda memerlukan versi fio tidak lebih rendah daripada 3.5, kerana versi lama tidak mengagregatkan hasil fdatasync dalam bentuk persentil.
Kesimpulan di atas hanyalah petikan kecil daripada kesimpulan keseluruhan fio.

Butiran tentang fio dan etcd

Sedikit perkataan tentang WAL dll

Biasanya, pangkalan data menggunakan pembalakan proaktif (pelogan tulis ke hadapan, WAL). etcd ini juga terpakai. Perbincangan tentang WAL adalah di luar skop artikel ini, tetapi untuk tujuan kami inilah yang perlu anda ketahui: Setiap ahli kluster dll menyimpan WAL dalam storan berterusan. etcd menulis beberapa operasi kedai nilai kunci (seperti kemas kini) ke WAL sebelum melaksanakannya. Jika nod ranap dan dimulakan semula antara syot kilat, dsb boleh memulihkan transaksi yang dijalankan sejak syot kilat sebelumnya berdasarkan kandungan WAL.

Oleh itu, setiap kali pelanggan menambah kunci ke stor KV atau mengemas kini nilai kunci sedia ada, dsb menambahkan perihalan operasi kepada WAL, yang merupakan fail biasa dalam storan berterusan. etcd MESTI 100% pasti bahawa entri WAL sebenarnya disimpan sebelum meneruskan. Untuk mencapai ini di Linux, ia tidak mencukupi untuk menggunakan panggilan sistem write, memandangkan operasi tulis itu sendiri kepada medium fizikal mungkin ditangguhkan. Sebagai contoh, Linux mungkin menyimpan entri WAL dalam cache kernel dalam ingatan (seperti cache halaman) untuk beberapa waktu. Untuk memastikan data ditulis kepada media, panggilan sistem mesti dipanggil selepas menulis fdatasync - inilah yang dilakukan oleh etcd (seperti yang dapat dilihat dalam output berikut strace; Di sini 8 - Pemegang fail WAL):

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>

Malangnya, menulis ke storan berterusan mengambil sedikit masa. Mengambil masa yang lama untuk menyelesaikan panggilan fdatasync boleh menjejaskan prestasi dll. Dalam dokumentasi untuk repositori ditunjukkanbahawa untuk prestasi yang mencukupi adalah perlu bahawa persentil ke-99 tempoh semua panggilan fdatasync semasa menulis ke fail, WAL adalah kurang daripada 10 ms. Terdapat metrik lain yang berkaitan dengan storan, tetapi artikel ini akan memfokuskan pada yang ini.

Menilai storan menggunakan fio

Anda boleh menilai sama ada storan tertentu sesuai untuk digunakan dengan etcd menggunakan utiliti fio - penguji I/O yang popular. Perlu diingat bahawa I/O cakera boleh berlaku dalam cara yang berbeza: penyegerakan/tak segerak, banyak kelas panggilan sistem yang berbeza, dsb. Sebelah lagi syiling ialah itu fio amat sukar untuk digunakan. Utiliti mempunyai banyak parameter, dan gabungan nilai yang berbeza membawa kepada hasil yang sama sekali berbeza. Untuk mendapatkan anggaran yang munasabah untuk etcd, anda mesti memastikan bahawa beban tulis yang dijana oleh fio adalah sama yang mungkin dengan beban tulis etcd kepada fail WAL:

Ini bermakna bahawa yang dihasilkan fio beban kerja mestilah sekurang-kurangnya satu siri penulisan berurutan ke fail, di mana setiap operasi tulis terdiri daripada panggilan sistem writediikuti oleh fdatasync.
Untuk mendayakan rakaman berjujukan, anda mesti menentukan bendera --rw=write.
Itu fio menulis menggunakan panggilan write (dan bukan panggilan sistem lain - contohnya, pwrite), gunakan bendera --ioengine=sync.
Akhirnya, bendera --fdatasync=1 menjamin bahawa di sebalik setiap write sepatutnya fdatasync.
Dua parameter lain dalam contoh kami: --size и --bs - mungkin berbeza bergantung pada kes penggunaan tertentu. Bahagian seterusnya akan menerangkan cara mengkonfigurasinya.

Sebab kami memilih fio dan cara kami mempelajari cara menyediakannya

Nota ini datang daripada kes sebenar yang kami temui. Kami mempunyai kluster pada Kubernetes v1.13 dengan pemantauan pada Prometheus. Pemacu keadaan pepejal digunakan sebagai storan untuk etcd v3.2.24. metrik etcd menunjukkan kependaman terlalu tinggi fdatasync, walaupun ketika kelompok melahu. Kami mendapati metrik ini sangat dipersoalkan dan kami tidak pasti apa sebenarnya yang diwakilinya. Di samping itu, kluster terdiri daripada mesin maya, jadi adalah mustahil untuk mengetahui sama ada kelewatan itu disebabkan oleh virtualisasi atau SSD yang harus dipersalahkan.

Selain itu, kami sedang melihat pelbagai perubahan pada konfigurasi perkakasan dan perisian, jadi kami memerlukan cara untuk menilainya. Sudah tentu, adalah mungkin untuk menjalankan etcd dalam setiap konfigurasi dan melihat metrik Prometheus yang sepadan, tetapi ini memerlukan usaha yang ketara. Kami memerlukan cara mudah untuk menilai konfigurasi tertentu. Kami ingin menguji pemahaman kami tentang metrik Prometheus yang datang dari etcd.

Untuk melakukan ini, dua masalah perlu diselesaikan:

Pertama, apakah rupa beban I/O yang etcd hasilkan apabila menulis ke fail WAL? Apakah panggilan sistem yang digunakan? Apakah saiz blok tulis?
Kedua, katakan kita mempunyai jawapan kepada soalan di atas. Bagaimana untuk menghasilkan semula beban yang sepadan dengan fio? Lagipun fio — utiliti yang sangat fleksibel dengan banyak parameter (ini mudah untuk mengesahkan, contohnya, di sini - lebih kurang terjemah.).

Kami menyelesaikan kedua-dua masalah menggunakan pendekatan berasaskan arahan yang sama lsof и strace:

Dengan lsof Anda boleh melihat semua deskriptor fail yang digunakan oleh proses, serta fail yang mereka rujuk.
Dengan strace anda boleh menganalisis proses yang sudah berjalan atau menjalankan proses dan memerhatikannya. Perintah itu memaparkan semua panggilan sistem yang dibuat oleh proses ini dan, secara pilihan, keturunannya. Yang terakhir adalah penting untuk proses yang bercabang, dan etcd adalah salah satu daripada proses tersebut.

Perkara pertama yang kami lakukan ialah menggunakan strace untuk mengkaji pelayan etcd dalam kelompok Kubernetes semasa ia melahu.

Oleh itu, didapati bahawa blok tulis dalam WAL dikumpulkan dengan sangat padat, majoritinya berada dalam julat 2200-2400 bait. Inilah sebabnya mengapa arahan pada permulaan artikel ini menggunakan bendera --bs=2300 (bs — saiz dalam bait setiap blok rakaman masuk fio).

Sila ambil perhatian bahawa saiz blok tulis etcd mungkin berbeza-beza bergantung pada versi, penggunaan, nilai parameter, dsb. - ini menjejaskan tempoh fdatasync. Jika anda mempunyai kes penggunaan yang serupa, analisis dengan strace proses etcd anda untuk mendapatkan nilai terkini.

Kemudian, untuk mendapatkan pemahaman yang jelas dan komprehensif tentang cara etcd berfungsi dengan sistem fail, kami menjalankannya dari bawah strace dengan bendera -ffttT. Ini memungkinkan untuk menangkap proses kanak-kanak dan menulis output setiap satu ke fail yang berasingan. Di samping itu, maklumat terperinci diperolehi tentang detik mula dan tempoh setiap panggilan sistem.

Kami juga menggunakan arahan lsofuntuk mengesahkan pemahaman anda tentang output strace dari segi deskriptor fail yang digunakan untuk tujuan apa. Hasilnya ialah strace, serupa dengan yang di atas. Manipulasi statistik dengan masa penyegerakan mengesahkan bahawa metrik wal_fsync_duration_seconds daripada panggilan perlawanan etcd fdatasync dengan deskriptor fail WAL.

Untuk menjana menggunakan fio beban kerja serupa dengan beban dari etcd, dokumentasi utiliti telah dikaji dan parameter yang sesuai untuk tugas kami telah dipilih. Kami memastikan bahawa panggilan sistem yang betul telah terlibat dan mengesahkan tempohnya dengan berjalan fio daripada strace (seperti yang dilakukan dalam kes etcd).

Perhatian khusus diberikan untuk menentukan nilai parameter --size. Ia mewakili jumlah beban I/O yang dijana oleh utiliti fio. Dalam kes kami, ini ialah jumlah bilangan bait yang ditulis kepada media. Ia berkadar terus dengan bilangan panggilan write (dan fdatasync). Untuk yang tertentu bs bilangan panggilan fdatasync sama dengan size / bs.

Oleh kerana kami berminat dengan persentil, kami berusaha untuk memastikan bahawa bilangan sampel adalah cukup besar untuk kepentingan statistik. Dan mereka memutuskan itu 10^4 (yang sepadan dengan saiz 22 MB) sudah memadai. Nilai parameter yang lebih kecil --size menghasilkan bunyi yang lebih jelas (contohnya, panggilan fdatasync, yang mengambil masa lebih lama daripada biasa dan menjejaskan persentil ke-99).

Terpulang kepada anda

Artikel menunjukkan cara menggunakan fio anda boleh menilai sama ada media yang dimaksudkan untuk digunakan dengan etcd cukup pantas. Sekarang terpulang kepada anda! Anda boleh meneroka mesin maya dengan storan berasaskan SSD dalam perkhidmatan IBM Cloud.

PS daripada penterjemah

Dengan contoh penggunaan siap pakai fio untuk menyelesaikan masalah lain boleh didapati di dokumentasi atau terus ke repositori projek (terdapat lebih banyak daripada mereka di sana daripada yang disebutkan dalam dokumentasi).

Bagaimana untuk menyemak cakera dengan fio untuk prestasi yang mencukupi untuk etcd