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

רגילה

במאמר הזה מוסבר איך לפרוס ולנהל עומסי עבודה באמצעות התכונה 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). קוביה היא טופולוגיה של שבבי TPU מחוברים, שרלוונטית רק לטופולוגיות ב-3-tuples‏ ({A}x{B}x{C}).4x4x4

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

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

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

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

• מפעילים את ממשק Google Kubernetes Engine API.
הפעלת Google Kubernetes Engine API
• כדי להשתמש ב-CLI של Google Cloud למשימה הזו, צריך להתקין ואז להפעיל את gcloud CLI. אם התקנתם בעבר את ה-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 ב-GKE תומך רק בגרסאות Ironwood ‏ (TPU7x).

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

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

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

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

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

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

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

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

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

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

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

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

1. לראות את ההגדרות הזמינות לחסימה, לחסימת משנה ולמארח. משלימים את השלבים במאמר View the topology and health status of All Capacity mode reservations.

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 All Capacity הן הזמנות ללא הגבלת זמן. No-holdback (ללא הגבלה) פירושו שאתם מקבלים את מלוא קיבולת ה-TPU, כולל החלק ש-Google Cloud בדרך כלל שומרת למעבר לגיבוי במצב קיבולת מנוהלת.

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

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

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

• ‫Google Cloudמתחיל אירוע תיקון למכונה וירטואלית של Compute Engine שנכשלה. במהלך התהליך הזה, המערכת מנסה לשחזר את ה-VM לסטטוס RUNNING ולהחזיר את סטטוס הצומת של GKE ל-READY.
• המכונה הווירטואלית של TPU עוברת לסטטוס תיקון, ויכול להיות שעומס העבודה שפועל בצומת הזה ייכשל, בהתאם למדיניות המעבר לגיבוי. הסטטוס של מאגר הצמתים לא משתנה ל-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