ניהול אשכולות GKE שעברו אופטימיזציה באמצעות AI

בדף הזה מוסבר איך לנהל אשכולות של Google Kubernetes Engine ‏ (GKE) שעברו אופטימיזציה ל-AI של מכונות A4X Max,‏ A4X,‏ A4,‏ A3 Ultra,‏ A3 Mega ו-A3 High (עם 8 מעבדי GPU), כולל האירועים הנפוצים הבאים שרלוונטיים לאשכולות GKE ולעומסי עבודה של AI:

• תחזוקת המארח
• שדרוגי אשכולות
• דיווח שגוי של מארח

ניהול תחזוקת המארח לעומסי עבודה של AI

צמתים של GKE פועלים במכונות ב-Compute Engine שחווים מדי פעם אירועים במארח שיכולים לשבש את עומסי העבודה של AI. מכיוון שאירועים של המארח מתרחשים בתשתית הבסיסית שלGoogle Cloud , הם לא מושפעים מחלונות התחזוקה וההחרגות של GKE. לרוב מכונות החישוב מוגדרת מדיניות תחזוקת המארח live migrate, שמצמצמת את השיבוש בעומסי העבודה, אבל לא ניתן לבצע מיגרציה פעילה של GPU ו-TPU. כשהאירועים האלה במארח משפיעים על צומתי GKE שמריצים עומסי עבודה של AI, ‏ GKE צריך לסיים את הצומת ואת ה-Pods שפועלים בצומת. אם ה-Pods נפרסים כחלק מעומס עבודה גדול יותר כמו Job או Deployment, מערכת GKE מנסה להפעיל מחדש את ה-Pods בצומת המושפע.

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

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

באשכולות שמופעלת בהם GKE בגרסה 1.31.1-gke.2008000 ואילך, אפשר לראות את זמן ההתחלה המתוזמן של אירוע התחזוקה של המארח בדרך הבאה. זמן ההתחלה מיוצג על ידי תוויות של צומת Kubernetes בצומת GKE המתאים לכל יחידות ה-GPU וה-TPU.

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

בעזרת תוויות הצמתים האלה, אפשר:

• התחלה ידנית של אירוע תחזוקה של מארח
• שימוש במידע על אירועי תחזוקה של המארח במהלך תזמון עומסי העבודה

הפעלה ידנית של אירוע תחזוקה של מארח

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

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

פועלים לפי ההוראות להתחלה ידנית של אירוע תחזוקה של מארח. בנוסף, בהמשך הקטע הזה מוסבר:

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

שימוש במידע על תחזוקת המארח במהלך תזמון עומסי העבודה

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

בקטעים הבאים מופיעות דוגמאות לשימוש במידע הזה.

תזמון של Pods לצמתים שאין בהם אירועי תחזוקה מתוזמנים עתידיים

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

spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: cloud.google.com/scheduled-maintenance-time
            operator: DoesNotExist

תזמון של Pods לצמתים שתחזוקה שלהם מתוזמנת אחרי תאריך מסוים

אפשר להנחות את GKE לתזמן Pods רק לצמתים שתחזוקה מתוזמנת להם אחרי תאריך מסוים, על ידי ציון הזמן בפורמט Unix epoch:

spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: cloud.google.com/scheduled-maintenance-time
            operator: Gt
            values:
            - 1733296000

ניהול שדרוגים של אשכולות GKE לעומסי עבודה של AI

עומסי עבודה של AI רגישים לשיבושים.

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

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

מומלץ להשאיר את האשכול שלכם רשום לערוץ הפצה. כברירת מחדל, אשכולות GKE רשומים בערוץ ההפצה הרגיל. מידע נוסף על היתרונות של ערוצי הפצה זמין במאמר השוואה בין אשכולות שרשומים לערוץ הפצה לבין אשכולות שלא רשומים לערוץ הפצה.

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

דיווח על מארחים פגומים דרך GKE

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

זהירות: דיווח על מארח פגום היא פעולה שגורמת לשיבוש ומפסיקה את פעולת מכונת ה-VM. לפני שמדווחים על מארח, כדאי לחקור את הסביבה לעומק באמצעות כלים כמו סורק תקינות האשכול (CHS) כדי לזהות את שורש הבעיה. אפשר לדווח על המארח כפגום רק אם אין לכם אפשרויות אחרות לפתרון הבעיה.

מארח הוא מכונת שרת פיזית יחידה במרכז הנתונים שמריצה מופע מחשוב שמארח את הצומת של GKE. אפשר לדווח על מארחים פגומים על ידי הוספת תווית צומת fault-behavior לצומת GKE המושפע. אחרי שמחילים את תווית הצומת על צומת GKE מסוים, GKE מבצע את השלבים הבאים:

1. מפנה עומסי עבודה מהצומת בצורה מסודרת.
2. מונעת תזמון של Pods חדשים בצומת.
3. הקריאה ל-API במכונת החישוב מסמנת את המארח כפגום.
4. הכלי ממתין עד שמכונת המארח תקינה, ואז מפעיל מחדש את מופע החישוב. בהזמנות שמוגדר בהן מצב הפעלה של הזמנת כל הקיבולת, מערכת Compute Engine מחזירה את מכונת ה-Compute באותו הצומת אחרי השלמת פעולת התיקון.
5. ההגדרה הזו מסירה את הכתם ואת התווית fault-behavior מהצומת.

אחרי זה, הצומת יהיה מוכן שוב להצגת עומסי עבודה.

דרישות

כדי לדווח על מארח פגום, הצומת של GKE צריך לעמוד בדרישות הבאות:

• צריך להשתמש בגרסת תיקון של GKE‏ ‎1.32.3-gke.1057001 או בגרסה מתקדמת יותר.
• אתם צריכים להריץ אחד מהסוגים הבאים של מכונות GPU: A4X Max,‏ A4X,‏ A4,‏ A3 Ultra,‏ A3 Mega ו-A3 High (8 GPUs).
• צריך להפעיל את הצמתים של GKE במופע מחשוב שהוא משויך להזמנה.
• הצומת שלכם ב-GKE צריך להיות במצב RUNNING. אם תנסו לדווח על מארח פגום אחרי מחיקת מופע המחשוב, תוצג הודעת שגיאה ומכונת המארח לא תסומן כפגומה.
• יכול להיות שיהיה מספר מוגבל של קריאות ל-API הזה לכל הזמנה בחודש, על סמך הערכה של תקינות הבלוקים. מגבלות קצב לא חלות אם ההזמנה שלכם משתמשת במצב ההפעלה של הזמנת כל הקיבולת.

דיווח על מארח עם תקלה

הערה: הנתונים ב-SSD המקומי יימחקו אחרי הפעלה מוצלחת של ה-API, כי המכונה לחישוב תעבור בין מארחים. מומלץ לגבות את נתוני ה-SSD המקומיים לפני שמדווחים על צומת פגום דרך GKE.

כדי לדווח על מארח עם בעיה:

1. כדי לזהות את צמתי GKE שבהם יש בעיות בביצועים, אפשר להשתמש בכלים של GKE Observability, בכלים שלכם למעקב או ביומנים. שומרים את NODE_NAME.

2. מדווחים על הצומת כפגום:

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

     kubectl label nodes NODE_NAME cloud.google.com/fault-behavior=FAULT_REASON
   

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫NODE_NAME: השם של הצומת הפגום.
   • ‫FAULT_REASON: הסיבה המתאימה לשגיאה. משתמשים באחד או יותר מהערכים הבאים:
     • ‫PERFORMANCE: משתמשים בערך הזה אם הביצועים של מעבדי ה-GPU במופע Compute איטיים יותר מהביצועים של מעבדי GPU אחרים באשכול, ולא מופיעות שגיאות XID ביומנים, ולא מזוהים אף אחד מדפוסי הכשל הרגילים האחרים, כמו השחתת נתונים שקטה.
     • ‫SDC: משתמשים בערך הזה אם יש נתונים פגומים אבל לא קריסת מערכת. השחתת הנתונים הזו יכולה להיגרם מפגמים במעבד, באגים בתוכנה כמו use-after-free או memory stomping, בעיות בקרנל או פגמים אחרים. בדרך כלל, המונח הזה מתייחס לפגמים שנגרמים בגלל בעיות בחומרה.
     • ‫XID: משתמשים בערך הזה אם זוהתה שגיאת GPU שלא ניתן לשחזר עם XID עבור מכונת חישוב.
     • ‫unspecified: משתמשים בערך הזה אם לא בטוחים איזו התנהגות גורמת לבעיה במופע המחשוב. זה ערך ברירת המחדל. עם זאת, מומלץ לציין אחד מהערכים האחרים, אם זה רלוונטי.

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

	מצב קיבולת מלאה (ALL_CAPACITY)	מצב מנוהל (HIGHLY_AVAILABLE_CAPACITY)
סוגי מכונות נתמכים	‫A4X Max ו-A4X	‫A4,‏ A3 Ultra,‏ A3 Mega ו-A3 High
הגבלת קצב בקשות (rate limiting) שגויה ב-API של דוחות על מארחים	אין הגבלות על קצב יצירת הבקשות.	יכול להיות שיהיו הגבלות על קצב השליחה של בקשות ל-API.
תהליך דיווח על מארח פגום	כשמדווחים על מארח פגום של צומת שפועל במצב של כל הקיבולת, קורה הדבר הבא: הוצאת Pods: אחרי שהתווית מוחלת על הצומת הפגום, GKE מוסיף לצומת taint כדי לחסום את התזמון של Pods חדשים. בנוסף,‏ GKE מתחיל להוציא את ה-Pods הפועלים בצומת בצורה מסודרת. ‫GKE מכבד את Pod Disruption Budgets (PDBs) ואת השדה spec.terminationGracePeriodSeconds של מניפסטים של Pod. פרטים נוספים זמינים במאמר בנושא הגדרת סיום תקין של עומסי עבודה ב-GKE. דיווח על המארח הפגום ותיקון שלו: GKE מדווח באופן אוטומטי על המארח הפגום ומתקן אותו באמצעות קריאה ל-Compute Engine API. כתוצאה מכך, מתבצע רצף של פעולות שבדרך כלל לוקח 10-12 דקות לדווח על המארח הפגום, ואז יכולות לחלוף 3-14 ימים, או אפילו יותר לפעמים, עד שהמארח יתוקן. הפעלה מחדש של המופע: אחרי שפעולת התיקון של המארח מסתיימת (בדרך כלל תוך 3 עד 14 ימים), אחד מהדברים הבאים קורה: אם המופע במצב REPAIRING והמשאבים זמינים כשהתיקון מסתיים, Compute Engine מפעיל מחדש את המופע באופן אוטומטי במארח המתוקן. אחרת, אם המופע במצב TERMINATED או אם המשאבים לא זמינים כשהתיקון מסתיים, מצב המופע נשאר TERMINATED או משתנה לTERMINATED. צריך להפעיל מחדש את המופע באופן ידני כשרוצים שהוא יפעל. עם זאת, יכול להיות שההפעלה מחדש של המכונה תיכשל אם המשאבים לא יהיו זמינים כשמפעילים אותה מחדש. לדוגמה, זה יכול לקרות אם מכונות אחרות כבר משתמשות במארח שתוקן.	כשמדווחים על מארח פגום לצומת שפועל במצב מנוהל, קורה הדבר הבא: הוצאת Pods: אחרי שהתווית מוחלת על הצומת הפגום, GKE מטיל כתם על הצומת כדי לחסום את התזמון של Pods חדשים. בנוסף,‏ GKE מתחיל להוציא את ה-Pods הפועלים בצורה מסודרת מהצומת. ‫GKE מכבד את Pod Disruption Budgets (PDBs) ואת השדה spec.terminationGracePeriodSeconds של מניפסטים של Pod. פרטים נוספים זמינים במאמר בנושא הגדרת סיום תקין של עומסי עבודה ב-GKE. דיווח על המארח הפגום ותיקון שלו: GKE מדווח באופן אוטומטי על המארח הפגום ומתקן אותו באמצעות קריאה ל-Compute Engine API, וכתוצאה מכך מתבצע רצף של פעולות. בדרך כלל לוקח 10-12 דקות לדווח על המארח הפגום, ואז יכולות לחלוף 3-14 ימים, או אפילו יותר לפעמים, עד שהמארח מתוקן. העברה והפעלה מחדש של המכונה: אחרי שפעולת התיקון של המארח מתחילה (בדרך כלל תוך 10-12 דקות), מערכת Compute Engine מנסה לשריין עוד מארח אחד כדי להחליף את המארח הפגום שדווח בקיבולת השמורה. אם Compute Engine מוצא מארח תקין – אם הוא מחליף בהצלחה את המארח הפגום או מוצא מארח תקין תואם בקיבולת השמורה שלכם – אז Compute Engine מעביר את המופע למארח הזה. לאחר מכן, ההפעלה מחדש של המופע מתבצעת באחת מהדרכים הבאות: אם המופע במצב REPAIRING ויש משאבים זמינים לפני או בזמן השלמת התיקון, Compute Engine מפעיל מחדש את המופע באופן אוטומטי במארח תקין. אחרת, אם המופע במצב TERMINATED או אם המשאבים לא זמינים לפני או אחרי השלמת התיקון, מצב המופע נשאר TERMINATED או משתנה לTERMINATED. תצטרכו להפעיל מחדש את המופע באופן ידני כשתרצו שהוא יפעל. עם זאת, יכול להיות שההפעלה מחדש של המכונה תיכשל אם המשאבים לא יהיו זמינים כשמפעילים אותה מחדש. לדוגמה, זה יכול לקרות אם מכונות אחרות כבר משתמשות במארח שתוקן.

מעקב אחרי התקדמות הפעולה

אפשר לעקוב אחרי התקדמות הפעולה של GKE באמצעות התווית cloud.google.com/report-and-replace-status של הצומת בצומת GKE, שיש לה אחד מהערכים הבאים:

• ‫PodsEvicted: מערכת GKE סיימה להוציא את ה-Pods מהצומת המושפע.
• ‫OperationRUNNING: הפעולה לדיווח על המארח הפגום פועלת.
• ‫OperationDone: המארח הבסיסי דווח כתקול, והצומת של GKE מוכן להעברה למארח חדש
• ‫Error: קריאה ל-API נכשלה, מסיבות שכוללות אחת מהדרישות שמתוארות בקטע הקודם.

אפשר גם להציג את התווית של צומת cloud.google.com/report-and-replace-operation כדי לראות את מזהה הפעולה של Compute Engine ולעקוב אחרי הסטטוס של הפעולה.

אפשר להציג את שתי התוויות של הצמתים באמצעות הפקודה הבאה:

  kubectl get nodes NODE_NAME \
  -L cloud.google.com/report-and-replace-status,cloud.google.com/report-and-replace-operation

במקרה של שגיאות API, ‏ GKE מגדיר את תווית הצומת cloud.google.com/report-and-replace-status=ERROR. ‫GKE מנקה את ההכתמות של הצומת ומסיר את התווית cloud.google.com/fault-behavior של הצומת.

במאמר בדיקת פעולות מארח שגויות בדוח מוסבר איך לעקוב אחרי הסטטוס המפורט של פעולות מארח שגויות בדוח.

כדי לנסות שוב את הפעולה במקרה של שגיאות זמניות כמו מגבלות קצב, צריך להחיל מחדש את התווית cloud.google.com/fault-behavior על הצומת.

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

• איך מתזמנים עומסי עבודה ב-GKE באמצעות Topology Aware Scheduling

• איך מבצעים אופטימיזציה של רשתות אשכולות באמצעות NCCL/gIB

• איך פותרים בעיות שקשורות לשגיאות ב-API של המארח