Kecepatan penyimpanan cocok untuk etcd? Mari kita bertanya fio

Sebuah cerita pendek tentang fio dan etcd

Kinerja gugus dll sangat tergantung pada kinerja penyimpanannya. etcd mengekspor beberapa metrik ke Prometheusuntuk memberikan informasi kinerja penyimpanan yang diinginkan. Misalnya, metrik wal_fsync_duration_seconds. Dokumentasi untuk etcd mengatakan: Agar penyimpanan dianggap cukup cepat, persentil ke-99 metrik ini harus kurang dari 10 milidetik. Jika Anda berencana menjalankan klaster etcd di mesin Linux dan ingin mengevaluasi apakah penyimpanan Anda cukup cepat (mis. SSD), Anda dapat menggunakan fio adalah alat yang populer untuk menguji operasi I/O. Jalankan perintah berikut, di mana test-data adalah direktori di bawah titik pemasangan penyimpanan:

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

Anda hanya perlu melihat hasilnya dan memeriksa persentil ke-99 dari durasinya sinkronisasi data kurang dari 10 ms. Jika demikian, Anda memiliki penyimpanan yang cukup cepat. Berikut adalah contoh hasilnya:

  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]

Catatan

• Kami telah menyesuaikan opsi --size dan --bs untuk skenario khusus kami. Untuk mendapatkan hasil yang bermanfaat dari fio, berikan nilai Anda sendiri. Di mana mendapatkannya? Membaca bagaimana kami belajar mengkonfigurasi fio.
• Selama pengujian, semua beban I/O berasal dari fio. Dalam skenario kehidupan nyata, kemungkinan akan ada permintaan tulis lain yang masuk ke penyimpanan selain yang terkait dengan wal_fsync_duration_seconds. Beban ekstra akan menambah nilai wal_fsync_duration_seconds. Jadi, jika persentil ke-99 mendekati 10 md, penyimpanan Anda akan kehabisan kecepatan.
• Ambil versinya fio tidak lebih rendah dari 3.5 (yang sebelumnya tidak menunjukkan persentil durasi fdatasync).
• Di atas hanyalah cuplikan hasil dari fio.

Cerita panjang tentang fio dan etcd

Apa itu WAL di etcd

Biasanya menggunakan database log tulis-depan; etcd menggunakannya juga. Kami tidak akan membahas write-ahead log (WAL) secara rinci di sini. Cukup bagi kita untuk mengetahui bahwa setiap anggota klaster etcd menyimpannya dalam penyimpanan persisten. etcd menulis setiap operasi nilai kunci (seperti pembaruan) ke WAL sebelum menerapkannya ke toko. Jika salah satu anggota penyimpanan mengalami crash dan restart di antara snapshot, itu dapat mengembalikan transaksi secara lokal sejak snapshot terakhir oleh konten WAL.

Saat klien menambahkan kunci ke penyimpanan nilai kunci atau memperbarui nilai kunci yang ada, etcd merekam operasi di WAL, yang merupakan file biasa dalam penyimpanan persisten. etcd HARUS benar-benar yakin bahwa entri WAL benar-benar terjadi sebelum melanjutkan pemrosesan. Di Linux, satu panggilan sistem tidak cukup untuk ini. menulis, karena penulisan sebenarnya ke penyimpanan fisik mungkin tertunda. Sebagai contoh, Linux dapat menyimpan entri WAL dalam cache di memori kernel (seperti cache halaman) untuk beberapa waktu. Dan agar data ditulis secara akurat ke penyimpanan persisten, panggilan sistem fdatasync diperlukan setelah penulisan, dan etcd hanya menggunakannya (seperti yang dapat Anda lihat di hasil pekerjaan jejak, di mana 8 adalah 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>

Sayangnya, menulis ke penyimpanan persisten tidak terjadi secara instan. Jika panggilan fdatasync lambat, kinerja sistem etcd akan terganggu. Dokumentasi untuk etcd mengatakanbahwa penyimpanan dianggap cukup cepat jika, pada persentil ke-99, panggilan fdatasync memerlukan waktu kurang dari 10 md untuk menulis ke file WAL. Ada metrik lain yang berguna untuk penyimpanan, tetapi dalam postingan ini kita hanya membahas tentang metrik ini.

Memperkirakan penyimpanan dengan fio

Jika Anda perlu mengevaluasi apakah penyimpanan Anda cocok untuk etcd, gunakan fio, alat pengujian beban I/O yang sangat populer. Harus diingat bahwa operasi disk bisa sangat berbeda: sinkron dan asinkron, banyak kelas panggilan sistem, dll. Akibatnya, fio cukup sulit digunakan. Ini memiliki banyak parameter, dan kombinasi nilainya yang berbeda menghasilkan beban kerja I/O yang sangat berbeda. Untuk mendapatkan angka yang memadai untuk etcd, Anda harus memastikan bahwa beban uji tulis dari fio sedekat mungkin dengan beban sebenarnya dari etcd saat menulis file WAL.

Oleh karena itu, fio harus, minimal, membuat serangkaian penulisan berurutan ke file, setiap penulisan akan terdiri dari panggilan sistem menulisdiikuti oleh panggilan sistem fdatasync. Penulisan berurutan ke fio memerlukan opsi --rw=write. Untuk fio menggunakan panggilan sistem tulis saat menulis, bukan menulis, Anda harus menentukan parameter --ioengine=sync. Terakhir, untuk memanggil fdatasync setelah setiap penulisan, Anda perlu menambahkan parameter --fdatasync=1. Dua opsi lainnya dalam contoh ini (--size dan -bs) khusus skrip. Di bagian selanjutnya, kami akan menunjukkan cara menyiapkannya.

Mengapa fio dan bagaimana kami belajar mengaturnya

Dalam posting ini, kami menjelaskan kasus nyata. Kami memiliki sebuah kluster Kubernetes v1.13 yang kami pantau dengan Prometheus. etcd v3.2.24 dihosting di SSD. Metrik etcd menunjukkan latensi fdatasync terlalu tinggi, bahkan saat cluster tidak melakukan apa pun. Metriknya aneh dan kami tidak benar-benar tahu apa artinya. Cluster terdiri dari mesin virtual, perlu dipahami apa masalahnya: di SSD fisik atau di lapisan virtualisasi. Selain itu, kami sering membuat perubahan pada konfigurasi perangkat keras dan perangkat lunak, dan kami membutuhkan cara untuk mengevaluasi hasilnya. Kita bisa menjalankan etcd di setiap konfigurasi dan melihat metrik Prometheus, tapi itu terlalu merepotkan. Kami sedang mencari cara yang cukup sederhana untuk mengevaluasi konfigurasi tertentu. Kami ingin memeriksa apakah kami memahami metrik Prometheus dari etcd dengan benar.

Tetapi untuk ini, dua masalah harus diselesaikan. Pertama, seperti apa beban I/O yang dibuat etcd saat menulis ke WAL? Panggilan sistem apa yang digunakan? Berapa ukuran recordnya? Kedua, jika kita menjawab pertanyaan ini, bagaimana kita mereproduksi beban kerja serupa dengan fio? Jangan lupa bahwa fio adalah alat yang sangat fleksibel dengan banyak pilihan. Kami memecahkan kedua masalah dengan satu pendekatan - menggunakan perintah lsof и jejak. lsof mencantumkan semua deskriptor file yang digunakan oleh proses dan file terkaitnya. Dan dengan strace, Anda dapat memeriksa proses yang sudah berjalan, atau memulai proses dan memeriksanya. strace mencetak semua panggilan sistem dari proses yang sedang diperiksa (dan proses anaknya). Yang terakhir ini sangat penting, karena etcd hanya mengambil pendekatan serupa.

Kami pertama kali menggunakan strace untuk menjelajahi server etcd untuk Kubernetes saat tidak ada beban di cluster. Kami melihat bahwa hampir semua rekaman WAL memiliki ukuran yang hampir sama: 2200–2400 byte. Oleh karena itu, pada perintah di awal posting, kami menentukan parameter -bs=2300 (bs berarti ukuran dalam byte untuk setiap entri fio). Perhatikan bahwa ukuran entri etcd bergantung pada versi etcd, distribusi, nilai parameter, dll., dan memengaruhi durasi fdatasync. Jika Anda memiliki skenario serupa, periksa proses etcd Anda dengan strace untuk mengetahui angka pastinya.

Kemudian, untuk mengetahui apa yang dilakukan sistem file etcd, kami memulainya dengan opsi strace dan -ffttT. Jadi kami mencoba memeriksa proses anak dan merekam keluaran masing-masing dalam file terpisah, dan juga mendapatkan laporan terperinci tentang awal dan durasi setiap panggilan sistem. Kami menggunakan lsof untuk mengonfirmasi analisis kami tentang keluaran strace dan melihat deskriptor file mana yang digunakan untuk tujuan tertentu. Jadi dengan bantuan strace, hasil yang ditunjukkan di atas diperoleh. Statistik waktu sinkronisasi mengonfirmasi bahwa wal_fsync_duration_seconds dari etcd konsisten dengan panggilan fdatasync dengan deskriptor file WAL.

Kami membaca dokumentasi untuk fio dan memilih opsi untuk skrip kami sehingga fio akan menghasilkan beban yang mirip dengan etcd. Kami juga memeriksa panggilan sistem dan durasinya dengan menjalankan fio dari strace, mirip dengan etcd.

Kami telah dengan hati-hati memilih nilai parameter --size untuk mewakili seluruh beban I/O dari fio. Dalam kasus kami, ini adalah jumlah total byte yang ditulis ke penyimpanan. Ternyata berbanding lurus dengan jumlah panggilan sistem tulis (dan fdatasync). Untuk nilai bs tertentu, jumlah panggilan fdatasync = ukuran/bs. Karena kami tertarik pada persentil, kami harus memiliki sampel yang cukup untuk memastikannya, dan kami menghitung bahwa 10^4 akan cukup bagi kami (yaitu 22 mebibyte). Jika --size lebih kecil, outlier dapat terjadi (misalnya, beberapa panggilan fdatasync memakan waktu lebih lama dari biasanya dan memengaruhi persentil ke-99).

Coba sendiri

Kami menunjukkan kepada Anda cara menggunakan fio dan melihat apakah penyimpanan memiliki kecepatan yang cukup untuk performa tinggi dll. Sekarang Anda dapat mencobanya sendiri menggunakan, misalnya, mesin virtual dengan penyimpanan SSD Cloud IBM.

Sumber: www.habr.com