פתרון בעיות שקשורות לזמינות של משאבים

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

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

הסבר על שגיאות שקשורות לזמינות של משאבים

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

  • מאיצים (אם יש)

  • ליבות מעבד (CPU)

  • דיסקים

  • זיכרון

לדוגמה, נניח שאתם רוצים ליצור מכונה מסוג a2-highgpu-2g עם שני דיסקים מסוג Local SSD. סוג המכונה הזה כולל 24 vCPUs במעבד Intel Xeon Platinum 8273CL, זיכרון בנפח 170GB ושני מעבדי NVIDIA A100 GPU. אם כל המשאבים האלה זמינים באזור שציינתם בזמן הבקשה, הבקשה תצליח. אחרת, הבקשה תיכשל ותופיע שגיאה לגבי זמינות המשאבים.

כשמתרחשת שגיאה שקשורה לזמינות המשאבים, Compute Engine מחזיר הודעת שגיאה שדומה לאחת מההודעות הבאות במסוף Google Cloud , ב-Google Cloud CLI או בתגובה מה-API:

ZONE_RESOURCE_POOL_EXHAUSTED

ZONE_RESOURCE_POOL_EXHAUSTED_WITH_DETAILS

REGION_RESOURCE_POOL_EXHAUSTED_WITH_DETAILS

POOL_CAPACITY_INSUFFICIENT

The zone 'projects/PROJECT_ID/zones/ZONE' does not have
enough resources available to fulfill the request. Try a different zone, or try
again later.

A VM_TYPE_AND_SIZE VM instance with RESOURCE_ATTACHMENT is
currently unavailable in the ZONE zone.

Capacity changes frequently, so try your request in a different zone, with a
different VM hardware configuration, or at a later time. For more options, see
troubleshooting documentation.

A VM_TYPE_AND_SIZE VM instance with RESOURCE_ATTACHMENT is
currently unavailable in the ZONE zone because of REASON.

Consider trying your request in the AVAILABLE_ZONES zones, which
currently has capacity to accommodate your request.

If you cannot move your VM to AVAILABLE_ZONES, review the
instructions to resolve the REASON failure that are available in
troubleshooting documentation, then try your request again. If your workload
can't accommodate the suggested resolution, try your request with a different VM
hardware configuration or at a later time.

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

  • במכונות עצמאיות, במכונות שנוצרו בכמות גדולה, בצמתים של דייר יחיד או בהזמנות, Compute Engine מחזיר את הודעות השגיאה האלה במסוף Google Cloud , ב-CLI של gcloud או בתגובה מה-API.

  • בקבוצות של מופעי מכונה מנוהלים (MIG), השגיאות האלה נרשמות ביומן של Compute Engine ברשימת השגיאות של המופעים ב-MIG. כדי לראות את הודעת השגיאה ואת מגבלת החומרה שגרמה לשגיאה, עיינו במאמר הצגת רשימה של שגיאות במכונות.

פתרון שגיאות שקשורות לזמינות של משאבים

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

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

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

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

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

אם נתקלתם בשגיאות שקשורות לזמינות של משאבים כשניסיתם ליצור אשכול של Google Kubernetes Engine ‏(GKE) או לשנות את הגודל שלו באופן אוטומטי, קראו את המאמר פתרון בעיות ביצירת אשכולות.

פתרון שגיאות לפי סיבות לשגיאות

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

במסוף Google Cloud , ב-CLI של gcloud או ב-Cloud Logging, שורש הבעיה מופיע בהודעת השגיאה של הפעולה:

ERROR: (gcloud.compute.instances.create) Could not fetch resource:
 - A n1-standard-1 VM instance with 2 local SSD(s) is currently unavailable in the us-central1-a zone, because of cpu_availability,local_ssd_availability root cause(s). Consider trying your request in the us-central1-b, us-central1-c zone(s), which currently has capacity to accommodate your request.

ב-API בארכיטקטורת REST, פרטי השגיאה מופיעים במערך error.errors[] של הפעולה, וסיבות השורש מוחזרות ב-LocalizedMessage ובפרט google.rpc.ErrorInfo (domain: "compute.googleapis.com"):

{
  "code": "ZONE_RESOURCE_POOL_EXHAUSTED_WITH_DETAILS",
  "message": "A n1-standard-1 VM instance with 2 local SSD(s) is currently unavailable in the us-central1-a zone, because of cpu_availability,local_ssd_availability root cause(s). Consider trying your request in the us-central1-b, us-central1-c zone(s), which currently has capacity to accommodate your request.",
  "errorDetails": [
    {
      "errorInfo": {
        "domain": "compute.googleapis.com",
        "reason": "cpu_availability,local_ssd_availability",
        "metadata": {
          "vmType": "n1-standard-1",
          "zone": "us-central1-a",
          "attachment": "local-ssd:2",
          "zonesAvailable": "us-central1-b,us-central1-c"
        }
      }
    }
  ]
}

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

  • ‫ZONE_RESOURCE_POOL_EXHAUSTED_WITH_DETAILS: המערכת של Compute Engine מזהה את שורש הבעיה שמונעת את מילוי הבקשה באזור היעד. אם באזורים אחרים באותו מחוז יש קיבולת לבקשה שלכם, פרטי השגיאה כוללים גם רשימה של אזורים מומלצים (AVAILABLE_ZONES בהודעה או zonesAvailable במטא-נתונים של ErrorInfo ב-API). אם בפרטי השגיאה מופיעה רשימה של אזורים מומלצים, צריך ליצור, להעביר או לשריין את המכונות באחד מהאזורים האלה. אם אין קיבולת באזורים אחרים באותו אזור, הודעת השגיאה לא תכלול אזורים חלופיים.

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

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

  • ACCELERATOR_INTERCONNECT_CONFIG_FAILED: ‏Compute Engine לא הצליח להגדיר את טופולוגיית הקישוריות במהירות גבוהה שנדרשת לפרוסת המאיץ, כמו פרוסת TPU או פרוסת GPU עם כמה צמתים. צריך לחכות כמה דקות ולנסות שוב. אם הבעיה נמשכת, פנו לצוות ניהול החשבון או לתמיכה.

אם הבקשה נתקלת באילוצים בכמה משאבים פיזיים בו-זמנית, Compute Engine מחזיר רשימה מופרדת בפסיקים של קודי reason, כמו "reason": "gpu_availability,local_ssd_availability". אם תגובת השגיאה כוללת סיבה אחת או יותר לאילוץ, עיינו בשלבים הבאים לפתרון בעיות לכל אילוץ משאבים רלוונטי:

configuration_availability

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

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

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

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

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

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

cpu_availability

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

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

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

  • ביטול ההגבלות על פלטפורמת ה-CPU: אם הבקשה מציינת פלטפורמת CPU מינימלית (minCpuPlatform), צריך להגדיר את הערך ל-AUTOMATIC. כשאתם דורשים פלטפורמת מעבד ספציפית, Compute Engine לא יכול להציב את המכונה בפלטפורמות מעבד אחרות שסדרת המכונות שלכם תומכת בהן באותו אזור.

  • מעבר לסדרת מכונות אחרת: אם באזור היעד אין מספיק קיבולת לסדרת מכונות ספציפית, נסו סדרת מכונות או דור אחרים שתומכים בעומס העבודה שלכם, כמו N2,‏ N2D או N4. בסדרות שונות של מכונות נעשה שימוש בפלטפורמות שונות של מעבדים ובשרתים פיזיים שונים. סדרות מכונות מדורות מתקדמים יותר מציעות גם ביצועים גבוהים יותר לכל vCPU, מה שמאפשר להריץ את עומס העבודה עם פחות vCPU.

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

  • חלוקת דרישות המחשוב בין סוגי מכונות קטנים יותר: אם האפליקציה תומכת בארכיטקטורה מבוזרת, חלקו את טביעת הרגל של המחשוב בין סוגי מכונות קטנים יותר באותה משפחת מכונות. לדוגמה, אם אתם לא יכולים ליצור 80 מכונות באמצעות סוגי המכונות n2-standard-96 (עם 96 מעבדי vCPU לכל אחת), נסו ליצור 160 מכונות באמצעות סוגי המכונות n2-standard-48 (עם 48 מעבדי vCPU לכל אחת).

gpu_availability

שגיאת gpu_availability מציינת שבאזור אין מספיק קיבולת למודל ה-GPU שביקשתם.

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

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

  • שימוש במודל הקצאה חלופי: אם אתם לא מצליחים ליצור מכונות GPU באמצעות מודל ההקצאה הרגיל, נסו לבקש משאבים באמצעות מודל ההקצאה "התחלה גמישה", "ספוט" או "מבוסס-הזמנה". מודלים שונים של הקצאת משאבים מבוססים על מאגרי קיבולת נפרדים. למידע נוסף, קראו על מודלים של הקצאת מכונות ב-Compute Engine.

local_ssd_availability

השגיאה local_ssd_availability מציינת שבאזור אין מספיק קיבולת למספר או לסוגים של דיסקי ה-SSD המקומיים שביקשתם.

אם עומס העבודה שלכם תומך באחסון מתמיד, כדאי לעבור מדיסקים מסוג Local SSD לנפחים מסוג Hyperdisk Extreme,‏ Hyperdisk Balanced או דיסק מתמיד שמבוסס על SSD. במאמר אפשרויות אחסון זמני לעומת אחסון עמיד מוסבר על הפשרות בין ביצועים לעמידות.

memory_availability

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

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

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

  • חלוקת דרישות המחשוב בין סוגי מכונות קטנים יותר: אם האפליקציה תומכת בארכיטקטורת זיכרון מבוזרת, חלקו את הזיכרון שבשימוש בין כמה מכונות קטנות יותר. לדוגמה, אם אתם לא יכולים ליצור מכונה עם זיכרון בנפח 1.88TB (כמו m1-ultramem-80), אתם יכולים לחלק את עומס העבודה בין כמה מכונות קטנות יותר, שיספקו את קיבולת הזיכרון המשולבת הזו.

resource_availability

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

  • צריך לציין אזור חלופי.

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

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

  • אם השגיאה הזו מופיעה כשמבקשים מכונה מסוג a3-highgpu-1g,‏ a3-highgpu-2g או a3-highgpu-4g, צריך לוודא שהקצאת המכונה מתבצעת באמצעות אחת משיטות הפריסה הנתמכות.

פתרון שגיאות נפוצות

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

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

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

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

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

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

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

פתרון שגיאות שמופיעות כשיוצרים מכונות Compute עצמאיות

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

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

    • גמישות במיקום: אתם יכולים ליצור מכונות באזור במקום בתחום אחד. כך Compute Engine יכול להפיץ מכונות בין אזורים שיש בהם חומרה זמינה.

    • הוספת גמישות לסוג המכונה: אתם יכולים לציין כמה סוגי מכונות חלופיים במדיניות הגמישות של המכונות. כך Compute Engine יכול לבחור סוג מכונה אחר מהרשימה אם הבחירה הראשית לא זמינה.

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

  • יצירת סוגי מכונות בהתאמה אישית: סוגי מכונות בהתאמה אישית משתמשים באותם שרתים פיזיים כמו מכונות עם קונפיגורציה מוגדרת (predefined) באותה סדרת מכונות, ואין להם מאגר קיבולת נפרד. כדי להתאים לשרתים פיזיים עם קיבולת מוגבלת, צריך לבקש פחות מעבדי vCPU מאשר מכונה עם קונפיגורציה מוגדרת (predefined) גדולה יותר (לדוגמה, לבקש סוג מכונה בהתאמה אישית עם 20 מעבדי vCPU במקום n2-standard-32). בסדרות של מכונות עם אופטימיזציה למאיצים (כמו G2), סוגי מכונות בהתאמה אישית עדיין דורשים מעבדי GPU פיזיים ולא יכולים לפתור מחסור במעבדי GPU. איך יוצרים מכונה וירטואלית עם סוג מכונה בהתאמה אישית

  • שינוי סוגי האחסון: אם סוג המכונה תומך באפשרויות אחסון חלופיות, אתם יכולים לעבור בין Google Cloud Hyperdisk לבין Persistent Disk. ‫SSD Persistent Disk ו-Balanced Persistent Disk חולקים את אותו מאגר אחסון פיזי. אם לסוג דיסק אחד אין קיבולת באזור מסוים, ברוב המקרים גם סוג הדיסק השני לא יהיה זמין. אם אין מספיק נפח אחסון ב-Persistent Disk, צריך לוודא שיש לפרויקט מספיק מכסה ל-Hyperdisk, ולעבור לסוג מכונה שתומך בנפחי Hyperdisk. כדי לבדוק אילו סדרות מכונות תומכות גם בנפחי Persistent Disk וגם בנפחי Hyperdisk, קראו את המאמר השוואה בין סדרות מכונות.

פתרון שגיאות כשיוצרים מכונות בכמות גדולה

כשיוצרים מכונות בכמות גדולה (bulkInsert), המערכת של Compute Engine בודקת את הקיבולת מראש בלי להכניס את הבקשה לתור או לנסות שוב. כברירת מחדל, המספר המינימלי (minCount) שווה למספר הכולל שביקשתם (count). לכן, אם Compute Engine לא יכול ליצור את כל המכונות שביקשתם בזמן הבקשה, הבקשה נכשלת ולא נוצרות מכונות.

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

  • ‫Accept partial capacity (minCount): אם עומס העבודה יכול להתחיל עם פחות מכונות מהמספר הכולל שביקשתם, הגדירו ערך נמוך יותר בשדה minCount. ההגדרה הזו מאפשרת לבקשה להצליח כל עוד Compute Engine יכול להקצות לפחות את המספר המינימלי של מכונות.

  • יצירת מכונות באזור: אם יוצרים מכונות בכמות גדולה בתחום ספציפי, הבקשה נכשלת כשאין מספיק קיבולת בתחום הזה. במקום זאת, כדאי לטרגט אזור כדי ש-Compute Engine יבחר אזורים שיש בהם חומרה זמינה. כברירת מחדל, ביצירה בכמות גדולה ברמה האזורית נעשה שימוש בתבנית חלוקת היעד ANY_SINGLE_ZONE, שבה כל המכונות ממוקמות באזור אחד שיש בו קיבולת. אם אין אזור אחד שיכול להכיל את כל המכונות שלכם, והמכונות יכולות להתפרס על פני כמה אזורים, הגדירו את צורת ההפצה ל-BALANCED או ל-ANY. להוראות, ראו יצירת מכונות וירטואליות בכמות גדולה באזור.

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

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

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

פתרון שגיאות שמופיעות כשיוצרים, משנים את קנה המידה או מתקנים קבוצות MIG

בניגוד לבקשות ליצירת מכונות בודדות או בכמות גדולה, קבוצת MIG מקצה כמה שיותר מכונות בהתאם לקיבולת הנוכחית. אם יש מכונות שה-MIG לא יכולה ליצור, הקבוצה מתעדת את השגיאות ב-List instance errors וממשיכה לנסות ליצור אותן ברקע.

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

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

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

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

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

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

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

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

  • הגדרת גמישות בסוגי המכונות ב-MIG אזורי: ב-MIG אזורי שמשתמש בתבנית ההפצה BALANCED,‏ ANY או ANY_SINGLE_ZONE, מוסיפים סוגי מכונות חלופיים במדיניות ההפעלה הגמישה של המכונות (instanceFlexibilityPolicy). אם סוג המכונה הראשי לא זמין כשה-MIG מתרחב אופקית, ה-MIG מקצה את סוג המכונה הזמין הבא ברשימה. כברירת מחדל, התיקונים מנסים שוב רק את סוג המכונה המקורי של המכונה שנכשלה. כדי לאפשר לתיקונים להשתמש גם בסוגי מכונות חלופיים, מפעילים את האפשרות עדכון במהלך תיקון על ידי הגדרת השדה instanceLifecyclePolicy.forceUpdateOnRepair לערך "YES". לעומסי עבודה באזור יחיד, צריך להשתמש ב-MIG אזורי עם הצורה ANY_SINGLE_ZONE או לבחור אזור יעד יחיד. מידע נוסף זמין במאמר מידע על הפעלה גמישה של מכונות בקבוצות MIG.

  • תיקונים באזור חלופי: בקבוצת MIG אזורית בלי שמירת מצב שמשתמשת בצורת ההפצה BALANCED או ANY, מגדירים את הקבוצה כך שתיצור מחדש מכונות שנכשלו באזור אחר במהלך התיקון. ההגדרה הזו רלוונטית רק כשקבוצת ה-MIG מתקנת מכונות קיימות שנכשלו. כדי להציב מכונות חדשות באזורים זמינים במהלך היצירה או ההרחבה האופקית, משתמשים בתבנית ההפצה BALANCED או ANY. כדי להפעיל תיקון באזור חלופי, צריך להגדיר את השדה instanceLifecyclePolicy.onRepair.allowChangingZone ואת השדה instanceLifecyclePolicy.forceUpdateOnRepair לערך "YES". תיקון מכונה וירטואלית באזור חלופי

  • בקשות להוספת קיבולת לתור של חומרה נדירה: לעומסי עבודה באצווה או ב-AI/ML שדורשים חומרה נדירה (כמו GPUs) ויכולים להתמודד עם שעת התחלה גמישה, השתמשו בבקשות לשינוי גודל של MIG כדי להוסיף את הבקשה לתור ולהקצות את המכונות המבוקשות יחד כשהקיבולת תהיה זמינה, או צרו MIG עם מכונות וירטואליות מסוג Flex-start.

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

  • מעקב אחרי ההתפלגות של המכונות: כשיוצרים קבוצה או מרחיבים אותה אופקית, אם קבוצת MIG אזורית שמשתמשת בתבנית ההתפלגות BALANCED,‏ ANY או ANY_SINGLE_ZONE מגיעה לגודל היעד באמצעות אזורים זמינים או סוגי מכונות חלופיים, הקבוצה לא מתעדת ביומן שגיאות שקשורות לזמינות המשאבים. עם זאת, אם במהלך התיקונים סוג המכונה המקורי של מכונה שנכשלה לא זמין, קבוצת ה-MIG מתעדת שגיאות ZONE_RESOURCE_POOL_EXHAUSTED גם אם מפעילים את העדכון בזמן התיקון. כדי לראות איפה Compute Engine מיקם את המכונות באזורים ובסוגי המכונות השונים, אפשר לבדוק את הכרטיסייה Monitoring של קבוצת ה-MIG במסוףGoogle Cloud או להציג את מרכז הבקרה של Cloud Monitoring. איך עוקבים אחרי התפלגות המכונות בקבוצות MIG?

פתרון שגיאות שמופיעות כשיוצרים צומתי sole-tenant

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

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

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

פתרון שגיאות שמופיעות כשיוצרים פרוסות TPU

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

  • שימוש ב-Flex-start VMs, במקומות שמורים לעתיד במצב תזמון או במשאבים בתור: במקום לשלוח בקשות ליחידות TPU על פי דרישה בלי מקום שמור, אתם יכולים להשתמש ב-Flex-start VMs או במקומות שמורים לעתיד במצב תזמון כדי לתזמן או להוסיף לתור את הבקשה לפרוסת TPU ב-Compute Engine. אם אתם מקצים יחידות TPU דרך Cloud TPU API במקום Compute Engine, אתם יכולים להשתמש ב-Queued Resources API כדי להוסיף את הבקשה לתור עד שיהיה קיבולת רציפה זמינה באזור.

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

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

פתרון שגיאות שמופיעות כשיוצרים הזמנה

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

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

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

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

פתרון שגיאות כשמעדכנים סוגי מכונות

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

כדי לעדכן ולהפעיל מחדש את המכונה, נסו לבצע אחת מהפעולות הבאות או את שתיהן:

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

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

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

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

מה צריך לשמור מה אפשר לשנות המלצה תכונות רלוונטיות
מיקום (אזור או תחום ספציפי) סדרת מכונות או סוג מגדירים סוגי מכונות חלופיים באמצעות הפעלה גמישה של מכונות, או מחלקים את דרישות המחשוב בין סוגי מכונות קטנים יותר שתומכים בעומס העבודה.
סוג המכונה (הגדרה ספציפית) מיקום לבקש משאבים באזור או בתחום אחרים, להשתמש בצורת התפלגות גמישה של יעדים (BALANCED,‏ ANY או ANY_SINGLE_ZONE) או להפעיל תיקון בתחום חלופי לקבוצות MIG אזוריות שמשתמשות בצורה BALANCED או ANY.
חומרה ספציפית (כמו דגם ספציפי של GPU) שעת ההתחלה או מודל ההקצאה משתמשים ב-Flex-start VMs, בבקשות לשינוי כמות ב-MIG, ב-VM במודל Spot (כולל כשיוצרים מכונות בכמות גדולה), במקום שמור לעתיד במצב תזמון או במשאבים בתור ל-TPU.
הפעלה מיידית של מכונות זמינות מספר המכונות הראשוני כשיוצרים מכונות בכמות גדולה, מגדירים ערך נמוך יותר ל-minCount כדי לקבל קיבולת חלקית, או משתמשים ב-MIG כדי להפעיל מיד את המכונות הזמינות בזמן שהקבוצה מנסה שוב להשיג את המכונות שנותרו.

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