מעקב אחרי מכונות Compute Engine ואשכולות Slurm

במאמר הזה מוסבר איך משתמשים במרכזי בקרה של Cloud Monitoring כדי לעקוב אחרי מופעי A4X Max,‏ A4X,‏ A4,‏ A3 Ultra ו-A3 Mega שיצרתם באמצעות קיבולת מוזמנת. בעזרת מרכזי הבקרה האלה תוכלו לזהות צווארי בקבוק בביצועים של מופעי Compute Engine עצמאיים או של אשכולות Slurm, ולפתור בעיות כדי לצמצם את זמן ההשבתה בעומסי העבודה.

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

  • תקינות המכונה

  • ביצועי ה-GPU

  • יעילות השידור ברשת

  • יעילות הרשת בין בלוקים ותתי-בלוקים

  • יעילות של עומסי עבודה של למידת מכונה (ML)

  • זיהוי של הודעות שלא נמסרו

כדי לעקוב אחרי אשכולות Cluster Director, אפשר לעיין במאמר בנושא מעקב אחרי ביצועי אשכולות באמצעות לוחות בקרה מוכנים מראש.

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

לפני שמתחילים לעקוב אחרי עומס העבודה, צריך לבצע את השלבים הבאים (אם עדיין לא עשיתם את זה):

כשמשתמשים במסוף Google Cloud כדי לגשת לשירותים ולממשקי ה-API, לא צריך להגדיר אימות. Google Cloud

מגבלות

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

    • צריך ליצור את המכונות כמכונות עצמאיות של Compute Engine או כחלק מאשכול Slurm.
    • המכונות הווירטואליות צריכות להיווצר באמצעות קיבולת מוזמנת.
    • במכונות הווירטואליות צריך להשתמש בסדרת המכונות A4X Max,‏ A4X,‏ A4,‏ A3 Ultra או A3 Mega.

  • כדי לעקוב אחרי מדדים של עומסי עבודה של ML, צריך להגדיר מעקב אחרי עומס העבודה.

  • למדדים של זיהוי חריגים יש מגבלות נוספות:

    • עבור סדרות מכונות נתמכות מלבד A3 Mega, זיהוי חריגים תומך רק במופעי מחשוב שמאפשרים לספריית Collective Communication Analyzer ‏ (CoMMA) לייצא טלמטריה של NCCL לשירותי Google Cloud . מידע נוסף מופיע במאמר סקירה כללית על CoMMA.
    • בדרך כלל, זיהוי של משתתף שלא הוזמן נמשך עד 10 דקות.
    • בשונה מהמדדים האחרים במסמך הזה, אי אפשר לסנן את מדדי זיהוי הנתונים החסרים בפרויקטים לפי אשכול, בלוק, בלוק משנה או מופע מחשוב. עם זאת, אפשר לסנן שאילתות ביומני זיהוי של שאילתות שמתעכבות לפי המזהה של מופע מחשוב אחד או יותר שחשודים כשאילתות שמתעכבות.

התפקידים הנדרשים

כדי לקבל את ההרשאות שדרושות בשביל לעקוב אחרי מדדים של עומסי עבודה ב-AI Hypercomputer, אתם צריכים לבקש מהאדמין לתת לכם את התפקידים הבאים ב-IAM:

  • כדי להציג מדדים ב-Cloud Monitoring: עריכת Monitoring (roles/monitoring.editor) בפרויקט
  • כדי לצפות ביומנים של זיהוי משתמשים שאין להם חשבון ב-Google Cloud ב-Logging: מציג היומנים (roles/logging.viewer) בפרויקט

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

התפקידים המוגדרים מראש האלה כוללים את ההרשאות שנדרשות למעקב אחרי מדדים של עומסי עבודה ב-AI Hypercomputer. כדי לראות בדיוק אילו הרשאות נדרשות, אפשר להרחיב את הקטע ההרשאות הנדרשות:

ההרשאות הנדרשות

כדי לעקוב אחרי מדדים של עומסי עבודה (workloads) ב-AI Hypercomputer, נדרשות ההרשאות הבאות:

  • כדי להציג מרכזי בקרה: monitoring.dashboards.get בפרויקט
  • כדי ליצור מרכזי בקרה: monitoring.dashboards.create בפרויקט
  • כדי לראות את רשומות היומן: logging.logEntries.list בפרויקט

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

מדדים זמינים

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

הוראות לצפייה במדדים האלה מפורטות במאמר הצגת מדדים בצורה ויזואלית.

מדדי תשתית

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

Google Cloud מדדים זמינים ב-Compute Engine.

מדדי הבריאות של ה-GPU

כדי לעקוב אחרי תקינות יחידות ה-GPU, משתמשים במדדים הבאים:

שם סוג מדד סדרות מכונות נתמכות תיאור
סטטוס המכונה machine/machine_status ‫A4X Max,‏ A4X,‏ A4,‏ A3 Ultra או A3 Mega האם המכונה שמופע החישוב משתמש בה תקינה, או שהמכונה לא תקינה ונדרש תיקון.
סטטוס NVSwitch instance/gpu/nvswitch_status ‫A4X Max,‏ A4X,‏ A4,‏ A3 Ultra או A3 Mega האם מתג NVLink ב-GPU של NVIDIA שמצורף למופע של Compute נתקל בבעיות.
תקינות התשתית של מכונות וירטואליות instance/gpu/infra_health ‫A4X,‏ A4,‏ A3 Ultra או A3 Mega התקינות של האשכול, הבלוק, הבלוק המשני והמארח שבהם פועלים מופעי המחשוב. אם המדד הזה מראה שהתשתית של מכונת חישוב לא תקינה, המדד גם מתאר את הבעיה.
ציון חיזוי כשל של מכונה וירטואלית instance/gpu/failure_prediction_score ‫A4X,‏ A4,‏ A3 Ultra או A3 Mega הסבירות שהמארח שבו פועל מופע החישוב ייפגע בחמש השעות הבאות. הערך יכול להיות בין 0.0 ל-1.0. ככל שהערך קרוב יותר ל-1.0 לאורך תקופה עקבית, כך גדל הסיכוי שהביצועים של מופע המחשוב ירדו. במקרה כזה, מומלץ להעביר את העבודה למופע מחשוב אחר, ואם נתקלים בבעיות במופע המחשוב, לדווח על המארח שלו כפגום.

מדדי ביצועים של GPU

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

שם סוג מדד סדרות מכונות נתמכות תיאור
שימוש מצטבר בהקשר instance/gpu/accumulated_context_utilization_seconds ‫A4X Max,‏ A4X,‏ A4,‏ A3 Ultra או A3 Mega הזמן הכולל בשניות שבו ה-GPU עסוק בעיבוד עומס עבודה.
צריכת חשמל של GPU instance/gpu/power_consumption ‫A4X Max,‏ A4X,‏ A4,‏ A3 Ultra או A3 Mega ההספק בוואט (W) וערכים עשרוניים שנצרכים במעבדים גרפיים (GPU) בודדים במארח. במקרים של מופעי מחשוב עם כמה מעבדים גרפיים שמחוברים, המדד מספק את צריכת החשמל בנפרד לכל מעבד גרפי במארח.
SM Utilization instance/gpu/sm_utilization ‫A4X Max,‏ A4X,‏ A4,‏ A3 Ultra או A3 Mega ערך שונה מאפס מציין שהמעבדים המרובי-ליבות (SM) במעבדים הגרפיים נמצאים בשימוש פעיל.
טמפרטורת ה-GPU instance/gpu/temperature ‫A4X Max,‏ A4X,‏ A4,‏ A3 Ultra או A3 Mega הטמפרטורה במעלות צלזיוס (℃) ובערכים עשרוניים של יחידות GPU נפרדות במארח. במקרים של מכונות וירטואליות עם כמה יחידות GPU שמחוברות אליהן, המדד מספק את הטמפרטורה בנפרד לכל יחידת GPU במארח.
מרווח תרמי של GPU instance/gpu/tlimit ‫A4X Max,‏ A4X,‏ A4,‏ A3 Ultra או A3 Mega המרחק מהסף התרמי במעלות צלזיוס (℃) ובערכים עשרוניים של כל GPU בנפרד, לפני שהמהירות שלו תרד בגלל טמפרטורה גבוהה. במכונות לחישוב עם כמה GPU שמחוברים אליהן, המדד הזה מספק את המרחק מהסף התרמי בנפרד לכל GPU במארח.

מדדי ביצועים של רשת ה-GPU

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

שם סוג מדד סדרות מכונות נתמכות תיאור
שינויים בקישור לספק instance/gpu/link_carrier_changes ‫A4X,‏ A4,‏ A3 Ultra או A3 Mega התדירות שבה הספק של קישור הרשת משתנה בדקה.
RTT ברשת instance/gpu/network_rtt ‫A4X,‏ A4,‏ A3 Ultra או A3 Mega זמן הלוך ושוב, שנמדד במיקרו-שניות, של נתוני רשת במעבר בין מקור ליעד.
תנועה ברשת בין בלוקים instance/gpu/network/inter_block_tx ‫A4X,‏ A4,‏ A3 Ultra או A3 Mega מספר הבייטים של תעבורת הרשת בין הבלוקים.
תנועה ברשת בין תתי-בלוקים instance/gpu/network/inter_subblock_tx ‫A4X,‏ A4,‏ A3 Ultra או A3 Mega מספר הבייטים של תנועת הרשת בין תתי-הבלוקים.
תנועה ברשת בתוך תת-בלוק instance/gpu/network/intra_subblock_tx ‫A4X,‏ A4,‏ A3 Ultra או A3 Mega מספר הבייטים של תעבורת הרשת בתוך תת-בלוק יחיד.
מהירות פעילה של NVLink instance/gpu/nvlink_active_speed ‫A4X Max,‏ A4X,‏ A4,‏ A3 Ultra או A3 Mega מהירות היציאה הנוכחית של קישור הגישה, ב-GBps.
תפוקה של בייטים שהתקבלו instance/gpu/throughput_rx_bytes ‫A4X,‏ A4,‏ A3 Ultra או A3 Mega מספר הבייטים שהתקבלו מתנועת הרשת.
תפוקה (בייטים של העברה) instance/gpu/throughput_tx_bytes ‫A4X,‏ A4,‏ A3 Ultra או A3 Mega מספר הבייטים שמועברים לתעבורת הרשת.

מדדים של שגיאות קריטיות ב-GPU

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

שם סוג מדד סדרות מכונות נתמכות תיאור
שגיאת זמן ריצה של NVLink instance/gpu/nvlink_runtime_error A4X Max או A4X האם אירעה שגיאת זמן ריצה של NVLink.
שגיאות DRAM ECC שלא ניתן לתקן instance/gpu/dram_uncorrectable_ecc_error_count A4X Max או A4X מספר קודי תיקון השגיאות (ECC) שלא ניתן לתקן בזיכרון גישה אקראית (DRAM) דינמי של GPU.
מספר המיפויים מחדש של שורות בזיכרון DRAM שלא ניתן לתקן instance/gpu/dram_uncorrectable_row_remapping_count A4X Max או A4X מספר המיפויים מחדש של שורות משגיאות שלא ניתן לתקן ב-DRAM של GPU.
מיפוי מחדש של שורת DRAM שלא ניתן לתקן נכשל instance/gpu/dram_row_remapping_failed A4X Max או A4X האם מיפוי מחדש של שורה ב-DRAM של GPU נכשל בגלל אחת מהבעיות הבאות:
  • ניסיון למפות מחדש בנק זיכרון נכשל כי בבנק הזיכרון כבר יש שמונה שורות שגיאה שלא ניתן לתקן שממופות מחדש.
  • ניסיון למפות מחדש שורה נכשל כי השורה כבר מופתה מחדש.
  • ניסיון למיפוי מחדש נכשל כי בוצעו 512 מיפויים מחדש בסך הכול.
שגיאות PCIe שלא ניתן לתקן instance/gpu/pcie_fatal_error_count A4X Max או A4X מספר השגיאות ב-PCIe (‏Peripheral Component Interconnect Express) שלא ניתן לתקן.
שגיאות ECC במטמון שלא ניתן לתקן instance/gpu/cache_uncorrectable_ecc_error_count A4X Max או A4X מספר שגיאות ה-ECC שלא ניתן לתקן בזיכרון המטמון.

מדדים של עומסי עבודה של למידת מכונה

כדי לעקוב אחרי הפרודוקטיביות – ובאופן ספציפי אחרי התפוקה – של עומסי העבודה של ה-ML, משתמשים במדדים הבאים:

שם סוג מדד סדרות מכונות נתמכות תיאור
זמן פרודוקטיבי workload/goodput_time ‫A4X,‏ A4,‏ A3 Ultra או A3 Mega הזמן, בשניות, שבו עומס העבודה מושקע בפעילויות של תפוקה טובה. הפעילויות האלה הן משימות ליבה שימושיות, כמו העברה קדימה או אחורה במהלך אימון המודל.
זמן לא פרודוקטיבי workload/badput_time ‫A4X,‏ A4,‏ A3 Ultra או A3 Mega הזמן, בשניות, שבו עומס העבודה מושקע בפעילויות של badput. הפעילויות האלה הן משימות שדורשות משאבים, כמו טעינה או עיבוד מקדים של נתונים לצורך אימון.

מדדים של זיהוי חריגים

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

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

שם סוג מדד סדרות מכונות נתמכות תיאור
חשד למשתמשים שמתקשים להצטרף instance/gpu/straggler_status ‫A4X,‏ A4,‏ A3 Ultra או A3 Mega האם יש חשד שמכונה וירטואלית היא מכונה לא יעילה שמשפיעה על הביצועים של עומס העבודה. מומלץ לפעול לגבי עומסים שסביר להניח שהם חריגים רק אם מדדים אחרים מצביעים על כך שיש בעיות בעומס העבודה.

אפשר גם לראות את מדדי זיהוי החריגים ברשומות היומן של מופע A4X, ‏ A4,‏ A3 Ultra או A3 Mega. לדוגמה, אפשר להשתמש בשאילתות הבאות:

תיאור שאילתה
יומנים עם נתונים שמעוררים חשד לגבי חריגות ספציפיות במכונות וירטואליות. אפשר להשתמש בשאילתה הזו כדי לבדוק אם יש נתונים שמעוררים חשד לגבי חריגות ספציפיות בעומס עבודה מסוים בפרויקט. 
    logName=~ "/logs/compute.googleapis.com%2Fworkload_diagnostic" AND jsonPayload.suspectedStragglersDetection.numNodes > 0 AND jsonPayload.suspectedStragglersDetection.nodes.instanceId="INSTANCE_ID"

מחליפים את INSTANCE_ID במזהה של מכונה וירטואלית. לכל מכונה וירטואלית נוספת שרוצים לציין, מוסיפים את התנאי הבא לשאילתה:

    OR jsonPayload.suspectedStragglersDetection.nodes.instanceId="INSTANCE_ID"
כל היומנים מזיהוי של תהליכים שמתעכבים בפרויקט. אפשר להשתמש בשאילתה הזו כדי לוודא ששירות זיהוי הנתונים המצטברים פועל כשלא מזוהים נתונים מצטברים חשודים. (בגלל המגבלות, אי אפשר לסנן את היומנים בלי חשד לזומבים לפי מכונות וירטואליות ספציפיות). 
    logName=~ "/logs/compute.googleapis.com%2Fworkload_diagnostic"

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

  • עומסי עבודה של למידת מכונה (ML) בהיקף גדול רגישים מאוד ל-stragglers. עומסי עבודה של ML בהיקף גדול משתמשים במחשוב סינכרוני ומבוזר באופן נרחב. (במילים אחרות, יש להם הרבה רכיבים שתלויים מאוד זה בזה ופועלים בו-זמנית). הארכיטקטורה הזו הופכת את עומסי העבודה של ML בהיקף גדול לרגישים מאוד לכשלים בנקודה אחת, כמו stragglers.

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

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

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

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

הצגת המדדים

כדי לראות את המדדים של מופעי מחשוב ושל אשכולות Slurm, משתמשים בלוחות בקרה של Monitoring באופן הבא:

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

שימוש במרכזי בקרה מוכנים מראש

אתם יכולים להשתמש בלוחות בקרה של Monitoring שנוצרו מראש עבור AI Hypercomputer כדי להציג מדדים של מופעי מחשוב ושל אשכולות Slurm. אתם יכולים גם ליצור עותק של לוח בקרה שנוצר מראש ולשנות אותו כך שיתאים לצרכים שלכם.

כדי להשתמש במרכז בקרה מוכן מראש ל-AI Hypercomputer:

  1. נכנסים לדף  Dashboards במסוף Google Cloud :

    עוברים אל מרכזי בקרה.

    אם משתמשים בסרגל החיפוש כדי למצוא את הדף הזה, בוחרים בתוצאה שבה הכותרת המשנית היא Monitoring.

  2. בעמודה Name (שם), לוחצים על השם של אחת מלוחות הבקרה הבאים, בהתאם למדדים שרוצים לראות:

    • כדי לעקוב אחרי תקינות מופע מחשוב, ביצועי GPU וזיהוי של משימות שמתעכבות, אפשר להשתמש בלוח הבקרה Cluster Director Health Monitoring.

      כדי לקבל מידע נוסף על השימוש במדדים האלה לזיהוי ולניתוח בעיות, אפשר גם להשתמש במרכז הבקרה של מדריך ההפעלה האינטראקטיבי של GCE – מעקב אחרי תקינות של Cluster Director.

    • כדי לעקוב אחרי יעילות השידור ברשת, משתמשים בלוח הבקרה Cluster Director Transmission Efficiency.

    • כדי לעקוב אחרי יעילות הרשת בין בלוקים ותתי-בלוקים, אפשר להשתמש בלוח הבקרה Cluster Director Block Network.

      כדי לקבל מידע נוסף על האופן שבו אפשר להשתמש במדדים האלה כדי לזהות ולנתח בעיות, אפשר גם להשתמש בלוח הבקרה של המדריך האינטראקטיבי של GCE – רשת חסימות של Cluster Director.

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

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

יצירת מרכזי בקרה בהתאמה אישית

כדי ליצור לוח בקרה מותאם אישית של Monitoring:

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

  2. יצירה וניהול של לוחות בקרה בהתאמה אישית.

צפייה ביומני זיהוי של מכשירים שלא מדווחים

כדי להציג את היומנים של זיהוי משתמשים שאין להם חשבון באמצעות Logs Explorer, פועלים לפי השלבים הבאים:

  1. במסוף Google Cloud , נכנסים לדף Logs Explorer:

    כניסה אל Logs Explorer

    אם משתמשים בסרגל החיפוש כדי למצוא את הדף הזה, בוחרים בתוצאה שכותרת המשנה שלה היא Logging.

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

  2. משתמשים בבורר טווח הזמן בסרגל הכלים כדי לבחור את טווח הזמן שרוצים לנתח.

  3. בחלונית Query, מזינים שאילתה לזיהוי יומני רישום של תהליכים שמתעכבים.

  4. לוחצים על Run Query (הפעלת שאילתה).

הדוגמה הבאה מציגה רשומה ביומן של זיהוי חריג.

  {
    ...
    "jsonPayload": {
      ...
      "@type": "type.googleapis.com/ml.aitelemetry.performancedebugging.output.NetworkStragglersOutput",
      "suspectedStragglersDetection": {
        "numNodes": 4,
        "nodes": [
          {
            "latencyMs": 9,
            "instanceId": "INSTANCE_ID_1"
          },
          {
            "latencyMs": 9,
            "instanceId": "INSTANCE_ID_2"
          },
          {
            "instanceId": "INSTANCE_ID_3",
            "latencyMs": 4
          },
          {
            "instanceId": "INSTANCE_ID_4",
            "latencyMs": 0
          }
        ],
        "message": "Suspected stragglers detected."
      }
    },
    "resource": {
      "type": "project",
      "labels": {
        "project_id": "PROJECT_NUMBER"
      }
    },
    ...
    "severity": "INFO",
    "logName": "projects/PROJECT_ID/logs/compute.googleapis.com%2Fworkload_diagnostic",
    ...
  }

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

  • ‫numNodes: מספר מופעי המחשוב החשודים שזוהו בפרויקט. בדוגמה, המערכת זיהתה ארבעה מקרים חשודים של מופעי מחשוב שנותרו ללא שימוש.
  • ‫instanceId: המזהה של מופע Compute שזוהה כחשוד כמשאב לא פעיל.

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