בעיות מוכרות
בדף הזה מתוארות בעיות מוכרות שאולי תיתקלו בהן במהלך השימוש ב-Google Cloud VMware Engine.
בעיות כלליות
ריכזנו כאן כמה בעיות כלליות ידועות שמשפיעות על VMware Engine.
התראות שגיאה מובנות של vCenter pNIC מופעלות באירועים זמניים ברשת
הבעיה: התראות מובנות בתשתית vCenter, כמו 'זוהה שיעור שגיאות גבוה ב-pNIC', יכולות להיות מופעלות לסירוגין במסוף vSphere Client בגלל אנומליות חולפות ומקומיות במנות מידע.
פרטים: מסגרת ההתראות המובנית של VMware מעריכה את מוני כרטיס הרשת הפיזי (pNIC) הבסיסיים בחלונות דגימה קצרים וקבועים. בגלל העיצוב הזה, vCenter יכול להפעיל התראות מיידיות לגבי אירועים שגרתיים שלא משפיעים על הביצועים – כמו רעש חולף או התנהגות צפויה של השמטת מנות בקישורי העלאה של vSAN במצב המתנה – גם כששכבת הרשת תקינה. בגלל יתירות מובנית בנתיב, ההתראות האלה לא משפיעות על זמינות הסביבה או על שלמות הנתונים.
פתרון עקיף: לא נדרשת פעולה מצד הלקוחות או פתרון עקיף. לא צפוי עדכון לרגישות הדגימה של האזעקה המובנית ב-vCenter בטווח הקצר, ולכן Google הטמיעה אינטליגנציה בסיסית של הפלטפורמה כדי לנהל ולסנן את התוצאות החיוביות השגויות האלה. בסביבות ייצור ממוקדות, Google משביתה את ההתראות המובנות האלה במסוף שמוצג ללקוחות. במקום זאת, מנוע Google Analytics עוקב אחרי נתוני התשתית ומעריך את השכבה הפיזית באופן רציף באמצעות ממוצע נע של 30 דקות. אם מנוע ניתוח הנתונים של Google מזהה ירידה מתמשכת בביצועים הפיזיים, כמו כבל או סיב אופטי פגומים, הפלטפורמה מתריעה אוטומטית לתמיכה של Google כדי לחקור את הבעיה ולפתור אותה, ושולחת לכם באופן שיטתי הודעה אוטומטית.
סטטוס: זו מגבלה ידועה של הלוגיקה המובנית להערכת התראות ב-vCenter. Google מנהלת את ההתנהגות הזו באמצעות פלטפורמה משולבת בסיסית וחכמה. חברת 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 Update 3 ו-NSX-T בגרסה 4.2.1.2. במהלך תקופת השדרוג הזו, יצירה והרחבה של ענן פרטי יתבצעו במהירויות הקצאת המשאבים הרגילות לכל הפריסות החדשות עם הגרסאות המעודכנות.
פרטים: יצירת ענן פרטי יכולה להימשך עד 140 דקות.
פתרון עקיף: אין צורך בפתרון עקיף, אבל כדאי לתכנן מראש הקצאת זמן נוסף כשפורסים עננים פרטיים חדשים או מרחיבים קלאסטרים קיימים.
זיהוי: יכול להיות שתבחינו בזמני פריסה ארוכים מהרגיל בענן פרטי חדש או כשמרחיבים אשכולות קיימים.
סטטוס: זה תקין בגלל עדכוני הגרסה והשדרוגים המתמשכים.
מכונה וירטואלית עם Windows Server 2022 KB5022842 (OS Build 20348.1547) שהוגדרה עם אתחול מאובטח מופעל לא מופעלת (90947)
אחרי התקנת העדכון KB5022842 (OS Build 20348.1547) ל-Windows Server 2022, מערכת ההפעלה האורחת לא יכולה לבצע אתחול כשהמכונות הווירטואליות מוגדרות עם אתחול מאובטח מופעל. כדי לעקוף את הבעיה, אפשר לבצע אחת מהפעולות הבאות:
יש מגבלה של 100 קידומות לפרסום מסלולים מהענן הפרטי לרשת ה-VPC
אם פרסום הניתוב חורג מהמגבלה הזו, יכול להיות שחלק מהקידומות יושמטו. כדי לא לחרוג מהמגבלה הזו, צריך להטמיע צבירה ב-NSX-T Edge.
VMware Engine מסתמך על Cloud Routers כדי לפרסם טווחי כתובות IP (קידומות או CIDR) מ-NSX לרשת VPC של בעלים של שירות מנוהל. הקידומות האלה הופכות למסלולים דינמיים מותאמים אישית ברשת ה-VPC של הבעלים של שירות מנוהל שמקושרת לרשת ה-VPC שלכם.
כשמגדירים את רשת ה-VPC לייבוא של מסלולים דינמיים מותאמים אישית בקשר הפירינג הזה, הקידומות של NSX מבצעות פירינג של מסלולים מותאמים אישית ברשת ה-VPC. מספר הקידומות של NSX שאפשר לייבא מוגבל על ידי שני גורמים:
- המגבלה שמוגדרת כברירת מחדל ב-Cloud Router למספר הקידומות הייחודיות לכל אזור, שמועברת בירושה מ-VMware Engine
- מספר המסלולים הדינמיים המקסימלי בקבוצת פירינג ברשת ה-VPC
פעולות בענן פרטי שבוצעו לפני שהענן הפרטי נפרס במלואו נכשלות
בפורטל Google Cloud VMware Engine מותרות פעולות כמו הרחבת הרשאות, הרחבת ענן פרטי והחלפת צומת בעננים פרטיים תפעוליים שעדיין לא הוקצו במלואם. עם זאת, אם תנסו לבצע את הפעולות האלה ב-VMware Engine לפני שהענן הפרטי נפרס במלואו (כולל NSX-T ו-HCX), הפעולות ייכשלו. אל תנסו לבצע את הפעולות האלה לפני שתפרסו את הענן הפרטי באופן מלא.
עדיין אין תמיכה מלאה ב-VMware Engine ב-VPC Service Controls
ב-VPC Service Controls מוטמע פתרון ביניים (עקיפת הבעיה) שמאפשר לכם להמשיך להשתמש ב-VMware Engine מתוך פרויקט ב-VPC Service Controls perimeter. מידע נוסף זמין במאמר בנושא VPC Service Controls.
יכולת פעולה הדדית של Apigee עם ניתוב אינטרנט מקומי
אם אתם משתמשים ב-Apigee עם VPC Peering באותה רשת 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 Server שרוצים להחריג.
- לוחצים על ייצוא יומני המערכת....
- בוחרים את מארח ESXi שרוצים להחריג את חבילת היומנים ממנו.
- בקטע Select Logs (בחירת יומנים), גוללים אל Storage (אחסון), מבטלים את הסימון של האפשרות NVMe ולוחצים על Exported logs (יומנים שיוצאו). המניפסט של NVMe לא נכלל יותר.
מידע נוסף על התיקון הזה זמין במאמר VMware ESXi 7.0 Update 3q.
שגיאת תרגום של שם משאב בענן פרטי
אם אתם מפעילים VMware Engine Horizon (VDI) ב-Google Cloud VMware Engine, יכול להיות שתיתקלו בשגיאות אחרי שתשנו את השמות של משאבי הענן הפרטי כדי לעמוד בתקנים של Google Cloud CLI ו-VMware Engine API.
השגיאה הבאה מתרחשת כשמשנים שמות של משאבים בענן פרטי בלי לערוך כראוי את הקצאת המשאבים של Horizon Desktop Pools:
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, ומגדירים אותם להשבתת הקצאת משאבים.
אחרי שמשלימים את שינוי השם של משאב הענן הפרטי, מבצעים את השלבים הבאים:
עורכים כל מאגר של מחשבים וירטואליים ומגדירים מחדש את ההגדרות הבאות בכרטיסייה vCenter Settings עבור מאגרי Full Clone ו-Instant Clone:
- מאגר משאבים
- Datastore
מחזירים את הסטטוס של כל מאגר להפעלת הקצאת הרשאות.
בודקים כל מאגר על ידי הוספה או הסרה של שולחן עבודה מהמאגר כדי לוודא שההקצאה פועלת כראוי.
צוות VMware Engine פועל באופן אקטיבי כדי לספק פתרון לאינטראופרביליות בהקדם האפשרי. כדי לקבל עדכונים על הזמינות של התכונה, אפשר לפנות לצוות ניהול החשבון.