יכול להיות שחלק מהמידע בדף הזה או כולו לא רלוונטי ל-Cloud de Confiance by S3NS. פרטים נוספים מופיעים במאמר מה ההבדל מ-Google Cloud.

‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

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

טייס אוטומטי רגילה

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

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

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

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

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

הכנת הסביבה

דרישות

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

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

מגבלות

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

הפעלת הרחבת נפח אחסון ל-StorageClass

בודקים אם StorageClass תומך בהרחבת נפח האחסון:
```
kubectl get sc STORAGECLASS_NAME -o jsonpath='{.allowVolumeExpansion}{"\n"}'
```
מחליפים את STORAGECLASS_NAME בשם של StorageClass.

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

בכלי העריכה, מוסיפים את השדה allowVolumeExpansion: true להגדרות של StorageClass:

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

הרחבת נפח אחסון מתמיד

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

מזהים את הגודל החדש והתקין להרחבה, כמו שמתואר במאמר קביעת גדלים תקינים להרחבה.
פותחים את ההגדרה של ה-PVC לעריכה:
```
kubectl edit pvc PVC_NAME
```
מחליפים את PVC_NAME בשם של ה-PVC.
בכלי לעריכת מוצרים מעדכנים את השדה spec.resources.requests.storage עם גודל ההרחבה התקין. לדוגמה, כדי להגדיל את נפח האחסון מ-9000Gi ל-18000Gi, משנים את השדה storage באופן הבא:
```
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 18000Gi # Changed from 9000Gi
```

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

כדי לעקוב אחרי התקדמות ההרחבה, בודקים את האירועים של ה-PVC:
```
kubectl describe pvc PVC_NAME
```
האירועים הבאים בפלט של ה-PVC מציינים את ההתקדמות או את התוצאה הנוכחית של בקשת הרחבת נפח האחסון:
- ‫ExternalExpanding: מציין שמערכת Kubernetes מחכה ש-external-resizer תרחיב את ה-PVC.
- ‫Resizing: מציין שפעולת שינוי הגודל נמצאת בתהליך. הפעולה הזו יכולה להימשך עד 90 דקות אם מדובר בהגדלת נפח גדולה יותר.
- ‫VolumeResizeSuccessful: מאשר שהרחבת נפח האחסון בוצעה בהצלחה.
- ‫VolumeResizeFailed: מציין שקרתה שגיאה. הודעת האירוע מכילה פרטים מ-Google Cloud Managed Lustre API. יכול להיות שהמצב הזה זמני ויסתדר מעצמו.
אחרי שההרחבה מסתיימת, מאמתים את ההגדרה המעודכנת של ה-PVC:
```
kubectl get pvc PVC_NAME -o yaml
```
מוודאים שהשדה status.capacity משקף את הגודל החדש והמוגדל.

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

קביעת גדלי הרחבה תקינים

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

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

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

StorageClass

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

kubectl get sc STORAGECLASS_NAME -o yaml

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

מכונת Lustre

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

מוצאים את השם של ה-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

מוצאים את המיקום של אמצעי האחסון ואת שם המופע בשדה volumeHandle:
```
kubectl get pv PV_NAME -o yaml
```
מחליפים את PV_NAME בשם ה-PV מהשלב הקודם.

הערך volumeHandle מופיע בפורמט PROJECT_ID/LOCATION/INSTANCE_NAME. שימו לב לערכים INSTANCE_NAME ו-LOCATION כדי להשתמש בהם בשלב הבא.
כדי לבדוק את המאפיינים של רמת הביצועים, מתארים את מכונת Managed Lustre:
```
gcloud lustre instances describe INSTANCE_NAME --location=LOCATION
```
מחליפים את INSTANCE_NAME ו-LOCATION בערכים מהשלב הקודם.

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

מגבלות קיבולת וגדלי צעדים

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

רמה (`perUnitStorageThroughput`)	קיבולת מינימלית	קיבולת מקסימלית	גודל המרווח
‫1,000 MBps לכל 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 per 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.

ההרחבה נכשלת עם השגיאה Invalid Argument (ארגומנט לא תקין)

תסמין

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

הסיבה

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

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

פתרון

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

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

תסמין

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

הסיבה

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

פתרון

מנסים להרחיב שוב על ידי החלת מניפסט ה-PVC שוב עם הגודל החדש שנדרש. יכול להיות שהפעולה הזו תפתור בעיות זמניות בבק-אנד.
אם הניסיון החוזר נכשל, פונים אל 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, שהוא הרכיב שאחראי על הפעלת ההרחבה.

פתרון

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

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

תסמין

שינוי הגודל של ה-PVC נכשל, ואירוע VolumeResizeFailed מופיע ב-PVC.
כשמריצים את הפקודה kubectl describe pvc PVC_NAME, הודעת האירוע מהקצה העורפי של 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.

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

מידע נוסף על אחסון לאשכולות GKE
קוראים את התיעוד בנושא הקצאה של נפחי אחסון קבועים ב-GKE.