בעיות מוכרות
בדף הזה מתוארות בעיות ידועות שאתם עשויים להיתקל בהן במהלך השימוש ב-Google Cloud VMware Engine.
בעיות כלליות
ריכזנו כאן כמה בעיות כלליות ידועות שמשפיעות על VMware Engine.
התראות מובנות על שגיאות ב-vCenter pNIC מופעלות באירועי רשת זמניים
הבעיה: התראות מובנות של תשתית vCenter, כמו "זוהה שיעור שגיאות גבוה של pNIC", יכולות להופיע מדי פעם במסוף הלקוח של vSphere בגלל חריגות זמניות בחבילות מקומיות.
פרטים: מסגרת ההתראות המובנית של VMware בודקת את המונים של כרטיס הרשת הפיזי (pNIC) הבסיסי בחלונות דגימה קצרים וקשיחים. בגלל העיצוב הזה, vCenter יכול להפעיל התראות מיידיות על אירועים שגרתיים שלא משפיעים על המערכת, כמו רעש זמני או התנהגות צפויה של אובדן מנות בקישורים של vSAN במצב המתנה, גם כששכבת הרשת תקינה. בגלל יתירות הנתיבים המובנית, ההתראות האלה לא משפיעות על הזמינות של הסביבה או על תקינות הנתונים.
פתרון עקיף: לא נדרשת פעולה של הלקוח או פתרון עקיף. מכיוון שלא צפוי עדכון לרגישות הדגימה של ההתראות המובנות ב-vCenter בטווח הקצר, Google פרסה בינה מלאכותית בפלטפורמה הבסיסית כדי לנהל ולסנן את ההתראות החיוביות השגויות האלה. בסביבות ייצור מטורגטות, Google משביתה את ההתראות המובנות האלה במסוף שמוצגות ללקוחות. במקום זאת, מנוע הניתוח של Google Analytics עוקב אחרי נתוני התשתית ומעריך את השכבה הפיזית באופן רציף באמצעות ממוצע נע של 30 דקות. אם מנוע לניתוח נתונים של Google מזהה פגיעה פיזית מתמשכת, כמו כבל או רכיב אופטי פגומים, הפלטפורמה מתריעה באופן אוטומטי לתמיכה של Google כדי לחקור ולפתור את הבעיה, ושולחת לכם התראה אוטומטית באופן שיטתי.
סטטוס: זו מגבלה ידועה של לוגיקת הערכת ההתראות המובנית של vCenter. Google מנהלת את ההתנהגות הזו באמצעות בינה מלאכותית (AI) מובנית בפלטפורמה. VMware מודעת לבעיה הזו והציעה פתרון עקיף.
שדרוג של HCX Manager סומן בטעות כשדרוג של גרסת vSphere
הבעיה: שדרוג של HCX Manager מסומן בטעות כ "שדרוג גרסה של vSphere" במסוף Google Cloud .
פרטים: למרות שהתראות ספציפיות באימייל שמזהות את השדרוג של HCX נשלחות לפחות 14 ימים ו-24 שעות לפני האירוע, ההתראות האוטומטיות "העדכון של הענן הפרטי שלך התחיל" ו "העדכון של הענן הפרטי שלך הושלם" משקפות עדכון כללי של הענן הפרטי. בנוסף,Google Cloud בממשק של המסוף הפעולה מסומנת במפורש כשדרוג גרסה של vSphere. חוסר ההתאמה הזה יכול לגרום לבלבול, במיוחד אצל לקוחות שסיימו לאחרונה שדרוג מלא של סטאק (לדוגמה, vSphere 7.x ל-8.x), כי נראה שהסביבה עוברת עדכון משמעותי נוסף של הפלטפורמה.
פתרון עקיף: כדי לאשר את היקף העבודה, בודקים את הודעות האימייל הספציפיות ל-HCX שנשלחו לפני חלון הזמן לתחזוקה. אם לוח הזמנים תואם, הסטטוס "שדרוג גרסת vSphere" במסוף Google Cloud מתייחס רק לעדכון של HCX Manager. לא נדרשת שום פעולה.
סטטוס: זו מגבלה ידועה של העיצוב הנוכחי של מערכת ההתראות.
זמן הקצאה לעננים פרטיים ב-vSphere 8.0 update 3
הבעיה: VMware Engine פורס עכשיו עננים פרטיים חדשים עם VMware vSphere גרסה 8.0 עדכון 3 ו-NSX-T 4.2.1.2. במהלך תקופת השדרוג, יצירה והרחבה של ענן פרטי משתמשות במהירויות הקצאה סטנדרטיות לכל הפריסות החדשות עם הגרסאות המעודכנות.
פרטים: יצירת ענן פרטי יכולה להימשך עד 140 דקות.
פתרון עקיף: אין צורך בפתרון עקיף, אבל כדאי להקצות זמן נוסף לפריסת עננים פרטיים חדשים או להרחבת אשכולות קיימים.
זיהוי: יכול להיות שתבחינו בזמני פריסה ארוכים מהרגיל של עננים פרטיים חדשים או בהרחבה של אשכולות קיימים.
סטטוס: זה תקין בגלל עדכוני הגרסאות והשדרוגים השוטפים.
מכונה וירטואלית עם Windows Server 2022 KB5022842 (גרסת build 20348.1547 של מערכת ההפעלה) שמוגדרת עם אתחול מאובטח מופעל לא מבצעת אתחול (90947)
אחרי שמתקינים את העדכון KB5022842 (OS Build 20348.1547) של Windows Server 2022, מערכת ההפעלה של האורח לא יכולה לבצע אתחול כשהמכונות הווירטואליות מוגדרות עם אתחול מאובטח. כדי לעקוף את הבעיה, אתם יכולים לבצע אחת מהפעולות הבאות:
יש מגבלה של 100 קידומות לפרסומי ניתוב מהענן הפרטי לרשת ה-VPC
אם פרסום הניתוב חורג מהמגבלה הזו, יכול להיות שחלק מהקידומות יושמטו. כדי לא לחרוג מהמגבלה הזו, צריך להטמיע צבירה ב-NSX-T Edge.
ב-VMware Engine, שירותי Cloud Router משמשים לפרסום טווחי כתובות IP (תחיליות או CIDR) מ-NSX לרשת VPC של בעלי השירות המנוהל. התחיליות האלה הופכות לנתיבים דינמיים בהתאמה אישית ברשת ה-VPC של הבעלים של השירות המנוהל, שמקושרת לרשת ה-VPC שלכם.
כשמגדירים את רשת ה-VPC לייבא נתיבים דינמיים בהתאמה אישית ביחסי הקישור האלה בין רשתות שכנות, הקידומות של NSX מקשרות בין נתיבים בהתאמה אישית ברשת ה-VPC. מספר הקידומות של NSX שאפשר לייבא מוגבל על ידי שני גורמים:
- המגבלה שמוגדרת כברירת מחדל ב-Cloud Router על מספר הקידומות הייחודיות לכל אזור, ש-VMware Engine יורש
- המספר המקסימלי של נתיבים דינמיים בקבוצת רשתות שכנות (peering) ברשת ה-VPC
פעולות בענן הפרטי שנכשלות לפני שהענן הפרטי נפרס במלואו
בפורטל Google Cloud VMware Engine, בעננים פרטיים תפעוליים שעדיין לא הוקצו באופן מלא, אפשר לבצע פעולות כמו הרחבת הרשאות, הרחבת ענן פרטי והחלפת צומת. עם זאת, אם תנסו לבצע את הפעולות האלה ב-VMware Engine לפני שהענן הפרטי נפרס במלואו (כולל NSX-T ו-HCX), הפעולות ייכשלו. אל תנסו לבצע את הפעולות האלה לפני שפרסתם את הענן הפרטי באופן מלא.
עדיין אין תמיכה מלאה ב-VMware Engine ב-VPC Service Controls
ב-VPC Service Controls יש פתרון זמני (מעקף) שמאפשר להמשיך להשתמש ב-VMware Engine מתוך פרויקט שנמצא בגבולות הגזרה של VPC Service Controls. מידע נוסף זמין במאמר VPC Service Controls.
יכולת הפעולה ההדדית של Apigee עם ניתוב אינטרנט מקומי (on-premises)
אם אתם משתמשים ב-Apigee עם קישור VPC באותה רשת VPC כמו VMware Engine, ומגדירים את VMware Engine לנתב את תעבורת הנתונים דרך חיבור מקומי, יכול להיות שגם התקשורת היוצאת של Apigee תנותב דרך החיבור המקומי.
ההגדרה הזו מתרחשת כשמפעילים את VPC Service Controls בקישור בין רשתות שכנות (peering) של servicenetworking.googleapis.com, כמו שמתואר במאמר הגדרת גישה לאינטרנט למכונות וירטואליות של עומסי עבודה.
אם תעבורת הנתונים של Apigee מנותבת דרך החיבור המקומי, Apigee לא תשתמש יותר בכתובת ה-IP החיצונית שהוגדרה לה לתקשורת יוצאת לשירותים חיצוניים לקצה העורפי של ה-API. אם אתם מסתמכים על כתובת ה-IP החיצונית של Apigee להגדרות של חומת האש, אתם צריכים לעדכן את ההגדרות של חומת האש כדי לאפשר תעבורת נתונים מהרשת המקומית.
מארחי ESXi עלולים לאבד את הקישוריות באופן זמני במהלך איסוף נתוני האבחון
מארחי ESXi בסביבות עם מכשירי NVMe PCIe עלולים לאבד את הקישוריות באופן זמני במהלך איסוף פרטי האבחון.
שורש הבעיה
כשמשתמשים בפקודה vm-support או בממשק המשתמש של vCenter כדי לאסוף מידע על מערכות ESXi, היומנים נשמרים באופן זמני בספרייה ramdisk /tmp. אם במערכת יש הרבה מכשירי NVMe PCIe או שקובץ היומן גדול, הספרייה ramdisk /tmp מתמלאת במהירות, מה שעלול לגרום למארח ESXi לאבד את הקישוריות באופן זמני עד להשלמת האיסוף של vm-support.
פתרון עקיף:
החרגת המניפסט של NVME מהקטע של בחירת היומנים בדף היצירה של חבילת היומנים מונעת מהספרייה ramdisk /tmp להתמלא, ומוודאת שהמארח של EXSi לא מאבד את הקישוריות לרשת. כדי להחריג את המניפסט של NVMe:
- נכנסים ל-vCenter באמצעות שם המשתמש והסיסמה של
cloudowner. - במלאי, לוחצים לחיצה ימנית על המכונה של שרת vCenter שבה רוצים להגדיר את ההחרגה.
- לוחצים על ייצוא של יומני המערכת….
- בוחרים את מארח ה-ESXi שממנו רוצים להחריג את חבילת היומנים.
- בקטע Select Logs, גוללים אל Storage, מבטלים את הבחירה באפשרות NVMe ולוחצים על Exported logs. המניפסט של NVMe לא נכלל יותר.
למידע נוסף על התיקון הזה, ראו עדכון 3q של VMware ESXi 7.0.
שגיאה בתרגום של שם המשאב בענן הפרטי
אם אתם מריצים את VMware Engine Horizon (VDI) ב-Google Cloud VMware Engine, יכול להיות שתקבלו שגיאות אחרי שתשנו את השמות של משאבי הענן הפרטי כדי לעמוד בתקנים של Google Cloud CLI ושל VMware Engine API.
השגיאה הבאה מתקבלת כשמשנים את השמות של משאבי הענן הפרטי בלי לערוך כמו שצריך את הקצאת המשאבים של מאגרי Horizon Desktop:
Error during Provisioning Cloning of VM Desktop-UK-005 has failed. No resource pool available for the pool: ic-pool-1
Error during Provisioning Cloning of VM Desktop-UK-005 has failed. No datastores available for the pool: {}ic-pool-1
כדי לפתור את הבעיה, צריך לבצע את הפעולות הבאות לפני התאריך שנקבע לתרגום השם:
- נכנסים למרכז הבקרה של VMware Horizon.
- עורכים את כל מאגרי Horizon Desktop, גם Full Clone וגם Instant Clone, ומגדירים אותם ל-Disable Provisioning.
אחרי שמשנים את שם המשאב של הענן הפרטי, מבצעים את הפעולות הבאות:
עורכים כל מאגר של מחשבים וירטואליים ומגדירים מחדש את ההגדרות הבאות בכרטיסייה vCenter Settings, גם במאגרים של Full Clone וגם במאגרים של Instant Clone:
- מאגר משאבים
- Datastore
מגדירים את הסטטוס של כל מאגר בחזרה למצב הפעלת הקצאת הרשאות ידנית.
כדי לוודא שההקצאה פועלת כמו שצריך, בודקים כל מאגר על ידי הוספה או הסרה של מחשב שולחני מהמאגר.
צוות VMware Engine פועל כדי לספק פתרון לתאימות הדדית בהקדם האפשרי. כדי להתעדכן בזמינות של התכונות, פנו לצוות ניהול החשבון.