מדריך: ניהול חשבונות ותזמון משימות באשכול

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

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

היעד

בסוף המדריך הזה, תהיה לכם מסגרת לניהול משאבי אשכול שיכולה:

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

דרישות מוקדמות

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

  • Orchestrate

  • הגדרות מתקדמות של Slurm

  • sudo גישה לצומת הכניסה של האשכול כדי להריץ פקודות אדמין.

מושגי ליבה: אבני הבניין של מערכת החשבונאות ב-Slurm

מערכת Slurm משתמשת בהיררכיה ברורה וגמישה לניהול משאבים. חשוב להבין את ארבעת המרכיבים האלה.

רכיב דוגמה מטרה
חשבון צוות או פרויקט היחידה העיקרית לקיבוץ משתמשים ולהגדרת מגבלות כוללות על משאבים (לדוגמה, team_ace יכול להשתמש ב-10 צמתים לכל היותר).
משתמש חוקר/ת פרטי/ת האדם ששולח עבודה. כל משתמש חייב להשתייך לחשבון ברירת מחדל.
Partition תור חומרה קיבוץ לוגי של צמתים. כדי ליהנות מגמישות מקסימלית, מומלץ להשתמש במחיצה אחת שמכילה את כל הצמתים.
QOS ספר חוקים קבוצה של כללים עם שם שמגדירה מגבלות על עבודות (לדוגמה, "עבודות ב-QoS הזה יכולות להשתמש רק ב-2 צמתים") ועדיפות בתזמון.

במודל הזה, אפשר להגדיר מכסה ברמה גבוהה לכל החשבון ולהחיל מגבלה מפורטת יותר, לכל עבודה, באמצעות QOS.

הפרסונות: אדמין לעומת חוקר

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

אדמין של אשכול

  • כלי ראשי: sacctmgr (Slurm account manager)
  • התפקיד שלכם: לבנות את ה "פיגומים" של חשבונות, משתמשים וכללי QoS. בדרך כלל מדובר במשימה שצריך להגדיר אותה פעם אחת ולעדכן אותה לפי הצורך.
  • משימות עיקריות: יצירת חשבונות, הקצאת משתמשים לחשבונות, הגדרת כללי QOS וקישור ביניהם.

חוקר/ת

  • כלים עיקריים: sbatch, squeue, sinfo
  • התפקיד שלהם: לשלוח את עבודות המחקר ולעקוב אחריהן.
  • הקסם: כשחוקר שולח עבודה, Slurm בודק באופן אוטומטי את הכללים שמשויכים לחשבון שלו ול-QoS. אם העבודה חורגת ממגבלה כלשהי, Slurm דוחה אותה ומציג הודעת שגיאה ברורה.

המדריך: הדרכה מפורטת

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

חלק 1: הגדרה ראשונית (ללא מגבלות)

יוצרים את החשבון ומקשרים אליו את המשתמש.

  • המטרה: ליצור את ההיררכיה הבסיסית בשביל team_ace ו-user_alice.
  • השיטה: משתמשים ב-sacctmgr כדי להוסיף חשבון, ואז מוסיפים משתמש שמשויך לחשבון הזה.
# --- (Run as Admin) ---

# 1. Create the 'team_ace' account
sudo sacctmgr add account team_ace Description="The Ace Team"

# 2. Create the 'user_alice' user and map them to their default account
# (Note: 'user_alice' must already exist as a Linux user on the node)
sudo sacctmgr add user user_alice Account=team_ace

# 3. Show the hierarchy we just built to confirm
sacctmgr show associations where account=team_ace

תוצאה: בתור המשתמש user_alice, עכשיו אפשר לשלוח עבודה גדולה. מכיוון שאין מגבלות, עבודה עם 7 צמתים מתקבלת ומופעלת באופן מיידי (בהנחה ש-7 צמתים לא פעילים).

חלק 2: הוספת מגבלות ברמת הקבוצה לחשבון

לאחר מכן, מגדירים מכסת משאבים לחשבון team_ace, ומגבילים את כל הצוות למקסימום של 6 צמתים ו-4 משימות בסך הכול.

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

  • השיטה: אנחנו מגבילים את מספר המשאבים שניתן להוסיף לחשבון באמצעות team_ace GrpJobs (Group Jobs) ו-GrpTRES (Group Trackable Resources, במקרה הזה, node=6).

# --- (Run as Admin) ---

# 1. Add group-level job and node limits to the 'team_ace' account
sudo sacctmgr modify account where name=team_ace set GrpJobs=4 GrpTRES=node=6

# 2. View the limits to confirm the change
sacctmgr show association where account=team_ace

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

  1. מגבלת הצמתים: שליחת משימה עם 7 צמתים נכשלת עכשיו. המשימה מועברת למצב 'בהמתנה' (PD) עם הסיבה (AssocGrpNodeLimit).
  2. מגבלת משימות: שליחה של 5 משימות עם צומת יחיד תגרום להרצה של 4 משימות (R) ולמשימה החמישית להיות בהמתנה (PD) עם הסיבה (AssocGrpJobsLimit).

המגבלות ברמת החשבון פועלות בצורה מושלמת.

חלק 3: הוספת מגבלה לכל משימה באמצעות QOS

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

  • המטרה: להגביל את הגודל המקסימלי של כל משימה בנפרד שהצוות שולח.
  • השיטה: ניצור איכות שירות (QoS) בשם qos1 עם כלל MaxTRESPerJob=node=2. לאחר מכן נגדיר את זה כ-QoS ברירת המחדל לכל team_ace החשבון.
# --- (Run as Admin) ---

# 1. Create a QOS with a per-job limit of 2 nodes
sudo sacctmgr add qos qos1 MaxTRESPerJob=node=2

# 2. Allow the 'team_ace' account to use this QOS
sudo sacctmgr modify account where account=team_ace set QOS=qos1

# 3. Set 'qos1' as the DEFAULT QOS for all users in this account
sudo sacctmgr modify account where account=team_ace set DefaultQOS=qos1

תוצאה: עכשיו, אם user_alice שולח עבודה עם 3 צמתים, העבודה מועברת למצב 'בהמתנה' עם הסיבה (QOSMaxNodePerJobLimit). המשתמש עדיין נמצא במסגרת מכסת החשבון הכוללת (6 צמתים), אבל הוא הפר את כלל QOS לכל עבודה.

חלק 4: הוספת שינוי שספציפי למשתמש

מה קורה אם user_alice הוא מתמחה וצריך להגביל אותו לעבודות קטנות יותר, בלי להשפיע על שאר הצוות?

  • המטרה: להחיל מגבלה מחמירה יותר על משתמש יחיד.
  • השיטה: ניצור QOS חדש ומגביל יותר (qos_intern) ונחיל אותו כברירת מחדל ספציפית ל-user_alice. כך נשנה את ברירת המחדל של ה-QOS בחשבון.

# --- (Run as Admin) ---

# 1. Create a more restrictive QOS with a 1-node limit
sudo sacctmgr add qos qos_intern MaxTRESPerJob=node=1

# 2. Allow the account to use this new QOS
sudo sacctmgr modify account where account=team_ace set QOS+=qos_intern

# 3. Apply 'qos_intern' as the default QOS for the specific user association
sudo sacctmgr modify user where name=user_alice account=team_ace set DefaultQOS=qos_intern

התוצאה: אם user_alice ינסה לשלוח את העבודה עם 2 הצמתים שאושרה קודם במסגרת qos1, הפעולה תיכשל עם (QOSMaxNodePerJobLimit). הכלל הספציפי יותר ברמת המשתמש ביטל בהצלחה את הכלל הכללי ברמת החשבון.

חלק 5: הגדרת עדיפות וקדימות

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

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

    1. יוצרים qos_urgent חדש עם ערך Priority גבוה.
    2. אומרים ל-qos_urgent שמותר לו Preempt משימות שפועלות ב-qos1.
    3. מגדירים את qos1 לREQUEUE את המשימות שלו כשהן נדחקות.

# --- (Run as Admin) ---

# 1. Create a new 'qos_urgent' with a high priority that can preempt 'qos1'
sudo sacctmgr add qos qos_urgent Priority=1000 Preempt=qos1

# 2. Configure 'qos1' to requeue preempted jobs after a 10-second grace period
sudo sacctmgr modify qos where name=qos1 set PreemptMode=REQUEUE GraceTime=10

# 3. Allow the 'team_ace' account and 'user_alice' to use this new QOS
sudo sacctmgr modify account where account=team_ace set QOS+=qos_urgent
sudo sacctmgr modify user where name=user_alice account=team_ace set QOS+=qos_urgent

# 4. For this scenario, remove the group limits so preemption is easier to trigger
sudo sacctmgr modify account where name=team_ace set GrpJobs=-1 GrpTRES=node=-1

תוצאה:

  1. בטרמינל אחד, הפקודה user_alice שולחת עבודה ממושכת עם ברירת המחדל qos1. העבודה מתחילה לפעול (R).
  2. בטרמינל השני, user_alice שולח עבודה גדולה באמצעות ה-QOS הדחוף (sbatch --qos=qos_urgent ...).
  3. תוך שניות, המצב של העבודה הראשונה משתנה מ'פועלת' (R) ל'בהמתנה' (PD) עם הסיבה (Preempted). לאחר מכן, העבודה הדחופה מתחילה לפעול.

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

סיכום והשלבים הבאים

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

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

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