NFS di sebalik VPN: lekap semasa but atau lekap automatik atas permintaan?
Lekapan semasa but tersekat pada terowong yang mungkin belum naik. Lekapan automatik menunggu akses pertama, dan kebergantungan VPN terletak pada unit lekap, bukan pada pencetus.
Dua konfigurasi menyelesaikan masalah yang sama dan gagal dalam arah yang bertentangan. Melekapkan kongsi semasa but memberikan setiap perkhidmatan sistem fail yang sama ada wujud atau menjelaskan mengapa but tersekat. Lekapan automatik atas permintaan memberikan mesin but yang pantas dan menyerahkan penantian kepada sesiapa yang menyentuh laluan itu dahulu. Di sebalik VPN yang kedua biasanya pertukaran yang lebih baik, dan alasannya ialah terowong memaksa susunan yang tidak dapat dilihat oleh jujukan but.
Lekap semasa but berbanding lekap automatik
Lekapan semasa but mudah difikirkan. Sasaran sistem fail menunggu lekap, perkhidmatan yang mengisytiharkan kebergantungan padanya bermula selepas itu, dan jika pelayan tidak dapat dicapai mesin sama ada menunggu atau gagal bergantung pada pilihan. Semua yang di hilir mewarisi satu keputusan itu.
Lekapan automatik menyongsangkan perkara itu. Laluan wujud serta-merta, lekap sebenar berlaku apabila sesuatu membukanya, dan perkhidmatan yang bermula awal tidak tersekat pada terowong yang belum naik.
Perbandingan berpunca pada siapa yang patut menyerap kelewatan. Stesen kerja yang memerlukan kongsi sebelum pengguna boleh bekerja mungkin patut menunggu. Komputer riba yang but di dalam beg, atau pelayan yang kongsinya pilihan, tidak sepatutnya.
Tiada pilihan yang membaiki laluan yang hilang. Kedua-duanya hanya memutuskan bila kegagalan diperhatikan.
Baris fstab, pilihan demi pilihan
Andaikan contoh klien OpenVPN yang sedia ada ialah [email protected], pelayan ialah files.corp.example dan titik lekap ialah /mnt/work. Gantikan ketiga-tiganya dengan nilai yang dibenarkan daripada tapak anda sendiri. Satu baris yang boleh berfungsi kelihatan 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 menandakan lekap sebagai memerlukan rangkaian, dan ia tidak menamakan mana-mana terowong langsung. nofail mengekalkan kongsi sebagai pilihan untuk sasaran sistem fail biasa. x-systemd.automount mencipta pencetus atas permintaan dan bukannya melekap serta-merta.
x-systemd.requires= ialah bahagian yang mengikat percubaan lekap kepada unit VPN, dan ia tergolong dalam operasi lekap, bukan pada pencetus. Meletakkan susunan luas pada unit lekap automatik itu sendiri ialah cara orang mencipta kitaran yang kemudiannya diadukan oleh systemd dalam bahasa yang tiada siapa membaca dua kali.
x-systemd.mount-timeout=30s mengehadkan arahan lekap awal. Ia tidak mengehadkan apa-apa yang berlaku selepas itu, dan itulah salah faham yang paling biasa tentang pilihan ini.
Apa yang «bermula» tidak bermaksud
Semak apa maksud aktif bagi unit VPN yang anda namakan. Perkhidmatan terowong boleh melaporkan dirinya bermula sebelum laluan ke pelayan fail wujud atau sebelum nama peribadi diselesaikan, dan menyusun selepasnya kemudian tidak memberi anda apa-apa. Di celah inilah hampir setiap percubaan yang gagal tinggal. Ia juga tidak kelihatan melainkan anda melihat laluan dan penyelesai dan bukannya keadaan unit.
Gunakan isyarat kesediaan pemilik sambungan itu sendiri sebagai prasyarat tambahan di tempat yang ada. Tidur tetap ialah tekaan yang berfungsi di meja anda dan gagal pada rangkaian yang lebih perlahan atau selepas sambung semula.
Periksa unit yang dijana untuk laluan contoh: mnt-work.automount dan mnt-work.mount. Selepas perubahan fstab yang disemak, muat semula systemd dan uruskan unit itu secara langsung dan bukannya menjalankan arahan lekap menyeluruh yang melatih entri tidak berkaitan.
Satu lagi amaran tergolong di sini. Perkhidmatan yang menyentuh /mnt/work semasa bermula masih mencetuskan lekap dan masih menunggunya, jadi menanda kongsi sebagai pilihan tidak menjadikan setiap aplikasi sabar.
Selepas lekap ia adalah kegagalan yang berbeza
Sebaik sahaja NFS dilekapkan, tingkah laku cubaan semula dan pemulihan sistem fail menentukan apa yang dilakukan oleh gangguan kemudian terhadap bacaan atau tulisan. Had masa lekap yang anda tetapkan tidak mempunyai pengaruh terhadapnya.
Lekap lembut memendekkan sesetengah penantian dan mengubah semantik ralat, dengan akibat integriti data yang mudah terlepas pandang apabila matlamatnya ialah but yang lebih pantas. Memilihnya untuk memenangi dua saat permulaan jarang merupakan pertukaran yang baik. Jika keperluan itu benar-benar operasi terbatas semasa gangguan, itu keputusan peringkat aplikasi, bukan bendera fstab.
Putuskan apa yang harus berlaku kepada proses yang sedang menulis apabila terowong jatuh, dan tuliskan. Jawapan itu lebih berguna daripada mana-mana rentetan pilihan.
Uji empat keadaan, bukan satu
But biasa dengan terowong tersedia ialah kes yang mudah dan hampir tidak membuktikan apa-apa. Ia mengesahkan bahawa rentetan itu dieja dengan betul dan tidak lebih. Uji akses pertama tanpa VPN, kemudian pemulihan apabila ia naik, kemudian gangguan terkawal selepas lekap yang berjaya.
Empat keadaan, empat pemerhatian, dan nota diletakkan di sebelah entri fstab. Orang seterusnya mewarisi tingkah laku dan bukannya konfigurasi yang perlu direkayasa semula.