פתרון בעיות שקשורות ל-GPU ב-GKE

אם הפודים שלכם ב-Google Kubernetes Engine‏ (GKE) נתקעים במצב Pending בזמן בקשת משאבי nvidia.com/gpu, או אם הצמתים לא מצליחים לרשום את יחידות ה-GPU הזמינות שלהם, יכול להיות שיש בעיה בהתקנה של מנהל ההתקן (דרייבר) של NVIDIA או בהגדרות של מאגר הצמתים. הבעיות האלה מונעות מעומסי העבודה שלכם לגשת לחומרה של ה-GPU שהם צריכים.

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

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

התקנת דרייבר של GPU

בקטע הזה מופיע מידע לפתרון בעיות שקשורות להתקנה אוטומטית של מנהלי התקנים של מכשירי NVIDIA ב-GKE.

התקנת מנהל ההתקן נכשלת בצמתי Ubuntu

אם אתם משתמשים בצמתי Ubuntu עם GPU מסוג L4,‏ RTX PRO 6000,‏ H100 או H200 שמצורפים אליהם, יכול להיות שמנהל התקן ה-GPU שמוגדר כברירת מחדל ומוגדר ב-GKE לא יהיה בגרסה הנדרשת או בגרסה מאוחרת יותר. כתוצאה מכך, ה-Pod של תוסף מכשיר ה-GPU נשאר תקוע במצב Pending (בהמתנה), ויכול להיות שיהיו בעיות בעומסי העבודה של ה-GPU בצמתים האלה.

כדי לפתור את הבעיה, צריך לפעול לפי ההוראות שמתאימות ל-GPU:

L4 ו-H100

כדי לפתור את הבעיה ב-GPU מדגם L4 וב-GPU מדגם H100, מומלץ לשדרג לגרסאות GKE הבאות שבהן מותקן דרייבר GPU בגרסה 535 כדרייבר ברירת המחדל:

  • ‫1.26.15-gke.1483000 ואילך
  • ‫1.27.15-gke.1039000 ואילך
  • ‫1.28.11-gke.1044000 ואילך
  • ‫1.29.6-gke.1073000 ואילך
  • ‫1.30.2-gke.1124000 ואילך

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

kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/master/nvidia-driver-installer/ubuntu/daemonset-preloaded-R535.yaml

RTX PRO 6000

כדי לפתור את הבעיה הזו במעבדי RTX PRO 6000, צריך לשדרג לאחת מגרסאות GKE הבאות. בגרסאות האלה מותקנת גרסת הדרייבר 580 של ה-GPU כדרייבר ברירת המחדל:

  • ‫1.32.8-gke.1170000 ואילך
  • ‫1.33.4-gke.1245000 ואילך
  • ‫1.34.0-gke.1662000 ואילך

H200

כדי לפתור את הבעיה ב-GPU מדגם H200, צריך להתקין באופן ידני את מנהל ההתקן בגרסה 550 ואילך באמצעות הפעלת הפקודה הבאה:

kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/refs/heads/master/nvidia-driver-installer/ubuntu/daemonset-preloaded-R550.yaml

תוספי מכשירי GPU נכשלים עם שגיאות CrashLoopBackOff

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

קונטיינר האתחול של פלאגין מכשיר ה-GPU נכשל עם הסטטוס Init:CrashLoopBackOff. היומנים של המאגר דומים ליומנים הבאים:

failed to verify installation: failed to verify GPU driver installation: exit status 18

כדי לפתור את הבעיה, אפשר לנסות את השיטות הבאות:

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

    kubectl delete -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/master/nvidia-driver-installer/cos/daemonset-preloaded.yaml

  • מחילים מחדש את מניפסט ה-DaemonSet של התקנת מנהל ההתקן הידנית על האשכול. ב-25 בינואר 2023 עדכנו את קובץ המניפסט כך שיתעלם מצמתים שמשתמשים בהתקנה אוטומטית של מנהלי התקנים.

    kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/master/nvidia-driver-installer/cos/daemonset-preloaded.yaml

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

    gcloud container node-pools update POOL_NAME \
    --accelerator=type=GPU_TYPE,count=GPU_COUNT,gpu-driver-version=disabled \
    --cluster=CLUSTER_NAME \
    --location=LOCATION

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

    • ‫POOL_NAME: השם של מאגר הצמתים.
    • ‫GPU_TYPE: סוג ה-GPU שמאגר הצמתים כבר משתמש בו.
    • ‫GPU_COUNT: מספר המעבדים הגרפיים שכבר מצורפים למאגר הצמתים.
    • ‫CLUSTER_NAME: השם של אשכול GKE שמכיל את מאגר הצמתים.
    • ‫LOCATION: המיקום של האשכול ב-Compute Engine.

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

שגיאה: 'קובץ אימג' של קונטיינר cos-nvidia-installer:fixed לא קיים עם מדיניות משיכה של Never' או 'קובץ אימג' של קונטיינר ubuntu-nvidia-installer:fixed לא קיים עם מדיניות משיכה של Never'.

הבעיה הזו מתרחשת כש-Pods של nvidia-driver-installer נמצאים במצב PodInitializing, וכשמכשיר הפלאגין של ה-GPU או ה-Pods של תוכנת ההתקנה של מנהל ההתקן של ה-GPU מדווחים על השגיאה הבאה. הודעת השגיאה הספציפית תלויה במערכת ההפעלה שפועלת בצומת:

COS

Container image "cos-nvidia-installer:fixed" is not present with pull policy of Never.

Ubuntu

Container image "gke-nvidia-installer:fixed" is not present with pull policy of Never.

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

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

  • ‫1.25.15-gke.1040000 ואילך
  • ‫1.26.10-gke.1030000 ואילך
  • ‫1.27.6-gke.1513000 ואילך
  • ‫1.28.3-gke.1061000 ואילך

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

אם הצמתים שלך מריצים אובונטו, עדיין אין תיקון זמין לבעיית איסוף האשפה הזו. כדי לצמצם את הבעיה ב-Ubuntu, אפשר להריץ קונטיינר עם הרשאות שמתקשר עם המארח כדי לוודא שההגדרה של מנהלי ההתקנים (דרייברים) של NVIDIA GPU נכונה. כדי לעשות זאת, מריצים את הפקודה sudo /usr/local/bin/nvidia-container-first-boot מהצומת או מחילים את המניפסט הבא:

apiVersion: v1
kind: Pod
metadata:
  name: gke-nvidia-installer-fixup
spec:
  nodeSelector:
    cloud.google.com/gke-os-distribution: ubuntu
  hostPID: true
  containers:
  - name: installer
    image: ubuntu
    securityContext:
      privileged: true
    command:
      - nsenter
      - -at
      - '1'
      - --
      - sh
      - -c
      - "/usr/local/bin/nvidia-container-first-boot"
  restartPolicy: Never

סיבה פוטנציאלית נוספת לבעיה היא אובדן של תמונות הדרייבר של NVIDIA אחרי הפעלה מחדש של הצומת או תחזוקה של המארח. זה יכול לקרות בצמתים סודיים או בצמתים עם יחידות GPU שמשתמשים באחסון SSD מקומי זמני. במצב הזה, GKE טוען מראש את קובצי האימג' של הקונטיינר nvidia-installer-driver בצמתים ומעביר אותם מדיסק האתחול ל-SSD המקומי באתחול הראשון.

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

resource.type="gce_instance"
protoPayload.serviceName="compute.googleapis.com"
log_id("cloudaudit.googleapis.com/system_event")

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

  • ‫1.27.13-gke.1166000 ואילך
  • ‫1.29.3-gke.1227000 ואילך
  • ‫1.28.8-gke.1171000 ואילך

שגיאה: הגדרת ספריות ההתקנה של מנהל ההתקן של ה-GPU נכשלה: יצירת שכבת-על של lib64 נכשלה: יצירת הספרייה ‎ /usr/local/nvidia/lib64 נכשלה: mkdir /usr/local/nvidia/lib64: not a directory.

השגיאה הזו מתרחשת מהקונטיינר של מתקין מנהל ההתקן (דרייבר) של ה-GPU בתוך הפלאגין של מכשיר ה-GPU, כשהאפשרות NCCL fastsocket מופעלת:

failed to configure GPU driver installation dirs: failed to create lib64 overlay: failed to create dir /usr/local/nvidia/lib64: mkdir /usr/local/nvidia/lib64: not a directory.

הבעיה הזו מתרחשת רק באשכולות ובצמתים שמופעלים בהם GKE 1.28 ו-GKE 1.29.

הבעיה נגרמת בגלל מרוץ תהליכים של NCCL fastsocket עם תוכנת ההתקנה של מנהל ההתקן של ה-GPU.

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

  • ‫1.28.8-gke.1206000 ואילך
  • ‫1.29.3-gke.1344000 ואילך

מידע נוסף זמין בהערות הגרסה של GPUDirect-TCPXO.

שגיאה: לא ניתן לאחזר את המכשיר nvidia0: המכשיר nvidia0 לא נמצא.

השגיאה הבאה מציינת ש-XID 62 ו-RmInitAdapter נכשלו עבור GPU עם מינור 0:

Failed to get device for nvidia0: device nvidia0 not found.

בגרסה 525.105.17 של מנהל ההתקן של NVIDIA יש באג שעלול לגרום לשגיאות תקשורת (XID) ולמנוע אתחול תקין של ה-GPU, מה שמוביל לכשל באתחול ה-GPU.

כדי לפתור את הבעיה, צריך לשדרג את הדרייבר של NVIDIA לגרסה 525.110.11 או לגרסה חדשה יותר.

מיפוי של גרסת GKE וגרסת קובץ האימג' של צומת מערכת ההפעלה שמותאמת לקונטיינרים לגרסת מנהל ההתקן של GPU

כדי למצוא את גרסאות מנהלי ההתקנים של ה-GPU שממופות לגרסאות GKE ולגרסאות של קובצי אימג' של צמתים של מערכת הפעלה שמותאמת לקונטיינרים, פועלים לפי השלבים הבאים:
  1. מיפוי גרסאות של תמונות צמתים של מערכת הפעלה שמותאמת לקונטיינרים לגרסאות תיקון של GKE לגרסת GKE ספציפית שבה רוצים למצוא את גרסת הדרייבר של ה-GPU. לדוגמה, בגרסה 1.33.0-gke.1552000 נעשה שימוש ב-cos-121-18867-90-4.
  2. בוחרים את אבן הדרך של גרסת קובץ האימג' של הצומת של מערכת ההפעלה שמותאמת לקונטיינרים בהערות הגרסה של מערכת ההפעלה שמותאמת לקונטיינרים. לדוגמה, בוחרים באבן דרך 121 עבור cos-121-18867-90-4.
  3. בדף הערות הגרסה של אבן הדרך הספציפית, מאתרים את הערת הגרסה שמתאימה לגרסה הספציפית של תמונת הצומת של מערכת ההפעלה שמותאמת לקונטיינרים. לדוגמה, בהערות מוצר של מערכת הפעלה שמותאמת לקונטיינרים: אבן דרך 121, אפשר לראות את cos-121-18867-90-4. בטבלה בעמודה GPU Drivers, לוחצים על See List כדי לראות את פרטי הגרסה של מנהל ההתקן של ה-GPU.

הפקודה nvidia-smi נכשלת

כשמשתמשים במכונות וירטואליות עם GPU כדי להריץ עומסי עבודה ב-GKE, יכול להיות שהפקודות כמו nvidia-smi ייכשלו בקונטיינר עם אחת מהשגיאות הבאות:

  • bash: nvidia-smi: command not found
  • שגיאות שמציינות שלא ניתן למצוא את libnvidia-ml.so או ספריות אחרות של NVIDIA.

‫GKE מטמיע את הדרייברים והכלים הנדרשים של NVIDIA מהמארח (host) של הצומת בקונטיינרים, בדרך כלל בנתיב /usr/local/nvidia/. עם זאת, יכול להיות שמשתני הסביבה שמוגדרים כברירת מחדל בקונטיינר (PATH ו-LD_LIBRARY_PATH) לא יכללו את הנתיבים לקבצים הבינאריים ולספריות של NVIDIA.

כדי לפתור את השגיאות האלה, צריך לעדכן את קובץ המניפסט של ה-Pod או הפריסה כדי לכלול את הנתיבים הנדרשים של NVIDIA במשתני הסביבה PATH ו-LD_LIBRARY_PATH של הקונטיינר.

לדוגמה, מוסיפים את הבלוק env הבא למפרט spec.template.spec.containers:

spec:
  containers:
  - name: gpu-container
    image: gpu-image
    env:
    - name: LD_LIBRARY_PATH
      # Prepend NVIDIA lib64 directory to existing LD_LIBRARY_PATH
      value: /usr/local/nvidia/lib64
    - name: PATH
      # Prepend NVIDIA bin directory to existing PATH
      value: /usr/local/nvidia/bin:$PATH
    # ... other container settings

איפוס יחידות GPU במכונות וירטואליות מסוג A3 ו-A4

יכול להיות שתצטרכו לאפס את ה-GPU במכונה וירטואלית מסוג A3 כדי לפתור בעיות מסוימות.

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

כדי לאפס את ה-GPU באופן ידני:

  1. מסירים את ה-Pods שמבקשים משאבי GPU מהצומת שבו צריך לאפס את ה-GPU.

  2. משביתים את תוסף מכשיר ה-GPU בצומת:

    kubectl get nodes \
    --selector=kubernetes.io/hostname=NODE_NAME \
    --no-headers | awk '{print $1}' \
    | xargs -I{} kubectl label node {} gke-no-default-nvidia-gpu-device-plugin=true

    מחליפים את NODE_NAME בשם הצומת.

  3. מתחברים ל-VM שמגבה את הצומת.

  4. בסשן ה-SSH, מאפסים את ה-GPU:

    איפוס כל יחידות ה-GPU במכונה הווירטואלית

    /home/kubernetes/bin/nvidia/bin/nvidia-smi --gpu-reset

    כדי לאפס GPU ספציפי

    # Identify the faulty GPU
/home/kubernetes/bin/nvidia/bin/nvidia-smi

# Reset the specifc GPU using either the GPU index or PCI bus ID from above command output 
/home/kubernetes/bin/nvidia/bin/nvidia-smi --gpu-reset -i <gpu_id>

  5. מפעילים מחדש את הפלאגין של מכשיר ה-GPU:

    kubectl get nodes --selector=kubernetes.io/hostname=NODE_NAME \
    --no-headers \| awk '{print $1}' \
    | xargs -I{} kubectl label node {} gke-no-default-nvidia-gpu-device-plugin=false \
    --overwrite

יחידות GPU בצומתי Confidential GKE

בקטעים הבאים מוסבר איך לזהות ולפתור בעיות ב-GPU שפועלים ב-Confidential GKE Nodes.

עומסי עבודה של GPU לא מתוזמנים בצומתי Confidential GKE

כדי להשתמש בצמתים סודיים ב-GKE, צריך להתקין ידנית דרייבר של GPU שמתאים לסוג ה-GPU שנבחר ולגרסת ה-GKE. אם לא מתבצע תזמון של GPU Pods ב-Confidential GKE Nodes והם נשארים במצב Pending, צריך לתאר את DaemonSet של התקנת הדרייבר:

kubectl --namespace=kube-system get daemonset nvidia-driver-installer -o yaml

אם הפלט מחזיר שגיאה NotFound, צריך להתקין את מנהל ההתקן.

אם ה-DaemonSet פועל, הפלט דומה לזה:

apiVersion: apps/v1
kind: DaemonSet
# lines omitted for clarity
spec:
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      k8s-app: nvidia-driver-installer
  template:
    metadata:
      creationTimestamp: null
      labels:
        k8s-app: nvidia-driver-installer
        name: nvidia-driver-installer
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: cloud.google.com/gke-accelerator
                operator: Exists
              - key: cloud.google.com/gke-gpu-driver-version
                operator: DoesNotExist
              - key: cloud.google.com/gke-confidential-nodes-instance-type
                operator: In
                values:
                - TDX

בפלט הזה, מוודאים שהשדה nodeAffinity מכיל את המפתח cloud.google.com/gke-confidential-nodes-instance-type. אם הפלט לא מכיל את המפתח הזה, ה-DaemonSet של התקנת מנהל ההתקן לא תומך בצמתים סודיים של GKE.

פורסים את DaemonSet שתומך ב-GPU ב-Confidential GKE Nodes:

kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/refs/heads/master/nvidia-driver-installer/cos/daemonset-confidential.yaml

אחרי שמתקינים את הדרייברים, בודקים אם עומסי העבודה של ה-GPU מתחילים בהצלחה.

שגיאה: לא ניתן להקצות וקטור של מכשיר

הודעת השגיאה הבאה ביומני מאגר ה-GPU מציינת שה-GPU נותק ממופע ה-VM של הצומת:

Failed to allocate device vector A (error code unknown error)!

הניתוק הזה יכול לקרות בגלל שגיאת חומרה או בגלל בעיה במפתחות ההצפנה.

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

  1. משיגים את השם של הצומת שמריץ את ה-Pod של ה-GPU:

    kubectl get pod POD_NAME -o yaml | grep "nodeName"

    מחליפים את POD_NAME בשם של ה-Pod שנכשל.

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

    nodeName: gke-cluster-1-default-pool-b7asdfbt-fd3e

  2. מאפסים את המכונה של Compute Engine:

    gcloud compute instances reset NODE_NAME

    מחליפים את NODE_NAME בשם הצומת מהפלט של השלב הקודם.

    ה-CLI של gcloud מחפש מכונות וירטואליות עם השם הזה בפרויקט הפעיל. אם מוצגת בקשה לבחור אזור, מציינים Y.

  3. בודקים אם עומסי העבודה של ה-GPU פועלים ללא שגיאות.

שגיאה: הפענוח נכשל עם השגיאה ‎-74

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

Decryption failed with error -74

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

gcloud compute instances reset NODE_NAME

מחליפים את NODE_NAME בשם של הצומת שנכשל.

ה-CLI של gcloud מחפש מכונות וירטואליות עם השם הזה בפרויקט הפעיל. אם מוצגת בקשה לבחור אזור, מציינים Y.

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

איתור שגיאות XID

ה-daemonset‏ gpu-device-plugin פועל במרחב השמות kube-system ואחראי על הפעולות הבאות:

  • תזמון של עומסי עבודה ב-GPU: הקצאת משאבי GPU ל-Pods.
  • בדיקת תקינות של GPU: מעקב אחר התקינות של יחידות ה-GPU.
  • איסוף מדדים של GPU: איסוף מדדים שקשורים ל-GPU, כמו דיוטי סייקל (Duty cycle) ושימוש בזיכרון.

‫gpu-device-plugin משתמש בספריית הניהול של NVIDIA‏ (NVML) כדי לזהות שגיאות XID. כשמתרחשת שגיאת XID, השגיאה נרשמת ביומן של gpu-device-plugin Pod שפועל בצומת המושפע. יש שני סוגים של יומני שגיאות של XID:

  • שגיאות לא קריטיות של XID:
    • פורמט יומן: Skip error Xid=%d as it is not Xid Critical
    • המשמעות: השגיאות האלה לא נחשבות קריטיות. הן יכולות להיגרם מבעיות שונות בתוכנה או בחומרה.
    • פעולה: GKE לא מבצע פעולה אוטומטית לגבי שגיאות XID לא קריטיות.
  • שגיאות קריטיות ב-XID:
    • פורמט יומן: XidCriticalError: Xid=%d, All devices will go unhealthy
    • משמעות: השגיאות האלה מעידות על בעיה בחומרה של ה-GPU.
    • פעולה:
      • ‫GKE מסמן את משאבי ה-GPU של הצומת כלא תקינים.
      • ‫GKE מונע תזמון של עומסי עבודה (workloads) של GPU בצומת.
      • אם התיקון האוטומטי של הצומת מופעל, GKE יוצר מחדש את הצומת.

בעיות ב-GPUDirect-TCPX(O)

בקטע הזה מפורט מידע לפתרון בעיות שקשורות ל-GPUDirect-TCPX(O). אם אתם משתמשים ב-GKE גרסה 1.34 ואילך, כדאי לעיין גם בדף בעיות ידועות ב-GKE.

נתוני גרסה והוראות שדרוג

למשתמשים חדשים, המאמר Maximize GPU network bandwidth in Standard mode clusters מספק הנחיות לשימוש ב-GPUDirect-TCPX(O). משתמשים קיימים יכולים לקרוא את הערות הגרסה של GPUDirect-TCPXO כדי לקבל מידע על הגרסה והוראות לשדרוג, כי אנחנו משיקים גרסאות חדשות באופן שוטף.

כשלים ב-tcpx-daemon וב-tcpxo-daemon אחרי שדרוג גרסת GKE

יכול להיות שתיתקלו בשגיאה הבאה אם הפודים של tcpx-daemon או tcpxo-daemon נכשלו:

cuda error detected! name: CUDA_ERROR_NO_DEVICE; string: no CUDA-capable device is detected

בנוסף, בודקים אם ה-Pods במרחב השמות kube-system נמצאים במצב CrashLoopBackOff או Error.device-injector

הבעיה הזו מתרחשת אם שדרגתם את מאגרי הצמתים של GKE לאחת מהגרסאות הבאות או לגרסאות מתקדמות יותר:

  • ‫GKE 1.31: ‏ 1.31.14-gke.1033000
  • ‫GKE 1.32: ‏ 1.32.9-gke.1575000
  • ‫GKE 1.33: ‏ 1.33.5-gke.1862000
  • ‫GKE 1.34: ‏ 1.34.1-gke.3225000
  • ל-GKE מגרסה 1.35 ואילך

הבעיה נגרמת כתוצאה משימוש בגרסה ישנה של מניפסט הכלי להוספת מכשירים ל-NRI, שכולל initContainer בשם enable-nri. בגרסאות GKE המושפעות, ה-NRI מופעל כברירת מחדל בהגדרת הצומת. המאגר enable-nri שיצא משימוש מנסה לשנות את ההגדרה ולהפעיל מחדש את זמן הריצה של המאגר, וזה מתנגש עם ברירות המחדל של המערכת וגורם לקריסת ה-Pods של nri-device-injector. הכשל הזה מונע את החשיפה של מכשירי GPU למאגר tcpx-daemon או tcpxo-daemon.

כדי לפתור את הבעיה, צריך לעדכן את nri-device-injector DaemonSet לגרסה העדכנית ביותר, שבה הוסר initContainer שגורם להתנגשות.

  1. מוחקים את DaemonSet הקיים:

    kubectl delete daemonset device-injector -n kube-system

  2. החלת המניפסט העדכני:

    kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/master/nri_device_injector/nri-device-injector.yaml

  3. מפעילים מחדש את ה-Pods של עומס העבודה.

ניפוי באגים באמצעות יומנים של NCCL

אם לא הצלחתם לפתור בעיה ב-NCCL, אתם יכולים לאסוף יומנים של NCCL עם מידע על ניפוי באגים. היומנים האלה מכילים מידע חשוב על פעולות NCCL ויכולים לעזור לכם למצוא את מקור הבעיה. אם לא הצלחתם לפתור את הבעיה, עליכם לאסוף את היומנים האלה לפני שאתם פותחים פנייה לתמיכה של Cloud Customer Care. היומנים האלה יכולים לעזור ל-Cloud Customer Care לפתור את הבעיה שלכם מהר יותר.

כדי ליצור ולאסוף את היומנים, מבצעים את השלבים הבאים:

  1. מגדירים את משתני הסביבה הבאים בתוך ה-Pod או המניפסט של האפליקציה:

    NCCL_DEBUG=INFO
NCCL_DEBUG_SUBSYS=INIT,NET,ENV,COLL,GRAPH
NCCL_DEBUG_FILE=/DIRECTORY/FILE_NAME.%h.%p

    מידע נוסף על משתני הסביבה האלה זמין במאמר בנושא איסוף יומני ניפוי באגים של NCCL.

  2. כדי ליצור נתונים ליומנים, מריצים בדיקת NCCL. הדרך להריץ את הבדיקה הזו תלויה בסוג האשכול שבו משתמשים. באשכולות GKE, אפשר לפרוס ולהריץ בדיקת NCCL באמצעות Topology Aware Scheduling (TAS). אחרי שמריצים את הבדיקה של NCCL, הכלי יוצר אוטומטית את היומנים בכל הצמתים שמשתתפים בבדיקה.

  3. איסוף היומנים מכל הצמתים. כדי לוודא שאספתם יומני NCCL מכל הצמתים, צריך לבדוק שהיומנים מכילים את המידע הבא:

    • שמות המארחים של כל המכונות הווירטואליות שמשתתפות בעומס העבודה.
    • מזהי התהליכים (PID) של כל התהליכים הרלוונטיים במכונת ה-VM.
    • הדירוגים של כל יחידות ה-GPU שמשמשות את עומס העבודה בכל מכונת VM.

    אם אתם לא בטוחים איפה קובצי היומן נמצאים, בדוגמה הבאה אפשר לראות איפה NCCL יוצר את קובצי היומן כשהמשתנה NCCL_DEBUG_FILE מוגדר ל-/tmp/nccl_log.%h.%p. יש לכם שתי מכונות וירטואליות בשם a3plus-vm-1 ו-a3plus-vm-2, וכל מכונה וירטואלית מפעילה שמונה תהליכים בתוך קונטיינר עומס העבודה. בתרחיש הזה, NCCL יוצר את קובצי היומן הבאים בספרייה /tmp בתוך קונטיינר עומס העבודה בכל מכונה וירטואלית:

    • ב-a3plus-vm-1: שמונה קובצי יומן בשם nccl_log.a3plus-vm-1.PID, כאשר PID הוא מזהה התהליך.
    • ב-a3plus-vm-2: שמונה קובצי יומן בשם nccl_log.a3plus-vm-2.PID.

  4. בודקים את היומנים. הרשומות ביומן NCCL הן בפורמט הבא:

    HOSTNAME:PID:TID [RANK] NCCL_MESSAGE

    רשומות היומן האלה מכילות את הערכים הבאים:

    • ‫HOSTNAME: שם המארח של המכונה הווירטואלית. הערך הזה מציין באיזו מכונה וירטואלית נעשה שימוש כש-NCCL יצר את רשומת היומן.
    • ‫PID: ה-PID. הערך הזה מזהה את התהליך שיצר את רשומת היומן.
    • ‫TID: מזהה השרשור. הערך הזה מזהה את השרשור בתהליך שהיה בשימוש כש-NCCL יצר את רשומת היומן.
    • ‫RANK: מזהה הדירוג המקומי. הערך הזה מציין באיזה GPU נעשה שימוש כש-NCCL יצר את הרשומה ביומן. הדירוגים ממוספרים מ-0 עד N, כאשר N הוא המספר הכולל של יחידות ה-GPU שמשתתפות בתהליך. לדוגמה, אם עומס העבודה שלכם פועל עם שמונה מעבדי GPU לכל מכונה וירטואלית, לכל מכונה וירטואלית צריכים להיות שמונה ערכים שונים של דירוג (0-7).
    • NCCL_MESSAGE: הודעה תיאורית שמספקת מידע נוסף על האירוע וכוללת את חותמת הזמן של מועד יצירת היומן על ידי NCCL.

    לדוגמה:

    gke-a3plus-mega-np-2-aa33fe53-7wvq:1581:1634 [1] NCCL INFO 00:09:24.631392: NET/FasTrak plugin initialized.

    בדוגמה הזו יש את הערכים הבאים:

    • ‫gke-a3plus-mega-np-2-aa33fe53-7wvq: שם המארח.
    • ‫1581: מזהה התהליך.
    • ‫1634: מזהה השרשור.
    • ‫1: מזהה הדירוג המקומי.
    • ‫NCCL INFO 00:09:24.631392: NET/FasTrak plugin initialized.: ההודעה שמסבירה מה קרה.

  5. אם פותחים בקשת תמיכה, צריך לארוז את היומנים שאספתם, יחד עם הפלט של בדיקת NCCL, בקובץ zip. צריך לצרף את קובץ ה-ZIP כששולחים בקשת תמיכה ל-Cloud Customer Care.

  6. כדי להפסיק את האיסוף של יומני ניפוי הבאגים של NCCL, מסירים את המשתנים שהוספתם בשלב 1.

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