סקירה כללית על יצירה והפעלה של משימות

במסמך הזה מוסבר על תהליך ההפעלה ועל אפשרויות היצירה של משימות. משימות באצווה מאפשרות להריץ עומסי עבודה של עיבוד באצווה ב-Google Cloud. כדי לקבל מידע על הרכיבים של משימה ועל הדרישות המוקדמות לשימוש ב-Batch, אפשר לעיין במאמר תחילת העבודה עם Batch.

איך יוצרים ומריצים משימות

כדי להשתמש ב-Batch, יוצרים משימה שמציינת את עומס העבודה והדרישות שלו, ואז Batch מריץ אותה באופן אוטומטי.

בקטעים הבאים מוסבר איך יצירה והרצה של משימות מתבצעות:

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

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

לכל עומס עבודה שרוצים להריץ ב-Batch, מבצעים את התהליך הבסיסי הבא:

  1. יצירת עבודה: מגדירים את עומס העבודה שרוצים להריץ על ידי ציון הפריטים שניתנים להרצה, המשימות וכל דרישה אחרת של העבודה. פרטים על יצירת משרה מופיעים בקטע אפשרויות ליצירת משרה במסמך הזה.
  2. מעקב אחר העבודה ופתרון בעיות: כשמסיימים ליצור עבודה, היא מתווספת אוטומטית לתור, מתוזמנת ומתבצעת במשאבים שצוינו. אתם יכולים לראות את הפרטים של עבודה שנוצרה או של כל אחת מהמשימות שלה כדי לראות את המצב הנוכחי. במקרה הצורך, אפשר לבטל עבודה כדי להפסיק אותה או כדי למנוע את ההפעלה שלה. אחרי שהעבודה פועלת או מסתיימת, אפשר גם לעקוב אחרי העבודה ולנתח אותה באמצעות יומנים. אם משימה נכשלת, אפשר לפתור את הבעיה באמצעות הודעות שגיאה, אירועי סטטוס או יומנים, לפני שיוצרים מחדש את המשימה.
  3. מחיקה או ייצוא של העבודה: פרטי העבודה ב-Batch נשארים זמינים עד שאתם או Google Cloud מוחקים אותם.Google Cloud מחיקה אוטומטית של עבודה מתבצעת 60 יום אחרי שהיא מסתיימת. לפני כן, אתם יכולים למחוק את המשימה בעצמכם, או לייצא את פרטי המשימה ב-Batch לפני שהיא תימחק, אם אתם צריכים לשמור את המידע. כשמוחקים משרה, זה לא משפיע על מידע שקשור למשרה ומאוחסן בשירותים אחרים של Google Cloud Google, כי לכל שירות יש מדיניות שמירת נתונים משלו. לדוגמה, היומנים של משימה נשמרים ונמחקים באופן אוטומטי בהתאם למדיניות השמירה של Cloud Logging.

אחרי שיוצרים משימה, היא עוברת בין המצבים הבאים:

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

  3. פועל (RUNNING): המשאבים של העבודה נוצרו בהצלחה והמשימות שלה יכולות להתחיל לפעול.

    כשמשימה פועלת, כל אחת מהמשימות שלה עוברת את השלבים הבאים:

    1. בהמתנה (PENDING): המשימה ממתינה להרצה במכונה וירטואלית.
    2. הוקצה (ASSIGNED): למשימה הוקצה מכונה וירטואלית להרצה.
    3. פועלת (RUNNING): המשימה פועלת במכונה וירטואלית.

    4. משימה מסתיימת באחד מהסטטוסים הבאים:

      • הושלם בהצלחה (SUCCEEDED): המשימה הושלמה בהצלחה כי כל אחד מהרכיבים שלה עמד באחד מהתנאים הבאים:

        • קובץ ההפעלה הצליח (הוחזר קוד יציאה של אפס).
        • הפעולה נכשלה (הוחזר קוד יציאה שאינו אפס), אבל היא הייתה פעולה לא קריטית (הפעלתם את השדה ignoreExitStatus של הפעולה).
        • הקובץ הניתן להרצה לא הסתיים, אבל הוא היה קובץ ניתן להרצה ברקע (הפעלתם את השדה background של הקובץ הניתן להרצה).

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

    המשאבים של העבודה נמחקים לפני שהעבודה מסתיימת.

  4. עבודה מסתיימת באחד מהסטטוסים הבאים:

    • הושלם בהצלחה (SUCCEEDED): העבודה הושלמה בהצלחה כי כל המשימות שלה הושלמו בהצלחה.
    • נכשל (FAILED): העבודה נכשלה והפעולה שלה הופסקה כי לפחות אחת מהמשימות שלה נכשלה.
    • בוטלה (CANCELLED): משתמש ביטל את העבודה לפני שהיא הסתיימה בהצלחה או נכשלה.

מידע נוסף מופיע במאמרי העזרה בנושא מצבי עבודה ומצבי משימה.

הוספה לתור ותזמון של משימות

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

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

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

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

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

    אפשר גם לציין את העדיפות של עבודה באמצעות הדגל --priority ב-ה-CLI של gcloud או השדה priority ב-JSON. אפשר להגדיר את העדיפות של עבודה כמספר בין 0 (העדיפות הנמוכה ביותר) לבין 99 (העדיפות הגבוהה ביותר). הגדרת עדיפות גבוהה יותר יכולה לעזור להריץ משימה מוקדם יותר ממשימות בעדיפות נמוכה יותר בפרויקט.

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

  • זמינות משאבי המשימה: הזמינות של המשאבים הנדרשים למשימה במיקומים המותרים.

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

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

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

  • מכסות ומגבלות: ערכי הסף שנקבעו בפרויקט שלכם למשאבים ולבקשות של Google Cloud .

    אי אפשר להריץ ג'וב אם הוא חורג ממגבלה או מהמכסה של הפרויקט עבור אחד מהמשאבים או הבקשות הנדרשים. במקרים כאלה, יכול להיות ש-Batch יעכב את העבודה וינסה שוב מאוחר יותר, או שהעבודה תיכשל ותוצג שגיאה שקשורה לכך.

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

ביצוע של משימה

משך הזמן שנדרש להרצת משימה יכול להשתנות בהתאם לתזמון המשימה ולמשאבים שלה.

תזמון משימות

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

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

משאבים למשרות

כל משימת Batch פועלת בקבוצה אזורית של מופעי מכונה מנוהלים (MIG), שהיא קבוצה של מופע אחד או יותר של מכונות וירטואליות (VM) תואמות של Compute Engine, שכל אחת מהן ממוקמת באחד מהתחומים הכלולים. לכל מכונה וירטואלית יש חומרה ייעודית לליבות של מעבד (במיוחד מעבדים וירטואליים (vCPU)) ולזיכרון – שמשפיעים על הביצועים של העבודה – ודיסק הפעלה – שבו מאוחסן קובץ אימג' של מערכת הפעלה (OS) והוראות להרצת העבודה.

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

  • משאבי מחשוב לכל משימה: אלא אם ערכי ברירת המחדל מספיקים, אתם צריכים לציין את משאבי המחשוב – vCPU, זיכרון ואחסון נוסף בדיסק האתחול (אם נדרש) – שנדרשים להפעלת כל משימה. מידע נוסף מופיע במאמר בנושא שדות של משאבי מחשוב לכל משימה (computeResource).

  • משאבי מכונות וירטואליות: אפשר גם לציין את המכונות הווירטואליות של העבודה – כמו סוג המכונה ומערכת ההפעלה, ומשאבים נוספים כמו יחידות GPU ונפחי אחסון – בעיקר באמצעות השדות של מדיניות משאבי המכונות הווירטואליות (instances[].policy) או השדה החלופי instances[].instanceTemplate. (אופציונלי, אפשר גם להשתמש בשדות instanceFlexibilityPolicy אם רוצים לאפשר כמה סוגי מכונות למשימה).

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

מספר המכונות הווירטואליות ומספר המשימות שאפשר להריץ בו-זמנית בכל מכונה וירטואלית משתנים בין עבודות שונות, בהתאם לתזמון המשימות ולדרישות החומרה שצוינו. אם מציינים שמשימות של ג'וב יפעלו IN_ORDER, לג'וב תהיה מכונה וירטואלית אחת והוא יריץ רק משימה אחת בכל פעם. אחרת, אם המשימות של העבודה מופעלות AS_SOON_AS_POSSIBLE, אפשר להעריך את מספר המכונות הווירטואליות ואת מספר המשימות שמופעלות בו-זמנית באמצעות הנוסחה הבאה:

\[{vmsPerJob}=\frac{taskCount}{parallelTasksPerVm}\]

הנוסחה הזו כוללת את הערכים הבאים:

אפשרויות ליצירת משימות

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

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

  • כדי לשלוט בגישה למשרה:

  • הגדרת אפשרויות נוספות למשימה:

    • במאמר הזה מוסבר איך להגדיר תקשורת בין משימות באמצעות ספריית MPI מוסבר איך להגדיר עבודה עם משימות שתלויות זו בזו ומתקשרות ביניהן במכונות וירטואליות שונות באמצעות ספריית Message Passing Interface‏ (MPI). תרחיש נפוץ לשימוש ב-MPI הוא עומסי עבודה של מחשוב עתיר ביצועים (HPC) עם צימוד הדוק.

    • התאמה אישית של המשאבים שבהם מופעלת עבודה:

      • במאמר הגדרת משאבי משימה באמצעות תבנית של הגדרות מכונה מוסבר איך לציין תבנית של הגדרות מכונה ב-Compute Engine כדי להגדיר את משאבי המשימה כשיוצרים משימה. זוהי חלופה לציון משאבים של משימה ישירות באמצעות השדה instances[].policy.

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

      • במאמר שימוש בנפחי אחסון לעבודה מוסבר איך להגדיר עבודה שיכולה לגשת לנפח אחסון חיצוני אחד או יותר. אפשרויות האחסון כוללות דיסקים קשיחים חדשים או קיימים, כונני SSD מקומיים חדשים, קטגוריות קיימות של Cloud Storage ומערכת קבצים קיימת ברשת (NFS), כמו שיתוף קבצים ב-Filestore.

      • סקירה כללית של סביבת מערכת ההפעלה של מכונה וירטואלית כוללת סקירה כללית של מתי ואיך אפשר להתאים אישית את סביבת מערכת ההפעלה (OS) של מכונה וירטואלית עבור משימה, כולל תמונת מערכת ההפעלה של המכונה הווירטואלית ודיסקי האתחול של המשימה.

    • אופטימיזציה של היבטים שונים של משרה:

      • שיפור המעקב והניתוח:

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

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

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

      • שיפור הזמינות של המשאבים:

      • הפחתת זמן האחזור:

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

        • במאמר שימוש בסטרימינג של תמונות מוסבר איך לשפר את זמן ההפעלה של משימות על ידי סטרימינג של תמונות של מאגרי תגים מ-Artifact Registry.

  • שימוש בשירותים נוספים כדי ליצור ולהפעיל משימות:

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