הגדלת נפח האחסון ב-Managed Lustre ב-GKE

במאמר הזה מוסבר איך להגדיל באופן דינמי את נפח האחסון של נפחי Managed Lustre לעומסי עבודה עם שמירת מצב (stateful) ב-Google Kubernetes Engine‏ (GKE) בלי לשבש את האפליקציות.

לדוגמה, אם למשימות האימון של AI/ML שפועלות לאורך זמן יש דרישות אחסון דינמיות ובלתי צפויות, הפעילו את הרחבת הנפח של Managed Lustre כדי להגדיל את קיבולת האחסון של PersistentVolume‏ (PV) הקיים של Managed Lustre.

המסמך הזה מיועד לאדמינים ולמפעילי פלטפורמות, למהנדסי DevOps, לאדמינים של אחסון ולמהנדסי למידת מכונה (ML) שמנהלים אחסון לעומסי עבודה עם שמירת מצב (stateful) ב-GKE.

כשמרחיבים נפח, העלויות גדלות בהתאם לקיבולת החדשה והגדולה יותר, לפי התמחור הרגיל שלCloud de Confiance by S3NS Managed Lustre.

לפני שמתחילים

הכנת הסביבה.

דרישות

צריך לעמוד בדרישות הבאות:

  • צריך אשכול GKE בגרסה 1.35.0-gke.2331000 ואילך.
  • צריך להפעיל את מנהל ההתקן של Managed Lustre CSI באשכול קיים. מנהל ההתקן מושבת כברירת מחדל באשכולות Standard ו-Autopilot.

מגבלות

  • אפשר רק להגדיל את הנפח הקיים, ואי אפשר להקטין אותו.
  • אי אפשר להשתמש בהרחבת נפח במצב הגישה ReadOnlyMany.
  • כשמשנים את הגודל של נפחי אחסון ב-Lustre, צריך לפעול לפי מגבלות הקיבולת המינימליות והמקסימליות וגודלי השלבים שמוגדרים ברמת הביצועים של נפח האחסון. מידע נוסף זמין במאמר שיקולי ביצועים.
  • מציינים את הגדלים של נפחי האחסון ב-Lustre ב-GiB בכפולות של 1,000. ‫Kubernetes מתרגם יחידות כמו Ti לערכים בינאריים (לדוגמה, ‎18 Ti מתורגם ל-‎18,432 GiB), וכתוצאה מכך ה-API של Lustre דוחה את הבקשה.

הפעלת הרחבת נפח ל-StorageClass

  1. בודקים אם StorageClass תומך בהרחבת נפח האחסון:

    kubectl get sc STORAGECLASS_NAME -o jsonpath='{.allowVolumeExpansion}{"\n"}'
    

    מחליפים את STORAGECLASS_NAME בשם של StorageClass.

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

  2. פותחים את ההגדרות של StorageClass לעריכה:

    kubectl edit storageclass STORAGECLASS_NAME
    
  3. בעורך, מוסיפים את השדה allowVolumeExpansion: true להגדרות של StorageClass:

    apiVersion: storage.k8s.io/v1
    kind: StorageClass
    metadata:
      name: lustre-sc
    provisioner: lustre.csi.storage.gke.io
    ...
    allowVolumeExpansion: true

הרחבה של PersistentVolumeClaim

כדי להתחיל את הרחבת הנפח, עורכים את PersistentVolumeClaim‏ (PVC) ומבקשים להגדיל את הנפח.

  1. מזהים את הגודל החדש והתקין להרחבה, כפי שמתואר בקטע קביעת גודלי הרחבה תקינים.
  2. פותחים את הגדרות ה-PVC לעריכה:

    kubectl edit pvc PVC_NAME
    

    מחליפים את PVC_NAME בשם של ה-PVC.

  3. בכלי לעריכת מוצרים, מעדכנים את השדה spec.resources.requests.storage במידת ההרחבה החוקית. לדוגמה, כדי להרחיב נפח מ-9000Gi ל-18000Gi, משנים את השדה storage באופן הבא:

    spec:
      accessModes:
      - ReadWriteOnce
      resources:
        requests:
          storage: 18000Gi # Changed from 9000Gi
    

אימות הרחבת הנפח

  1. כדי לעקוב אחרי התקדמות ההרחבה, בודקים את האירועים של ה-PVC:

    kubectl describe pvc PVC_NAME
    

    האירועים הבאים בפלט של ה-PVC מציינים את ההתקדמות הנוכחית או את התוצאה של הבקשה להרחבת הנפח:

    • ‫ExternalExpanding: מציין ש-Kubernetes ממתין ל-external-resizer כדי להרחיב את ה-PVC.
    • ‫Resizing: מציין שפעולת שינוי הגודל מתבצעת. הפעולה הזו יכולה להימשך עד 90 דקות כשמדובר בהגדלות קיבולת גדולות יותר.
    • ‫VolumeResizeSuccessful: אישור שנפח האחסון הורחב.
    • ‫VolumeResizeFailed: מציין שאירעה שגיאה. הודעת האירוע מכילה פרטים מ-Google Cloud Managed Lustre API. יכול להיות שהמצב הזה זמני וייפתר מעצמו.
  2. אחרי שההרחבה מסתיימת, מאמתים את ההגדרה המעודכנת של ה-PVC:

    kubectl get pvc PVC_NAME -o yaml
    
  3. מוודאים שהשדה status.capacity משקף את הגודל החדש והמוגדל.

אם נתקלתם בבעיות בתהליך ההרחבה, עיינו בקטע פתרון בעיות.

קביעת גודל ההרחבה החוקי

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

זיהוי רמת הביצועים של האחסון

כדי למצוא את רמת הביצועים של אמצעי האחסון, אתם יכולים להשתמש באחת מהאפשרויות הבאות:

StorageClass

מריצים את הפקודה הבאה ומחפשים את הערך של perUnitStorageThroughput (לדוגמה, 1000). הערך הזה מציין את רמת הביצועים ב-MBps ל-TiB.

kubectl get sc STORAGECLASS_NAME -o yaml

מחליפים את STORAGECLASS_NAME בשם של StorageClass.

מכונת Lustre

כדי לזהות את רמת הביצועים של הנפח, בודקים ישירות את המאפיינים של המכונה הבסיסית ב-Managed Lustre:

  1. מוצאים את השם של ה-PV שקשור ל-PVC:

    kubectl get pvc PVC_NAME
    

    מחליפים את PVC_NAME בשם של ה-PVC.

    הפלט אמור להיראות כך: שימו לב לשם של ה-PV בעמודה VOLUME, לדוגמה pv-lustre.

    NAME         STATUS   VOLUME      CAPACITY   ACCESS MODES   STORAGECLASS   VOLUMEATTRIBUTESCLASS   AGE
    pvc-lustre   Bound    pv-lustre   9000Gi     RWX            lustre-rwx     <unset>                 26m
    
  2. מאתרים את המיקום של אמצעי האחסון ואת שם המכונה בשדה volumeHandle:

    kubectl get pv PV_NAME -o yaml
    

    מחליפים את PV_NAME בשם של ה-PV מהשלב הקודם.

    הערך volumeHandle בפורמט PROJECT_ID/LOCATION/INSTANCE_NAME. שימו לב ל-INSTANCE_NAME ול-LOCATION בשביל השלב הבא.

  3. כדי לבדוק את המאפיינים של רמת הביצועים, מתארים את המכונה של Managed Lustre:

    gcloud lustre instances describe INSTANCE_NAME --location=LOCATION
    

    מחליפים את INSTANCE_NAME ואת LOCATION בערכים מהשלב הקודם.

    בפלט, מחפשים את השדה perUnitStorageThroughput. הערך הזה מציין את רמת הביצועים ב-MBps ל-TiB.

מגבלות קיבולת וגודל שלבים

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

רמה (perUnitStorageThroughput) קיבולת מינימלית קיבולת מקסימלית גודל המרווח
‫1,000MBps ל-TiB 9,000 GiB ‫954,000 GiB (כ-1 PiB) 9,000 GiB
‫‎500 MBps לכל TiB ‫18,000 GiB ‫1,908,000 GiB (כ-2 PiB) ‫18,000 GiB
‫‎250 MBps ל-TiB ‫36,000 GiB ‫3,816,000 GiB (כ-4 PiB) ‫36,000 GiB
‫‎125 MBps לכל TiB 72,000 GiB ‫7,632,000 GiB (כ-8 PiB) 72,000 GiB

צריך להגדיל את הנפחים בהתאם לגודל השלב שהוקצה לרמה שלהם. כל הגדלה של הקיבולת חייבת להיות כפולה של גודל השלב הספציפי הזה. לדוגמה, אם לנפח שלכם ברמה של 1,000 MBps יש קיבולת של 9,000 GiB, אתם יכולים להגדיל אותה ל-18,000 GiB, ל-27,000 GiB ולכפולות אחרות.

פתרון בעיות

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

ההרחבה נכשלת ומוצגת הודעת השגיאה "ארגומנט לא חוקי"

תסמין

  • ה-PVC נכנס למצב Resizing אבל נכשל.
  • כשמריצים את הפקודה kubectl describe pvc PVC_NAME, מופיעה שגיאה שדומה ל-VolumeResizeFailed: rpc error: code = InvalidArgument desc = ....

הסיבה

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

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

רזולוציה

  1. בקטע מגבלות קיבולת וגודלי שלבים תוכלו למצוא את גודלי השלבים ומגבלות הקיבולת החוקיים לרמת הביצועים של הנפח שלכם.
  2. עורכים שוב את ה-PVC כדי לבקש נפח אחסון תקין שעומד במגבלות של גודל השלב והקיבולת.

ההרחבה נכשלת ומוצגת ההודעה "שגיאה פנימית"

תסמין

  • שינוי הגודל של ה-PVC נכשל.
  • כשמריצים את הפקודה kubectl describe pvc PVC_NAME, יכול להיות שיופיע אירוע VolumeResizeFailed עם הודעת שגיאה שמכילה את code = Internal.

הסיבה

השגיאה הזו מעידה על בעיה בשירות Managed Lustre הבסיסי.

רזולוציה

  1. מנסים שוב להרחיב את הנפח על ידי החלה מחדש של מניפסט ה-PVC עם הגודל החדש שביקשתם. הפעולה הזו יכולה לפתור בעיות זמניות ב-backend.
  2. אם הניסיון החוזר נכשל, פנו ל-Cloud Customer Care.

ההרחבה נתקעת במצב "שינוי גודל"

תסמין

  • ה-PVC נשאר במצב Resizing למשך זמן רב (יותר מ-30 דקות להרחבות קטנות יותר, או יותר מ-90 דקות להרחבות גדולות יותר).
  • יכול להיות שיופיע אירוע VolumeResizeFailed עם הודעת השגיאה DEADLINE_EXCEEDED.

הסיבה

הבעיה הזו יכולה לקרות כשמגדילים את הקיבולת באופן משמעותי, כי התהליך יכול להימשך עד 90 דקות. יכול להיות שתוקף הזמן הקצוב של הרכיב csi-external-resizer יפוג בזמן ההמתנה לתגובה מ-Google Cloud Managed Lustre API, גם אם פעולת ההרחבה הבסיסית עדיין מתבצעת.

רזולוציה

  • ‫csi-external-resizer מנסה לבצע את הפעולה באופן אוטומטי אחרי תקופת השהיה. ממשיכים לעקוב אחרי אירועי ה-PVC כדי לראות אירוע VolumeResizeSuccessful.
  • אם ה-PVC נשאר במצב Resizing במשך יותר מ-90 דקות, פנו ל-Cloud Customer Care.

ההרחבה לא מתחילה או שהיא תקועה במצב ExternalExpanding

תסמין

  • אתם מעדכנים את השדה spec.resources.requests.storage ב-PVC, אבל הסטטוס של ה-PVC לא משתנה ל-Resizing.
  • כשמריצים את הפקודה kubectl describe pvc PVC_NAME, ביומן האירועים מוצג רק המצב ExternalExpanding והוא לא מתקדם למצב Resizing:
Events:
  Type    Reason             Age                From             Message
  ----    ------             ----               ----             -------
  Normal  ExternalExpanding  21m (x2 over 58m)  volume_expand    waiting for an external controller to expand this PVC

הסיבה

ההתנהגות הזו בדרך כלל מצביעה על אחת מהבעיות הבאות:

  • ה-StorageClass שמשויך ל-PVC לא מאפשר הרחבה של הנפח.
  • יש בעיה בקונטיינר המשני (sidecar) csi-external-resizer, שהוא הרכיב שאחראי על הפעלת ההרחבה.

רזולוציה

  1. בודקים את ההגדרות של StorageClass ומוודאים שהשדה allowVolumeExpansion: true מוגדר:

    kubectl get sc STORAGECLASS_NAME -o jsonpath='{.allowVolumeExpansion}{"\n"}'
    
  2. אם allowVolumeExpansion חסר או מוגדר ל-false, צריך לעדכן את StorageClass כדי לאפשר הרחבת נפח.

  3. אם ה-StorageClass מוגדר בצורה נכונה, סביר להניח שהבעיה היא ברכיבים של מישור הבקרה של GKE שמנהלים את פעולת שינוי הגודל. אפשר לפנות ל-Cloud Customer Care כדי לקבל עזרה.

ההרחבה נכשלת בגלל בעיה במכסה או בקיבולת

תסמין

  • שינוי הגודל של ה-PVC נכשל, ואירוע VolumeResizeFailed מופיע ב-PVC.
  • כשמריצים את הפקודה kubectl describe pvc PVC_NAME, הודעת האירוע מה-backend של Managed Lustre מצביעה על בעיה במכסה או בקיבולת.

הסיבה

אי אפשר לבצע את ההרחבה התקינה שביקשתם כי היא חורגת מהקיבולת הכוללת או מהמכסה שזמינה לשירות Managed Lustre בפרויקט או באזור שלכם.

רזולוציה

  • עורכים שוב את ה-PVC ומבקשים הגדלה קטנה יותר של נפח האחסון.
  • כדי לבקש להגדיל את המכסות או הקיבולת הכוללות של שירות Lustre בפרויקט, פנו לאדמין של Cloud de Confiance by S3NS בארגון.

הסרת המשאבים

כדי להימנע מצבירת חיובים בחשבון Cloud de Confiance by S3NS על המשאבים שבהם השתמשתם במסמך הזה, צריך למחוק את ה-PVC. הפעולה הזו גם מוחקת את ה-PV המשויך ואת המכונה הבסיסית של Managed Lustre אם הערך של reclaimPolicy מוגדר כ-Delete.

kubectl delete pvc PVC_NAME

מחליפים את PVC_NAME בשם של ה-PVC.

המאמרים הבאים