Dari Mana Pertumbuhan Disk Server VPN Berasal dan Cara Membatasinya

Tunnel berhenti menerima koneksi, layanan restart dua kali, lalu tidak ada apa pun yang muncul di log-nya. Keheningan itu adalah petunjuknya, karena log-lah yang memenuhi disk dan daemon tidak punya tempat menuliskan galat yang Anda tunggu. Layanan apa pun yang berjalan lama bisa mencapai keadaan itu, dan menghapus direktori bernama logs jarang memperbaikinya. Perbaikan yang tahan lama adalah mengetahui penyimpanan mana yang tumbuh, siapa pemilik kebijakan retensinya, dan apakah penulisnya benar-benar melepaskan ruang itu.

Temukan penyimpanan yang tumbuh, dan laju pertumbuhannya

Mulailah dengan dua angka yang mudah terlupa: blok bebas dan inode bebas. Sistem berkas bisa melaporkan banyak ruang dan tetap menolak penulisan karena inode-nya habis, yang terjadi ketika layanan membuat satu berkas per sesi. Mintalah kedua pembacaan pada volume yang sama, karena jawabannya bisa berbeda pada sore yang sama. Lakukan saat host sehat, agar angkanya menggambarkan operasi normal, bukan gangguan.

df -h /var
df -i /var

Lalu kaitkan pertumbuhan itu ke pemiliknya. Angka pemakaian journal sendiri hanya mencakup journal, dan tidak akan pernah melihat daemon yang menulis ke jalur dari berkas konfigurasinya.

journalctl --disk-usage

Pertumbuhan sepanjang waktu mengatakan lebih banyak daripada pembacaan tunggal apa pun. Tingkat debug yang dibiarkan menyala, perulangan percobaan ulang yang mencatat setiap upaya, atau berkas tangkapan yang tidak dihentikan siapa pun: masing-masing bisa tampak biasa pada satu saat dan mengkhawatirkan sejam kemudian. Ambil satu pembacaan, tunggu melewati periode sibuk, ambil yang lain, dan bagi dengan intervalnya. Laju yang bisa Anda sebutkan mengubah kapasitas menjadi keputusan, bukan kebakaran.

Apa yang dilakukan rotasi pada berkas yang terbuka

Berkas log adalah nama yang menunjuk ke sebuah inode, dan ruangnya baru kembali ketika pegangan terbuka terakhir ditutup. Ganti nama berkasnya dan penulisnya terus mengisi inode yang sama; hapus berkasnya dan penulisnya terus mengisi inode tanpa nama sama sekali. Keadaan itulah sebabnya «saya menghapus berkasnya dan disk tetap penuh» menggambarkan deskriptor berkas, bukan sistem berkas yang rusak. Menyalakan ulang penulisnya, atau memilih mode rotasi yang membuka kembali berkasnya, adalah yang benar-benar mengembalikan bloknya.

lsof +L1 | head

Kebijakan menjadi milik komponen yang menulis berkas. Journal menegakkan batas penyimpanannya sendiri dari berkas konfigurasinya, sedangkan layanan berbasis berkas biasanya mengandalkan logrotate, entah dengan aturan pembuatan dan sinyal pembukaan ulang atau dengan mode pemotongan di tempat saat penulisnya tidak dapat membuka ulang. Pastikan keputusannya tanpa mengubah apa pun lebih dulu:

logrotate -d /etc/logrotate.conf

Di mana batas itu seharusnya berada, dan seberapa besar

Letakkan batasnya di tempat penulis dikonfigurasi, bukan di titik kait. Kuota pada seluruh volume melindungi host tetapi tidak mengatakan layanan mana yang gagal lebih dulu, dan skrip pembersihan global cenderung menghapus bukti yang dibutuhkan insiden berikutnya. Batas journal, jumlah rotasi dengan ukuran maksimum, dan retensi tingkat aplikasi masing-masing membatasi satu produsen. Bersama-sama mereka membatasi totalnya; sendirian masing-masing adalah dugaan.

Ukur batas itu dari retensi yang bisa Anda pertahankan, bukan dari ruang kosong yang tersedia. Jika peninjauan memerlukan satu minggu percobaan koneksi, journal harus menyimpan satu minggu pada laju tersibuk yang diperkirakan, dan laju itu adalah angka yang diukur sebelumnya.

Pencatatan debug adalah mode sementara dengan waktu mulai yang tercatat, bukan rencana penyimpanan. Simpan pertanyaan privasi di dalam keputusan yang sama, karena log koneksi membawa alamat dan pengenal. Retensi yang lebih panjang juga pilihan penanganan data, dan sebaiknya diambil oleh orang yang mengenal kedua batasan.

Verifikasi batas setelah restart

Perubahan retensi yang bertahan sampai reboot berikutnya bukanlah perubahan. Nyalakan ulang penulisnya, pastikan batas baru berlaku, dan periksa bahwa rotasi masih berjalan sesudahnya. Untuk journal, satu restart dan satu pembacaan pemakaian menjawab kedua pertanyaannya:

systemctl restart systemd-journald
journalctl --disk-usage

Untuk layanan berbasis berkas, jalankan tugas rotasi sekali secara manual dan pastikan berkasnya diganti serta deskriptornya dibuka ulang. Penulis yang mempertahankan pegangan lama lolos pemeriksaan dangkal dan gagal saat volume penuh berikutnya. Awasi ruang kosong selama uji, karena berkas yang menyusut sementara ruangnya tidak kembali berarti inode lama masih dipegang.

Bandingkan pembacaan berikutnya dengan yang ini

Kembalilah setelah sepekan dan bandingkan laju pertumbuhan dengan yang tercatat. Laju yang cocok berarti batasnya bertahan dan beban kerjanya stabil; laju yang berlipat berarti ada yang berubah, dan pertanyaan yang berguna adalah apa. Bacalah isi log untuk kegagalan berulang lebih dulu, karena perulangan percobaan ulang adalah gejala sekaligus penyebab volume. Lalu periksa apa pun yang baru diaktifkan, termasuk tingkat debug yang dinyalakan selama insiden dan tidak pernah dimatikan.

Simpan cadangan di luar volume yang sama, atau terima bahwa satu disk penuh akan membawa cadangannya. Salinan yang ditulis ke host yang dilindunginya bukan rencana pemulihan, dan retensinya perlu jawabannya sendiri.

Tuliskan apa yang disimpan, di mana, berapa lama, dan siapa yang menghapusnya. Kalimat itu adalah hasil kerjanya, dan itulah satu-satunya bagian dari pekerjaan ini yang bertahan melewati restart berikutnya.