NFS خلف شبكة VPN: تحميل عند الإقلاع أم تحميل تلقائي عند الطلب؟

يحل إعدادان المشكلة نفسها ويفشلان في اتجاهين متعاكسين. تحميل المشاركة عند الإقلاع يمنح كل خدمة نظام ملفات إما موجودًا وإما سببًا لتوقف الإقلاع. التحميل التلقائي عند الطلب يمنح الجهاز إقلاعًا سريعًا ويسلّم الانتظار إلى أول من يلمس المسار. خلف شبكة VPN يكون الخيار الثاني عادة أفضل مقايضة، والسبب أن النفق يفرض ترتيبًا لا تستطيع تسلسل الإقلاع رؤيته.

التحميل عند الإقلاع مقابل التحميل التلقائي

التحميل عند الإقلاع سهل التفكير فيه. هدف نظام الملفات ينتظر التحميل، والخدمات التي تعلن اعتمادها عليه تبدأ بعده، وإذا كان الخادم غير قابل للوصول فإن الجهاز إما ينتظر أو يفشل بحسب الخيارات. كل ما هو لاحق يرث ذلك القرار الواحد.

التحميل التلقائي يعكس ذلك. المسار موجود فورًا، والتحميل الحقيقي يحدث عندما يفتحه شيء ما، والخدمات التي تبدأ مبكرًا لا تتعطل على نفق لم يقم بعد.

المقارنة تتلخص في من ينبغي أن يستوعب التأخير. محطة عمل تحتاج المشاركة قبل أن يتمكن المستخدم من العمل ينبغي أن تنتظر على الأرجح. حاسوب محمول يُقلع داخل حقيبة، أو خادم مشاركته اختيارية، لا ينبغي أن ينتظر.

لا يصلح أي من الخيارين مسارًا مفقودًا. كلاهما يقرر فقط متى يُلاحظ الفشل.

سطر fstab، خيارًا بخيار

افترض أن نسخة عميل OpenVPN الحالية هي [email protected]، وأن الخادم هو files.corp.example، ونقطة التحميل هي /mnt/work. استبدل الثلاثة بالقيم المصرح بها من موقعك. سطر واحد صالح للعمل يبدو هكذا:

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

_netdev يعلّم التحميل بأنه يحتاج إلى شبكة، وهو لا يسمّي أي نفق على الإطلاق. nofail يبقي المشاركة اختيارية لهدف نظام الملفات العادي. x-systemd.automount ينشئ المشغّل عند الطلب بدلًا من التحميل فورًا.

x-systemd.requires= هو الجزء الذي يربط محاولة التحميل بوحدة VPN، وهو ينتمي إلى عملية التحميل لا إلى المشغّل. ووضع ترتيب واسع على وحدة التحميل التلقائي نفسها هو الطريقة التي يخلق بها الناس دورات تشكو منها systemd بعد ذلك بلغة لا يقرأها أحد مرتين.

x-systemd.mount-timeout=30s يحدّ من أمر التحميل الأولي. وهو لا يحدّ من أي شيء يحدث بعد ذلك، وهذا هو أكثر سوء فهم شائع حول هذا الخيار.

ما لا يعنيه بدء التشغيل

تحقق مما يعنيه أن تكون الخدمة نشطة بالنسبة لوحدة VPN التي سميتها. يمكن لخدمة نفق أن تعلن نفسها بدأت قبل أن يوجد المسار إلى خادم الملفات أو قبل أن يُحلّ الاسم الخاص، والترتيب بعدها لا يجلب لك شيئًا. هذه هي الفجوة التي تعيش فيها كل محاولة فاشلة تقريبًا. وهي أيضًا غير مرئية إلا إذا نظرت إلى المسار والمُحلّل بدلًا من حالة الوحدة.

استخدم إشارة الجاهزية الخاصة بمالك الاتصال كشرط مسبق إضافي حيث توجد. النوم الثابت تخمين ينجح على مكتبك ويفشل على شبكة أبطأ أو بعد إعادة اتصال.

افحص الوحدات المُولّدة للمسار في المثال: mnt-work.automount و mnt-work.mount. بعد تغيير في fstab تمت مراجعته، أعد تحميل systemd وأدر تلك الوحدات مباشرة بدلًا من تشغيل أمر تحميل شامل يمارس إدخالات غير ذات صلة.

تحذير آخر ينتمي إلى هنا. الخدمة التي تلمس /mnt/work عند بدء التشغيل ما زالت تُطلق التحميل وما زالت تنتظره، لذا فإن جعل المشاركة اختيارية لا يجعل كل تطبيق صبورًا.

ما بعد التحميل فشل من نوع آخر

بمجرد تحميل NFS، يحكم سلوك إعادة المحاولة والاستعادة في نظام الملفات ما يفعله انقطاع لاحق بقراءة أو كتابة. مهلة التحميل التي ضبطتها لا تأثير لها على ذلك.

التحميل اللين يقصّر بعض الانتظارات ويغيّر دلالات الأخطاء، مع عواقب على سلامة البيانات يسهل إغفالها عندما يكون الهدف إقلاعًا أسرع. اختياره لكسب ثانيتين من بدء التشغيل مقايضة نادرة الجودة. وإذا كان الشرط حقًا عملية محدودة زمنيًا أثناء انقطاع، فذلك قرار على مستوى التطبيق لا علامة في fstab.

قرر ما ينبغي أن يحدث لعملية في منتصف كتابة عندما يسقط النفق، واكتب ذلك. تلك الإجابة أنفع من أي سلسلة خيارات.

اختبر أربع حالات، لا حالة واحدة

بدء التشغيل العادي مع توفر النفق هو الحالة السهلة ولا يثبت شيئًا تقريبًا. إنه يؤكد أن السلسلة مكتوبة بشكل صحيح ولا شيء أكثر. اختبر أول وصول مع غياب VPN، ثم الاستعادة عندما يقوم، ثم انقطاعًا متحكمًا فيه بعد تحميل ناجح.

أربع حالات، وأربع ملاحظات، وتذهب الملاحظات بجانب إدخال fstab. الشخص التالي يرث سلوكًا بدلًا من إعداد عليه أن يعكسه هندسيًا.