Versi terbaru dari Podman, Buildah, dan CRI-O telah mulai memanfaatkan fitur kernel baru, mount overlay yang mudah menguap. Fitur ini memungkinkan Anda memasang sistem file overlay dengan tanda yang memberitahukannya untuk tidak menyinkronkan ke disk.
Jika Anda membutuhkan pengingat tentang penggunaan dan manfaat pemasangan overlay, lihat artikel saya dari musim panas lalu.
Apa itu sinkronisasi, dan mengapa itu penting?
Di Linux, ketika Anda menulis ke file atau direktori, kernel tidak langsung menulis data ke disk. Sebagai gantinya, ini menyangga sekelompok penulisan dan kemudian secara berkala menyimpan data ke disk untuk meningkatkan kinerja. Ini disebut sinkronisasi . Masalah dengan ini adalah bahwa proses berpikir data disimpan ketika penulisan selesai, tetapi sebenarnya tidak sampai kernel menyinkronkan data itu. Artinya, jika Anda menulis data dan kernel mengalami crash, ada kemungkinan data tersebut tidak pernah disimpan.
Karena itu, banyak sistem file yang disinkronkan secara teratur, dan alat dapat meminta agar sinkronisasi sering terjadi. Saat sinkronisasi terjadi, kernel berhenti memproses data dengan kunci dan menyinkronkan semua data ke disk. Tentu saja, ini menyebabkan kinerja yang lebih buruk. Jika Anda memiliki proses yang sering menyebabkan sinkronisasi, kinerja pekerjaan Anda dapat benar-benar terganggu. Alat tertentu seperti RPM meminta sinkronisasi setelah setiap file ditulis ke disk, menyebabkan semua halaman kotor untuk file tersebut dihapus, dan ini merupakan overhead yang cukup besar.
[ Memulai container? Lihat kursus gratis ini. Menyebarkan aplikasi kemas:Tinjauan teknis. ]
Kontainer mungkin tidak perlu disinkronkan
Di dunia kontainer, kami memiliki banyak kasus penggunaan di mana kami tidak peduli jika data disimpan. Jika kernel crash, kami tidak akan menggunakan data tertulis.
Saat melakukan buildah bud atau podman build , gambar container ditulis ke titik pemasangan overlay, sering kali menggunakan DNF atau YUM. Jika kernel mogok di tengah pembuatan gambar, konten yang ditulis ke lapisan overlay tidak akan berguna dan harus dibersihkan oleh pengguna. Apa pun yang gagal untuk menulis hanya akan dihapus. Namun, ketika build selesai, lapisan overlay ditar menjadi bundel gambar yang kemudian dapat disinkronkan ke disk.
Kasus penggunaan lain untuk mount overlay volatil adalah menjalankan Podman dengan --rm bendera. --rm flag memberitahu Podman untuk menghancurkan container dan titik pemasangan overlay saat container selesai. Kerusakan penampung akan meninggalkan konten yang sudah diindikasikan pengguna bahwa mereka tidak menggunakannya, jadi tidak ada alasan untuk peduli apakah penulisan berhasil.
Di dunia Kubernetes, CRI-O adalah mesin kontainer. Kubernetes hampir selalu diatur untuk menghapus semua container saat boot. Pada dasarnya, ia ingin memulai dengan keadaan bersih. Ini berarti jika kernel mengalami crash saat data sedang ditulis ke overlay mount, data ini akan dimusnahkan segera setelah sistem melakukan booting. Juga aman untuk menggunakan konfigurasi seperti itu dengan container stateful karena data biasanya ditulis ke volume eksternal yang tidak akan terpengaruh oleh flag “volatile” saat runtime.
Menambahkan opsi yang mudah berubah
Insinyur tim kontainer Giuseppe Scrivano memperhatikan kasus penggunaan ini dan berpikir bahwa kami dapat meningkatkan kinerja dengan menambahkan opsi volatil ke sistem file overlay kernel Linux dan menerapkan perilaku ini. Akibatnya, versi Buildah, Podman, dan CRI-O yang lebih baru akan menggunakan flag volatil secara default dalam kasus penggunaan ini dan semoga mendapatkan kinerja yang lebih baik.
Perhatikan bahwa volume apa pun yang dipasang ke penampung akan terus memiliki perilaku sinkronisasi default dari sistem file biasa, jadi Anda tidak perlu khawatir kehilangan data yang ditulis ke penyimpanan permanen.
Grafik di bawah ini menunjukkan bagaimana jumlah IOPS tulis berkurang dalam wadah yang menjalankan yum install -y texlive pada mesin dengan 16 GB RAM. Selain itu, saat container berjalan dengan flag volatil diaktifkan, waktu jam dindingnya juga terpengaruh dan berakhir lebih cepat.
Halaman kotor pada akhirnya akan ditulis ke penyimpanan setelah rasio kotor atau batas waktu inode berakhir, karena pengaturan ini tidak terpengaruh oleh tanda pemasangan yang mudah menguap.
Menutup
Dengan teknologi container, kami terus mendorong apa yang dapat ditangani oleh sistem Linux dan bereksperimen dengan kasus penggunaan baru. Menambahkan opsi volatil ke sistem file overlay kernel membantu meningkatkan kinerja, memungkinkan container untuk terus berkembang dan memberikan manfaat yang lebih besar.
[ Unduh gratis:Lembar contekan perintah Linux tingkat lanjut. ]