שיטות מומלצות להעברה

בדף הזה מפורטות כמה שיטות מומלצות להעברת מכונות וירטואליות (VM) של VMware לענן הפרטי באמצעות Google Cloud VMware Engine.

תכנון פרויקט ההעברה

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

  • לזהות את אנשי הצוות, כולל:

    • בעלי עניין של הלקוח
    • האחראי והבעלים של התוכנית
    • הצוות הטכני שאחראי על ההעברה
    • בעלי העניין במערכות ובאפליקציות שנכללות בהיקף
    • מנהל החשבונות הטכני (TAM) הרלוונטי ב-Google, מנהל הנדסה של שותפים (PEM) או Customer Engineer (CE)

  • בודקים את סביבת המקור.

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

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

  • חשוב לוודא שיש תיאום עם כל בעלי העניין.

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

כדי להעריך את אפשרויות המיגרציה השונות ל-VMware Engine, אפשר לשקול את האפשרויות הבאות:

  • כדאי לתכנן את ההעברה בגלים.

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

  • קובעים אסטרטגיה ל-Backup and DR של מכונות וירטואליות. מומלץ להשתמש ב-Google Cloud Backup and DR וב-VMware Engine Protected.

  • מוודאים שגרסאות vSphere,‏ vCenter,‏ HCX ו-NSX-T (אם רלוונטי) בפריסה המקומית עומדות בדרישות התאימות המינימליות לגרסאות של רכיבי VMware Engine.

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

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

  • פיתוח אסטרטגיות לפני ואחרי ההעברה לתוכן שלא ניתן להעביר בגלל חומרה או תיוג קבועים, כמו קובצי ISO מוטמעים, תגי NSX-T, מכשירי passthrough שמשתמשים ב-DirectPath I/O, דיסקים עם גישת כתיבה מרובה ו-RDMs פיזיים. לדוגמה, אפשר לשקול להמיר מכשירי RDM פיזיים למצב תאימות וירטואלי.

  • הערכה של שיטות ההעברה.

    מומלץ להשתמש בהעברה בכמות גדולה. חשוב לקרוא את הדרישות וההגבלות שקשורות לכך.

שימוש ב-VMware HCX להעברות

כשמשתמשים ב-HCX להעברה, כדאי להביא בחשבון את ההמלצות הבאות:

  • אף על פי שטופולוגיה שטוחה של רשת נתמכת בפריסות של HCX Connector ו-HCX Service Mesh, כדי למנוע בעיות ניתוב ושגיאות קישוריות, צריך להגדיר את HCX Management ואת פרופילי הרשת של HCX Uplink ברשתות וברשתות VLAN נפרדות.

  • ודאו שבסביבת VMware שלכם מותקנות הגרסאות האחרונות של HCX. מידע נוסף זמין במאמר HCX Service Update Procedures.

  • חשוב להגדיר גיבויים ושחזורים של HCX לפי הצורך.

    צוות ה-SRE מנהל גיבויים של HCX Manager, אבל לא של HCX Connector.

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

  • כשמגדילים את הרשת בשכבה 2 באמצעות תוספי רשת HCX, צריך להפעיל את האפשרות TCP Flow Conditioning. מידע נוסף זמין במאמר בנושא תכונות של ניהול תנועה שזמינות ב-HCX.

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

    ‫Google ממליצה להגדיר MTU של 1,350 עד 1,390 בייט או פחות לממשקי מכונות וירטואליות שמאפשרים העברת נתונים בדרכים הבאות:

    • מנקודת קצה מקומית לענן פרטי ולהפך
    • ממכונה וירטואלית בענן פרטי אחד למכונה וירטואלית בענן פרטי אחר דרך הרחבת L2

    הנחיות נוספות לחישוב התקורה של האנקפסולציה זמינות במאמרים שיקולים לגבי MTU ורשתות VPN של VMware NSX-T.

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