NFS di balik VPN: mount saat boot atau automount sesuai permintaan?

Dua konfigurasi menyelesaikan masalah yang sama dan gagal ke arah berlawanan. Me-mount share saat boot memberi setiap layanan sebuah sistem berkas yang entah ada atau menjelaskan mengapa boot tersendat. Automount sesuai permintaan memberi mesin boot cepat dan menyerahkan penantian kepada siapa pun yang menyentuh jalur itu lebih dulu. Di balik VPN yang kedua biasanya pertukaran yang lebih baik, dan alasannya adalah terowongan memaksakan urutan yang tidak dapat dilihat oleh urutan boot.

Mount saat boot versus automount

Mount saat boot mudah dipikirkan. Target sistem berkas menunggu mount, layanan yang menyatakan ketergantungan padanya mulai sesudahnya, dan jika server tidak dapat dijangkau mesin entah menunggu atau gagal tergantung opsinya. Semua yang di hilir mewarisi satu keputusan itu.

Automount membalik itu. Jalur langsung ada, mount sebenarnya terjadi ketika ada yang membukanya, dan layanan yang mulai lebih awal tidak terhalang pada terowongan yang belum naik.

Perbandingannya bermuara pada siapa yang harus menyerap penundaan. Stasiun kerja yang memerlukan share sebelum pengguna dapat bekerja sebaiknya menunggu. Laptop yang boot di dalam tas, atau server yang share-nya opsional, tidak perlu.

Tak satu pun opsi memperbaiki rute yang hilang. Keduanya hanya memutuskan kapan kegagalan itu diamati.

Baris fstab, opsi demi opsi

Misalkan instans klien OpenVPN yang ada adalah [email protected], servernya files.corp.example dan titik mount-nya /mnt/work. Ganti ketiganya dengan nilai resmi dari situs Anda sendiri. Satu baris yang dapat bekerja tampak seperti ini:

files.corp.example:/export/work /mnt/work nfs _netdev,nofail,x-systemd.automount,[email protected],x-systemd.mount-timeout=30s 0 0

_netdev menandai mount sebagai memerlukan jaringan, dan itu sama sekali tidak menyebut terowongan mana pun. nofail menjaga share tetap opsional untuk target sistem berkas biasa. x-systemd.automount membuat pemicu sesuai permintaan alih-alih me-mount segera.

x-systemd.requires= adalah bagian yang mengikat percobaan mount ke unit VPN, dan itu berada pada operasi mount, bukan pada pemicu. Menaruh urutan luas pada unit automount itu sendiri adalah cara orang membuat siklus yang kemudian dikeluhkan systemd dalam bahasa yang tidak dibaca dua kali oleh siapa pun.

x-systemd.mount-timeout=30s membatasi perintah mount awal. Itu tidak membatasi apa pun yang terjadi sesudahnya, dan itulah kesalahpahaman paling umum tentang opsi ini.

Apa yang tidak berarti «sudah mulai»

Periksa apa arti aktif untuk unit VPN yang Anda sebutkan. Layanan terowongan dapat melaporkan dirinya sudah mulai sebelum rute ke server berkas ada atau sebelum nama privat teresolusi, dan mengurutkan sesudahnya tidak memberi Anda apa pun. Di celah inilah hampir setiap percobaan gagal hidup. Itu juga tidak terlihat kecuali Anda melihat rute dan resolver alih-alih keadaan unit.

Gunakan sinyal kesiapan milik pemilik koneksi sebagai prasyarat tambahan di tempat yang ada. Tidur tetap adalah tebakan yang bekerja di meja Anda dan gagal pada jaringan yang lebih lambat atau setelah menyambung ulang.

Periksa unit yang dihasilkan untuk jalur contoh: mnt-work.automount dan mnt-work.mount. Setelah perubahan fstab yang ditinjau, muat ulang systemd dan kelola unit itu secara langsung alih-alih menjalankan perintah mount menyeluruh yang melatih entri tak terkait.

Satu peringatan lagi pantas ada di sini. Layanan yang menyentuh /mnt/work saat mulai tetap memicu mount dan tetap menunggunya, jadi menandai share opsional tidak membuat setiap aplikasi sabar.

Setelah mount, kegagalannya berbeda

Setelah NFS di-mount, perilaku percobaan ulang dan pemulihan sistem berkas mengatur apa yang dilakukan pemadaman berikutnya terhadap pembacaan atau penulisan. Batas waktu mount yang Anda tetapkan tidak berpengaruh pada itu.

Mount lunak memperpendek sebagian penantian dan mengubah semantik kesalahan, dengan konsekuensi integritas data yang mudah terlewat ketika tujuannya boot yang lebih cepat. Memilihnya untuk memenangkan dua detik waktu mulai jarang merupakan pertukaran yang baik. Jika persyaratannya benar-benar operasi terbatas selama pemadaman, itu keputusan tingkat aplikasi, bukan tanda fstab.

Putuskan apa yang harus terjadi pada proses yang sedang menulis ketika terowongan jatuh, dan tuliskan. Jawaban itu lebih berguna daripada rangkaian opsi apa pun.

Uji empat keadaan, bukan satu

Boot normal dengan terowongan tersedia adalah kasus mudah dan hampir tidak membuktikan apa pun. Itu memastikan string-nya ditulis dengan benar dan tidak lebih. Uji akses pertama tanpa VPN, lalu pemulihan saat naik, lalu pemadaman terkendali setelah mount yang berhasil.

Empat keadaan, empat pengamatan, dan catatannya diletakkan di samping entri fstab. Orang berikutnya mewarisi perilaku alih-alih konfigurasi yang harus direkayasa balik.