מיזוג ופיצול של התחייבויות

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

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

לפני שמתחילים

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

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

    המסוף

    כשמשתמשים במסוף Google Cloud כדי לגשת לשירותים ולממשקי ה-API של Google Cloud , לא צריך להגדיר אימות.

    gcloud

    1. התקינו את ה-CLI של Google Cloud. אחר כך, אתחלו את ה-CLI של Google Cloud באמצעות הפקודה הבאה:

      gcloud init

      אם אתם משתמשים בספק זהויות חיצוני (IdP), קודם אתם צריכים להיכנס ל-CLI של gcloud באמצעות המאגר המאוחד לניהול זהויות.

  • הגדרת אזור ותחום כברירת מחדל.
  • REST

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

      התקינו את ה-CLI של Google Cloud.

      אם אתם משתמשים בספק זהויות חיצוני (IdP), קודם אתם צריכים להיכנס ל-CLI של gcloud באמצעות המאגר המאוחד לניהול זהויות.

    מידע נוסף מופיע במאמר אימות לשימוש ב-REST במסמכי האימות של Google Cloud .

מיזוג התחייבויות

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

איך המיזוג עובד

כשממזגים התחייבויות נפרדות (התחייבויות מקור), נוצרת התחייבות חדשה (התחייבות ממוזגת) שמשלבת את המשאבים מכל התחייבויות המקור. ביום שאחרי, בשעה 00:00 (חצות) לפי שעון החוף המערבי בארה"ב ובקנדה (UTC-8, או UTC-7 בשעון קיץ), ההתחייבות הממוזגת הופכת לפעילה וההתחייבויות המקוריות מבוטלות. תאריך ההפעלה הזה הופך לתאריך ההתחלה של ההתחייבות הממוזגת, ופעולת המיזוג מסתיימת.

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

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

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

לדוגמה, נניח שיש שתי התחייבויות במקור שמתחילות ב-1 בינואר 2020 וב-1 בדצמבר 2020. תאריכי הסיום שלהם הם 1 בינואר 2023 ו-1 בדצמבר 2023, בהתאמה. חלון הזכאות להארכת התקופה של ההתחייבות הראשונה נשאר פתוח עד 1 במאי 2020, ושל ההתחייבות השנייה עד 1 באפריל 2021. אם תמזגו את ההתחייבויות האלה ב-1 במרץ 2022, ההתחייבות הממוזגת תהיה התחייבות לתקופה בהתאמה אישית, עם תאריך התחלה ב-2 במרץ 2022 ותאריך סיום ב-1 בדצמבר 2023. חלון הזכאות להארכת התקופה של ההתחייבות הממוזגת כבר היה מסתיים עד 1 במאי 2020.

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

דוגמה להתחייבות ממוזגת

בטבלה הבאה מוצגים המאפיינים של ההתחייבויות המקוריות וההתחייבות הממוזגת, כשממזגים שתי התחייבויות (source-commitment-1 ו-source-commitment-2) להתחייבות אחת (merged-commitment) ב-1 במרץ 2022:

התחייבות למקור ראשון התחייבות למקור שני התחייבות ממוזגת
שם source-commitment-1 source-commitment-2 merged-commitment
סוג N2 N2 N2
אזור us-central1 us-central1 us-central1
Resources
  • מעבדים וירטואליים: 100
  • זיכרון: 100GB
  • מעבדים וירטואליים: 200
  • זיכרון: 300GB
  • מעבדים וירטואליים: 300
  • זיכרון: 400GB
תוכנית ‫3 שנים ‫3 שנים ‫3 שנים
תקופה ‫3 שנים ‫3 שנים מותאם אישית (שנה ו-9 חודשים)
תאריך התחלה* ‫1 בינואר 2020 ‫1 בדצמבר 2020 ‫2 במרץ 2022
(היום שאחרי המיזוג)
תאריך סיום† ‫1 בינואר 2023 ‫1 בדצמבר 2023 ‫1 בדצמבר 2023
חלון הזכאות להארכת התקופה פתוח עד ‫1 במאי 2020 ‫1 באפריל 2021 ‫1 במאי 2020

‫*כל ההתחייבויות מתחילות בשעה 00:00 (חצות) לפי שעון החוף המערבי בארה"ב ובקנדה (UTC-8 או UTC-7) בתאריך ההתחלה שצוין.
†כל ההתחייבויות מסתיימות בשעה 00:00 (חצות) לפי שעון החוף המערבי בארה"ב ובקנדה (UTC-8 או UTC-7) בתאריך הסיום שצוין.

ההשפעות על התמחור

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

מגבלות

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

דרישות

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

  • ההתחייבויות במקור צריכות להיות באותו פרויקט, אזור, תוכנית התחייבות, סוג התחייבות וקטגוריית התחייבות.
  • ההתחייבות הממוזגת צריכה להיות באותו פרויקט, אזור, תוכנית התחייבות, סוג התחייבות וקטגוריית התחייבות כמו ההתחייבויות המקוריות. עם זאת, אתם יכולים לבחור שם חדש להתחייבות הממוזגת.
  • סוגי המשאבים שאתם מציינים בהתחייבות הממוזגת חייבים להיות זהים לסוגי המשאבים בהתחייבויות המקור. בנוסף, הכמות של כל סוג משאב בהתחייבות הממוזגת צריכה להיות הסכום של הכמויות של אותו סוג משאב בכל ההתחייבויות המקוריות. לדוגמה, אם בהתחייבות הראשונה יש 100 vCPUs ו-100GB זיכרון, ובהתחייבות השנייה יש 200 vCPUs ו-300GB זיכרון, ההתחייבות הממוזגת צריכה להיות עם 300 vCPUs ו-400GB זיכרון.
  • ההתחייבויות המקוריות וההתחייבות הממוזגת חייבות להיות למשאבי חומרה (vCPU, זיכרון, GPU ודיסקים מקומיים של SSD).

יצירת התחייבויות ממוזגות

יוצרים התחייבות ממוזגת באמצעות מסוף Google Cloud , ה-CLI של gcloud או REST. לפני שאתם ממזגים התחייבויות, קראו את המגבלות על מיזוג.

המסוף

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

    לדף Committed use discounts

  2. כדי להתחיל את פעולת המיזוג של קבוצת התחייבויות, בכרטיסייה Hardware commitments שבדף Commitment list לוחצים על Merge.

    לחלופין, אפשר לבחור מהרשימה את ההתחייבויות שרוצים למזג וללחוץ על Merge.

  3. בכרטיסייה Choose commitment בדף Merge שנפתח:

    1. בקטע Choose commitments to merge, בוחרים מהרשימה את ההתחייבויות שרוצים למזג. אם כבר בחרתם את ההתחייבויות האלה בדף Commitment list, אתם צריכים לאמת את ההתחייבויות שבחרתם בכרטיסייה הזו.

      אופציונלי: כדי לסנן את רשימת ההתחייבויות, לפני שבוחרים התחייבויות כלשהן, מציינים את הערכים של Plan, ‏ Region ו-Commitment type להתחייבות הממוזגת.

    2. לוחצים על הבא. הכרטיסייה בדיקה נפתחת.

  4. בכרטיסייה Review בדף Merge, מבצעים את הפעולות הבאות:

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

    2. בשדה New commitment name, נותנים שם להתחייבות הממוזגת.

    3. אופציונלי: כדי להפעיל חידוש אוטומטי בהתחייבות הממוזגת, מסמנים את התיבה Enable auto renew.

    4. קוראים את התנאים וההגבלות.

    5. כדי לסיים את המיזוג ולחזור לדף Commitment list, לוחצים על Merge.

gcloud

כדי למזג התחייבויות קיימות להתחייבות אחת, משתמשים בפקודה gcloud compute commitments create עם הדגל --merge-source-commitments.

gcloud compute commitments create COMMITMENT_NAME \
    --region=REGION \
    --project=PROJECT_ID \
    --plan=COMMITMENT_PLAN \
    --type=COMMITMENT_TYPE \
    --resources=vcpu=NUMBER_VCPUS,memory=MEMORY \
    --merge-source-commitments=SOURCE_COMMITMENT_URLS

מחליפים את מה שכתוב בשדות הבאים:

  • ‫COMMITMENT_NAME: השם של ההתחייבות הממוזגת החדשה.
  • ‫NUMBER_VCPUS: סכום מספרי ה-vCPU בהתחייבויות המקור.
  • ‫COMMITMENT_TYPE: סוג ההתחייבות זהה לזה של ההתחייבויות במקור, אחד מהבאים:

    • למכונות מסוג A2, משתמשים ב-accelerator-optimized
    • למכונות מסוג A3 Edge ו-A3 High, משתמשים ב-accelerator-optimized-a3
    • למכונות מסוג A3 Mega, משתמשים ב-accelerator-optimized-a3-mega
    • לסוגי מכונות G2, משתמשים ב-graphics-optimized
    • לסוגי מכונות G4, משתמשים ב-graphics-optimized-g4
    • לסוגי מכונות C2, משתמשים ב-compute-optimized
    • לסוגי מכונות C2D, משתמשים ב-compute-optimized-c2d
    • לסוגי מכונות C3, משתמשים ב-compute-optimized-c3
    • למכונות מסוג C3D, משתמשים ב-compute-optimized-c3d
    • במכונות מסוג H3, משתמשים ב-compute-optimized-h3
    • למכונות מסוג H4D, משתמשים ב-compute-optimized-h4d
    • לסוגי מכונות N1, משתמשים ב-general-purpose
    • לסוגי מכונות C4, משתמשים ב-general-purpose-c4
    • בסוגי מכונות C4A, משתמשים ב-general-purpose-c4a
    • בסוגי מכונות C4D, משתמשים ב-general-purpose-c4d
    • בסוגי מכונות C4N, משתמשים ב-network-optimized-c4n
    • לסוגי מכונות E2, משתמשים ב-general-purpose-e2
    • למכונות מסוג N2, משתמשים ב-general-purpose-n2
    • לסוגי מכונות N2D, משתמשים ב-general-purpose-n2d
    • במכונות מסוג N4, משתמשים ב-general-purpose-n4
    • בסוגי מכונות N4D, משתמשים ב-general-purpose-n4d
    • לסוגי מכונות N4A, משתמשים ב-general-purpose-n4a
    • לסוגי מכונות Tau T2D, משתמשים ב-general-purpose-t2d
    • למכונות מסוג M1 או M2, משתמשים ב-memory-optimized
    • לסוגי מכונות M3, משתמשים ב-memory-optimized-m3
    • למכונות מסוג M4 עם זיכרון בנפח 6TB, משתמשים ב-memory-optimized-m4-6tb
    • לסוגי מכונות אחרים של M4, משתמשים ב-memory-optimized-m4
    • לסוג המכונה M4N עם זיכרון בנפח 6TB, משתמשים ב-memory-optimized-m4n-6tb
    • לסוגי מכונות אחרים של M4N, משתמשים ב-memory-optimized-m4n
    • במכונות מסוג X4 עם זיכרון בנפח 6TB, משתמשים ב-memory-optimized-x4-6t
    • למכונות מסוג X4 עם זיכרון בנפח 8TB, משתמשים ב-memory-optimized-x4-8t
    • במכונות מסוג X4 עם זיכרון בנפח 12TB, משתמשים ב-memory-optimized-x4-12t
    • במכונות מסוג X4 עם זיכרון בנפח 16TB, משתמשים ב-memory-optimized-x4-960-16t
    • במכונות מסוג X4 עם זיכרון בנפח 24TB, משתמשים ב-memory-optimized-x4-1440-24t
    • במכונות מסוג X4 עם זיכרון בנפח 32TB, משתמשים ב-memory-optimized-x4-1920-32t
    • במכונות מסוג Z3, משתמשים ב-storage-optimized-z3
    • במכונות מסוג Z4D, משתמשים ב-storage-optimized-z4d
    • במכונות מסוג Z4M, משתמשים ב-storage-optimized-z4m

  • ‫REGION: אותו אזור כמו ההתחייבויות המקוריות.

  • ‫PROJECT_ID: מזהה הפרויקט שבו רוצים למזג את ההתחייבויות.

  • ‫COMMITMENT_PLAN: תוכנית ההתחייבות (‎12-month או ‎36-month), שצריכה להיות זהה להתחייבויות המקור.

  • ‫MEMORY: סכום נפחי הזיכרון, ב-MB או ב-GB, בהתחייבויות במקור. לדוגמה, 1,000MB. אם לא מציינים יחידה, ברירת המחדל היא GB.

  • ‫SOURCE_COMMITMENT_URLS: רשימה מופרדת בפסיקים של שתי כתובות URL שונות לפחות של התחייבויות מקור. אל תוסיפו רווחים בין כתובות ה-URL.

לדוגמה, נניח שיש שתי התחייבויות במקור באזור us-east1, עם משאבים שצוינו בתור ארבעה מעבדי N2 וירטואליים ו-2,048MB, ושלושה מעבדי N2 וירטואליים ו-2,048MB, בהתאמה. תוכנית ההתחייבות של כל התחייבות מקור היא 12-month. הפקודה הבאה ב-CLI של gcloud ממזגת את שתי ההתחייבויות ויוצרת התחייבות חדשה בשם merged-commitment. בהתחייבות הממוזגת, המשאבים הם שבעה מעבדי N2 vCPU ו-4,096MB, ותוכנית ההתחייבות היא 12-month:

gcloud compute commitments create merged-commitment \
    --plan=12-month \
    --project=myproject \
    --region=us-east1 \
    --type=general-purpose-n2 \
    --resources=vcpu=7,memory=4096MB \
    --merge-source-commitments=projects/myproject/regions/us-east1/commitments/source-commitment-1,projects/myproject/regions/us-east1/commitments/source-commitment-2

REST

כדי למזג התחייבויות קיימות להתחייבות אחת, משתמשים בשיטה regionCommitments.insert.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION/commitments
{
  "name": "COMMITMENT_NAME",
  "plan": "COMMITMENT_PLAN",
  "type": "COMMITMENT_TYPE",
  "region": "REGION",
  "resources": [
    {
      "type": "VCPU",
      "amount": "NUMBER_VCPUS"
    },
    {
      "type": "MEMORY",
      "amount": "MEMORY"
    }
  ],
  "mergeSourceCommitments": ["SOURCE_COMMITMENT_URL" ...]
}

מחליפים את מה שכתוב בשדות הבאים:

  • ‫PROJECT_ID: מזהה הפרויקט שבו רוצים למזג את ההתחייבויות.
  • ‫REGION: אותו אזור כמו ההתחייבויות המקוריות.
  • ‫COMMITMENT_TYPE: סוג ההתחייבות, שצריך להיות זהה לסוג ההתחייבות במקור. הערכים האפשריים:

    • למכונות מסוג A2, משתמשים ב-ACCELERATOR_OPTIMIZED
    • למכונות מסוג A3 Edge ו-A3 High, משתמשים ב-ACCELERATOR_OPTIMIZED_A3
    • למכונות מסוג A3 Mega, משתמשים ב-ACCELERATOR_OPTIMIZED_A3_MEGA
    • לסוגי מכונות G2, משתמשים ב-GRAPHICS_OPTIMIZED
    • לסוגי מכונות G4, משתמשים ב-GRAPHICS_OPTIMIZED_G4
    • לסוגי מכונות C2, משתמשים ב-COMPUTE_OPTIMIZED
    • לסוגי מכונות C2D, משתמשים ב-COMPUTE_OPTIMIZED_C2D
    • לסוגי מכונות C3, משתמשים ב-COMPUTE_OPTIMIZED_C3
    • למכונות מסוג C3D, משתמשים ב-COMPUTE_OPTIMIZED_C3D
    • במכונות מסוג H3, משתמשים ב-COMPUTE_OPTIMIZED_H3
    • למכונות מסוג H4D, משתמשים ב-COMPUTE_OPTIMIZED_H4D
    • לסוגי מכונות N1, משתמשים ב-GENERAL_PURPOSE
    • לסוגי מכונות C4, משתמשים ב-GENERAL_PURPOSE_C4
    • בסוגי מכונות C4A, משתמשים ב-GENERAL_PURPOSE_C4A
    • בסוגי מכונות C4D, משתמשים ב-GENERAL_PURPOSE_C4D
    • בסוגי מכונות C4N, משתמשים ב-NETWORK_OPTIMIZED_C4N
    • לסוגי מכונות E2, משתמשים ב-GENERAL_PURPOSE_E2
    • למכונות מסוג N2, משתמשים ב-GENERAL_PURPOSE_N2
    • לסוגי מכונות N2D, משתמשים ב-GENERAL_PURPOSE_N2D
    • במכונות מסוג N4, משתמשים ב-GENERAL_PURPOSE_N4
    • בסוגי מכונות N4D, משתמשים ב-GENERAL_PURPOSE_N4D
    • לסוגי מכונות N4A, משתמשים ב-GENERAL_PURPOSE_N4A
    • לסוגי מכונות Tau T2D, משתמשים ב-GENERAL_PURPOSE_T2D
    • למכונות מסוג M1 או M2, משתמשים ב-MEMORY_OPTIMIZED
    • לסוגי מכונות M3, משתמשים ב-MEMORY_OPTIMIZED_M3
    • למכונות מסוג M4 עם זיכרון בנפח 6TB, משתמשים ב-MEMORY_OPTIMIZED_M4_6TB
    • לסוגי מכונות אחרים של M4, משתמשים ב-MEMORY_OPTIMIZED_M4
    • לסוג המכונה M4N עם זיכרון בנפח 6TB, משתמשים ב-MEMORY_OPTIMIZED_M4N_6TB
    • לסוגי מכונות אחרים של M4N, משתמשים ב-MEMORY_OPTIMIZED_M4N
    • במכונות מסוג X4 עם זיכרון בנפח 6TB, משתמשים ב-MEMORY_OPTIMIZED_X4_480_6T
    • למכונות מסוג X4 עם זיכרון בנפח 8TB, משתמשים ב-MEMORY_OPTIMIZED_X4_480_8T
    • במכונות מסוג X4 עם זיכרון בנפח 12TB, משתמשים ב-MEMORY_OPTIMIZED_X4_960_12T
    • במכונות מסוג X4 עם זיכרון בנפח 16TB, משתמשים ב-MEMORY_OPTIMIZED_X4_960_16T
    • במכונות מסוג X4 עם זיכרון בנפח 24TB, משתמשים ב-MEMORY_OPTIMIZED_X4_1440_24T
    • במכונות מסוג X4 עם זיכרון בנפח 32TB, משתמשים ב-MEMORY_OPTIMIZED_X4_1920_32T
    • במכונות מסוג Z3, משתמשים ב-STORAGE_OPTIMIZED_Z3
    • במכונות מסוג Z4D, משתמשים ב-STORAGE_OPTIMIZED_Z4D
    • במכונות מסוג Z4M, משתמשים ב-STORAGE_OPTIMIZED_Z4M

  • ‫COMMITMENT_PLAN: תוכנית ההתחייבות ('TWELVE_MONTH' או 'THIRTY_SIX_MONTH'), שחייבת להיות זהה להתחייבויות המקוריות.

  • ‫COMMITMENT_NAME: השם של ההתחייבות הממוזגת החדשה.

  • ‫NUMBER_VCPUS: המספר הכולל של מעבדי ה-vCPU בהתחייבויות המקור.

  • ‫MEMORY: סכום נפחי הזיכרון (ב-MB) בהתחייבויות המקור. לדוגמה, 1,000MB. אם לא מציינים יחידה, יחידת ברירת המחדל היא MB.

  • ‫SOURCE_COMMITMENT_URL: כתובת ה-URL של ההתחייבות המקורית שרוצים למזג. צריך לציין רשימה מופרדת בפסיקים של כתובות URL נפרדות של התחייבויות מקור.

לדוגמה, נניח שיש שתי התחייבויות במקור (source-commitment-1 ו-source-commitment-2) באזור us-east1, והמשאבים שלהן הם (ארבעה מעבדי N2 vCPU ו-2048MB) ו-(שלושה מעבדי N2 vCPU ו-2048MB), בהתאמה. תוכנית ההתחייבות של כל התחייבות במקור היא TWELVE_MONTH. הבקשה הבאה, POST, ממזגת את ההתחייבויות במקור ויוצרת התחייבות חדשה בשם merged-commitment. בהתחייבות הממוזגת מוגדרים המשאבים הבאים: שבעה מעבדי N2 vCPU ו-4,096MB, ותוכנית ההתחייבות היא TWELVE_MONTH.

POST https://compute.googleapis.com/compute/v1/projects/myproject/regions/us-east1/commitments
{
  "name": "merged-commitment",
  "plan": "TWELVE_MONTH",
  "type": "GENERAL_PURPOSE_N2",
  "region": "us-east1",
  "resources": [
    {
      "type": "VCPU",
      "amount": "7"
    },
    {
      "type": "MEMORY",
      "amount": "4096"
    }
  ],
  "mergeSourceCommitments": [
    "projects/myproject/regions/us-east1/commitments/source-commitment-1",
    "projects/myproject/regions/us-east1/commitments/source-commitment-2",
    ...
  ]
}

פיצול התחייבויות

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

איך הפיצול עובד

כשמפצלים התחייבות קיימת (התחייבות המקור), מעבירים משאבים מהתחייבות המקור, יוצרים התחייבות חדשה אחת או יותר (התחייבויות מפוצלות) ומחלקים מחדש את המשאבים שהועברו בין ההתחייבויות המפוצלות החדשות. ההפעלה של ההתחייבויות המפוצלות ושינוי הגודל של ההתחייבות המקורית מתרחשים בשעה 12:00 בלילה לפי שעון החוף המערבי בארה"ב ובקנדה (UTC-8, או UTC-7 במהלך שעון קיץ) ביום הבא. ‫Compute Engine מגדיר את תאריך ההפעלה הזה כתאריך ההתחלה של ההתחייבויות המפוצלות. אחרי שהפיצול מסתיים, אלה ההתחייבויות שלכם:

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

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

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

אפשר ליצור רק התחייבות מפוצלת חדשה אחת בכל פעם באמצעות REST ו-CLI של gcloud. אתם יכולים ליצור כמה התחייבויות מפוצלות חדשות בפעולה אחת באמצעות מסוף Google Cloud .

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

דוגמה להתחייבות מפוצלת

בטבלה הבאה מוצגים מאפייני ההתחייבות כשמפצלים התחייבות קיימת (source-commitment) לשתי התחייבויות נפרדות (source-commitment בנפח שונה ו-split-commitment) ב-1 במרץ 2022:

התחייבות במקור
(לפני הפיצול)
התחייבות מפוצלת ההתחייבות המקורית
(אחרי הפיצול)
שם source-commitment split-commitment source-commitment
סוג N2 N2 N2
אזור us-central1 us-central1 us-central1
Resources
  • מעבדים וירטואליים: 200
  • זיכרון: 200GB
  • מעבדים וירטואליים: 50
  • זיכרון: 100GB
  • מעבדים וירטואליים: 150
  • זיכרון: 100GB
תוכנית ‫3 שנים ‫3 שנים ‫3 שנים
תקופה ‫3 שנים בהתאמה אישית (10 חודשים) ‫3 שנים
תאריך התחלה* ‫1 בינואר 2020 ‫2 במרץ 2022
(היום שאחרי הפיצול)
‫1 בינואר 2020
תאריך סיום† ‫1 בינואר 2023 ‫1 בינואר 2023 ‫1 בינואר 2023
חלון הזכאות להארכת התקופה פתוח עד ‫1 בינואר 2021 ‫1 בינואר 2021 ‫1 בינואר 2021

‫*כל ההתחייבויות מתחילות בשעה 00:00 (חצות) לפי שעון החוף המערבי בארה"ב ובקנדה (UTC-8 או UTC-7) בתאריך ההתחלה שצוין.
†כל ההתחייבויות מסתיימות בשעה 00:00 (חצות) לפי שעון החוף המערבי בארה"ב ובקנדה (UTC-8 או UTC-7) בתאריך הסיום שצוין.

ההשפעות על התמחור

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

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

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

מגבלות

  • אי אפשר לפצל התחייבויות לרישיונות תוכנה או התחייבויות לאחסון בלוקים.
  • אי אפשר לפצל התחייבויות שרכשתם באמצעות מקום שמור לעתיד של גושי קיבולת.
  • אי אפשר לפצל התחייבויות עם מקומות שמורים מצורפים. לכן אי אפשר לפצל התחייבויות שיש בהן מעבדי GPU, דיסקים של SSD מקומיים או שניהם, כי להתחייבויות עם המשאבים האלה תמיד מצורפות הזמנות.
  • אי אפשר לצרף התחייבויות מפוצלות להזמנות (חדשות או קיימות).
  • אי אפשר לפצל התחייבויות שהתוקף שלהן פג או שהן בוטלו.
  • כברירת מחדל, כשמפצלים התחייבויות, הגדרת החידוש האוטומטי מושבתת בהתחייבויות המפוצלות, גם אם כל ההתחייבויות המקוריות הוגדרו לחידוש אוטומטי. אם אתם רוצים שההתחייבויות המפוצלות יחודשו באופן אוטומטי, אתם צריכים להפעיל ידנית את הגדרת החידוש האוטומטי בהתחייבויות האלה. אפשר לעשות את זה בזמן היצירה או אחרי היצירה.
  • אפשר ליצור רק התחייבות מפוצלת חדשה אחת בכל פעם באמצעות REST או ה-CLI של gcloud. לכן, כשמשתמשים בממשקים האלה, אפשר לפצל את ההתחייבות המקורית לשתי התחייבויות לכל היותר בפעולה אחת. כדי לפצל את ההתחייבות המקורית לשלוש התחייבויות או יותר בפעולה אחת, צריך להשתמש ב-Google Cloud מסוף.
  • במסוף Google Cloud אפשר לציין זיכרון רק במרווחים של 0.25GB. כדי לציין ערך זיכרון בהתאמה אישית להתחייבות, צריך להשתמש ב-CLI של gcloud או ב-REST.

דרישות

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

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

    • אתם יכולים לחלק חלק מ-200 ה-vCPU וחלק מ-300GB הזיכרון בין ההתחייבויות המפוצלות.
    • אתם יכולים להפיץ מחדש את כל 200 ה-vCPU, אבל אתם צריכים לשמור חלק מהזיכרון בהתחייבות המקורית.
    • אתם יכולים להקצות מחדש את כל 300GB הזיכרון, אבל אתם צריכים לשמור חלק ממעבדי ה-vCPU בהתחייבות המקורית.
    • אי אפשר לחלק מחדש את כל 200 ה-vCPUs ואת כל 300GB הזיכרון בין ההתחייבויות המפוצלות.
  • בהתחייבויות המקוריות והמפוצלות אפשר לציין רק את משאבי החומרה הבאים: מעבדי vCPU, זיכרון או שילוב של שניהם.

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

יצירת התחייבויות מפוצלות

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

המסוף

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

    לדף Committed use discounts

  2. כדי לפצל התחייבות, בכרטיסייה Hardware commitments בדף Commitment list:

    • בוחרים מהרשימה את ההתחייבות שרוצים לפצל ולוחצים על Split.
    • בעמודה Name, לוחצים על שם ההתחייבות שרוצים לפצל. בדף Hardware commitment details שנפתח, לוחצים על Split.
  3. בכרטיסייה Resize בדף Split commitment שנפתח, מבצעים את הפעולות הבאות:

    1. בשדות vCPUs ו-Memory, מציינים את מספר המעבדים הווירטואליים ואת נפח הזיכרון שרוצים לשמור מההתחייבות המקורית. את שאר המשאבים אפשר להקצות מחדש להתחייבות המפוצלת. ההתחייבות המקורית לא יכולה להיות ריקה אחרי שמשנים את הגודל שלה.
    2. לוחצים על הבא. הכרטיסייה הפצה מחדש נפתחת.
  4. בכרטיסייה Redistribute בדף Split commitment, מבצעים את הפעולות הבאות:

    1. בשדה Name, נותנים שם להתחייבות המפוצלת.
    2. בשדות vCPUs ו-Memory, מציינים את מספר המעבדים הווירטואליים ואת נפח הזיכרון של ההתחייבות המפוצלת. אפשר לציין זיכרון רק במרווחים של 0.25GB. כדי לציין ערך זיכרון בהתאמה אישית להתחייבות, צריך להשתמש ב-CLI של gcloud או ב-REST.

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

    3. אופציונלי: כדי להפעיל חידוש אוטומטי של ההתחייבות המפוצלת, מסמנים את התיבה Enable auto renew.

    4. לוחצים על סיום.

    5. אופציונלי: כדי ליצור התחייבויות מפוצלות נוספות, לוחצים על Add an item וחוזרים על השלבים הקודמים.

    6. לוחצים על הבא. הכרטיסייה בדיקה נפתחת.

  5. בכרטיסייה Review בדף Split commitment:

    1. בודקים ומאשרים את פרטי ההתחייבות ששיניתם את הגודל שלה ואת פרטי ההתחייבויות שפיצלתם.
      • כדי לשנות את הקצאת המשאבים מההתחייבות המקורית, בוחרים בכרטיסייה Resize בצד שמאל של החלון וחוזרים על שלב 3.
      • כדי לשנות את חלוקת המשאבים בין ההתחייבויות המפוצלות, לוחצים על הכרטיסייה Redistribute בצד שמאל של החלון וחוזרים על שלב 4.
    2. קוראים את התנאים וההגבלות.
    3. כדי לסיים את יצירת ההתחייבויות המפוצלות ולחזור לדף Commitment list, לוחצים על Submit.

gcloud

כדי לפצל התחייבות קיימת לשתי התחייבויות, משתמשים בפקודה gcloud compute commitments create עם הדגל --split-source-commitment.

gcloud compute commitments create COMMITMENT_NAME \
    --region=REGION \
    --project=PROJECT_ID \
    --plan=COMMITMENT_PLAN \
    --type=COMMITMENT_TYPE \
    --resources=vcpu=NUMBER_VCPUS,memory=MEMORY \
    --split-source-commitment=SOURCE_COMMITMENT_URL

מחליפים את מה שכתוב בשדות הבאים:

  • ‫COMMITMENT_NAME: השם של ההתחייבות המפוצלת החדשה.
  • ‫COMMITMENT_TYPE: סוג ההתחייבות, שזהה לסוג ההתחייבות במקור. אחד מהבאים:

    • למכונות מסוג A2, משתמשים ב-accelerator-optimized
    • למכונות מסוג A3 Edge ו-A3 High, משתמשים ב-accelerator-optimized-a3
    • למכונות מסוג A3 Mega, משתמשים ב-accelerator-optimized-a3-mega
    • לסוגי מכונות G2, משתמשים ב-graphics-optimized
    • לסוגי מכונות G4, משתמשים ב-graphics-optimized-g4
    • לסוגי מכונות C2, משתמשים ב-compute-optimized
    • לסוגי מכונות C2D, משתמשים ב-compute-optimized-c2d
    • לסוגי מכונות C3, משתמשים ב-compute-optimized-c3
    • למכונות מסוג C3D, משתמשים ב-compute-optimized-c3d
    • במכונות מסוג H3, משתמשים ב-compute-optimized-h3
    • למכונות מסוג H4D, משתמשים ב-compute-optimized-h4d
    • לסוגי מכונות N1, משתמשים ב-general-purpose
    • לסוגי מכונות C4, משתמשים ב-general-purpose-c4
    • בסוגי מכונות C4A, משתמשים ב-general-purpose-c4a
    • בסוגי מכונות C4D, משתמשים ב-general-purpose-c4d
    • בסוגי מכונות C4N, משתמשים ב-network-optimized-c4n
    • לסוגי מכונות E2, משתמשים ב-general-purpose-e2
    • למכונות מסוג N2, משתמשים ב-general-purpose-n2
    • לסוגי מכונות N2D, משתמשים ב-general-purpose-n2d
    • במכונות מסוג N4, משתמשים ב-general-purpose-n4
    • בסוגי מכונות N4D, משתמשים ב-general-purpose-n4d
    • לסוגי מכונות N4A, משתמשים ב-general-purpose-n4a
    • לסוגי מכונות Tau T2D, משתמשים ב-general-purpose-t2d
    • למכונות מסוג M1 או M2, משתמשים ב-memory-optimized
    • לסוגי מכונות M3, משתמשים ב-memory-optimized-m3
    • למכונות מסוג M4 עם זיכרון בנפח 6TB, משתמשים ב-memory-optimized-m4-6tb
    • לסוגי מכונות אחרים של M4, משתמשים ב-memory-optimized-m4
    • לסוג המכונה M4N עם זיכרון בנפח 6TB, משתמשים ב-memory-optimized-m4n-6tb
    • לסוגי מכונות אחרים של M4N, משתמשים ב-memory-optimized-m4n
    • במכונות מסוג X4 עם זיכרון בנפח 6TB, משתמשים ב-memory-optimized-x4-6t
    • למכונות מסוג X4 עם זיכרון בנפח 8TB, משתמשים ב-memory-optimized-x4-8t
    • במכונות מסוג X4 עם זיכרון בנפח 12TB, משתמשים ב-memory-optimized-x4-12t
    • במכונות מסוג X4 עם זיכרון בנפח 16TB, משתמשים ב-memory-optimized-x4-960-16t
    • במכונות מסוג X4 עם זיכרון בנפח 24TB, משתמשים ב-memory-optimized-x4-1440-24t
    • במכונות מסוג X4 עם זיכרון בנפח 32TB, משתמשים ב-memory-optimized-x4-1920-32t
    • במכונות מסוג Z3, משתמשים ב-storage-optimized-z3
    • במכונות מסוג Z4D, משתמשים ב-storage-optimized-z4d
    • במכונות מסוג Z4M, משתמשים ב-storage-optimized-z4m

  • ‫REGION: אותו אזור כמו ההתחייבות המקורית.

  • ‫PROJECT_ID: מזהה הפרויקט שבו רוצים לפצל את ההתחייבות המקורית.

  • ‫COMMITMENT_PLAN: תוכנית ההתחייבות (‎12-month או ‎36-month), שצריכה להיות זהה להתחייבות המקורית.

  • ‫NUMBER_VCPUS: מספר ה-vCPU שרוצים להעביר מההתחייבות המקורית כדי ליצור את ההתחייבות המפוצלת החדשה. המספר הזה חייב להיות מספר שלם שקטן ממספר ה-vCPUs בהתחייבות המקורית.

  • ‫MEMORY: כמות הזיכרון, ב-MB או ב-GB, שרוצים להעביר מההתחייבות המקורית כדי ליצור את ההתחייבות המפוצלת החדשה. הכמות הזו חייבת להיות קטנה מכמות הזיכרון בהתחייבות המקורית. לדוגמה, 10,000MB. אם לא מציינים יחידה, יחידת ברירת המחדל היא GB.

  • ‫SOURCE_COMMITMENT_URL: כתובת ה-URL של ההתחייבות שממנה רוצים להקצות משאבים.

לדוגמה, נניח שיש התחייבות מקור (source-commitment) באזור us-east1 עם משאבים שמוגדרים בתור שלושה מעבדי N2 vCPU וזיכרון בנפח 2,048MB. תוכנית ההתחייבות של ההתחייבות המקורית היא 12-month. הפקודה הבאה ב-CLI של gcloud מפצלת את ההתחייבות לשתי התחייבויות נפרדות:

gcloud compute commitments create split-commitment \
    --plan=12-month \
    --type=general-purpose-n2 \
    --region=us-east1 \
    --project=myproject \
    --resources vcpu=1,memory=1024MB \
    --split-source-commitment=projects/myproject/regions/us-east1/commitments/source-commitment

כשמפצלים את source-commitment, המערכת של Compute Engine מבצעת את הפעולות הבאות:

  • הפקודה הזו לוקחת משאבים מ-source-commitment ויוצרת התחייבות חדשה split-commitment עם מעבד וירטואלי אחד מסוג N2 וזיכרון בנפח 1,024MB.
  • משנה את הגודל של source-commitment בהתאם למשאבים שנותרו.

REST

כדי לפצל התחייבות קיימת לשתי התחייבויות, משתמשים בשיטה regionCommitments.insert.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION/commitments
{
  "name": "COMMITMENT_NAME",
  "plan": "COMMITMENT_PLAN",
  "type": "COMMITMENT_TYPE",
  "region": "REGION",
  "resources": [
    {
      "type": "VCPU",
      "amount": "NUMBER_VCPUS"
    },
    {
      "type": "MEMORY",
      "amount": "MEMORY"
    }
  ],
  "splitSourceCommitment": "SOURCE_COMMITMENT_URL"
}

מחליפים את מה שכתוב בשדות הבאים:

  • ‫PROJECT_ID: מזהה הפרויקט שבו רוצים לפצל את ההתחייבות המקורית.
  • ‫REGION: אותו אזור כמו ההתחייבות המקורית.
  • ‫COMMITMENT_NAME: השם של ההתחייבות המפוצלת החדשה.
  • ‫COMMITMENT_TYPE: סוג ההתחייבות, שזהה לסוג ההתחייבות במקור. אחד מהבאים:

    • למכונות מסוג A2, משתמשים ב-ACCELERATOR_OPTIMIZED
    • למכונות מסוג A3 Edge ו-A3 High, משתמשים ב-ACCELERATOR_OPTIMIZED_A3
    • למכונות מסוג A3 Mega, משתמשים ב-ACCELERATOR_OPTIMIZED_A3_MEGA
    • לסוגי מכונות G2, משתמשים ב-GRAPHICS_OPTIMIZED
    • לסוגי מכונות G4, משתמשים ב-GRAPHICS_OPTIMIZED_G4
    • לסוגי מכונות C2, משתמשים ב-COMPUTE_OPTIMIZED
    • לסוגי מכונות C2D, משתמשים ב-COMPUTE_OPTIMIZED_C2D
    • לסוגי מכונות C3, משתמשים ב-COMPUTE_OPTIMIZED_C3
    • למכונות מסוג C3D, משתמשים ב-COMPUTE_OPTIMIZED_C3D
    • במכונות מסוג H3, משתמשים ב-COMPUTE_OPTIMIZED_H3
    • למכונות מסוג H4D, משתמשים ב-COMPUTE_OPTIMIZED_H4D
    • לסוגי מכונות N1, משתמשים ב-GENERAL_PURPOSE
    • לסוגי מכונות C4, משתמשים ב-GENERAL_PURPOSE_C4
    • בסוגי מכונות C4A, משתמשים ב-GENERAL_PURPOSE_C4A
    • בסוגי מכונות C4D, משתמשים ב-GENERAL_PURPOSE_C4D
    • בסוגי מכונות C4N, משתמשים ב-NETWORK_OPTIMIZED_C4N
    • לסוגי מכונות E2, משתמשים ב-GENERAL_PURPOSE_E2
    • למכונות מסוג N2, משתמשים ב-GENERAL_PURPOSE_N2
    • לסוגי מכונות N2D, משתמשים ב-GENERAL_PURPOSE_N2D
    • במכונות מסוג N4, משתמשים ב-GENERAL_PURPOSE_N4
    • בסוגי מכונות N4D, משתמשים ב-GENERAL_PURPOSE_N4D
    • לסוגי מכונות N4A, משתמשים ב-GENERAL_PURPOSE_N4A
    • לסוגי מכונות Tau T2D, משתמשים ב-GENERAL_PURPOSE_T2D
    • למכונות מסוג M1 או M2, משתמשים ב-MEMORY_OPTIMIZED
    • לסוגי מכונות M3, משתמשים ב-MEMORY_OPTIMIZED_M3
    • למכונות מסוג M4 עם זיכרון בנפח 6TB, משתמשים ב-MEMORY_OPTIMIZED_M4_6TB
    • לסוגי מכונות אחרים של M4, משתמשים ב-MEMORY_OPTIMIZED_M4
    • לסוג המכונה M4N עם זיכרון בנפח 6TB, משתמשים ב-MEMORY_OPTIMIZED_M4N_6TB
    • לסוגי מכונות אחרים של M4N, משתמשים ב-MEMORY_OPTIMIZED_M4N
    • במכונות מסוג X4 עם זיכרון בנפח 6TB, משתמשים ב-MEMORY_OPTIMIZED_X4_480_6T
    • למכונות מסוג X4 עם זיכרון בנפח 8TB, משתמשים ב-MEMORY_OPTIMIZED_X4_480_8T
    • במכונות מסוג X4 עם זיכרון בנפח 12TB, משתמשים ב-MEMORY_OPTIMIZED_X4_960_12T
    • במכונות מסוג X4 עם זיכרון בנפח 16TB, משתמשים ב-MEMORY_OPTIMIZED_X4_960_16T
    • במכונות מסוג X4 עם זיכרון בנפח 24TB, משתמשים ב-MEMORY_OPTIMIZED_X4_1440_24T
    • במכונות מסוג X4 עם זיכרון בנפח 32TB, משתמשים ב-MEMORY_OPTIMIZED_X4_1920_32T
    • במכונות מסוג Z3, משתמשים ב-STORAGE_OPTIMIZED_Z3
    • במכונות מסוג Z4D, משתמשים ב-STORAGE_OPTIMIZED_Z4D
    • במכונות מסוג Z4M, משתמשים ב-STORAGE_OPTIMIZED_Z4M

  • ‫COMMITMENT_PLAN: תוכנית ההתחייבות ('TWELVE_MONTH' או 'THIRTY_SIX_MONTH'), שחייבת להיות זהה להתחייבות המקורית.

  • ‫NUMBER_VCPUS: מספר ה-vCPU שרוצים להעביר מההתחייבות המקורית כדי ליצור את ההתחייבות המפוצלת החדשה. המספר הזה חייב להיות מספר שלם שקטן ממספר ה-vCPUs בהתחייבות המקורית.

  • ‫MEMORY: נפח הזיכרון (ב-MB) שרוצים להעביר מההתחייבות המקורית כדי ליצור את ההתחייבות המפוצלת החדשה. הכמות הזו חייבת להיות קטנה מכמות הזיכרון בהתחייבות המקורית. לדוגמה, 1,000MB. אם לא מציינים יחידה, ברירת המחדל היא MB.

  • ‫SOURCE_COMMITMENT_URL: כתובת ה-URL של ההתחייבות שממנה רוצים להעביר משאבים.

לדוגמה, נניח שיש התחייבות מקור (source-commitment) באזור us-east1 עם משאבים שמוגדרים בתור שלושה מעבדי N2 vCPU וזיכרון בנפח 2,048MB. תוכנית ההתחייבות של ההתחייבות המקורית היא TWELVE_MONTH. הבקשה הבאה ב-POST מפצלת את ההתחייבות לשתי התחייבויות נפרדות:

POST https://compute.googleapis.com/compute/v1/projects/myproject/regions/us-east1/commitments
{
  "name": "split-commitment",
  "plan": "TWELVE_MONTH",
  "type": "GENERAL_PURPOSE_N2",
  "region": "us-east1",
  "resources": [
    {
      "type": "VCPU",
      "amount": "1"
    },
    {
      "type": "MEMORY",
      "amount": "1024"
    }
  ],
  "splitSourceCommitment": "projects/myproject/regions/us-east1/commitments/source-commitment"
}

כשמפצלים את source-commitment, המערכת של Compute Engine מבצעת את הפעולות הבאות:

  • הפקודה הזו לוקחת משאבים מ-source-commitment ויוצרת התחייבות חדשה split-commitment עם מעבד וירטואלי אחד מסוג N2 וזיכרון בנפח 1,024MB.
  • משנה את הגודל של source-commitment בהתאם למשאבים שנותרו.

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