העברת עומסי עבודה מציוד ve1 שיצא משימוש

במאמר הזה מוסבר איך להעביר את עומסי העבודה של Google Cloud VMware Engine מציוד ve1 שיצא משימוש לציוד ve1 או ve2 נתמך. אפשר להעביר עומסי עבודה באחת משתי דרכים: באפשרות 1 מוסיפים אשכולות חומרה חדשים לענן פרטי קיים כדי ליצור ענן פרטי עם צמתים מעורבים, ובאפשרות 2 פורסים ענן פרטי חדש באמצעות חומרה חדשה.

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

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

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

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

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

אלה הדרישות הקריטיות שצריך לקחת בחשבון לפני שמתחילים בהעברה:

  • חלון העברה מוגבל של 60 יום: Google תתמוך בהעברה שלכם למשך 60 יום לכל היותר אחרי אישור הבקשה שלכם להגדלת מכסת הקיבולת של היעד:
    • במהלך התקופה הזו, עליכם להשלים את העברת עומס העבודה ולהוציא משימוש את החומרה שהוצאה משימוש.
    • אם משך המיגרציה של עומס העבודה חורג מ-60 ימים אחרי הקצאת אשכול היעד, אתם צריכים להשתמש ברישיון Broadcom משלכם (BYOL) כדי לכסות את כל השימוש שחורג מהזכויות הרגילות.

הגורמים שיכולים לחסום את ההעברה הם:

  • חוסם של מרחב כתובות IP (חוסם של אפשרות 1): אפשרות 1 (ענן פרטי עם צמתים מעורבים) מחייבת שלענן הפרטי הקיים יהיה מרחב מספיק של כתובות IP לניהול פנויות. צריך שיהיה מספיק מקום כדי לתמוך באשכול היעד הנוסף, שנדרשים בו לפחות שלושה צמתים. אם בלוק ה-CIDR הקיים שלכם אין תמיכה בלפחות שלושה צמתים נוספים, לא תוכלו להשתמש באפשרות 1. במקרה כזה, צריך לפרוס ענן פרטי חדש (אפשרות 2). כדי לבדוק אם אתם עומדים בדרישות, כדאי לעיין בקיבולת התוכנית עבור מרחב כתובות ה-IP.
  • תמיכה במסדי נתונים במיגרציה פעילה: חלק מפלטפורמות מסדי הנתונים לא יכולות לסבול מיגרציות פעילות של vMotion. מזהים את מופעי מסד הנתונים של מכונות ה-VM ומתכננים לבנות אותם מחדש ישירות באשכול היעד.
  • קישוריות VMware HCX: מכשירי VMware HCX Fleet לא תומכים ב-vMotion רגיל בשידור חי. צריך לתכנן פריסה מחדש של רשתות שירות HCX באשכול היעד. מידע נוסף זמין במאמר של Broadcom בנושא העברת מכשירי HCX ל-SSO, ל-PSC או ל-vCenter אחרים.

תכנון הקיבולת של מרחב כתובות ה-IP

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

  1. צפייה בטווח כתובות ה-IP לניהול ובגרסה של תוכנית ה-IP של הענן הפרטי. לעיון, אפשר לעיין בגרסאות של חלוקת טווח CIDR של רשתות משנה.
  2. ספירת מספר הצמתים הנוכחיים בענן הפרטי.
  3. בודקים את מספר הצמתים המקסימלי שנתמך על ידי גודל ה-CIDR. אפשר לעיין בטבלה גודל טווח ה-CIDR של רשתות המשנה ב-vSphere וב-vSAN.
  4. חישוב: Existing node count + 3 ≤ maximum nodes supported by CIDR size

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

תכנון הקיבולת של צומת

אם בהצעת הקיבולת העתידית שלכם מצוינים ve2 צמתים, צריך לעבוד עם צוות ניהול החשבון שלכם ב- Google Cloud כדי לקבוע את הגודל ואת סוגי הצמתים הנכונים (mega,‏ large,‏ standard או small) ואת המספרים המתאימים לעומסי העבודה שלכם.ve2 מפרטים טכניים זמינים במאמר סוגי צמתים של VMware Engine HCI.

דרישות לגבי רישיונות ותוכנה

כדאי לשים לב לדרישות הרישיון והתוכנה הבאות להעברה:

  • רישיונות Broadcom: אם משך העברת עומסי העבודה שלכם חורג מ-60 ימים אחרי הקצאת אשכול היעד, אתם צריכים להביא רישיון Broadcom משלכם כדי לכסות את כל הצריכה שחורגת מהזכויות הרגילות שלכם.
  • רשתות שירות של VMware HCX: מכשירי VMware HCX Fleet לא תומכים ב-vMotion. צריך לפרוס מחדש את רשתות שירותי HCX באשכול היעד. מידע נוסף זמין במאמר של Broadcom‏ Migrating HCX appliances to a different SSO, PSC, or vCenter (העברת מכשירי HCX ל-SSO, ל-PSC או ל-vCenter אחרים).
  • ניהול קבוצות מיקום: Google מקצה קיבולת בקבוצות המיקום הנכונות. בהגדרות של צמתים מעורבים, Cloud Customer Care מגדיר את האשכול החדש בקבוצת המיקום של היעד. אם אתם יוצרים ענן פרטי חדש, כדאי לשלוח את השם המתוכנן של הענן הפרטי לצוות ניהול החשבון שלכם לפני שאתם יוצרים אותו, כדי לוודא ש-Google תגדיר אותו בקבוצת המיקומים הנכונה.

התחייבויות וחיובים במינוי

לפני שבוחרים נתיב העברה, חשוב לעיין במגבלות הבאות לגבי הנחות תמורת התחייבות לשימוש (CUD):

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

הסבר על ההודעה בנושא סוף החיים של ve1

ההודעה על סוף החיים (EoL) היא אימייל רשמי שמיידע אתכם שהצמתים שלכם מסוג Bare Metal מתקרבים לסוף חיי השימוש שלהם.ve1ve1

רכיבים מרכזיים בהודעה על סוף החיים

ההודעה כוללת את הפרטים הבאים:

  • האזור והתחום שבהם חל תאריך סוף החיים.
  • השימוש הנוכחי: רשימה של כל הפרויקטים הפעילים ושל ve1 העננים הפרטיים באזור, עם הפרטים הבאים:
    • שם הענן הפרטי
    • מספר הפרויקט
    • שם האשכול
    • ve1 סוג הצומת (HCI או SON)
    • מספר הצמתים מסוג ve1 מכל סוג
    • תאריך סוף חיי המוצר שאחריו לא ניתן יותר לקבל תמיכה באשכול
  • הצעה לקיבולת עתידית: בהודעה על סוף החיים מופיעה הצעה לקיבולת עתידית לכל אשכול ve1 באזור:
    • אם קיבולת היעד היא ve1: אותו מספר צמתים כמו באשכול ve1 הנוכחי, עם הגדרה של משך שימוש ארוך מספיק.
    • אם קיבולת היעד היא ve2: סוג הצומת ve2-mega-128, שמציע משאבי מחשוב, זיכרון ואחסון שווים או גבוהים יותר.
    • הסכם רמת שירות (SLA) וסובלנות לכשל (FTT): לכל אשכול עם שלושה צמתים או יותר, המבצע העתידי כולל לפחות שלושה צמתים. כך מובטח ערך ברירת מחדל של FTT של 1.

שלבים להעברת מפתחות

ההעברה כוללת את השלבים הבאים:

  1. בודקים את מבצע קיבולת היעד לכל אשכול שמועד סוף החיים שלו מתקרב. אם אתם צריכים הגדרה אחרת (סוגי צמתים או כמות), תוכלו לעבוד עם צוות ניהול החשבון שלGoogle Cloud כדי לשנות את הצעת הקיבולת.
  2. ניהול הנחות תמורת התחייבות לשימוש (CUD): אם יש לכם התחייבויות פעילות ל-ve1 CUD שתוקפן נמשך מעבר לתאריכי סוף החיים של החומרה, כדאי לפנות לצוות התמיכה של החשבון כדי לשנות אותן או לבטל אותן.
  3. בוחרים את מסלול ההעברה: אפשר ליצור ענן פרטי עם משפחה של צמתים מעורבים או פריסה חדשה של ענן פרטי. כדי לעזור לכם להחליט, השוו בין שיטות ההעברה בקטע הבא.
  4. מבצעים את ההעברה: מעבירים את עומסי העבודה באמצעות המסלול שנבחר. יש לכם חלון תמיכה של עד 60 יום להשלמת ההעברה אחרי ש-Google מאשרת את בקשת המכסה שלכם.
  5. להוציא את החומרה הישנה משימוש: כדי להשלים את ההעברה, צריך למחוק את אשכולי ve1 שהוצאו משימוש ואת המכסות שמשויכות אליהם.

השוואה בין אפשרויות העברה

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

תכונה אפשרות 1: ענן פרטי היברידי עם צמתים מעורבים אפשרות 2: פריסה חדשה של ענן פרטי
תיאור מוסיפים אשכולות של משפחות חומרה לטירגוט ישירות לענן הפרטי הקיים. פריסת ענן פרטי חדש לגמרי בחומרת היעד.
דרישה לטווח כתובות IP לניהול נדרש מספיק מקום פנוי ב-CIDR בענן הפרטי הקיים כדי לתמוך באשכול שנוסף (מינימום שלושה צמתים). אין מספיק נפח אחסון פנוי, ולכן אי אפשר להשתמש באפשרות 1. גמישות. משתמש בטווח כתובות IP חדש לגמרי לניהול.
השפעה על רשת ו-DNS מינימלי. שמירה של הרשתות, רשתות המשנה וממשקי הניהול הנוכחיים. גבוהה. נדרשת הגדרה של טופולוגיות רשת חדשות, DNS וקואורדינטות גישה.
תהליך העבודה של המיגרציה ‫VMware vMotion ו-Storage vMotion רגילים בשידור חי. העברות בהיקף רחב באמצעות VMware HCX.
שיטת יצירה הבקשה נשלחה באמצעות כרטיס תמיכה של Cloud Customer Care (אי אפשר להוסיף אשכולות לעננים פרטיים היברידיים באופן עצמאי). שירות עצמי מלא (מסוף, API בארכיטקטורת REST,‏ Google Cloud CLI או Terraform).

אפשרות 1: מיגרציה של ענן פרטי עם צמתים מעורבים

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

שליחת בקשה למכסה עבור חומרה של יעד

  1. במסוף Google Cloud , שולחים בקשה להגדלת מכסה עבור משפחת החומרה החדשה לטירגוט (ve1 או ve2) ומספר הצמתים.
  2. בתיאור בקשת המכסה, צריך לכתוב במפורש את המאפיינים הבאים:
    • "ve1 hardware end of life"
    • "Retiring PC Name(s): [YOUR_PC_NAME(S)]"
    • "Retiring Cluster Name(s): [YOUR_CLUSTER_NAME(S)]"
  3. אחרי ש-Google תאשר את הבקשה, תוכלו לראות את המכסה החדשה במסוף.

יצירת אשכול היעד בענן הפרטי

  1. אי אפשר ליצור אשכולות בעננים פרטיים עם צמתים מעורבים. שולחים בקשת תמיכה כדי לבקש הגדרה של אשכול.
  2. בכרטיס התמיכה, מציינים את הפרטים הבאים:
    • מספר הפרויקט
    • שם הענן הפרטי
    • שם חדש של אשכול יעד
    • משפחת מכונות חדשה (ve1 או ve2) וסוג הצומת
    • מספר צמתים של HCI
    • מספר הצמתים שמשמשים רק לאחסון (אם רלוונטי)
  3. נציגי Cloud Customer Care יודיעו לכם כשהאשכול היעד יהיה אונליין.

העברת עומסי עבודה

אחרי שהאשכול של היעד מוכן, משתמשים בשילוב של VMware vMotion ו-storage vMotion כדי להעביר מכונות וירטואליות של עומסי עבודה ודיסקים של מכונות וירטואליות:

  1. ב-vSphere Client, לוחצים לחיצה ימנית על המכונה הווירטואלית ובוחרים באפשרות העברה.
  2. בוחרים באפשרות שינוי משאבי מחשוב ואחסון.
  3. בוחרים את האשכול החדש ואת מאגרי הנתונים ליעד.

העברת מכונות וירטואליות לניהול ענן פרטי

אם האשכול שמוציאים משימוש הוא האשכול הראשי (הראשון) של הענן הפרטי, צריך להעביר את מכונות ה-VM לניהול:

  1. משתמשים במסוף Google Cloud VMware Engine או ב-API בארכיטקטורת REST כדי להעביר מכונות וירטואליות לניהול לאשכול החדש. הוראות מפורטות מופיעות במאמר בנושא ניהול משאבים בענן פרטי.
  2. לא לבצע פעילויות אחרות באשכול (כמו הוספת צמתים) במהלך ההעברה. במהלך התהליך, הסטטוס של הענן הפרטי משתנה ל'מתעדכן'.
  3. מבטלים את הטעינה של כל מאגרי הנתונים של NFS שמחוברים לאשכולות הישנים של ve1.

שינוי הגדרות ויישומים אחרים

  • רשתות שירות של VMware HCX: מכשירי Fleet לא תומכים ב-vMotion. פורסים מחדש את רכיבי HCX Service Mesh באשכול היעד. מידע נוסף זמין במאמר של Broadcom‏ Migrating HCX appliances to a different SSO, PSC, or vCenter (העברת מכשירי HCX ל-SSO, ל-PSC או ל-vCenter אחרים). אם אתם צריכים עזרה, אתם יכולים לשלוח כרטיס תמיכה.
  • אפליקציות Aria: העברת מכונות וירטואליות של אפליקציות Aria דומה להעברת מכונות וירטואליות של עומסי עבודה רגילים.
  • פלטפורמות של מסדי נתונים: צריך לבנות מחדש את מופעי מסד הנתונים באשכול היעד אם הם לא יכולים לעמוד ב-vMotion.

הוצאה משימוש של האשכול שהוצא משימוש

  1. אחרי שמשלימים את ההעברה של עומסי העבודה והמכונות הווירטואליות לניהול ומאמתים אותה, צריך למחוק את האשכול שיצא משימוש באמצעות מסוף Google Cloud , ה-API ל-REST או שורת הפקודה של Google Cloud CLI.
  2. שולחים בקשה להקצאת נפח אחסון כדי להקטין את מכסת החומרה של אשכול המקור. בתיאור הבקשה, מציינים:
    • "ve1 hardware end of life"
    • "Retiring PC Name(s): [YOUR_PC_NAME(S)]"
    • "Retiring Cluster Name(s): [YOUR_CLUSTER_NAME(S)]"

אפשרות 2: העברה חדשה של ענן פרטי

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

בקשת מכסה

  1. שולחים בקשה להגדלת המכסה עבור חומרת היעד.
  2. בתיאור הבקשה, כותבים במפורש:
    • "ve1 hardware end of life"
    • "Retiring PC Name(s): [YOUR_PC_NAME(S)]"
    • "Retiring Cluster Name(s): [YOUR_CLUSTER_NAME(S)]"
    • "New PC Name: [YOUR_NEW_PC_NAME]"

יצירת הענן הפרטי החדש

  1. משתמשים במסוף, ב-API בארכיטקטורת REST, ב-Google Cloud CLI או ב-Terraform כדי לפרוס את הענן הפרטי החדש בחומרה של היעד. Google Cloud
  2. אם הפריסה הנוכחית שלכם משתמשת ברשת VMware Engine מדור קודם (רשת VMware Engine שנוצרה לפני נובמבר 2022), אתם יכולים ליצור את הענן הפרטי החדש באותו פרויקט כדי להמשיך להשתמש ברשת VMware Engine מדור קודם. מידע נוסף זמין במאמר בנושא רשתות רגילות ורשתות מדור קודם ב-Google Cloud VMware Engine.

העברת עומסי עבודה באמצעות HCX

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

שינוי שירותים ואפליקציות

  • ‫VMware HCX: פריסת רשתות שירות HCX בענן הפרטי החדש.
  • מוצרי Aria: אם אתם משתמשים בחבילות Aria עם רישיון מ-Google, אתם צריכים לבקש תמיכה כדי להתקין את Aria Suite Lifecycle Manager ‏ (LCM) בענן הפרטי החדש.

הוצאה משימוש של הענן הפרטי הישן

  1. אחרי שמוודאים שכל עומסי העבודה פועלים בענן הפרטי החדש, מוחקים את האשכולות הישנים ואת הענן הפרטי עצמו.
  2. שולחים בקשה למכסה כדי לבטל את המכסה שהוצאה משימוש. בתיאור הבקשה, מציינים:
    • "ve1 hardware end of life"
    • "Retiring PC Name(s): [YOUR_PC_NAME(S)]"
    • "Retiring Cluster Name(s): [YOUR_CLUSTER_NAME(S)]"

ניהול התחייבויות וחיובים

במהלך ההעברה, כדאי לעבוד עם צוות ניהול החשבון כדי לארגן את מבני החיוב ולהתאים את הנחות השימוש בהתחייבות (CUD).

שינויים בהנחות תמורת התחייבות לשימוש (CUD)

ההשפעה של מיגרציות החומרה שלכם ב-ve1 על הנחות פעילות תמורת התחייבות לשימוש (CUD) ב-ve1 תלויה בלוח הזמנים ובהצעות הקיבולת:

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

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