חוסן של אשכולות

אם אתם מעוניינים באשכולות אימון של Gemini Enterprise Agent Platform, אתם יכולים לפנות לנציג המכירות שלכם כדי לקבל גישה.

‫Gemini Enterprise Agent Platform כולל מערכת מקיפה לבדיקת תקינות, כדי להבטיח את המהימנות של צמתי מחשוב ואת היציבות של משימות Slurm. במערכת הזו יש אפשרויות שחזור אוטומטיות וידניות. תהליך אוטומטי פועל במהלך ביצוע המשימה כדי לעקוב אחרי רכיבים קריטיים כמו תקינות ה-GPU והשימוש בדיסק, ומחליף באופן אוטומטי צמתים שנכשלים. במקרים שבהם נדרשת התערבות של המשתמש, אשכול האימון מספק reportFaultyNodesAPI, שמאפשר למחוק ידנית צומת פגום ספציפי או לדווח על חשד לכשל בחומרה במארח הבסיסי שלו.

הפעלת עומס עבודה לבדיקה כדי לוודא שהפונקציונליות של ה-GPU פועלת

שלב 1: מתחברים לצמתי האשכול באמצעות SSH

מ-Cloud Shell או ממסוף Google Cloud , מתחברים לצומת הכניסה באמצעות IAP. בדוגמה הבאה אפשר לראות את הפקודה עבור Cloud Shell:

gcloud compute ssh --zone $ZONE "Login Node Name" --tunnel-through-iap --project $PROJECT_ID

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

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

~$ sinfo
PARTITION   AVAIL  TIMELIMIT  NODES  STATE NODELIST
partition1*    up   infinite      2   idle hcsa3m1236-a3mnodeset-[0-1]

בשלב הבא, שולחים משימה באצווה.

~$ sbatch --qos normal --wrap "echo start! && sleep 10s && echo done!"

אמור להופיע קובץ בשם slurm-job-id.out בספריית הבית.

שלב 3: מריצים עומס עבודה של GPU

שומרים את התוכן הבא כקובץ סקריפט בשם test.sh בספריית הבית.

#!/bin/bash
#SBATCH --nodes=2
#SBATCH --ntasks-per-node=1
#SBATCH --cpus-per-task=4
#SBATCH --gres=gpu:8
#SBATCH --job-name=nvidia_smi

srun nvidia-smi -L

מגדירים את ההרשאות של הסקריפט ל-755 כדי לאפשר את ההרצה שלו, ואז שולחים את משימת Slurm:

~$ sbatch ./test.sh

מערכת Slurm שומרת את הפלט של הסקריפט בקובץ בשם slurm-job-id.out.

הפלט אמור להיראות כך:

GPU 0: NVIDIA H100 80GB HBM3 (UUID: GPU-f75045e8-4d87-49d1-2eb9-39ec2baddf9b)
GPU 1: NVIDIA H100 80GB HBM3 (UUID: GPU-b91556d8-5215-d0ed-50b8-a88720e5b29c)
GPU 2: NVIDIA H100 80GB HBM3 (UUID: GPU-7600155a-0036-35f5-9489-a7b4ed0ce887)
GPU 3: NVIDIA H100 80GB HBM3 (UUID: GPU-a402e125-7841-033f-f08b-7921526c121f)
GPU 4: NVIDIA H100 80GB HBM3 (UUID: GPU-20eef8f8-b2c7-1716-5ce7-7f64475bd2c0)
GPU 5: NVIDIA H100 80GB HBM3 (UUID: GPU-65463286-e587-b52f-4d5b-8880eecbf0e7)
GPU 6: NVIDIA H100 80GB HBM3 (UUID: GPU-d5ff75e7-dd54-edf6-a684-33c26fc365e1)
GPU 7: NVIDIA H100 80GB HBM3 (UUID: GPU-26e81ae2-11fd-9d7e-95b6-c186e5173007)
GPU 0: NVIDIA H100 80GB HBM3 (UUID: GPU-e66a185a-b40c-81d9-d35d-19cab811df34)
GPU 1: NVIDIA H100 80GB HBM3 (UUID: GPU-d23e5cf7-afd8-bec2-1487-9e27eeb6aae0)
GPU 2: NVIDIA H100 80GB HBM3 (UUID: GPU-4dde1b05-ea5e-01e9-5c1e-e1c0d3b4b113)
GPU 3: NVIDIA H100 80GB HBM3 (UUID: GPU-3a0d734a-6fb8-d841-a97f-d6846553ea7f)
GPU 4: NVIDIA H100 80GB HBM3 (UUID: GPU-76fe0d37-08b2-a3a6-8ddf-55501426bc7c)
GPU 5: NVIDIA H100 80GB HBM3 (UUID: GPU-9e0a41e1-b399-8934-01af-6198b749c02a)
GPU 6: NVIDIA H100 80GB HBM3 (UUID: GPU-dddd09ee-c944-1098-9c4e-d96f8762ecb1)
GPU 7: NVIDIA H100 80GB HBM3 (UUID: GPU-df52c109-0ac1-30cc-226b-85b1a8a6bc16)

בדיקות תקינות אוטומטיות ושחזור

כדי להבטיח את המהימנות של הצמתים, אשכולות האימון עוקבים באופן רציף אחרי תקינות הצמתים באמצעות חבילת הבדיקות האוטומטיות הבאה. אשכולות האימון מריצים בדיקות תקינות במהלך הפרוֹלוֹג של Slurm (לפני שתהליך מתחיל) והאפילוג (אחרי שתהליך מסתיים).

חבילת בדיקות תקינות

  • תקינות ה-GPU: מריץ אבחון מפורט של כל GPU בנפרד, כולל nvidia-smi, dcgmi וxidמעקב אחר קוד.
  • השימוש בדיסק: בדיקה של שימוש גבוה בדיסק במחיצות קריטיות (/, /mnt/localssd, /mnt/localdisk) כדי למנוע כשלים בעבודות בגלל חוסר מקום.
  • תקינות הרשת: מוודא שלממשקי הרשת הראשיים יש כתובת IPv4. אם נמצאת בעיה, המערכת מנסה לתקן אותה בעצמה על ידי איפוס הממשק.
  • עומס על המעבד: המדד הזה מנטר את העומס הממוצע על המערכת ומתעד אזהרה אם הוא חורג מסף מוגדר מראש.

תהליך שחזור לאחר כשל

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

השחזור האוטומטי הזה כפוף לתנאים הבאים:

  • מגבלת הפעלה מחדש: תהליך השחזור ידלג אם העבודה הרלוונטית ב-Slurm כבר הופעלה מחדש מספר מסוים של פעמים.

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

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

ניהול ידני של צמתי מחשוב פגומים

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

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

פעולה 1: מחיקת צומת פגום

הפעולה הזו מוחקת את הצומת שצוין. התוצאה של הפעולה הזו תלויה בסיווג של הצומת כ'סטטי' או כ'דינמי' על ידי Slurm:

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

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

בדוגמאות האלה אנחנו משתמשים בכינוי gcurl, שהוא קיצור דרך נוח ומאומת לאינטראקציה עם נקודות הקצה של ה-API. הפקודה הבאה יוצרת כינוי ל-curl שכולל את כותרות ההרשאה הנדרשות.

alias gcurl='curl -H "Authorization: Bearer $(gcloud auth print-access-token)" -H "Content-Type: application/json"'

בקשת API למחיקת צומת

כדי למחוק צומת פגום, מריצים את בקשת ה-POST הבאה. הערך NODE_ID צריך להיות בפורמט CLUSTER_ID-NODEPOOL_ID-INDEX. 

  gcurl -X POST https://REGION-aiplatform.googleapis.com/v1beta1/projects/PROJECT_ID/locations/REGION/modelDevelopmentClusters/CLUSTER_ID:reportFaultyNodes -d '{"nodeActions": [{"nodeId": "NODE_ID"}]}'

בדיקת סטטוס הפעולה
אפשר לעקוב אחרי התוצאה של פעולת reportFaultyNodes על ידי בדיקת סטטוס הפעולה. 

  gcurl https://REGION-aiplatform.googleapis.com/v1/projects/PROJECT_ID/locations/REGION/operations/OPERATION_ID

פעולה 2: דיווח על מארח כפגום

Google Cloud וליצור קשר עם צוות התמיכה.

אם אתם חושדים בכשל בחומרה, אתם יכולים לדווח על המארח הפיזי של צומת GPU כפגום.

  • מכונות וירטואליות נתמכות: A3 Ultra ו-A4 High-GPU

  • מצב הצומת: צומת היעד צריך להיות במצב RUNNING לפני ששולחים קריאה ל-API. הוא ישתנה ל-REPAIRING אם השיחה תצליח, ויחזור ל-RUNNING אחרי שהמארח יתוקן או שהצומת ייווצר מחדש במארח חדש. הפעולה הזו מתבצעת על בסיס הכי טוב שאפשר.

דרישה מוקדמת: מתן תפקיד IAM

כדי להשתמש בתכונה הזו, צריך להעניק לסוכן השירות של Agent Platform את התפקיד Compute Instance Admin ‏ (v1) (roles/compute.instanceAdmin.v1). 

  PROJECT_NUMBER=$(gcloud projects describe PROJECT_ID --format="value(projectNumber)")

  gcloud projects add-iam-policy-binding PROJECT_ID\
  --member="serviceAccount:service-PROJECT_NUMBER@gcp-sa-aiplatform.iam.iam.gserviceaccount.com" \
  --role="roles/compute.instanceAdmin.v1"

בקשת API לדיווח על מארח

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

התנהגות תיאור
PERFORMANCE יש בעיות בביצועים של יחידות ה-GPU שמצורפות למכונה הווירטואלית בהשוואה ליחידות GPU אחרות באשכול, לא מופיעות שגיאות XID ביומנים, ומערכת Compute Engine לא מזהה תבניות כשל רגילות אחרות כמו השחתת נתונים שקטה.
SILENT_DATA_CORRUPTION הנתונים במכונת ה-VM פגומים, אבל מכונת ה-VM ממשיכה לפעול. הסיבה לכך יכולה להיות בעיות כמו פגמים ב-vCPU, באגים בתוכנה או בעיות בקרנל.
UNRECOVERABLE_GPU_ERROR זיהית שגיאת GPU שלא ניתן לשחזר עם XID.
BEHAVIOR_UNSPECIFIED אתם לא בטוחים מה הבעיה במכונה הווירטואלית.

הנה דוגמה לבקשת API. 

gcurl -X POST \
  https://REGION-aiplatform.googleapis.com/v1beta1/projects/PROJECT_ID/locations/REGION/modelDevelopmentClusters/CLUSTER_ID:reportFaultyNodes \
  -d '{"nodeActions": [{"nodeId": "NODE_ID", "reportFaultyHost": {"faultReasons": [{"behavior": "BEHAVIOR_1", "description": "DESCRIPTION_1"}, {"behavior": "BEHAVIOR_2", "description": "DESCRIPTION_2"}]}}]}'

איך הכל משתלב יחד

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

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

הגדרת אשכול האימון לסבילות לתקלות היא שלב חשוב ביצירת תהליך עבודה מלא של MLOps שמוכן לייצור.