🥇Cara memeriksa disk dengan fio untuk kinerja yang memadai untuk etcd

Catatan. terjemahan: Artikel ini adalah hasil penelitian mini yang dilakukan oleh para insinyur IBM Cloud untuk mencari solusi atas masalah nyata terkait pengoperasian database etcd. Tugas serupa relevan bagi kami, namun, arah refleksi dan tindakan penulis mungkin menarik dalam konteks yang lebih luas.

Ringkasan singkat dari keseluruhan artikel: fio dan etcd

Kinerja klaster etcd sangat bergantung pada kecepatan penyimpanan yang mendasarinya. etcd mengekspor berbagai metrik Prometheus untuk memantau kinerja. Salah satunya adalah wal_fsync_duration_seconds. Dalam dokumentasi untuk etcd ia mengatakanpenyimpanan tersebut dapat dianggap cukup cepat jika persentil ke-99 metrik ini tidak melebihi 10 md…

Jika Anda sedang mempertimbangkan untuk menyiapkan klaster etcd pada mesin Linux dan ingin memeriksa apakah drive (seperti SSD) cukup cepat, kami sarankan untuk menggunakan penguji I/O populer yang disebut fio. Cukup dengan menjalankan perintah berikut (directory test-data harus terletak di partisi terpasang dari drive yang diuji):

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

Tetap hanya melihat output dan memeriksa apakah persentil ke-99 cocok fdatasync dalam 10 ms. Jika demikian, maka drive Anda bekerja cukup cepat. Berikut adalah contoh keluaran:

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]

Beberapa catatan:

Pada contoh di atas, kami telah menyesuaikan parameternya --size и --bs untuk kasus tertentu. Untuk mendapatkan hasil yang berarti dari fio, tentukan nilai yang sesuai untuk kasus penggunaan Anda. Cara memilihnya akan dibahas di bawah ini.
Selama pengujian saja fio memuat subsistem disk. Dalam kehidupan nyata, kemungkinan proses lain akan menulis ke disk (selain yang terkait dengan wal_fsync_duration_seconds). Beban tambahan ini bisa bertambah wal_fsync_duration_seconds. Dengan kata lain, jika persentil ke-99 dari pengujian dengan fio, hanya kurang dari 10 ms, ada kemungkinan besar kinerja penyimpanan tidak memadai.
Untuk pengujian, Anda memerlukan versinya fio tidak lebih rendah dari 3.5, karena versi lama tidak menggabungkan hasil fdatasync dalam bentuk persentil.
Kesimpulan di atas hanyalah sebagian kecil dari kesimpulan umum fio.

Lebih lanjut tentang fio dan etcd

Beberapa kata tentang WALs etcd

Umumnya, database menggunakan penebangan proaktif (tulis-depan logging, WAL). etcd juga terpengaruh. Diskusi tentang WAL berada di luar cakupan artikel ini, tetapi untuk tujuan kami, yang perlu Anda ketahui adalah bahwa setiap anggota klaster etcd menyimpan WAL dalam penyimpanan persisten. etcd menulis beberapa operasi penyimpanan nilai kunci (seperti pembaruan) ke WAL sebelum menjalankannya. Jika sebuah node crash dan restart di antara snapshot, etcd dapat memulihkan transaksi sejak snapshot sebelumnya berdasarkan konten WAL.

Jadi, setiap kali klien menambahkan kunci ke penyimpanan KV atau memperbarui nilai kunci yang ada, etcd menambahkan deskripsi operasi ke WAL, yang merupakan file biasa di penyimpanan persisten. etcd HARUS 100% yakin bahwa entri WAL benar-benar telah disimpan sebelum melanjutkan. Untuk mencapai ini di Linux, tidak cukup menggunakan system call write, karena operasi tulis itu sendiri ke media fisik mungkin tertunda. Sebagai contoh, Linux dapat menyimpan entri WAL di cache kernel di memori (misalnya, di cache halaman) untuk beberapa waktu. Untuk memastikan bahwa data ditulis ke media, panggilan sistem harus dilakukan setelah penulisan fdatasync - inilah yang dilakukan etcd (seperti yang Anda lihat pada output berikut strace; Di Sini 8 - deskriptor file 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>

Sayangnya, menulis ke penyimpanan persisten membutuhkan waktu. Eksekusi panggilan fdatasync yang berkepanjangan dapat memengaruhi kinerja etcd. Dalam dokumentasi repositori ditunjukkan, bahwa untuk kinerja yang memadai diperlukan persentil ke-99 dari durasi semua panggilan fdatasync saat menulis ke file WAL kurang dari 10 ms. Ada metrik terkait penyimpanan lainnya, tetapi artikel ini akan berfokus pada metrik tersebut.

Menilai penyimpanan dengan fio

Anda dapat mengevaluasi apakah penyimpanan tertentu cocok untuk digunakan dengan etcd menggunakan utilitas fio — penguji I/O yang populer. Perlu diingat bahwa I/O disk dapat terjadi dalam berbagai cara: sinkronisasi/async, banyak kelas syscall yang berbeda, dan sebagainya. Sisi lain dari koin adalah itu fio sangat sulit untuk digunakan. Utilitas memiliki banyak parameter, dan kombinasi nilainya yang berbeda menghasilkan hasil yang sangat berbeda. Untuk mendapatkan perkiraan yang masuk akal untuk etcd, Anda perlu memastikan bahwa beban tulis yang dihasilkan oleh fio sedekat mungkin dengan beban tulis file WAL etcd:

Artinya yang dihasilkan fio pemuatan setidaknya harus berupa serangkaian penulisan berurutan ke file, di mana setiap operasi penulisan terdiri dari panggilan sistem writediikuti oleh fdatasync.
Untuk mengaktifkan penulisan berurutan, Anda harus menentukan bendera --rw=write.
Bahwa fio menulis menggunakan panggilan write (daripada panggilan sistem lainnya - misalnya, pwrite), gunakan bendera --ioengine=sync.
Terakhir, bendera --fdatasync=1 menjamin bahwa untuk masing-masing write harus fdatasync.
Dua parameter lainnya dalam contoh kita adalah: --size и --bs - dapat bervariasi tergantung pada kasus penggunaan tertentu. Bagian selanjutnya akan menjelaskan konfigurasi mereka.

Mengapa kami memilih fio dan bagaimana kami mempelajari cara menyiapkannya

Catatan ini berasal dari kasus nyata yang kami temui. Kami memiliki klaster di Kubernetes v1.13 dengan pemantauan di Prometheus. SSD digunakan sebagai penyimpanan untuk etcd v3.2.24. Metrik etcd menunjukkan latensi yang terlalu tinggi fdatasync, bahkan saat kluster menganggur. Bagi kami, metrik ini tampak sangat meragukan, dan kami tidak yakin apa sebenarnya yang diwakilinya. Selain itu, cluster tersebut terdiri dari mesin virtual, jadi tidak mungkin untuk mengatakan apakah penundaan itu karena virtualisasi atau SSD yang harus disalahkan.

Selain itu, kami mempertimbangkan berbagai perubahan dalam konfigurasi perangkat keras dan perangkat lunak, sehingga kami memerlukan cara untuk mengevaluasinya. Tentu saja, dimungkinkan untuk menjalankan etcd di setiap konfigurasi dan melihat metrik Prometheus yang sesuai, tetapi itu membutuhkan upaya yang signifikan. Yang kami butuhkan adalah cara sederhana untuk mengevaluasi konfigurasi tertentu. Kami ingin menguji pemahaman kami tentang metrik Prometheus yang berasal dari etcd.

Ini membutuhkan pemecahan dua masalah:

Pertama, seperti apa beban I/O yang dihasilkan oleh etcd saat menulis ke file WAL? Panggilan sistem apa yang digunakan? Berapa ukuran blok rekaman?
Kedua, katakanlah kita memiliki jawaban untuk pertanyaan di atas. Cara mereproduksi beban yang sesuai dengan fio? Lagipula fio — utilitas yang sangat fleksibel dengan banyak parameter (ini mudah diverifikasi, misalnya, di sini - kira-kira. terjemahkan).

Kami memecahkan kedua masalah dengan pendekatan berbasis perintah yang sama lsof и strace:

Dengan lsof Anda dapat melihat semua deskriptor file yang digunakan oleh proses, serta file yang dirujuknya.
Dengan strace Anda dapat menganalisis proses yang sudah berjalan atau menjalankan proses dan menontonnya. Perintah tersebut menampilkan semua panggilan sistem yang dilakukan oleh proses ini dan, jika perlu, turunannya. Yang terakhir penting untuk proses yang bercabang, dan etcd adalah salah satu proses tersebut.

Hal pertama yang kami lakukan adalah menggunakan strace untuk memeriksa server etcd di kluster Kubernetes saat tidak digunakan.

Sehingga ditemukan bahwa blok record WAL dikelompokkan dengan sangat padat, ukuran mayoritas berada pada kisaran 2200-2400 byte. Itu sebabnya perintah di awal artikel ini menggunakan flag --bs=2300 (bs adalah ukuran dalam byte dari setiap blok tulis fio).

Harap dicatat bahwa ukuran blok tulis etcd dapat bervariasi tergantung pada versi, penyebaran, nilai parameter, dll. - itu mempengaruhi durasi fdatasync. Jika Anda memiliki kasus penggunaan serupa, analisis dengan strace proses etcd Anda untuk mendapatkan nilai terkini.

Kemudian, untuk mendapatkan gambaran yang jelas dan komprehensif tentang cara kerja etcd dengan sistem file, kami memulainya dari bawah strace dengan bendera -ffttT. Ini memungkinkan untuk menangkap proses anak dan menulis keluaran masing-masing ke file terpisah. Selain itu, informasi terperinci tentang waktu mulai dan durasi setiap panggilan sistem diperoleh.

Kami juga menggunakan perintah lsofuntuk mengkonfirmasi pemahaman Anda tentang output strace dalam hal deskriptor file mana yang digunakan untuk tujuan apa. Saya mendapat kesimpulan strace, mirip dengan yang di atas. Manipulasi statistik dengan waktu sinkronisasi menegaskan bahwa metrik wal_fsync_duration_seconds from etcd cocok dengan panggilan fdatasync dengan deskriptor file WAL.

Untuk menghasilkan dengan fio beban kerja yang mirip dengan etcd, dokumentasi utilitas dipelajari dan parameter yang sesuai untuk tugas kami dipilih. Kami telah memverifikasi bahwa panggilan sistem yang benar sedang berlangsung dan mengonfirmasi durasinya dengan menjalankan fio dari strace (seperti yang dilakukan dalam kasus etcd).

Perhatian khusus diberikan untuk menentukan nilai parameter --size. Ini mewakili total beban I/O yang dihasilkan oleh utilitas fio. Dalam kasus kami, ini adalah jumlah total byte yang ditulis ke media. Ini berbanding lurus dengan jumlah panggilan write (dan fdatasync). Untuk spesifik bs jumlah panggilan fdatasync sama size / bs.

Karena kami tertarik pada persentil, kami ingin jumlah sampel cukup besar agar signifikan secara statistik. Dan memutuskan itu 10^4 (yang sesuai dengan ukuran 22 MB) sudah cukup. Nilai parameter lebih kecil --size memberikan suara yang lebih jelas (misalnya, panggilan fdatasync, yang membutuhkan waktu lebih lama dari biasanya dan memengaruhi persentil ke-99).

Terserah kamu

Artikel ini menunjukkan cara menggunakan fio seseorang dapat menilai apakah media yang dimaksudkan untuk digunakan dengan etcd cukup cepat. Sekarang terserah kamu! Anda dapat menjelajahi mesin virtual dengan penyimpanan berbasis SSD di layanan Cloud IBM.

PS dari penerjemah

Dengan kasus penggunaan yang sudah jadi fio Untuk tugas lainnya, lihat dokumentasi atau langsung ke repositori proyek (ada lebih banyak dari yang disebutkan dalam dokumentasi).

Cara memeriksa disk dengan fio untuk performa yang memadai untuk etcd