פתרון בעיות ב-Distributed Cloud במודל מחובר

‫Google עוקבת מרחוק אחרי החומרה של Google Distributed Cloud במודל מחובר ומבצעת בה תחזוקה. לצורך הזה, למהנדסי Google יש גישה Secure Shell ‏ (SSH) לחומרה של Distributed Cloud במודל מחובר. אם Google מזהה בעיה, מהנדס של Google יפנה אליכם כדי לפתור אותה. אם זיהיתם בעיה בעצמכם, פנו מיד לתמיכה של Google כדי לאבחן אותה ולפתור אותה.

שדרוגי תוכנה מחוברים של Distributed Cloud

בקטע הזה מוסבר איך להשתמש בכלי Metrics Explorer כדי לבדוק אם מתבצעת שדרוג תוכנה באשכול שמחובר ל-Distributed Cloud.

בנוהל הזה נעשה שימוש במדדי Monitoring הבאים:

• ‫Current Cluster Version (/edge_cluster/current_cluster_version): מציין את הגרסה הנוכחית של התוכנה Google Distributed Cloud במודל מחובר שפועלת באשכול.

• ‫Target Cluster Version (/edge_cluster/target_cluster_version): מציין את גרסת היעד של Distributed Cloud במודל מחובר שאליו האשכול משודרג.

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

1. גישה למסוף Google Cloud ולפרויקט המקושר שלכם ב-Distributed Cloud. Google Cloud
2. תפקיד ה-IAM‏ Monitoring Viewer, שמאפשר לכם לצפות במדדים של Monitoring.
3. (אופציונלי) ערך machine_id של המכונה המחוברת ל-Distributed Cloud, לסינון התוצאות שמוחזרות.

שימוש ב-Metrics Explorer כדי לבדוק את גרסאות התוכנה הנוכחיות והמיועדות של האשכול

1. עוברים אל Metrics Explorer:

   1. במסוף Google Cloud , עוברים לקטע Monitoring.

   2. בעץ הניווט שבצד ימין, לוחצים על Metrics Explorer (הכלי לבחירת מדדים).

2. בוחרים את סוג משאב היעד:

   1. בדף Metrics Explorer, עוברים לדף Configuration.

   2. לוחצים על בחירת מדד.

   3. משתמשים בסרגל החיפוש כדי לחפש את סוג המשאב Cluster. אפשר גם להשתמש במזהה המשאב המלא edgecontainer.googleapis.com/Cluster.

   4. בתוצאות שמוחזרות, לוחצים על סוג המשאב Cluster.

3. משיגים את גרסת התוכנה הנוכחית של האשכול:

   1. בקטע Metric, מחפשים את הערך current_cluster_version.

   2. בוחרים במדד Machine Uptime (זמן הפעולה של המכונה). הנתיב המלא שלה הוא edgecontainer.googleapis.com/edge_cluster/current_cluster_version.

   3. (אופציונלי) אפשר לסנן לפי ערך היעד machine_id באמצעות הקטע Filter.

4. משיגים את גרסת התוכנה של היעד של האשכול:

   1. לוחצים על הוספת שאילתה.

   2. בקטע Metric, מחפשים את הערך target_cluster_version.

   3. בוחרים במדד Target Cluster Version (גרסת אשכול היעד). הנתיב המלא שלה הוא edgecontainer.googleapis.com/edge_cluster/target_cluster_version.

   4. (אופציונלי) אפשר לסנן לפי ערך היעד machine_id באמצעות הקטע Filter.

5. בודקים את סטטוס שדרוג התוכנה של האשכול בתרשים שמופיע.

   • אם בשורות Current Cluster Version ו-Target Cluster Version מופיעים ערכים שונים, האשכול עובר שדרוג תוכנה.

   • אם הערך שמופיע בשורות Current Cluster Version ו-Target Cluster Version זהה, סימן שלא מתבצע שדרוג תוכנה באשכול.

6. מוודאים את התוצאה מהשלב הקודם באמצעות הפקודה הבאה:

   gcloud edge-cloud container clusters describe CLUSTER_ID --location=REGION
   

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

   • ‫CLUSTER_ID: המזהה של אשכול היעד.
   • ‫REGION: האזור Google Cloud שבו נוצר האשכול.

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

   • אם הערך של השדה status הוא UPDATING, המשמעות היא שהאשכול עובר שדרוג תוכנה.
   • אם הערכים בשדות clusterVersion ו-targetVersion שונים, צריך להשוות אותם לערכים שמוחזרים ב-Metrics Explorer.

הסבר על התוצאות

בטבלה הבאה מוסברות התוצאות שמוחזרות על ידי Metrics Explorer והפקודה gcloud.

מצב האשכול	אבחון	רזולוציה
תקין הערכים currentVersion ו-targetVersion זהים הערך של `status` הוא RUNNING	האשכול מריץ את גרסת היעד של התוכנה המחוברת של Distributed Cloud.	אין.
שדרוג הערך של currentVersion נמוך מהערך של targetVersion הערך של status הוא UPDATING	האשכול משודרג לגרסת היעד של תוכנת Distributed Cloud במודל מחובר.	עוקבים אחרי האשכול ב-Metrics Explorer עד שהערכים של גרסת האשכול הנוכחית וגרסת האשכול של היעד זהים.
תקוע הערך של currentVersion נמוך מהערך של targetVersion ללא הגבלת זמן הערך של `status` הוא UPDATING ללא הגבלת זמן	השדרוג לגרסת היעד של התוכנה של Distributed Cloud במודל מחובר נכשל לפחות בצומת אחד באשכול.	כדאי לבדוק את הקישוריות של המכונה ואת יומני המערכת, ולפנות אל Google לקבלת עזרה.
החזרה לגרסה הקודמת הערך של currentVersion גבוה מהערך של targetVersion הערך של `status` הוא UPDATING	‫luster חוזר לגרסה קודמת של התוכנה Google Distributed Cloud במודל מחובר.	כדי לזהות את הסיבה להחזרה לגרסה הקודמת, צריך ליצור קשר עם Google.

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

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

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

הפעלה מחדש של מכונה מחוברת ב-Distributed Cloud

בקטע הזה מוסבר איך להשתמש ב-Metrics Explorer כדי לבדוק אם מכונה פיזית שמחוברת ל-Distributed Cloud הופעלה מחדש, ולברר את הסיבה להפעלה מחדש. מעקב אחרי הפעלות מחדש עוזר לקבוע אם הן היו חלק מתחזוקה מתוכננת או שהן נבעו מכשל בחומרה או מהפסקת חשמל.

בנוהל הזה נעשה שימוש במדדי Monitoring הבאים:

• זמן הפעלה של המחשב (/machine/uptime): מציין את הזמן בשניות מאז ההפעלה מחדש האחרונה.

• הפעלות מחדש של המחשב (/machine/restart_count): מציין את המספר הכולל של הפעלות מחדש של מחשב היעד מאז הפריסה שלו.

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

1. גישה למסוף Google Cloud ולפרויקט המקושר שלכם ב-Distributed Cloud. Google Cloud
2. תפקיד ה-IAM‏ Monitoring Viewer, שמאפשר לכם לצפות במדדים של Monitoring.
3. (אופציונלי) ערך machine_id של המכונה המחוברת ל-Distributed Cloud, לסינון התוצאות שמוחזרות.

שימוש ב-Metrics Explorer כדי לבדוק את זמן הפעולה של המכונה ואת מספר ההפעלה מחדש

1. עוברים אל Metrics Explorer:

   1. במסוף Google Cloud , עוברים לקטע Monitoring.

   2. בעץ הניווט שבצד ימין, לוחצים על Metrics Explorer (הכלי לבחירת מדדים).

2. בוחרים את סוג משאב היעד:

   1. בדף Metrics Explorer, עוברים לדף Configuration.

   2. לוחצים על בחירת מדד.

   3. משתמשים בסרגל החיפוש כדי לחפש את סוג המשאב Machine. אפשר גם להשתמש במזהה המשאב המלא edgecontainer.googleapis.com/Machine.

   4. בתוצאות שמוחזרות, לוחצים על סוג המשאב Machine.

3. בודקים את זמן הפעילות של המכונה:

   1. בקטע Metric, מחפשים את הערך uptime.

   2. בוחרים במדד Machine Uptime (זמן הפעולה של המכונה). הנתיב המלא שלה הוא edgecontainer.googleapis.com/machine/uptime.

   3. (אופציונלי) אפשר לסנן לפי ערך היעד machine_id באמצעות הקטע Filter.

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

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

   1. בקטע Metric, מחפשים את הערך restart_count.

   2. בוחרים במדד הפעלות מחדש של המחשב. הנתיב המלא שלה הוא edgecontainer.googleapis.com/machine/restart_count.

   3. (אופציונלי) אפשר לסנן לפי ערך היעד machine_id באמצעות הקטע Filter.

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

   5. (אופציונלי) כדי לראות אירועים בודדים במקום תרשים, עוברים לקטע Aggregation בדף, מגדירים את השדה Alignment period לערך 1 minute ואת השדה Per-series aligner לערך Delta.

הסבר על התוצאות

בטבלה הבאה מוסברות התוצאות שמוחזרות ב-Metrics Explorer.

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

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

קישוריות של מכונות שמחוברות ל-Distributed Cloud

בקטע הזה מוסבר איך לבדוק את החיבור לאינטרנט ואת הקישוריות של המכונות המחוברות ל-Distributed Cloud באמצעות התכונה 'סייר המדדים' ב-Cloud Monitoring. Google Cloud

בנוהל הזה נעשה שימוש במדדי Monitoring הבאים:

• ‫Machine Connected (/machine/connected): מציין אם המכונה מחוברת ל- Google Cloud.

• קישוריות רשת (/machine/network/connectivity): מציין אם לממשק הרשת הראשי של המחשב יש קישוריות לאינטרנט.

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

1. גישה למסוף Google Cloud ולפרויקט המקושר שלכם ב-Distributed Cloud. Google Cloud
2. תפקיד ה-IAM‏ Monitoring Viewer, שמאפשר לכם לצפות במדדים של Monitoring.
3. (אופציונלי) ערך machine_id של המכונה המחוברת ל-Distributed Cloud, לסינון התוצאות שמוחזרות.

שימוש ב-Metrics Explorer כדי לבדוק את הקישוריות של המכונה

1. עוברים אל Metrics Explorer:

   1. במסוף Google Cloud , עוברים לקטע Monitoring.

   2. בעץ הניווט שבצד ימין, לוחצים על Metrics Explorer (הכלי לבחירת מדדים).

2. בוחרים את סוג משאב היעד:

   1. בדף Metrics Explorer, עוברים לדף Queries.

   2. משתמשים בסרגל החיפוש כדי לחפש את סוג המשאב Machine. אפשר גם להשתמש במזהה המשאב המלא edgecontainer.googleapis.com/Machine.

   3. בתוצאות שמוחזרות, לוחצים על סוג המשאב Machine.

3. בודקים את החיבור של המכונה אל Google Cloud:

   1. בקטע Metric, מחפשים את הערך connected.

   2. בוחרים במדד Machine Connected (מכונה מחוברת). הנתיב המלא שלה הוא edgecontainer.googleapis.com/machine/connected.

   3. (אופציונלי) אפשר לסנן לפי ערך היעד machine_id באמצעות הקטע Filter.

   4. בתרשים הזמן שמופיע, מוודאים שהקו תקין נשאר רציף ב-100%. אם בשלב כלשהו הערך הזה הוא 0% או Unhealthy, המחשב איבד את הקישוריות ל- Google Cloud בזמן שצוין.

4. בודקים את החיבור של המכונה לאינטרנט:

   1. בקטע Metric, מחפשים את הערך connectivity.

   2. בוחרים במדד קישוריות לרשת. הנתיב המלא שלה הוא edgecontainer.googleapis.com/machine/network/connectivity.

   3. (אופציונלי) אפשר לסנן לפי ערך היעד machine_id באמצעות הקטע Filter.

   4. בתרשים הזמן שמופיע, מוודאים שהקו תקין נשאר רציף ב-100%. אם בשלב כלשהו הערך הזה הוא 0% לא תקין, המשמעות היא שהמחשב איבד את הקישוריות לאינטרנט בזמן שצוין.

הסבר על התוצאות

בטבלה הבאה מוסברות התוצאות שמוחזרות ב-Metrics Explorer.

מצב המכונה	אבחון	רזולוציה
תקין הערך של המדד 'המחשב מחובר' הוא 1 הערך של המדד 'קישוריות לרשת' הוא 1	פעולה רגילה.	אין.
מנותק הערך של המדד 'המחשב מחובר' הוא 0 הערך של המדד 'קישוריות לרשת' הוא 1	למחשב יש חיבור לאינטרנט, אבל הוא לא יכול להתחבר אל Google Cloud.	בודקים את הכללים של חומת האש עבור שירותי Google ונקודות קצה של API. מוודאים שהסוכנים המחוברים של Distributed Cloud פועלים במחשב.
מבודד הערך של המדד 'המחשב מחובר' הוא 0 הערך של המדד 'קישוריות לרשת' הוא 0	למכונה אין קישוריות לאינטרנט.	בודקים את כבלי החשמל והרשת, את ההגדרה של הרשת המקומית ואת הסטטוס של נורית ה-LED. מאמתים את ההגדרות של ה-VLAN והניתוב.
לסירוגין הערך של המדד 'המכונה מחוברת' משתנה לסירוגין בין 0 ל-1 הערך של המדד 'קישוריות לרשת' משתנה לסירוגין בין 0 ל-1	חיבור לא יציב לרשת, אובדן מנות או זמן אחזור מוגזם.	בודקים אם יש עומס ברשת המקומית או חומרה פגומה.

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

מכונות וירטואליות תקועות במצב Pending

עומס עבודה של מכונה וירטואלית יכול להיתקע במצב Pending ולא להתווסף לתזמון בצומת אם קורה אחד מהדברים הבאים:

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

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

1. מקבלים את פרטי הכניסה לאשכול כמו שמתואר במאמר קבלת פרטי כניסה לאשכול.

2. קבלת מידע על המכונה הווירטואלית שהושפעה:

   kubectl describe virtualmachine VM_NAME -n NAMESPACE
   

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

   • ‫VM_NAME: השם של המכונה הווירטואלית של היעד.
   • ‫NAMESPACE: מרחב השמות של המכונה הווירטואלית של היעד.

   הפקודה מחזירה פלט שדומה לזה:

   Status:
   ...
   State:                    Pending
   ...
   Events:
   Type     Reason                  Age   From                       Message
   ----     ------                  ----  ----                       -------
   Normal   SuccessfulCreate        15m   virtualmachine-controller  Created virtual machine my-stuck-vm
   Warning  DiskProvisioningFailed  14m   virtualmachine-controller  Failed to provision disk: DataVolume my-stuck-vm-data-disk not ready
   Warning  PVCNotBound             14m   virtualmachine-controller  PersistentVolumeClaim my-stuck-vm-data-disk is in phase Pending
   Warning  VMINotCreated           10m   virtualmachine-controller  VirtualMachineInstance cannot be created: dependencies not ready
   

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

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

אין מספיק משאבים

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

5/8 nodes are available: 3 Insufficient memory, 3 Insufficient CPU.

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

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

צמתים עם כתמים

יכול להיות שתופיע הודעה שמציינת שהצומת של היעד מוכתם. לדוגמה:

5/8 nodes are available: 3 node(s) had taint {<taint-key>:<taint-value>}, that the pod didn't tolerate.

כדי לפתור את הבעיה, צריך לבצע את הפעולות הבאות:

1. משתמשים בפקודה הבאה כדי לבדוק אם יש כתמים בצומת:

   kubectl get nodes -o custom-columns=NAME:.metadata.name,TAINTS:.spec.taints
   

   הפקודה מחזירה פלט שדומה לזה:

   NAME                           TAINTS
   node-name-1   [map[effect:PreferNoSchedule key:node-role.kubernetes.io/master] map[effect:PreferNoSchedule key:node-role.kubernetes.io/control-plane]]
   node-name-2   <none>
   

2. מבצעים אחת מהפעולות הבאות:

   • אם יש כתמים לא צפויים, צריך להסיר אותם כמו שמתואר במאמר Taints and Tolerations.
   • אם יש taints צפויים, מוסיפים את ה-tolerations המתאימים להגדרות של המכונה הווירטואלית, כמו שמתואר במאמר Taints and Tolerations.

תקלות באחסון

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

5/8 nodes are available: 3 node(s) had volume node affinity conflict, 3 node(s) had unbound immediate PersistentVolumeClaims.

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

כדי לפתור את הבעיה, צריך לבצע את הפעולות הבאות:

1. כדי לקבל את הסטטוס של התביעות לנפח אחסון מתמשך (PVC) במרחב השמות של המכונה הווירטואלית המושפעת, משתמשים בפקודה הבאה:

   kubectl get pvc -n NAMESPACE
   

   מחליפים את NAMESPACE בשם של מרחב השמות של היעד.

   הפקודה מחזירה פלט שדומה לזה:

   NAME                                               STATUS    VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS            AGE
   windows-robin-disk-0                               Bound     pvc-b1a1d264-84bf-4e58-857d-f37f629d5082   25Gi       RWX            robin-block-immediate   30h
   windows-robin-disk-1                               Bound     pvc-0130b9a8-7fed-4df0-8226-d79273792a16   25Gi       RWX            robin-block-immediate   30h
   windows-robin-vm-0-restored-windows-robin-disk-0   Pending                                                                        gce-pd-gkebackup-in     26m
   

2. מוודאים של-PVC המתאים יש סטטוס Bound. אם הסטטוס הוא Pending, מערכת המשנה של האחסון לא הצליחה להקצות את נפח האחסון. במקרים כאלה, צריך לפתור את הבעיה בהגדרת מערכת המשנה של האחסון ולוודא שזמין StorageClass מתאים.