Sebuah cerita pendek tentang fio dan lain-lain
Kinerja cluster etcd sangat tergantung pada kinerja penyimpanannya. etcd mengekspor beberapa metrik ke Prometheus untuk memberikan informasi yang diperlukan tentang kinerja penyimpanan. Misalnya, metrik wal_fsync_duration_seconds. Dokumentasi untuk etcd mengatakan : agar penyimpanan dianggap cukup cepat, persentil ke-99 dari metrik ini harus kurang dari 10 ms. Jika Anda berencana untuk menjalankan cluster etcd pada mesin Linux dan ingin mengevaluasi apakah penyimpanan Anda cukup cepat (misalnya, SSD), Anda dapat menggunakan fio , alat yang populer untuk menguji operasi I / O. Jalankan perintah berikut, di mana data uji 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 memverifikasi bahwa persentil ke-99 dari durasi fdatasync 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 mengonfigurasi opsi --size dan --bs untuk skenario spesifik kami. Untuk mendapatkan hasil yang bermanfaat dari fio, masukkan nilai Anda. Di mana mendapatkannya? Baca cara kami mempelajari cara mengkonfigurasi fio .
- Selama pengujian, seluruh beban I / O berasal dari fio. Dalam skenario nyata, kemungkinan permintaan penulisan lainnya akan datang ke repositori, kecuali untuk permintaan yang terkait dengan wal_fsync_duration_seconds. Beban ekstra akan meningkatkan nilai wal_fsync_duration_seconds. Jadi jika persentil ke-99 hampir mencapai 10 ms, penyimpanan Anda tidak akan memiliki kecepatan yang cukup.
- Ambil versi fio tidak lebih rendah dari 3,5 (yang sebelumnya tidak menunjukkan persentil durasi fdatasync).
- Di atas hanya cuplikan hasil dari fio.
Sebuah cerita panjang tentang fio dan lain-lain
Apa itu WAL di etcd
Database biasanya menggunakan log write-ahead ; etcd menggunakannya juga. Di sini kita tidak akan membahas secara rinci log write-ahead (WAL). Kita hanya perlu tahu bahwa setiap anggota gugus etcd menyimpannya dalam penyimpanan persisten. etcd menulis setiap operasi pasangan nilai kunci (misalnya memperbarui) ke WAL sebelum menerapkannya ke repositori. Jika di antara snapshot salah satu anggota penyimpanan crash dan restart, secara lokal dapat memulihkan transaksi dari snapshot terakhir menggunakan konten WAL.
Ketika klien menambahkan kunci ke penyimpanan pasangan nilai kunci atau memperbarui nilai kunci yang ada, dll akan mencatat operasi ini di WAL, yang merupakan file biasa dalam penyimpanan yang persisten. Sebelum melanjutkan, etcd HARUS yakin sepenuhnya bahwa menulis ke WAL benar-benar terjadi. Di Linux, panggilan sistem tulis tunggal tidak cukup untuk ini, karena sebenarnya menulis ke penyimpanan fisik mungkin tertunda. Sebagai contoh, Linux dapat menyimpan catatan WAL dalam cache di memori kernel untuk beberapa waktu (misalnya, cache halaman). Dan agar data ditulis secara akurat ke penyimpanan persisten, Anda memerlukan pemanggilan sistem fdatasync setelah menulis, dan etcd hanya menggunakannya (seperti yang Anda lihat sebagai hasil dari strace , 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, ".\0\0\0\0\0\0\202\10\2\20\361\223\255\266\6\32$\10\0\20\10\30\26\"\34\"\r\n\3fo"..., 2296) = 2296 <0.000130> 21:23:09.895041 fdatasync(8) = 0 <0.008314>
Sayangnya, menulis ke penyimpanan yang persisten tidak langsung berjalan. Jika panggilan fdatasync lambat, kinerja sistem etcd turun. Dokumentasi untuk etcd mengatakan bahwa repositori dianggap cukup cepat jika dalam persentil ke-99 panggilan fdatasync dibutuhkan kurang dari 10 ms untuk menulis ke file WAL. Ada metrik lain yang berguna untuk penyimpanan, tetapi dalam posting ini kita hanya berbicara tentang metrik ini.
Nilai penyimpanan dengan fio
Jika Anda perlu mengevaluasi apakah repositori Anda cocok untuk etcd, gunakan fio, alat pengujian beban I / O yang sangat populer. Harus diingat bahwa operasi disk dapat sangat berbeda: sinkron dan asinkron, banyak kelas panggilan sistem, dll. Akibatnya, fio sangat sulit digunakan. Ini memiliki banyak parameter, dan kombinasi nilai yang berbeda menghasilkan beban kerja I / O yang sama sekali berbeda. Untuk mendapatkan angka yang memadai untuk etcd, Anda harus memastikan bahwa beban rekaman pengujian dari fio sedekat mungkin dengan beban nyata dari etcd saat menulis file WAL.
Akibatnya, setidaknya harus membuat beban dalam bentuk serangkaian operasi tulis berurutan ke file, setiap catatan akan terdiri dari panggilan sistem tulis diikuti oleh panggilan sistem fdatasync. Untuk operasi penulisan berurutan, fio membutuhkan opsi --rw = write. Agar fio menggunakan panggilan sistem tulis alih-alih menulis saat merekam, ada baiknya menentukan parameter --ioengine = sinkronisasi. Akhirnya, untuk fdatasync dipanggil setelah setiap entri, Anda perlu menambahkan --fdatasync = 1 parameter. Dua opsi lain dalam contoh ini (--size dan --bs) adalah skenario khusus. Di bagian selanjutnya, kami akan menunjukkan kepada Anda cara mengonfigurasinya.
Mengapa harus dan bagaimana kami mempelajari cara mengonfigurasinya
Dalam posting ini kami menggambarkan kasus sebenarnya. Kami memiliki kluster Kubernetes v1.13, yang kami pantau menggunakan Prometheus. etcd v3.2.24 di-host pada SSD. Metrik Etcd menunjukkan latensi terlalu tinggi untuk fdatasync, bahkan ketika cluster tidak melakukan apa pun. Metriknya aneh, dan kami benar-benar tidak tahu apa artinya. Cluster terdiri dari mesin virtual, Anda harus memahami apa masalahnya: di SSD fisik atau di lapisan virtualisasi. Selain itu, kami sering melakukan perubahan pada konfigurasi perangkat keras dan perangkat lunak, dan kami membutuhkan cara untuk mengevaluasi hasilnya. Kita dapat menjalankan etcd di setiap konfigurasi dan melihat metrik Prometheus, tetapi ini terlalu merepotkan. Kami mencari cara yang cukup sederhana untuk mengevaluasi konfigurasi tertentu. Kami ingin memeriksa apakah kami memahami metrik Prometheus dari etcd dengan benar.
Tetapi untuk ini perlu untuk menyelesaikan dua masalah. Pertama, seperti apa I / O memuat yang diciptakan etcd saat menulis ke WAL? Sistem panggilan apa yang digunakan? Berapa ukuran catatan? Kedua, jika kita menjawab pertanyaan-pertanyaan ini, bagaimana cara mereproduksi beban kerja yang sama dengan fio? Jangan lupa bahwa fio adalah alat yang sangat fleksibel dengan banyak pilihan. Kami memecahkan kedua masalah dengan satu pendekatan - menggunakan perintah lsof dan strace . lsof menampilkan semua deskriptor file yang digunakan oleh proses dan file terkait. Dan dengan strace, Anda dapat mempelajari proses yang sudah berjalan atau memulai proses dan mempelajarinya. strace menampilkan semua panggilan sistem dari proses yang sedang dipelajari (dan proses anaknya). Yang terakhir ini sangat penting, karena etcd hanya menggunakan pendekatan yang sama.
Pertama-tama, kami menggunakan strace untuk mempelajari server etcd untuk Kubernet ketika tidak ada beban di cluster. Kami melihat bahwa hampir semua catatan WAL memiliki ukuran yang sama: 2200-2400 byte. Oleh karena itu, pada perintah di awal tulisan, kami menetapkan parameter --bs = 2300 (bs berarti ukuran dalam byte untuk setiap entri fio). Perhatikan bahwa ukuran entri etcd tergantung pada versi etcd, pengiriman, nilai parameter, dll, dan mempengaruhi durasi fdatasync. Jika Anda memiliki skenario yang sama, periksa proses etcd Anda dengan strace untuk mengetahui angka pastinya.
Kemudian, untuk mendapatkan ide bagus tentang tindakan dalam sistem file etcd, kami memulainya dengan strace dan dengan opsi -ffttT. Jadi kami mencoba mempelajari proses anak dan menulis output masing-masing dalam file terpisah, dan juga mendapatkan laporan rinci tentang awal dan durasi setiap panggilan sistem. Kami menggunakan lsof untuk mengkonfirmasi analisis kami tentang output strace dan melihat deskriptor file mana yang digunakan untuk tujuan apa. Jadi dengan strace kami mendapat hasil yang ditunjukkan di atas. Statistik pada waktu sinkronisasi mengkonfirmasi bahwa wal_fsync_duration_seconds eksponen dari etcd sesuai dengan panggilan fdatasync dengan deskriptor file WAL.
Kami mempelajari dokumentasi 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 dengan hati-hati memilih nilai parameter --size, yang 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 ke fdatasync = size / bs. Karena kami tertarik pada persentil, kami seharusnya memiliki sampel yang cukup untuk keandalan, dan kami menghitung bahwa 10 ^ 4 akan cukup bagi kami (kami mendapatkan 22 mebibytes). Jika --size lebih kecil, outlier dapat terjadi (misalnya, beberapa panggilan fdatasync bekerja lebih lama dari biasanya dan memengaruhi persentil ke-99).
Coba sendiri
Kami menunjukkan cara menggunakan fio dan mencari tahu apakah penyimpanan memiliki kecepatan yang cukup untuk kinerja tinggi, dll. Sekarang Anda dapat mencobanya sendiri, menggunakan, misalnya, mesin virtual dengan penyimpanan SSD di IBM Cloud .