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

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

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

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

מהו מצב 'קיבולת כוללת' של 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

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

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

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

  • מפעילים את ממשק Google Kubernetes Engine API.
    • הפעלת Google Kubernetes Engine API
  • אם רוצים להשתמש ב-CLI של Google Cloud למשימה הזו, צריך להתקין ואז להפעיל את ה-CLI של gcloud. אם התקנתם בעבר את ה-CLI של gcloud, מריצים את הפקודה gcloud components update כדי לקבל את הגרסה העדכנית. יכול להיות שגרסאות קודמות של ה-CLI של gcloud לא יתמכו בהרצת הפקודות שמופיעות במסמך הזה.
  • מוודאים שיש לכם ��שכול קיים מסוג 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 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 הן הזמנות ללא הגבלת כמות. ללא שמירת קיבולת פירושו שאתם מקבלים את קיבולת ה-TPU המלאה, כולל החלק שGoogle Cloud בדרך כלל נשמר למעבר לגיבוי במצב קיבולת מנוהלת.

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

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

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

  • ‫Google Cloudמתחיל אירוע תיקון למכונה וירטואלית של Compute Engine שנכשלה. במהלך התהליך הזה המערכת מנסה לשחזר את המכונה הווירטואלית לסטטוס 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: מיקום המחשוב של האשכול.

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