פריסת TPU במצב 'כל הקיבולת' ב-GKE

Standard

במאמר הזה מוסבר איך לפרוס ולנהל עומסי עבודה באמצעות התכונה TPU All Capacity mode ב-GKE. כל ההזמנות במצב קיבולת מספקות שליטה משופרת במשאבי ה-TPU, ומאפשרות לכם להציב את עומסי העבודה עם שליטה מדויקת בקיבולת שהזמנתם.

המסמך הזה מיועד למהנדסי למידת מכונה (ML) ולאדמינים ומפעילים של פלטפורמות שרוצים להשתמש בתיזמור של קונטיינרים ב-Kubernetes עם שליטה פרטנית בפריסות של TPU.

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

• TPUs
• ארכיטקטורת מערכת TPU
• TPU ב-GKE

מהו מצב 'קיבולת מלאה' של TPU?

מצב 'כל הקיבולת של TPU', שמופעל על ידי TPU Cluster Director, מאפשר לכם שליטה מלאה בקיבולת ה-TPU שהזמנתם. TPU Cluster Director הוא שירות ניהול שמאפשר לכם לשלוט ב-TPU על בסיס הזמנה.

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

מידע נוסף על התכונות העיקריות של מצב 'כל הקיבולת' זמין במאמר מצב 'כל הקיבולת' בסקירה הכללית של TPU Cluster Director.

מינוח שקשור למצב 'כל הקיבולת' ב-GKE

בטבלה הבאה מפורטים המונחים והערכים המקבילים שמוגדרים לפי הגודל של בלוק, תת-בלוק וקוביה בגרסת Ironwood ‏ (TPU7x). קוביה היא 4x4x4 טופולוגיה של שבבי TPU שמחוברים זה לזה, והיא רלוונטית רק לטופולוגיות של 3-tuples‏ ({A}x{B}x{C}).

משאב TPU	ליבות	צ'יפים	מארחים	Cubes
צ'יפ אחד	2	1	-	-
מארח אחד	8	4	1	-
בלוק משנה אחד	128	64	16	1
כל בלוק מכיל 144 תת-בלוקים	18432	9216	2304	144

מידע נוסף על הטופולוגיות המותרות בבלוק זמין במאמר בחירת טופולוגיה.

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

לפני שמתחילים, חשוב לוודא שביצעתם את המשימות הבאות:

• מפעילים את ממשק ה-API של Google Kubernetes Engine.
הפעלת Google Kubernetes Engine API
• כדי להשתמש ב-CLI של Google Cloud למשימה הזו, צריך להתקין ואז לאתחל את ה-CLI של gcloud. אם התקנתם בעבר את ה-CLI של gcloud, מריצים את הפקודה gcloud components update כדי לקבל את הגרסה העדכנית. יכול להיות שגרסאות קודמות של ה-CLI של gcloud לא יתמכו בהרצת הפקודות שמופיעות במסמך הזה.
  הערה: אם כבר התקנתם את ה-CLI של gcloud, הקפידו להגדיר את compute/region המאפיין. אם אתם משתמשים בעיקר באשכולות אזוריים, צריך להגדיר את compute/zone במקום זאת. אם מגדירים מיקום ברירת מחדל, אפשר להימנע משגיאות ב-CLI של gcloud כמו השגיאה הבאה: One of [--zone, --region] must be supplied: Please specify location. יכול להיות שתצטרכו לציין את המיקום בפקודות מסוימות אם המיקום של האשכול שונה מברירת המחדל שהגדרתם.

• מוודאים שיש לכם אשכול קיים מסוג Standard בגרסה 1.34.0-gke.2201000 ואילך. כדי ליצור אשכול חדש, אפשר לעיין במאמר בנושא יצירת אשכול אזורי.
• מוודאים שיש לכם מכסת TPU מספקת באזור שבו אתם רוצים להשתמש.
• מתקינים את JobSet גרסה 0.2.3 ואילך.

מגבלות

מצב TPU All Capacity ב-GKE תומך רק בגרסאות Ironwood‏ (TPU7x).

שימוש במצב 'כל הקיבולת' של TPU ב-GKE

בקטע הזה מתואר תהליך העבודה לשימוש במצב 'כל הקיבולת' של TPU ב-GKE.

1. מומלץ לעיין במידע על TPU Cluster Director.
2. בקשה לקיבולת TPU במצב 'כל הקיבולת'.
3. איך רואים את הטופולוגיה ואת סטטוס התקינות של כל ההזמנות במצב 'כל הקיבולת'
4. משלימים את השלב במסמך הזה:
   1. יצירת מאגר צמתים ב-GKE
   2. תזמון עומסי עבודה
   3. ניהול כשלים של צמתים באמצעות הזמנה במצב 'כל הקיבולת'
5. ניהול אירועי תחזוקה באמצעות TPU במצב 'כל הקיבולת'
6. דיווח על מארחים פגומים עם TPU ותיקון שלהם במצב All Capacity.

יצירת מאגר צמתים בהזמנה במצב 'כל הקיבולת'

ב-GKE, כל מצב הקיבולת מאפשר ליצור מאגרי צמתים בדרכים הבאות:

• מאגר צמתים שבו GKE בוחר את הבלוק או תת-הבלוק בהזמנת הקיבולת הכוללת של TPU.
• מאגר צמתים שמטרגט בלוק מסוים או תת-בלוק מסוים בהזמנה במצב 'כל הקיבולת' של TPU.

‫GKE בוחר את הבלוק או את תת-הבלוק בהזמנת הקיבולת הכוללת של ה-TPU

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

כדי ליצור מאגר צמתים, משתמשים בפקודה gcloud container node-pools create עם הדגל --reservation. מציינים את שם המשאב המלא של הזמנת ה-TPU כערך של הדגל --reservation.

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

טירגוט של בלוק או תת-בלוק בהזמנה

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

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

2. יוצרים מדיניות של עומס עבודה:

   הערה: אין צורך ליצור מדיניות חדשה של עומס עבודה לכל מאגר צמתים. מדיניות עומס עבודה היא ייחודית לכל פרויקט, לכל אזור ולכל טופולוגיה. אם כבר יש לכם מדיניות לגבי עומסי עבודה שתואמת לדרישות שלכם, אתם יכולים לדלג על השלב הזה ולהשתמש שוב במדיניות הקיימת בשלב הבא. כדי לראות את רשימת כללי המדיניות של עומסי העבודה, משתמשים בפקודה gcloud compute resource-policies list --filter="region:REGION".

   gcloud compute resource-policies create workload-policy WORKLOAD_POLICY_NAME \
       --type=HIGH_THROUGHPUT \
       --accelerator-topology=TPU_TOPOLOGY \
       --project=PROJECT_ID \
       --region=REGION
   

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

   • ‫WORKLOAD_POLICY_NAME: שם למדיניות של עומס העבודה.
   • ‫TPU_TOPOLOGY: טופולוגיית TPU Ironwood‏ (TPU7x). לדוגמה, 2x2x2. כדי לראות את כל הטופולוגיות הנתמכות של Ironwood ‏ (TPU7x), אפשר לעיין במאמר בנושא תכנון יחידות TPU ב-GKE.
   • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
   • ‫REGION: האזור של מדיניות עומס העבודה. מדיניות עומס עבודה היא משאב אזורי, ואפשר לעשות בה שימוש חוזר במאגרי צמתים שחולקים את אותה טופולוגיה.

3. כדי ליצור מאגר צמתים ולבחור בלוק או תת-בלוק מסוים בהזמנה, משתמשים בדגל --reservation כדי לציין את שם המשאב המלא של הבלוק או תת-הבלוק הרצויים בהזמנה.

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

   gcloud container node-pools create NODE_POOL_NAME \
       --cluster=CLUSTER_NAME \
       --machine-type=tpu7x-standard-4t \
       --placement-policy=WORKLOAD_POLICY_NAME \
       --zone=ZONE \
       --reservation=project/PROJECT/reservation/RESERVATION_NAME/reservationBlocks/BLOCK_NAME
   

   כדי לטרגט תת-בלוק ספציפי בתוך בלוק, משתמשים בפקודה הבאה:

   gcloud container node-pools create NODE_POOL_NAME \
       --cluster=CLUSTER_NAME \
       --machine-type=tpu7x-standard-4t \
       --placement-policy=WORKLOAD_POLICY_NAME \
       --zone=ZONE \
       --reservation=project/PROJECT/reservation/RESERVATION_NAME/reservationBlocks/BLOCK_NAME/reservationSubBlocks/SUB_BLOCK_NAME
   

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

   • ‫NODE_POOL_NAME: השם של מאגר הצמתים החדש.
   • ‫CLUSTER_NAME: השם של אשכול GKE.
   • ‫WORKLOAD_POLICY_NAME: השם של מדיניות עומס העבודה שיצרתם.
   • ‫ZONE: האזור של מאגר הצמתים, לדוגמה, us-central1-a.
   • ‫PROJECT: מזהה הפרויקט ב- Google Cloud .
   • ‫RESERVATION_NAME: השם של הזמנת ה-TPU.
   • ‫BLOCK_NAME: הבלוק הספציפי בהזמנה.
   • ‫SUB_BLOCK_NAME: בלוק המשנה הספציפי בהזמנה.

   בפקודות הקודמות,

תזמון עומסי עבודה

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

מידע נוסף ודוגמאות לעומסי עבודה שמשתמשים ב-TPU זמינים במאמרים הרצת עומס עבודה בצמתים של פרוסת TPU והרצת עומס עבודה של Multislice.

ניהול כשלים בצמתים

הזמנות במצב 'כל הקיבולת' של TPU הן הזמנות ללא הגבלת זמן. No-holdback (ללא שמירת קיבולת) פירושו שאתם מקבלים את קיבולת ה-TPU המלאה, כולל החלק ש-Google Cloud שומר בדרך כלל למעבר לגיבוי במצב קיבולת מנוהלת.

במצב TPU All Capacity, אם מכונה וירטואלית נכשלת בגלל בעיות כמו כשל בחומרה, Google Cloud המערכת מנסה לשחזר את המכונה הווירטואלית באותו מארח (תיקון במקום). לכן מומלץ לשמור על קיבולת פנויה כדי לאפשר תזמון מחדש של עומסי עבודה במהלך כשלים בתשתית.

כשל בצומת ושחזור

כשצומת נכשל בהזמנה במצב 'כל הקיבולת' של TPU, האירועים הבאים מתרחשים:

• ‫Google Cloudמתחיל אירוע תיקון למכונה וירטואלית של Compute Engine שנכשלה. התהליך הזה מנסה לשחזר את ה-VM לסטטוס RUNNING ולהחזיר את סטטוס הצומת של GKE ל-READY.
• המכונה הווירטואלית של TPU עוברת לסטטוס תיקון, ויכול להיות שעומס העבודה שפועל בצומת הזה ייכשל, בהתאם למדיניות המעבר לגיבוי (failover). הסטטוס של מאגר הצמתים לא משתנה ל-ERROR גם אם יש כשלים במכונה וירטואלית אחת או יותר.

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

1. מציגים ברשימה את הצמתים במאגר הצמתים:

   kubectl get nodes
   

   לצמתים שנכשלו יש סטטוס NotReady.

2. עוקבים אחרי הסטטוס של הצומת ב-Compute Engine:

   למכונות וירטואליות של TPU במצב 'כל הקיבולת', משתמשים ב-gcloud compute instances describe. הפקודה הזו מספקת גם את הסטטוס הפיזי של הטופולוגיה כדי למצוא פרטים על המארח, על תת-הבלוק ועל הבלוק.

   gcloud compute instances describe VM_NAME \
           --format="table[box,title=VM-Position](resourceStatus.physical_host_topology:label=location)" \
           --zone=ZONE
   

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

   • ‫VM_NAME: השם של מופע ה-TPU VM.
   • ‫ZONE: האזור של המכונה הווירטואלית, למשל us-central1-a.

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

ניהול התחזוקה

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

‫GKE לא תומך בתחזוקת קבוצות של מכונות וירטואליות של TPU בהזמנה במצב All Capacity (כל הקיבולת). כדי לבצע תחזוקה של קבוצות ברמת תת-הבלוק, הבלוק או ההזמנה, צריך להשתמש בממשקי ה-API של Compute Engine. מידע נוסף מופיע במאמר בנושא ניהול אירועי תחזוקה באמצעות TPU במצב 'כל הקיבולת'.

הסרת המשאבים

כדי להימנע מחיובים לא רצויים בחשבון Google Cloud , צריך למחוק את מאגרי הצמתים של TPU שאין בהם יותר עומסי עבודה מתוזמנים. אם צריך להפסיק את עומסי העבודה בצורה מסודרת, משתמשים בפקודה kubectl drain כדי לנקות את עומסי העבודה לפני שמוחקים את מאגר הצמתים.

1. כדי למחוק מאגר צמתים של TPU:

   gcloud container node-pools delete NODE_POOL_NAME \
       --location=LOCATION \
       --cluster=CLUSTER_NAME
   

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

   • ‫NODE_POOL_NAME: שם מאגר הצמתים.
   • ‫CLUSTER_NAME: שם האשכול.
   • ‫LOCATION: מיקום המחשוב של האשכול.

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

• מידע נוסף על TPU ב-GKE
• איך פורסים עומסי עבודה של TPU ב-GKE Standard
• מידע נוסף על TPU Cluster Director