מידע על הזמנות

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

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

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

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

הזמנות שימושיות לצורך צמיחה, העברות או התאוששות מאסון.

איך עובדות ההזמנות

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

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

  • מחיקה אוטומטית

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

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

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

  • מספר המכונות הווירטואליות

    VM count הוא מספר המכונות הווירטואליות עם מאפיינים תואמים והאזור שרוצים לשריין כשיוצרים שריון. אחרי שיוצרים את ההזמנה, אפשר לשנות את מספר מכונות ה-VM.

  • מאפייני מכונות וירטואליות

    בקטע VM properties (מאפייני המכונה הווירטואלית) מתוארות דרישות החומרה (זיכרון ומעבדים) והמשאבים האופציונליים (דיסקים מקומיים של SSD ויחידות GPU) של המכונות הווירטואליות שרוצים לשריין. כשיוצרים הזמנה, אפשר לציין את המאפיינים האלה ישירות, לציין את המאפיינים על סמך מכונה וירטואלית קיימת או לציין את המאפיינים באמצעות תבנית של מכונה. מכונה וירטואלית יכולה להשתמש בהזמנה רק אם המאפיינים של המכונה הוירטואלית ושל ההזמנה זהים לחלוטין. מידע נוסף זמין בקטע דרישות במאמר הזה.

  • אופציונלי: מדיניות מיקום משאבים (קומפקטי)

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

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

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

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

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

איך פועל שיתוף ההזמנות

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

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

דרישות

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

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

    • Project

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

    • תחום (zone)

    • סוג מכונה

    • פלטפורמת CPU מינימלית

    • סוג ה-GPU ומספר ה-GPU (אם יש)

    • סוג וספירה של דיסקים מקומיים מסוג SSD (אם יש)

    • תחום עניין משותף להזמנה

      • הדרישות לגבי קרבה לשיריוּן משתנות בהתאם לסוג הצריכה של השיריוּן.

    • מדיניות למיקום קומפקטי (אם יש)

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

    • רמז למיקום (אם יש)

      • אפשר לכלול בהזמנה את השדה locationHint, שאפשר לציין רק כשיוצרים הזמנות או מכונות וירטואליות באמצעות REST. ‫Google לא ממליצה לציין את השדה locationHint כשיוצרים הזמנות.

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

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

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

  • ההזמנות צריכות להיות לאותו פרויקט ולאותו אזור כמו ההתחייבות.

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

  • אפשרות המחיקה האוטומטית צריכה להיות מושבתת בהזמנות.

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

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

דרישות נוספות להזמנות שנוצרו מתבנית של הגדרות מכונה

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

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

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

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

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

דרישות מכסה נוספות להזמנות משותפות

בנוסף, יש השלכות על המכסה בפרויקטים של הבעלים והצרכן של הזמנה משותפת:

  • פרויקט הבעלים: פרויקט הבעלים צורך את המכסה באופן הבא:

    • כשיוצרים את המקום השמור המשותף, הפרויקט הבעלים צורך את המכסה של כל המשאבים השמורים.

    • כשצורכים משאבים שמורים, הפרויקט הבעלים צורך מכסה של המשאבים שהוא צורך.

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

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

דרישות נוספות להזמנות עם מדיניות למיקום קומפקטי

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

  • מדיניות למיקום קומפקטי צריכה לתמוך בהזמנות:

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

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

  • ההזמנה צריכה לתמוך במדיניות למיקום קומפקטי:

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

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

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

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

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

הגבלות

כל ההזמנות כפופות להגבלות הבאות:

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

    • Batch
    • Compute Engine
    • Dataflow
    • Dataproc
    • Google Kubernetes Engine
    • Vertex AI

  • אפשר להזמין עד 1,000 מכונות וירטואליות לכל הזמנה.

  • אי אפשר להזמין מראש מכונות וירטואליות מסוג A4X Max bare metal, או מכונות וירטואליות מסוג A4X,‏ A4,‏ A3 Ultra או A3 High (עם פחות מ-8 יחידות GPU).

  • אפשר לעדכן רק את מאפיין ההשתייכות להזמנה של מכונות וירטואליות כדי להשתמש אוטומטית בכל הזמנה תואמת (ANY_RESERVATION) או ללא הזמנות (NO_RESERVATION).

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

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

  • אפשר לצרף הזמנות רק להתחייבויות לשימוש במשאבים.

  • אפשר לצרף הזמנות רק בזמן הרכישה של ההתחייבות.

  • אפשר לצרף הזמנה ספציפית רק להתחייבות אחת.

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

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

הגבלות נוספות על הזמנות משותפות

בנוסף, יש הגבלות על הזמנות משותפות:

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

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

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

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

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

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

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

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

הגבלות נוספות על הזמנות עם מדיניות למיקום קומפקטי

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

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

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

חיוב

החיוב על שיריוּנים מתבצע באותו שיעור חיוב כמו על המשאבים ששוריינו, כולל אותם מחירים על פי דרישה וחיובים מינימליים של דקה אחת כמו על מכונות וירטואליות שפועלות ולא שוריינו. הנחות על שימוש מתמשך (SUD),‏ CUD ותמחור בהתאמה אישית חלים גם על מכונות וירטואליות שמופעלות.

לדוגמה, נניח את התרחיש הבא:

  • יש לך התחייבות ל-3 ליבות vCPU ב-us-central1.
  • אתם מפעילים 5 מעבדים וירטואליים ב-us-central1-a.
  • יש לך הזמנה של 10 ליבות וירטואליות (vCPU) ב-us-central1-a.

הזמנות שכוללות הנחות תמורת התחייבות לשימוש.

בתרחיש הזה, Google Cloud החיוב יתבצע באופן הבא:

מכוסה על ידי מספר יחידות ה-vCPU
מחיר הנחה תמורת התחייבות לשימוש 3
מחיר על פי דרישה (2 מקומות שמורים בשימוש + 5 מקומות שמורים לא בשימוש) 7

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

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

פרטי חיוב נוספים להזמנות משותפות

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

הפרויקט לחיוב והמחיר של הזמנות משותפות מנוהלים באופן הבא:

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

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