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

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

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

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

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

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

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

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

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

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

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

  3. ‫Running (RUNNING): המשאבים של המשימה נוצרו בהצלחה ואפשר להתחיל להריץ את המשימות שלה.

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

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

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

      • ‫Succeeded (SUCCEEDED): המשימה הצליחה כי כל אחד מהאובייקטים שאפשר להריץ עמד באחד מהתנאים הבאים:

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

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

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

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

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

למידע נוסף, קראו את מאמרי העזרה בנושא מצבי משימות ומצבי משימות.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ביצוע משימה

הזמן שלוקח להריץ משימה יכול להשתנות בהתאם לתזמון המשימה ולמשאבים שלה.

תזמון משימות

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

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

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

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

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

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

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

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

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

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

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

  • ‫\({vmsPerJob}\): המספר המקסימלי של מכונות וירטואליות למשימה. יכול להיות שמספר המכונות הווירטואליות שנוצרו בפועל למשימה יהיה קטן יותר. לדוגמה, אם ב-Batch צפוי שהרצת משימה עם פחות משאבים תהיה מהירה יותר מאשר המתנה למשאבים נוספים. הערך הזה מוגבל גם על ידי המגבלות על מספר המכונות הווירטואליות בו-זמנית לכל משימה.
  • ‫\({taskCount}\): המספר הכולל של המשימות במשימה, שאתם מגדירים באמצעות השדה task count (taskCount).

  • ‫\({parallelTasksPerVM}\): המספר המקסימלי של משימות שאפשר להריץ בו-זמנית במכונה וירטואלית.

    הערך הזה נקבע לפי כל הקריטריונים הבאים:

    • הערך המינימלי הוא משימה אחת.

    • הערך המקסימלי הוא הערך הקטן מבין 20 משימות, ואם הוא מוגדר, הערך של השדה max parallel tasks per job (parallelism).

    • אם מוגדר השדה maximum parallel tasks per VM (taskCountPerNode), המערכת משתמשת בערך הזה.

      אחרת, אם לא מגדירים את taskCountPerNode, Batch מחלקת את המספר הכולל של משאבי המחשוב (במיוחד vCPU) לכל VM בכמות שנדרשת לכל משימה:

      \[{parallelTasksPerVm}=\frac{vcpusPerVm}{vcpusPerTask}\]

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

      • ‫\({vcpusPerVm}\): המספר הכולל של מעבדי ה-vCPU לכל מכונה וירטואלית, שנקבע לפי סוג המכונה של המכונות הווירטואליות של המשימה.

      • ‫\({vcpusPerTask}\): מספר ה-vCPUs לכל משימה, שנקבע על ידי המרת היחידות של השדה vCPUs per task (cpuMilli).

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

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

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

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

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

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

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

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

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

      • במאמר שימוש ביחידות TPU למשימה מוסבר איך להגדיר משימה שמשתמשת ביחידת Tensor Processing Unit‏ (TPU) אחת או יותר. תרחישים נפוצים לשימוש במשימות שמשתמשות ב-TPU כוללים עומסי עבודה של הסקת מסקנות, הערכה, כוונון ואימון של בינה מלאכותית (AI) ולמידת מכונה (ML).

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

      • סקירה כללית על סביבת מערכת ההפעלה של ה-VM: מתי ואיך אפשר להתאים אישית את סביבת מערכת ההפעלה של ה-VM בשביל משימה, כולל קובץ האימג' של מערכת ההפעלה ודיסקי האתחול של ה-VM.

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

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

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

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

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

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

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

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

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

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

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