מכונת Linux מצטרפת ל-VPN, מעלה ייצוא NFS מרוחק, ואז מגישה את העלייה הזו לקבוצת לקוחות אחרת. הסידור הזה נראה כמו ניתוב עם צעדים נוספים, וזו ההנחה השגויה הראשונה. המכונה האמצעית היא לקוח של השרת במעלה הזרם ושרת עבור הלקוחות במורד הזרם, והיא משתתפת בשני קשרי שירות הקבצים. העברת מנות אינה מביעה דעה על ידיות קבצים, נעילה או זהות מערכת קבצים; ייצוא חוזר כן.

התחילו בשאלה אם הלקוחות במורד הזרם יכלו להגיע לשרת המקורי ישירות. אם כן, המכונה האמצעית אופציונלית.

שלושה מודלים, שלושה סיפורי עקביות

עלייה ישירה היא הפשוטה ביותר: כל לקוח מעלה את השרת המקורי דרך המנהרה, ומדיניות הייצוא של אותו שרת קובעת את הגישה. ייצוא חוזר הוא המכונה האמצעית שמציגה גבול שירות שונה, וזה שימושי כשהרשת הפונה ללקוחות אינה רשאית להגיע לשרת ישירות. שכפול הוא מודל שלישי, והוא מעביר את השאלה מעקביות לסנכרון ולפתרון קונפליקטים.

אל תתארו עותק משוכפל כאילו היה ייצוא חוזר חי. מצבי הכשל שונים, ומשתמש שמצפה שכל פעולה תגיע למערכת הקבצים המקורית יופתע במהלך נפילת קישור.

הזהות שורדת את פקודת העלייה

ייצוא חוזר זקוק למזהה מערכת קבצים מפורש, והזהות הזו חייבת לשרוד הפעלות מחדש ובנייה מחדש של התצורה. תיעוד הליבה ברור בדרישה, והוא גם מזהיר כי crossmnt אינו מסיר את הצורך לייצא מערכות קבצים בנות עם מזהים משלהן. עץ תיקיות שנראה למשתמש כרציף יכול לחצות כמה גבולות של מערכות קבצים. גרסאות nfs-utils עדכניות יכולות להקצות מזהים אוטומטית לתצורות נתמכות, וכשהן עושות זאת, מסד הנתונים שלהן הופך לחלק ממצב השער. התייחסו למזהים האלה כאל זהות שירות ולא כאל קבצים חד-פעמיים.

ידיות קבצים הן גבול הזהות השני: ייצוא חוזר עוטף את הידית המקורית, מה שמגדיל אותה ועלול לחרוג ממגבלת הלקוח. עלייה מוצלחת אינה מוכיחה שכל פריסת ייצוא תואמת.

לא כל תכונה של NFS שורדת את המכונה האמצעית

מדריך הייצוא החוזר של הליבה קובע שהשרת שמייצא מחדש אינו תומך בנעילה או בבקשות האצלה. יישומים שתלויים בפעולות האלה זקוקים לנתיב אחר או לתכנון שאומת מולן. עלייה מוצלחת ורישום תיקיות עובד אינם מראים שהפעולות האמיתיות של היישום עובדות.

זהות המשתמש ומדיניות הייצוא חשובות גם בכל קפיצה. התחברות ל-VPN מוכיחה שמשתתף רשת אומת; היא אינה מאשרת משתמש NFS, והיא אינה מעבירה את פרטי ההזדהות של הלקוח דרך השער.

לשער יש שתי תלויות במעלה הזרם

השער תלוי ב-VPN לצורך העלייה במעלה הזרם ובשרת במעלה הזרם לצורך מערכת הקבצים עצמה. תהליך ייצוא מקומי שעדיין פועל אינו יכול להפוך אחסון לא זמין לבריא. תכננו את סדר ההפעלה, את התנהגות ההתחברות מחדש ואת ההפעלות מחדש של השרת, כולל מה קורה לידיות הקבצים שלקוחות כבר מחזיקים. לקוח שעלה דרך השער ואיבד את הידית שלו זקוק לעלייה מחדש, וזה אירוע תפעולי ולא התאוששות שקופה.

אם כל מה שהדרישה אי פעם הייתה צריכה הוא נגישות של IP פרטיים, ניתוב ישיר לשרת המקורי הוא הארכיטקטורה הפשוטה יותר. הייצוא החוזר צריך להתקיים מסיבה שתשרוד כתיבה.

בדקו את עומס העבודה, לא את העלייה

תרגלו את עומס הקבצים האמיתי בסביבה מבוקרת: הפעולות שהיישום מבצע, גדלי הקבצים שבהם הוא משתמש והמקביליות שהוא מצפה לה. שימו לב לפערים בתכונות ולא רק לשגיאות תעבורה. אחר כך רשמו איזה מודל בחרתם ולמה, אחרת האדם הבא יניח שהשער הוא נתב.

ייצוא חוזר הוא לגיטימי כשהוא קיים מסיבה מכוונת, כמו רשת לקוחות מבודדת או גבול גרסה מבוקר. הוא תאונה גרועה, וההבדל הוא אם מישהו החליט על כך.

מאמרים קשורים