תאימות ל-POSIX

אלה החריגים לתאימות של Google Cloud Managed Lustre ל-POSIX:

• עדכוני atime: כברירת מחדל, atime מופעל ב-Lustre, אבל מסיבות שקשורות לביצועים, יכול להיות שהעדכונים שלו יידחו. כלומר, יכול להיות שזמן הגישה של קובץ לא יעודכן מיד אחרי כל פעולת קריאה.

• ‫flock/lockf: אלה שני ממשקי API עיקריים לנעילת קבצים: flock(2) ו-fcntl(2).

  • ‫flock: זוהי נעילה מייעצת של קובץ שלם בסגנון BSD, שלא מוגדרת על ידי POSIX. מערכת Lustre תומכת באופן מלא בסמנטיקה של flock בסגנון BSD באשכול כברירת מחדל.
  • ‫fcntl: זהו API לנעילה שמוגדר על ידי POSIX, שתומך בנעילות של טווח בייטים. ההטמעה של נעילות fcntl ב-Lustre כמעט תואמת ל-POSIX ועובדת כמו שצריך ברוב האפליקציות. עם זאת, מכיוון ש-fcntl תוכננה במקור למערכות קבצים מקומיות, אף מערכת קבצים מבוזרת לא יכולה להתאים ב-100% לכל הדרישות של fcntl של POSIX, כולל Lustre. לדוגמה, fcntl() מציין שצריך לבטל את הנעילות מיד כשתהליך הבעלות מסתיים, אבל יכול להיות שביטול הנעילה ב-Lustre יתעכב אם הלקוח יקרוס.

פרטים נוספים זמינים בשאלות הנפוצות בנושא Lustre.

שינויים במספר ה-inode בגלל העברת מטא-נתונים

מספר ה-inode של קובץ במערכת קבצים של Lustre הוא לא מזהה קבוע.

פעולה של איזון מחדש של מטא-נתונים, כמו פעולה שהופעלה על ידי lfs migrate, כוללת העברה של מטא-נתונים של קבצים מסוימים מ-MDT אחד ל-MDT אחר. כתוצאה ישירה מההעברה הזו ל-MDT חדש, לקבצים האלה מוקצה מספר inode חדש.

התנהגות כזו תואמת לתקן POSIX, אבל היא עלולה להפר את ההנחות של הרבה אפליקציות ושירותים נפוצים של Unix/Linux, שמתוכננים לצפות למספר inode קבוע למשך חיי הקובץ. האיסור הזה כולל, בין היתר:

• חזיתות קצה של NFS ו-SMB: השירותים האלה בדרך כלל מקבלים את ידיות הקבצים ממספרי inode. שינוי יכול לגרום לStale file handle שגיאות אצל לקוחות.

• כלי גיבוי ושמירה בארכיון: כלים כמו tar שעוקבים אחרי קבצים לפי המכשיר ומספר ה-inode שלהם עשויים להתייחס לקובץ שהועבר כאל קובץ חדש, מה שיוביל לגיבויים מצטברים לא יעילים.

• יכול להיות שגם מערכות לצבירת יומנים, מערכות לזיהוי פריצות ואפליקציות בהתאמה אישית שמשתמשות ב-stat() ומאחסנות את st_ino יושפעו.

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

אסטרטגיות לצמצום הסיכון

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

1. קובעים חלון זמן לתחזוקה. מומלץ להודיע לכל המשתמשים ולבעלי האפליקציות על הפסקת השירות המתוכננת. אם אפשר, לא כדאי לבצע פעולות lfs migrate במערכת ייצור פעילה.

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

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