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. האדם הבא יורש התנהגות במקום תצורה שעליו להנדס לאחור.