NFS מעל TCP בתוך מנהרת UDP של OpenVPN: שני נשאים
פרוטוקול ההרכבה ופרוטוקול המנהרה הם הגדרות נפרדות. תעדו את שניהם, ואז החליטו אם התקיעה שייכת לשירות הקבצים או לנשא.
העברת שיחה של NFS שמשתמשת ב-TCP בתוך מנהרה שנושאת UDP היא עקבית לחלוטין, והיא מבלבלת אנשים מפני שהיא נוקבת בשני נשאים בעת ובעונה אחת. TCP היא שיחת שירות הקבצים בין הלקוח לשרת ה-NFS. UDP הוא הנשא המוצפן בין קצוות ה-VPN. אף אחד מהם לא מרמז דבר על השני.
רשמו את שניהם בנפרד לפני שאתם מתחילים לנפות תקלות; רוב התקלות האלה מתחילות כשמישהו משנה את השכבה הלא נכונה.
שתי שכבות, שתי הגדרות
אפשרות ההרכבה proto=tcp מתארת כיצד לקוח ה-NFS מדבר עם שרת ה-NFS. ההגדרה proto udp בפרופיל ה-VPN מתארת כיצד קצוות המנהרה מחליפים מנות עטופות. שינוי אפשרות הרכבה אינו משנה את המנהרה, ושינוי הנשא של המנהרה אינו משנה את מה שלקוח ה-NFS ניהל משא ומתן עליו. אמתו את אפשרויות ההרכבה בפועל באמצעות nfsstat -m ולא לפי שורת ה-fstab, ואמתו את נשא ה-VPN מהפרופיל שבשימוש בפועל.
לאחר מכן תעדו אותם בהערות התקלה כשני שדות נפרדים. שיפור לכאורה ניתן לעקוב אחריו רק אם ההערה אומרת איזו שכבה השתנתה.
עיון אינו קריאה בכמות גדולה
רשימת תיקייה מוכיחה שחלק מהפעולות הושלמו. היא אינה מוכיחה שקריאה ממושכת, כתיבה, נעילה או שכבת האחסון שמתחת ישלימו באותם תנאים. תקיעה באמצע קובץ גדול היא תצפית שונה מהרכבה שלעולם אינה מצליחה, והן מצביעות על שכבות שונות.
תארו את הפעולה שנכשלת במדויק: נתיב, כיוון, נקודת התקיעה המשוערת והאירוע הרלוונטי האחרון ביומנים של הלקוח, השרת וה-VPN. לאחר מכן השוו היכן התעבורה נמשכת והיכן היא נעצרת.
MTU הוא השערה, לא אבחנה
אובדן שתלוי בגודל המנה הוא אפשרות ממשית כאשר מנהרה נושאת מקטעים גדולים, והוא יוצר בדיוק את הדפוס שבו העיון עובד והקריאה נתקעת. עם זאת הדפוס הזה אינו מוכיח בעיית MTU, מפני שאותה צורה מופיעה כששרת איטי, כשחומת אש מסיימת חיבור ארוך עקב פסק זמן, או כשדיסק עסוק. בדקו את ההשערה עם בדיקה מבוקרת במקום להוריד את ה-MTU בכל מקום ולהכריז על ניצחון.
פסק זמן בפני עצמו אינו אומר דבר על האם יש להחליף את UDP. זהו סימפטום עם כמה בעלים אפשריים.
שנו משתנה אחד בכל פעם
בהשוואת נשאים, שמרו על עומס העבודה של NFS ועל כל הגדרה אחרת יציבים. שינוי נשא ההרכבה, פרוטוקול המנהרה וה-MTU באותו חלון תחזוקה מפיק תוצאה שאיש אינו יכול לייחס. הריצו את אותה פעולת קובץ לפני ואחרי, ותעדו את התוצאה בכל שלב.
שמרו גם את הערכים הקודמים בכרטיס. אם שינוי מחמיר את המצב, הנסיגה צריכה להיות מספר מתועד ולא הזיכרון של מישהו כיצד היה קודם.
קראו את השכבה שנכשלה
אם המנהרה פעילה והבקשה של NFS ממתינה, ה-VPN לא נכשל; שירות הקבצים נכשל. אם המנהרה נפלה, כישלון בקשת ה-NFS הוא תוצאה ולא סיבה. התאמת שורות יומן משתי השכבות היא הדרך המהירה ביותר להבחין בין שני המקרים האלה, והיא עדיפה על ניחושים ממנהל הקבצים.
כתבו את המסקנה כשני משפטים, אחד לכל שכבה. זה מספיק כדי שהאדם הבא ישחזר את הבדיקה בלי לגזור מחדש איזה נשא הוא איזה.