במאמר הזה נסביר על בקשות למקומות שמורים לעתיד. למידע נוסף על הסוגים השונים של הזמנות, ראו בחירת סוג הזמנה.
אתם יכולים להשתמש במקומות שמורים לעתיד כדי לבקש מראש הבטחה לקיבולת חשובה או שקשה להשיג.
סקירה כללית
בהשוואה למקום שמור על פי דרישה, מקום שמור לעתיד מספק רמה גבוהה יותר של ודאות שתקבלו קיבולת למשאבים של תחום מוגדר ב-Compute Engine. עם מקום שמור לעתיד, אתם יכולים לבקש לשריין מקום החל מתאריך ספציפי, עד שנה קדימה. אחרי שיוצרים מקום שמור לעתיד, הבקשה נבדקת על ידי Google Cloud . אם היא מאושרת, Compute Engine מקצה את הקיבולת המבוקשת בתאריך ובשעה שצוינו. בתהליך הזה, הקיבולת המבוקשת נשמרת באופן בלעדי לפרויקט שלכם ולכל פרויקט אחר שאתם משתפים איתו את ההזמנה. לדוגמה, אפשר להשתמש במקומות שמורים לעתיד כדי:
העברה של מספר גדול של מכונות וירטואליות (VM).
להשיג משאבים מבוקשים.
איך משריינים קיבולת לאירועי שיא של הרחבת העומס.
כל מקום שמור לעתיד מספק רמה גבוהה מאוד של הבטחה למכונה וירטואלית אחת או יותר עם אותם מאפיינים באזור ספציפי. אם הבקשה לשמירת מקום לעתיד תאושר על ידי Google Cloud , בתאריך שביקשתם שבו הקיבולת תהיה זמינה, המערכת של Compute Engine תפחית את כל המקומות השמורים והמכונות הווירטואליות הפועלות שתואמים, ותיצור באופן אוטומטי מקומות שמורים כדי להגיע לקיבולת שצוינה בבקשה לשמירת מקום לעתיד. אחרי שהמקומות החדשים נוצרים אוטומטית, אפשר להשתמש בהם כמו במקומות שמורים על פי דרישה. כל עוד המקומות השמורים לא נמחקים, אף אחד אחר לא יכול להשתמש במשאבים ששמורים לכם.
אין עלויות נוספות ליצירת מקום שמור לעתיד. אתם מתחילים לשלם רק כש-Compute Engine מקצה את המשאבים השמורים, והחיוב הוא באותה עלות כמו של מקומות שמורים על פי דרישה.
איך פועלים מקומות שמורים לעתיד
בקטעים הבאים מוסבר איך פועלים מקומות שמורים לעתיד.
מאפיינים של מקומות שמורים לעתיד
כשיוצרים בקשה למקום שמור לעתיד, צריך להגדיר את המאפיינים הבאים:
תחילית שם
הקידומת של השם מציינת מחרוזת ש-Compute Engine מוסיף לתחילת השם של כל מקום שמור שנוצר אוטומטית לבקשה שלכם. כשמציגים את רשימת המקומות השמורים, אפשר לסנן לפי קידומת אחת או יותר של שם כדי לזהות את המקומות השמורים שנוצרו אוטומטית.
תחום עניין משותף בהזמנה
ההתאמה למקום שמור קובעת איך המכונות הווירטואליות משתמשות במקומות השמורים שנוצרו אוטומטית ב-Compute Engine, אחרי שהבקשה לשמירת מקום לעתיד אושרה על ידי Google Cloud והגיעה לשעת ההתחלה שלה. אפשר לציין אחת מההגדרות הבאות של זיקה למאגר:
שימוש אוטומטי (
ANY_RESERVATION): אם המאפיינים של המכונה הווירטואלית תואמים למאפיינים של בקשה שנוצרה אוטומטית, המכונה הווירטואלית משתמשת אוטומטית בבקשה. ההתנהגות הזו חלה על מכונות וירטואליות בפרויקט שלכם ובכל פרויקט שאתם משתפים איתו את ההזמנה, וגם על מכונות וירטואליות חדשות וקיימות. אם תמחקו את הבקשות שנוצרו אוטומטית אחרי שהן יסתיימו, המכונות הווירטואליות ימשיכו לפעול עד שתעצרו, תשעו או תמחקו אותן. איך משתמשים במקום שנשמר באופן אוטומטי?מטורגטות ספציפית (
SPECIFIC_RESERVATION): כדי להשתמש בבקשה שנוצרה באופן אוטומטי, המכונה הווירטואלית צריכה לטרגט את הבקשה לפי שם, והמאפיינים של המכונה הווירטואלית צריכים להתאים למאפיינים של הבקשה. אחרת, יצירת ה-VM תיכשל. כדי למחוק את ההזמנות שנוצרו באופן אוטומטי, צריך לעצור, להשעות או למחוק את כל המכונות הווירטואליות שמשתמשות בהן. מידע נוסף זמין במאמר שימוש בהזמנה שמטורגטת באופן ספציפי.
תקופת ההזמנה
תקופת ההזמנה מגדירה את משך הזמן שבו Compute Engine שומר את הקיבולת שהזמנתם. צריך לציין את שני הערכים הבאים:
שעת התחלה: התאריך והשעה שבהם Compute Engine משלים את יצירת הבקשות האוטומטיות. בזמן ההתחלה, תוכלו ליצור מכונות וירטואליות כדי להשתמש בהזמנות. בחרו שעת התחלה שתאפשר לכם ליצור את המכונות הווירטואליות לפני שתצטרכו אותן לעומס העבודה. שעת ההתחלה חייבת להיות בטווח של שנה אחת מהתאריך והשעה שבהם תגישו את הבקשה למקום שמור לעתיד לבדיקה.
שעת סיום: התאריך והשעה שבהם מסתיימת תקופת שמירת המקום. אחרי שהתוקף יפוג, תוכלו למחוק את הבקשה למקום שמור לעתיד ואת המקומות השמורים שנוצרו אוטומטית. שעת הסיום חייבת להיות לפחות 24 שעות אחרי שעת ההתחלה, ואין לה מגבלה עליונה. כדי להגדיל את הסיכוי שהבקשה תאושר ב-Google Cloud , השתמשו בתקופה המומלצת לשמירת מקום.
סוג השיתוף קובע באילו פרויקטים אפשר להשתמש במקומות שנוצרו אוטומטית בעקבות הבקשה למקום שמור לעתיד. אפשר לציין אחד מסוגי השיתוף הבאים:
Single-project: המכונות הווירטואליות יכולות לצרוך את הקיבולת השמורה מהפרויקט שבו יצרתם את הבקשה למקום שמור לעתיד, ולא מאף פרויקט אחר. מידע נוסף זמין במאמר מקומות שמורים לפרויקט יחיד.
Shared: המכונות הווירטואליות יכולות להשתמש בקיבולת השמורה מהפרויקט הבעלים, שבו יוצרים את הבקשה למקום שמור לעתיד, ומהפרויקטים הצרכנים, שיכולים להיות כל פרויקט שמשתפים איתו את הבקשה. אתם יכולים לשתף בקשה למקום שמור לעתיד עם עד 100 פרויקטים של צרכנים שנמצאים באותו ארגון ב- Google Cloudכמו הפרויקט של הבעלים. מידע נוסף זמין במאמר הזמנות משותפות.
המספר הכולל
המספר הכולל מציין את המספר הכולל של המכונות הווירטואליות עם המאפיינים שצוינו שרוצים לשריין באזור בשעת ההתחלה. בהתאם לזמינות של המקום השמור שציינתם, Compute Engine מקצה קיבולת באופן הבא:
בקשות למקום שמור שנוצלו אוטומטית: המערכת של Compute Engine מתייחסת לערך הזה כיעד הקיבולת הכולל. המערכת של Compute Engine מחסירה את המכונות הווירטואליות והמקומות השמורים התואמים שקיימים בפרויקט שלכם ובכל הפרויקטים שאתם משתפים איתם את המקום השמור, ומקצה קיבולת למספר הנותר.
הזמנות מטורגטות ספציפית: המערכת של Compute Engine מתייחסת לערך הזה כקיבולת מצטברת. המערכת של Compute Engine מקצה את המספר המלא של המכונות הווירטואליות, ולא מחסירה את המכונות הווירטואליות או את המקומות השמורים הקיימים שתואמים.
למידע נוסף, קראו את הקטע איך Compute Engine סופר ומקצה משאבים שמורים במאמר הזה.
מאפייני מכונה וירטואלית
מאפייני המכונה הווירטואלית מגדירים את דרישות החומרה, כמו זיכרון ומעבדי CPU, ומשאבים אופציונליים, כמו דיסקים מקומיים של SSD ויחידות GPU, למכונות הווירטואליות שאתם רוצים לשמור להן מקום. כשיוצרים בקשה לשמירת מקום לעתיד, אפשר לציין את המאפיינים האלה, להעתיק אותם ממכונה וירטואלית קיימת או להשתמש בתבנית של הגדרות מכונה. כדי להשתמש במקום שנוצר אוטומטית, המאפיינים של המכונה הווירטואלית צריכים להתאים לכל המאפיינים של המקום השמור.
תחום (zone)
בשדה zone מציינים את המיקום שבו רוצים לשמור מקום לקיבולת. השילוב של האזור וסוג המכונה שתבחרו משפיע על הסיכוי שהבקשה למקום שמור לעתיד תאושר ב- Google Cloud . למידע נוסף, קראו את הקטע תהליך הבדיקה של מקום שמור לעתיד במאמר הזה.
בנוסף, אפשר להגדיר את המאפיינים האופציונליים הבאים:
מחיקה אוטומטית
האפשרות auto-delete קובעת אם הבקשות שנוצרו אוטומטית יימחקו ב-Compute Engine אחרי שעת הסיום, גם אם המכונות הווירטואליות משתמשות בהן. אם תפעילו את האפשרות הזו, הבקשות שנוצרו אוטומטית ב-Compute Engine יימחקו תוך שעתיים מהשעה שבחרתם. האפשרות הזו עוזרת לכם להימנע מחיובים על הזמנות שלא נוצלו.
תיאור
בשדה description אפשר להוסיף טקסט שמתאר את הבקשה לשמירת מקום לעתיד.
סטטוס התכנון
סטטוס התכנון מציין אם אתם רוצים לשמור את הבקשה כטיוטה או לשלוח אותה לבדיקה של Google Cloud . מידע נוסף מופיע בקטע סטטוס של מקומות שמורים לעתיד במאמר הזה.
סטטוס המקומות השמורים לעתיד
בקטע הזה מפורטים הסטטוסים האפשריים של בקשה לשמירת מקום לעתיד. בקשה ל"מקום שמור לעתיד" מכילה את שדות הסטטוס הבאים:
-
בקטע הזה מוסבר על סטטוס התכנון, שאותו מציינים כשיוצרים בקשה למקום שמור לעתיד. סטטוס התכנון מציין אם הבקשה נמצאת במצב טיוטה או נשלחה לבדיקה שלGoogle Cloud .
-
בקטע הזה מוסבר מהו סטטוס הרכש, שמוגדר על ידי Compute Engine אחרי שיוצרים בקשה למקום שמור לעתיד. בהתחלה, בשדה של סטטוס הרכש מוצג סטטוס האישור של בקשה למקום שמור לעתיד. אחרי שהבקשה לשמירת מקום לעתיד תאושר ב- Google Cloud , והבקשה תיכנס לזמן הנעילה, בשדה הזה יוצג סטטוס הרכש של המשאבים שביקשתם.
סטטוס התכנון של מקומות שמורים לעתיד
כשיוצרים בקשה למקום שמור לעתיד, אפשר להגדיר את סטטוס התכנון (planningStatus) לאחד מהערכים הבאים:
Draft (
DRAFT): כברירת מחדל, נוצרת טיוטה של בקשה למקום שמור לעתיד. אתם יכולים לשנות את הטיוטה של בקשה למקום שמור לעתיד לפי הצורך, וכשתהיו מרוצים מהשינויים, תוכלו לשלוח אותה לבדיקה שלGoogle Cloud . Google ממליצה ליצור קודם בקשה בטיוטה, כי כך אפשר לקבוע את מספר המכונות הווירטואליות ש-Compute Engine יקצה לבקשה במקום להעריך את המספר הזה באופן ידני, ואם רוצים, לשנות את מספר המכונות הווירטואליות השמורות בבקשה לפני ששולחים אותה לבדיקה.Submitted (
SUBMITTED): הבקשה למקום שמור לעתיד נשלחה לבדיקה של Google Cloud. אחרי ששולחים בקשה למקום שמור לעתיד לבדיקה, אי אפשר לשנות את סטטוס התכנון שלה בחזרה ל-DRAFT. אפשר גם לשלוח את הבקשה למקום שמור לעתיד לבדיקה מיד כשיוצרים אותה.
סטטוס הרכש של מקומות שמורים לעתיד
אחרי שיוצרים בקשה למקום שמור לעתיד, הסטטוס של הבקשה (procurementStatus) ב-Compute Engine משתנה לאחד מהערכים הבאים:
Drafting (
DRAFTING): הבקשה למקום שמור לעתיד נמצאת במצב טיוטה.בהמתנה לאישור (
PENDING_APPROVAL): הבקשה למקום שמור לעתיד נשלחה לאישור של Google Cloud. בזמן שהבקשה נבדקת, סטטוס הרכש של בקשה למקום שמור לעתיד יכול להיות אחד מהבאים:Declined (
DECLINED): Google Cloud דחתה את הבקשה למקום שמור לעתיד. אתם יכולים לשנות את הבקשה למקום שמור לעתיד, ואחרי שתסיימו את השינויים, לשלוח אותה שוב לאישור.Approved (
APPROVED): Google Cloud הבקשה אושרה, וב-Compute Engine יוקצו המשאבים שנוצרו אוטומטית עם הקיבולת המבוקשת בתחילת התקופה של המקום השמור. אם Google Cloud מאשרת את הבקשה תוך 56 ימים (8 שבועות) משעת ההתחלה, המקום השמור לעתיד נכנס לזמן הנעילה תוך כמה דקות.Canceled (
CANCELED): משתמש ביטל את הבקשה למקום שמור לעתיד במהלך הבדיקה, או אחרי ש- Google Cloud אישרה או דחתה אותה.
אחרי שהבקשה למקום שמור לעתיד אושרה או נדחתה, אתם יכולים לשנות מאפיין אחד או יותר של הבקשה ולשלוח אותה שוב לבדיקה ב- Google Cloud . הפעולה הזו משנה את הסטטוס של המקום השמור לעתיד בחזרה ל"בהמתנה לאישור".
רכישה (
PROCURING): 56 ימים (8 שבועות) משעת ההתחלה של תקופת ההזמנה, המקום השמור לעתיד נכנס לזמן הנעילה שלו. אחרי שהמקום השמור לעתיד נכנס לסטטוס הזה:לא תוכלו לבטל את המקום השמור לעתיד.
אפשר למחוק את המקום השמור לעתיד רק אחרי שעת הסיום שלו.
כדי לשנות את תקופת השמירה, את הגדרות השיתוף, את המספר הכולל או את מאפייני המכונות הווירטואליות של המקום השמור לעתיד, צריך לבקש אישור מ- Google Cloud. לאחר מכן, Google Cloud מאשר או דוחה את הבקשה על ידי שינוי סטטוס העדכון שלה. אםGoogle Cloud דוחה בקשה ולא שולחים בקשות חדשות, Compute Engine מקצה את המשאבים השמורים באמצעות המאפיינים שצוינו קודם.
אם בבקשה למקום שמור לעתיד ציינתם תקופה של פחות מ-56 ימים מהתאריך והשעה שבהם שלחתם את הבקשה, המקום השמור לעתיד יינעל תוך כמה דקות אחרי שהבקשה תאושר.
הקצאה (
PROVISIONING): 24 שעות לפני שעת ההתחלה שצוינה בבקשה למקום שמור עתידי, המערכת של Compute Engine מתחילה להקצות את המשאבים המבוקשים על ידי יצירה אוטומטית של מקומות שמורים. לאחר מכן, סטטוס הרכש של המקום השמור לעתיד ב-Compute Engine משתנה לאחד מהסטטוסים הבאים:Fulfilled (
FULFILLED): המערכת של Compute Engine הקצתה את כל המשאבים שנדרשים כדי להגיע למספר הכולל שצוין בבקשה למקום שמור לעתיד.Partially fulfilled (
FAILED_PARTIALLY_FULFILLED): Compute Engine הקצתה רק חלק מהמשאבים שנדרשים כדי להגיע למספר הכולל שצוין במקום השמור לעתיד, כי המכסה לא מספיקה.Failed (
FAILED): המערכת של Compute Engine לא הצליחה להקצות את המשאבים השמורים.
אפשר להשתמש בבקשות שנוצרו אוטומטית בשעת ההתחלה. כדי לוודא שיש לכם את הקיבולת הכוללת שביקשתם, אתרו את כל המקומות השמורים שנוצרו אוטומטית ולא נוצלו, וצרו מכונות וירטואליות כדי לנצל אותם. אפשר לשנות או למחוק מקום שמור שנוצר אוטומטית רק אחרי שעת הסיום שצוינה במקום השמור לעתיד. למידע נוסף, קראו את הקטע איך Compute Engine מקצה משאבים במאמר הזה.
עדכונים לגבי מקומות שמורים לעתיד
אחרי שיוצרים בקשה למקום שמור לעתיד, אפשר לעדכן אותה – לבטל, למחוק, לשנות או לבקש לשנות אותה. עם זאת, אפשר לעדכן בקשות של מקומות שמורים לעתיד רק במסגרות זמן מסוימות, כמו שמוסבר בקטעים הבאים.
זמן הנעילה של המקום השמור לעתיד
אחרי ששולחים בקשה למקום שמור לעתיד, אפשר לבטל או למחוק אותה בכל שלב לפני ש- Google Cloud מתחיל להקצות (PROCURING) את המשאבים. בשלב הזה הבקשה למקום שמור לעתיד ננעלת. במהלך תקופת הנעילה של מקום שמור לעתיד, אי אפשר לבטל או למחוק אותו עד אחרי שעת הסיום שלו.
בנוסף, זמן הנעילה משפיע על המועד שבו אפשר לבקש שינויים. זמן הנעילה של בקשה למקום שמור לעתיד מתחיל באחד מהזמנים הבאים:
אם בבקשה למקום שמור לעתיד צוינה שעת התחלה שחלה פחות מ-56 ימים (8 שבועות) אחרי מועד השליחה, הבקשה נכנסת לזמן הנעילה זמן קצר אחרי שהיא מאושרת.
אחרת, זמן הנעילה של הבקשה למקום שמור לעתיד מתחיל 56 ימים משעת ההתחלה שלה.
שינוי של מקום שמור לעתיד
אם בקשה למקום שמור לעתיד לא בוטלה או ממתינה לאישור, אתם יכולים לשנות את הבקשה בכל שלב לפני שהיא מגיעה לסטטוס ההקצאה Provisioning (PROVISIONING).
אחרי שהבקשה למקום שמור לעתיד אושרה, אפשר לשנות את המאפיינים הבאים רק אם מבקשים שינוי מ- Google Cloud:
יחידות GPU וסוגי GPU
דיסקים מסוג SSD מקומי וסוג ממשק הדיסק
סדרת המכונות וסוג המכונה
פלטפורמת CPU מינימלית
שיתוף ההגדרות
שעת ההתחלה ושעת הסיום של שמירת המקום
המספר הכולל (מספר המכונות הווירטואליות)
אפשר לבקש רק שינוי אחד (של מאפיין אחד או יותר) בכל פעם למקום שמור לעתיד שאושר. בנוסף, אם תשלחו את סוגי הבקשות הבאים לשינוי,סביר להניח ש- Google Cloud תדחה אותן:
כל בקשה שנשלחת בטווח של 72 שעות לפני שעת ההתחלה.
כל בקשה לשינוי מאפייני VM שבוצעה תוך 14 ימים משעת ההתחלה.
כל בקשה להגדיל או להקטין באופן משמעותי את המספר הכולל של המשתתפים, שמוגשת בטווח של 14 ימים לפני שעת ההתחלה.
כששולחים בקשה לשינוי, בשדה סטטוס העדכון (AmendmentStatus) של המקום השמור לעתיד מופיע הסטטוס. אחרי ש- Google Cloud בודק את הבקשה, Compute Engine מגדיר את סטטוס העדכון לאחד מהערכים הבאים:
העדכון ממתין לאישור (
AMENDMENT_PENDING_APPROVAL): Google Cloud בודק את הבקשה שלך.העדכון אושר (
AMENDMENT_APPROVED): Google Cloud אישר את הבקשה שלך. המערכת של Compute Engine תקצה את המשאבים שהמקום שלהם נשמר לפי המאפיינים שאושרו.העדכון נדחה (
AMENDMENT_DECLINED): Google Cloud הבקשה שלך נדחתה. אם לא תשלחו בקשה חדשה והיא תאושר, Compute Engine יקצה את המשאבים השמורים באמצעות המאפיינים שאושרו בעבר.
במאמר שינוי בקשות למקום שמור לעתיד מוסבר איך משנים את הבקשות ואילו מאפיינים אפשר לשנות.
תהליך הבדיקה של בקשות לשריון מקום לעתיד
כדי להקצות את הקיבולת המבוקשת, צריך לשלוח את כל הבקשות למקומות שמורים לעתיד לבדיקה של Google Cloud .בדרך כלל הבדיקה של Google Cloud נמשכת חמישה ימים. אם ל- Google Cloud נדרש זמן נוסף או שיש שאלות, צוות ניהול החשבון או צוות המכירות יפנו אליכם.
אם בקשה למקום שמור לעתיד או בקשה לשינוי אושרה,Google Cloud תעשה מאמצים סבירים מבחינה מסחרית כדי שהקיבולת המבוקשת תהיה זמינה בשעת ההתחלה של תקופת ההזמנה של המקום השמור לעתיד. Google Cloud תתעדף את אספקת הקיבולת השמורה שלך על פני לקוחות אחרים ללא מקומות שמורים לעתיד שאושרו עם אותם מאפיינים. מידע נוסף זמין במאמר תנאים ספציפיים לשירות.
כדי להגדיל את הסיכוי שהבקשה למקום שמור לעתיד תאושר ב- Google Cloud , כדאי להקפיד על הדברים הבאים כשיוצרים או משנים את הבקשה:
שעת ההתחלה המומלצת
56 ימים (8 שבועות) לפני שעת ההתחלה של תקופת שמירת המקום, כל בקשה שאושרה למקום שמור לעתיד נכנסת לזמן נעילה. אם שעת ההתחלה שצוינה במקום שמור לעתיד שאושר היא פחות מ-56 ימים מהתאריך והשעה שבהם שלחתם בקשה למקום שמור לעתיד לבדיקה, הבקשה תינעל תוך כמה דקות מהאישור.
כדי שיהיה לכם מספיק זמן לבטל או למחוק בקשה למקום שמור לעתיד, וגם לשלוח בקשה לשינוי, מומלץ לציין שעת התחלה שהיא יותר מ-56 ימים מהתאריך והשעה שבהם אתם שולחים את הבקשה לבדיקה.
תקופת ההזמנה המינימלית המומלצת
כשיוצרים או משנים בקשה למקום שמור לעתיד, צריך לציין תקופת הזמנה של 24 שעות לפחות. עם זאת, כדי להגדיל את הסיכוי שהבקשה למקום שמור לעתיד תאושר ב-Google Cloud , מומלץ להגדיר תקופה של 365 ימים או יותר.
איך Compute Engine מקצה משאבים שמורים
בקטע הזה מוסבר איך Compute Engine מקצה את המשאבים השמורים:
-
בקטע הזה מוסבר איך המערכת של Compute Engine מתייחסת למקומות שמורים לעתיד, למקומות שמורים ולמכונות וירטואליות קיימים שתואמים לבקשה שלכם, כשהיא מקצה את המספר הכולל של המשאבים לבקשה שאושרה לשמירת מקום לעתיד.
-
בקטע הזה מוסבר איזה סוג של מקומות שמורים נוצר ב-Compute Engine לבקשה שאושרה לשמירת מקום לעתיד, בשעת ההתחלה שלה.
ספירה והקצאה של משאבים שמורים
האופן שבו Compute Engine מקצה קיבולת לבקשה שאושרה לשמירת מקום לעתיד תלוי בזיקה לשמירת המקום שציינתם בבקשה:
המספר הכולל של הקצאות שנוצלו אוטומטית
אם בבקשה למקום שמור לעתיד ציינתם שאתם רוצים ליצור אוטומטית מקומות שמורים שייצרכו אוטומטית, המערכת של Compute Engine תתייחס למספר הכולל כיעד קיבולת בכל הפרויקטים שציינתם. כדי להגיע למספר הכולל של המקומות השמורים לעתיד שאושרו, Compute Engine מבצע את הפעולות הבאות:
המערכת של Compute Engine מחסירה את כל המקומות השמורים הקיימים (שנוצלו ושלא נוצלו) שתואמים, שמשותפים רק עם (חלק מהפרויקטים או עם כל) הפרויקטים שצוינו במקום השמור לעתיד.
Compute Engine יוצר אוטומטית בקשות לשמירת מקום לכמות שנותרה. זה אומר ש:
כל המכונות הווירטואליות הקיימות שמתאימות לפרטי הבקשה יתחילו להשתמש בבקשות שנוצרו אוטומטית.
תצטרכו ליצור מכונות וירטואליות שמתאימות לכל בקשה שנוצרה אוטומטית ולא נוצלה.
לדוגמה, נניח שיצרתם בקשה משותפת למקום שמור לעתיד באזור us-central1-a. בבקשה הזו למקום שמור לעתיד מצוין מספר כולל של 10 מכונות וירטואליות מסוג n2-standard-2, פרויקט A כפרויקט הבעלים ופרויקטים B ו-C כפרויקטים הצרכנים. לאחר שבקשת המקום השמור לעתיד הזו תאושר ו-Compute Engine יתחיל ליצור מקומות שמורים בשעת ההתחלה של תקופת שמירת המקום, נניח שהפרויקטים האלה מכילים את המשאבים הבאים, עם מאפייני מכונות וירטואליות שתואמים למקום השמור לעתיד:
בפרויקט א', מכונה וירטואלית אחת פועלת ולא משתמשת בהזמנה.
בפרויקט ב', מקום שמור אחד שלא נוצל, שמשותף עם פרויקט ג' ל-2 מכונות וירטואליות.
בפרויקט ג', מקום שמור אחד שלא נוצל לפרויקט יחיד, למכונה וירטואלית אחת.
בתרחיש הזה, Compute Engine יוצר באופן אוטומטי הקצאת מקום משותפת ל-7 מכונות וירטואליות, כדי להגיע למספר כולל של 10 מכונות וירטואליות בשעת ההתחלה.
במאמר מכונות וירטואליות שניתנות לצריכה בבקשה למקום שמור לעתיד מוסבר איך בודקים את מספר המכונות הווירטואליות ש-Compute Engine מתכנן להקצות לבקשה קיימת למקום שמור לעתיד.
המספר הכולל של הזמנות עם טירגוט ספציפי
אם בבקשה למקום שמור לעתיד ציינתם שאתם רוצים ליצור אוטומטית בקשות ספציפיות, המערכת של Compute Engine תקצה את כל המכונות הווירטואליות שביקשתם כקיבולת נוספת. בסוג הזה של מקום שמור, המערכת של Compute Engine לא מחסירה מהמספר שביקשתם את המקומות השמורים התואמים הקיימים או את המכונות הווירטואליות שפועלות. בנוסף, מכונות וירטואליות קיימות לא משתמשות אוטומטית במקום השמור שנוצר אוטומטית בשעת ההתחלה. כדי להשתמש בקיבולת שהוקצתה, צריך ליצור מכונות וירטואליות שמיועדות לבקשות שנוצרו אוטומטית (לפי שם).
הזמנות שנוצרות באופן אוטומטי
24 שעות לפני שעת ההתחלה שצוינה בבקשה למקום שמור לעתיד, Compute Engine מתחיל להקצות את הקיבולת המבוקשת בבקשה שאושרה, על ידי יצירה אוטומטית של מקומות שמורים. עם זאת, החיוב על המקומות השמורים שנוצרו אוטומטית מתבצע רק בשעת ההתחלה. לכל מקום שמור שנוצר אוטומטית יש את המאפיינים הבאים:
כדי להשתמש במקום השמור, צריך ליצור מכונות וירטואליות עם מאפיינים תואמים.
מאפייני ה-VM של המקום השמור תואמים לאלה שצוינו בבקשה למקום שמור לעתיד.
הגדרות השיתוף של המקום השמור זהות להגדרות השיתוף של הבקשה למקום שמור לעתיד. באופן ספציפי:
אם שלחתם בקשה לשמירת מקום לעתיד לפרויקט יחיד, כל מקום שנוצר אוטומטית הוא מקום שמור לפרויקט יחיד.
אם יצרתם בקשה למקום שמור משותף לעתיד, כל מקום שמור שנוצר אוטומטית הוא מקום שמור משותף שמצוינים בו אותו פרויקט בעלים ואותם פרויקטים צרכניים.
השם של המקום השמור מתחיל בקידומת השם שצוינה בבקשה למקום שמור לעתיד.
אם הפעלתם את אפשרות המחיקה האוטומטית כששלחתם או שיניתם בקשה למקום שמור לעתיד, בכל בקשה שנוצרה אוטומטית מוגדר שדה
deleteAtTimeעם השעה שבה Compute Engine ימחק אותה אוטומטית.
כשהבקשה שנוצרה אוטומטית מגיעה לשעת ההתחלה, אפשר להשתמש בה כמו במקום שמור על פי דרישה. אם עומס העבודה משתנה, אפשר לשנות את ההזמנה. עם זאת, אי אפשר לשנות את מספר המכונות הווירטואליות בהזמנה או את שעת הסיום שלה. מידע נוסף מופיע במאמר שינוי הזמנות.
הגבלות
בקטעים הבאים מפורטות ההגבלות על הזמנות.
הגבלות על יצירה
כשיוצרים בקשה למקום שמור לעתיד, חלות ההגבלות הבאות:
אם יש לכם הזמנות קיימות עם מאפיינים תואמים, קראו את המידע הבא:
אם בפרויקט כבר יש מקומות שמורים שנוצרו אוטומטית או מקומות שמורים על פי דרישה, או שהמקומות השמורים האלה משותפים עם הפרויקט, אתם יכולים ליצור רק בקשות למקומות שמורים לעתיד שמשותפים לכל הפרויקטים שצוינו במקומות השמורים הקיימים.
אם בפרויקט כבר יש בקשה למקום שמור לעתיד לפרויקט יחיד, אתם יכולים ליצור רק בקשות למקום שמור לעתיד לפרויקט יחיד.
אם בפרויקט שלכם כבר יש בקשה משותפת למקום שמור לעתיד, או שבקשה למקום שמור לעתיד משותפת עם הפרויקט שלכם, אתם יכולים ליצור בקשות משותפות למקומות שמורים לעתיד רק באותם פרויקטים. לדוגמה, אם יש בקשה משותפת למקום שמור לעתיד בפרויקט א' (הפרויקט הבעלים) שמשותפת עם פרויקט ב' ופרויקט ג' (הפרויקטים הצרכנים), אתם יכולים:
יוצרים בקשה נוספת לשריון מקום משותף לעתיד בפרויקט א', ומשתפים אותה עם פרויקטים ב' ו-ג'.
יוצרים בקשה משותפת למקום שמור לעתיד בפרויקט ב' ומשתפים אותה עם פרויקטים א' וג'.
יוצרים בקשה לשיתוף של מקום שמור לעתיד בפרויקט C, ומשתפים אותה עם פרויקטים A ו-B.
אפשר ליצור ולשלוח בקשות למקומות שמורים לעתיד רק לסדרות המכונות הבאות:
מכונות שעברו אופטימיזציה למאיצים: A3 Mega, A3 High (עם 8 מעבדי GPU), A3 Edge ו-G4
מותאמות לצריכת מעבד גבוהה (compute-optimized): H3 ו-H4D
למטרות כלליות: C3, C3D, C4, C4A, C4D, C4N, N4, N4A ו-N4D
מותאמות לצריכת זיכרון גבוהה (memory-optimized): M3, M4, M4N ו-X4
אופטימיזציה של אחסון: Z3 ו-Z4M
אי אפשר לציין תקופת שמירה קצרה מ-24 שעות.
אם הגדרתם את מאפיין הזיקה של המקום השמור לשימוש אוטומטי (
ANY_RESERVATION), תקופת שמירת המקום לא יכולה לחפוף לבקשה אחרת של מקום שמור לעתיד עם מאפייני מכונה וירטואלית ואזור תואמים. ההגבלה הזו חלה גם אם הבקשה למקום שמור לעתיד קיימת בפרויקט שלכם וגם אם היא משותפת עם הפרויקט.שעת ההתחלה של בקשת מקום שמור לעתיד יכולה להיות עד שנה קדימה.
אי אפשר לציין כללי מדיניות מיקום.
הגבלות אחרי היצירה
אחרי שיוצרים בקשה למקום שמור לעתיד, חלות ההגבלות הבאות:
אם מעבירים לארגון אחר פרויקט שנוצרה בו בקשה למקום שמור לעתיד, והבקשה עדיין לא נכנסה לזמן הנעילה, הבקשה נמחקת.
אחרי שהבקשה לשמירת מקום לעתיד אושרה והגיעה לזמן הנעילה, חלות ההגבלות הבאות:
לא תוכלו לבטל את המקום השמור לעתיד.
אם רוצים לצרף להתחייבות בקשות שנוצרו אוטומטית, חלות ההגבלות הבאות:
אפשר לרכוש את ההתחייבות רק במהלך 24 השעות האחרונות לפני שעת ההתחלה של תקופת ההזמנה.
אפשר לצרף רק את הבקשות שנוצרו אוטומטית, שהאפשרות למחיקה אוטומטית מושבתת בהן. אם הפעלתם את אפשרות המחיקה האוטומטית כששלחתם או שיניתם את הבקשה למקום שמור לעתיד, אתם צריכים להשבית אותה.
אפשר למחוק את המקום השמור לעתיד רק אחרי שעת הסיום שלו.
אחרי שמקום שמור לעתיד נכנס לשעת ההתחלה שלו, אפשר לשנות או למחוק את המקומות השמורים שנוצרו אוטומטית עבור המקום השמור לעתיד רק אחרי שעת הסיום.
חיוב
אין עלויות נוספות ליצירת מקום שמור לעתיד.
אחרי שהבקשה למקום שמור לעתיד מאושרת ונכנסת לזמן הנעילה, אתם מתחייבים לשלם על כל הקיבולת שהוקצתה לכל תקופת ההזמנה, אלא אם תבקשו Google Cloud לשנות את מספר המשאבים או את מאפייני המכונות הווירטואליות של המשאבים שאתם מזמינים לפני שעת ההתחלה של תקופת ההזמנה. אם Google Cloud מאשרת את הבקשה, אתם מתחייבים לשלם על הקיבולת המעודכנת שביקשתם.
בתחילת התקופה של שמירת המקום לעתיד,Google Cloud מחייבת אתכם רק על הבקשות שנוצרו אוטומטית כדי להגיע למספר הכולל שצוין בשמירת המקום לעתיד. אם Compute Engine יכול לספק רק חלק מהקיבולת שביקשתם, תחויבו רק על המשאבים שהוקצו.
כל בקשה שנוצרת אוטומטית צוברת חיובים באופן הבא:
באותו תעריף כמו מקום שמור על פי דרישה.
כל עוד המקום השמור קיים, גם אם אתם משתמשים במשאבים השמורים וגם אם לא.
המאמרים הבאים
איך יוצרים בקשות למקומות שמורים לעתיד: