במאמר הזה מוסבר איך להגדיל באופן דינמי את נפח האחסון של נפחי 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
בודקים אם 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
כדי להתחיל את הרחבת הנפח, עורכים את 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). הערך הזה מציין את רמת הביצועים ב-MBps ל-TiB.
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,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, בגלל אחת מהסיבות הבאות:
- הגודל המבוקש הוא לא כפולה של גודל הצעד הנדרש לרמה.
- הנפח המבוקש נמוך מהמינימום או גבוה מהמקסימום של הרמה.
רזולוציה
- בקטע מגבלות קיבולת וגודלי שלבים תוכלו למצוא את גודלי השלבים ומגבלות הקיבולת החוקיים לרמת הביצועים של הנפח שלכם.
- עורכים שוב את ה-PVC כדי לבקש נפח אחסון תקין שעומד במגבלות של גודל השלב והקיבולת.
ההרחבה נכשלת ומוצגת ההודעה "שגיאה פנימית"
תסמין
- שינוי הגודל של ה-PVC נכשל.
- כשמריצים את הפקודה
kubectl describe pvc PVC_NAME, יכול להיות שיופיע אירועVolumeResizeFailedעם הודעת שגיאה שמכילה אתcode = Internal.
הסיבה
השגיאה הזו מעידה על בעיה בשירות Managed Lustre הבסיסי.
רזולוציה
- מנסים שוב להרחיב את הנפח על ידי החלה מחדש של מניפסט ה-PVC עם הגודל החדש שביקשתם. הפעולה הזו יכולה לפתור בעיות זמניות ב-backend.
- אם הניסיון החוזר נכשל, פנו ל-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, הודעת האירוע מה-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.
המאמרים הבאים
- מידע נוסף על אחסון לאשכולות GKE
- קוראים את המאמר אמצעי אחסון קבועים והקצאה ב-GKE.