פתרון בעיות במחברים של IBM Spectrum Symphony

במסמך הזה מוסבר איך לפתור בעיות נפוצות בשילוב של IBM Spectrum Symphony עם Google Cloud. באופן ספציפי, במסמך הזה מפורטות הנחיות לפתרון בעיות שקשורות לשירות IBM Spectrum Symphony host factory, למחברים של ספקי Compute Engine ו-GKE ול-Symphony Operator ל-Kubernetes.

בעיות בשירות של מארח Symphony

הבעיות האלה קשורות לשירות המארח המרכזי של Symphony. אפשר למצוא את קובץ היומן הראשי של השירות הזה במיקום הבא ב-Linux:

$EGO_TOP/hostfactory/log/hostfactory.hostname.log

מגדירים את משתנה הסביבה $EGO_TOP כשטוענים את משתני הסביבה של המארח. ב-IBM Spectrum Symphony, ‏ $EGO_TOP מציין את ספריית הבסיס של Enterprise Grid Orchestrator ‏ (EGO), שהוא מנהל המשאבים המרכזי של האשכול. נתיב ההתקנה שמוגדר כברירת מחדל ל-$EGO_TOP ב-Linux הוא בדרך כלל /opt/ibm/spectrumcomputing.

באשכול לא נוספים מכונות וירטואליות חדשות לעומסי עבודה בהמתנה

הבעיה הזו מתרחשת כשיש משימות בתור של Symphony, אבל מפעל המארחים לא מצליח להקצות מכונות וירטואליות (VM) חדשות כדי לנהל את העומס. קובץ היומן של host factory לא מכיל הודעות SCALE-OUT.

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

1. מאתרים את קובץ ההגדרה של השולח. בדרך כלל הקובץ נמצא במיקום:

   $HF_TOP/conf/requestors/hostRequestors.json
   

   משתנה הסביבה $HF_TOP מוגדר בסביבה שלכם כשמשתמשים בפקודה source. הערך הוא הנתיב לספריית ההתקנה ברמה העליונה של שירות המפעל של מארח IBM Spectrum Symphony.

2. פותחים את הקובץ hostRequestors.json ומאתרים את הרשומה symAinst. בקטע הזה, מוודאים שהפרמטר enabled מוגדר לערך 1 ושרשימת הספקים כוללת את השם של מופע הספק שהגדרתם Google Cloud .

   • בהגדרות של Compute Engine, ברשימת הספקים צריך להופיע השם של ספק Compute Engine שיצרתם בקטע הפעלת מופע הספק במהלך ההתקנה של ספק Compute Engine.
   • בהגדרות GKE, ברשימת הספקים צריך להופיע השם של ספק GKE שיצרתם בשלב הפעלת מופע הספק במהלך ההתקנה של ספק GKE.

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

   כדי לראות רשימה של כל הצרכנים והסטטוס של עומס העבודה שלהם:

   egosh consumer list
   

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

שירות פקטורי המארח לא מופעל

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

1. בודקים את הסטטוס של שירות HostFactory:

   egosh service list
   

   בפלט, מאתרים את השירות HostFactory ומוודאים שהסטטוס בשדה STATE הוא STARTED.

2. אם השירות HostFactory לא מופעל, מפעילים אותו מחדש:

   egosh service stop HostFactory
   egosh service start HostFactory
   

שגיאות אחרות ורישום ביומן

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

1. פותחים את הקובץ hostfactoryconf.json לעריכה. בדרך כלל, הקובץ נמצא במיקום הבא:

   $EGO_TOP/hostfactory/conf/
   

   מידע נוסף על הערך של משתנה הסביבה $EGO_TOP זמין במאמר בעיות בשירות של מפעל המארחים של Symphony.

2. מעדכנים את הערך של HF_LOGLEVEL מ-LOG_INFO ל-LOG_DEBUG:

   {
     ...
     "HF_LOGLEVEL": "LOG_DEBUG",
     ...
   }
   

3. שומרים את הקובץ אחרי שמבצעים את השינוי.

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

   egosh service stop HostFactory
   egosh service start HostFactory
   

אחרי ההפעלה מחדש, שירות HostFactory יוצר יומנים מפורטים יותר, שאפשר להשתמש בהם כדי לפתור בעיות מורכבות. אפשר לראות את היומנים האלה בקובץ היומן של פקטורי המארחים הראשי, שנמצא בנתיב $EGO_TOP/hostfactory/log/hostfactory.hostname.log ב-Linux.

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

הבעיות הבאות מתרחשות בסקריפטים של ספק host factory ב-Compute Engine או ב-Google Kubernetes Engine.

כדאי לבדוק את היומנים של הספק (hf-gce.log או hf-gke.log) כדי לראות הודעות שגיאה מפורטות. המיקום של הקבצים hf-gce.log ו-hf-gke.log נקבע על ידי המשתנה LOGFILE שמוגדר בקובץ התצורה של הספק בקטע הפעלת מופע הספק.

המכונה הווירטואלית או ה-pod לא הוקצו

הבעיה הזו עשויה להתרחש אחרי שביומנים של ספק המפעל המארח מופיעה קריאה לסקריפט requestMachines.sh, אבל המשאב לא מופיע בפרויקט Google Cloud.

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

1. בודקים את יומני הסקריפט של הספק (hf-gce.log או hf-gke.log) כדי לראות אם יש הודעות שגיאה מ- Google Cloud API. המיקום של הקבצים hf-gce.log ו-hf-gke.log נקבע על ידי המשתנה LOGFILE שמוגדר בקובץ התצורה של הספק בקטע הפעלת מופע הספק.

2. מוודאים שלחשבון השירות יש את הרשאות ה-IAM הנכונות:

   1. פועלים לפי ההוראות במאמר הצגת הגישה הנוכחית.
   2. מוודאים שלחשבון השירות יש את תפקיד ה-IAM‏ Compute Instance Admin (v1) (אדמין מכונות של Compute ‏(v1))‏ (roles/compute.instanceAdmin.v1) בפרויקט. מידע נוסף על הקצאת תפקידים מופיע במאמר ניהול הגישה לפרויקטים, לתיקיות ולארגונים.

3. כדי לוודא שהפרמטרים של Compute Engine בתבנית המארח תקינים, צריך לבדוק את הדברים הבאים:

   1. הפרמטרים של תבנית המארח צריכים להיות בקובץ gcpgceinstprov_templates.json שיצרתם כשהגדרתם מכונה של ספק במהלך ההתקנה של ספק Compute Engine. הפרמטרים הנפוצים ביותר שצריך לאמת הם gcp_zone ו-gcp_instance_group.

   2. מוודאים שקבוצת המופעים שהוגדרה על ידי הפרמטר gcp_instance_group קיימת. כדי לאשר את קבוצת המכונות, פועלים לפי ההוראות במאמר הצגת המאפיינים של קבוצת מכונות לניהול מופעים, באמצעות הערכים של שם קבוצת המכונות gcp_instance_group ואזור הזמינות gcp_zone מקובץ התבנית.

פוד נתקע במצב Pending או Error ב-GKE

הבעיה הזו יכולה לקרות אחרי שביומן hf-gke מופיעה יצירה של משאב GCPSymphonyResource, אבל ה-Pod התואם באשכול GKE אף פעם לא מגיע למצב Running, ויכול להיות שיוצג סטטוס כמו Pending, ‏ ImagePullBackOff או CrashLoopBackOff.

הבעיה הזו מתרחשת אם יש בעיה באשכול Kubernetes, כמו שם לא תקין של קובץ אימג' של קונטיינר, מחסור במשאבי מעבד (CPU) או זיכרון, או הגדרה שגויה של נפח או הגדרות רשת.

כדי לפתור את הבעיה, משתמשים ב-kubectl describe כדי לבדוק את האירועים של המשאב המותאם אישית ושל ה-Pod, ולזהות את שורש הבעיה:

kubectl describe gcpsymphonyresource RESOURCE_NAME
kubectl describe pod POD_NAME

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

• ‫RESOURCE_NAME: שם המשאב.
• ‫POD_NAME: שם ה-Pod.

פתרון בעיות שקשורות לאופרטור Kubernetes

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

אבחון בעיות בשדות של סטטוס המשאבים

אופרטור Kubernetes מנהל עומסי עבודה של Symphony ב-GKE באמצעות שני סוגים עיקריים של משאבים:

• המשאב GCPSymphonyResource (GCPSR) מנהל את מחזור החיים של פודים של מחשוב לעומסי עבודה של Symphony.
• המשאב MachineReturnRequest (MRR) מטפל בהחזרה ובניקוי של משאבי מחשוב.

אפשר להשתמש בשדות הסטטוס האלה כדי לאבחן בעיות במשאב GCPSymphonyResource resource:

• ‫phase: השלב הנוכחי במחזור החיים של המשאב. האפשרויות הן Pending,‏ Running,‏ WaitingCleanup או Completed.
• ‫availableMachines: מספר פודים של מחשוב שמוכנים.
• ‫conditions: תנאי סטטוס מפורטים עם חותמות זמן.
• ‫returnedMachines: רשימה של פודים שהוחזרו.

אפשר להשתמש בשדות הסטטוס האלה כדי לאבחן בעיות במשאב MachineReturnRequest resource:

• ‫phase: השלב הנוכחי של בקשת ההחזרה. האפשרויות הן Pending, InProgress, Completed, Failed או PartiallyCompleted.
• ‫totalMachines: המספר הכולל של המכונות שיוחזרו.
• returnedMachines: מספר המכונות שהוחזרו בהצלחה.
• ‫failedMachines: מספר המכונות שהחזרתן נכשלה.
• machineEvents: פרטי הסטטוס של כל מכונה.

משאב GCPSymphonyResource תקוע במצב Pending

הבעיה הזו מתרחשת כשהמשאב GCPSymphonyResource נשאר במצב Pending והערך של availableMachines לא עולה.

הבעיה הזו יכולה לקרות בגלל אחת מהסיבות הבאות:

• קיבולת הצמתים באשכול לא מספיקה.
• בעיות בשליפת קובץ אימג' של קונטיינר.
• מגבלות על מכסת משאבים.

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

1. כדאי לבדוק את הסטטוס של ה-pods כדי לזהות בעיות בשליפת תמונות או בהקצאת משאבים:

   kubectl describe pods -n gcp-symphony -l symphony.requestId=REQUEST_ID
   

   מחליפים את REQUEST_ID במזהה הבקשה.

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

   kubectl get nodes -o wide
   

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

התרמילים לא מוחזרים

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

הבעיה הזו יכולה לקרות מהסיבות הבאות:

• הפודים תקועים במצב Terminating.
• יש בעיות בחיבור הצמתים.

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

1. בודקים אם יש פודים תקועים במצב Terminating:

   kubectl get pods -n gcp-symphony --field-selector=status.phase=Terminating
   

2. כדי לקבל פרטים על תהליך ההחזרה, אפשר לתאר את MachineReturnRequest:

   kubectl describe mrr MRR_NAME -n gcp-symphony
   

   מחליפים את MRR_NAME בשם של MachineReturnRequest.

3. מוחקים ידנית את אובייקט המשאב המותאם אישית. המחיקה הזו מפעילה את הלוגיקה של הניקוי הסופי:

   kubectl delete gcpsymphonyresource RESOURCE_NAME
   

   מחליפים את RESOURCE_NAME בשם של משאב GCPSymphonyResource.

מספר גבוה של מכונות שנכשלו ב-MachineReturnRequest

הבעיה הזו מתרחשת כשמספר הפריטים failedMachines בסטטוס MachineReturnRequest גדול מ-0. הבעיה הזו יכולה לקרות מהסיבות הבאות:

• הזמן שהוקצב למחיקת ה-Pod פג.
• צומת לא זמין.

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

1. בודקים את הסטטוס machineEvents בMachineReturnRequest כדי לראות הודעות שגיאה ספציפיות:

   kubectl describe mrr MRR_NAME -n gcp-symphony
   

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

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

      kubectl get nodes -o wide
      

   2. בדיקת צומת ספציפי:

      kubectl describe node NODE_NAME
      

התרמילים לא נמחקים

הבעיה הזו מתרחשת כשפודים שנמחקו נתקעים במצב Terminating או Error

הבעיה הזו יכולה לקרות מהסיבות הבאות:

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

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

1. בודקים אם משאב האב GCPSymphonyResource עדיין זמין ולא במצב WaitingCleanup:

   kubectl describe gcpsymphonyresource RESOURCE_NAME
   

2. אם משאב ההורה GCPSymphonyResource כבר לא נמצא במערכת, צריך להסיר את ה-finalizer מה-pod או מה-pods באופן ידני. הפונקציה הסופית אומרת ל-Kubernetes לחכות שאופרטור Symphony ישלים את משימות הניקוי שלו לפני ש-Kubernetes מוחק את ה-pod באופן מלא. קודם כול, בודקים את הגדרת ה-YAML כדי למצוא את ה-finalizer:

   kubectl get pods -n gcp-symphony -l symphony.requestId=REQUEST_ID -o yaml
   

   מחליפים את REQUEST_ID במזהה הבקשה שמשויך ל-Pods.

3. בפלט, מחפשים את השדה finalizers בקטע metadata. הפלט שיוצג אמור להיות דומה לקטע הקוד הבא:

   metadata:
   ...
   finalizers:
   -   symphony-operator/finalizer
   

4. כדי להסיר ידנית את ה-finalizer מהפוד או מהפודים, משתמשים בפקודה kubectl patch:

   kubectl patch pod -n gcp-symphony -l symphony.requestId=REQUEST_ID --type json -p '[{"op": "remove", "path": "/metadata/finalizers", "value": "symphony-operator/finalizer"}]'
   

   מחליפים את REQUEST_ID במזהה הבקשה שמשויך ל-Pods.

משאבי Symphony ישנים לא נמחקים אוטומטית מאשכול GKE

אחרי שסיימתם עומס עבודה ו-GKE הפסיק את הפודים שלו, האובייקטים המשויכים GCPSymphonyResource ו-MachineReturnRequest נשארים באשכול GKE שלכם למשך זמן ארוך יותר מפרק הזמן הצפוי של 24 שעות לניקוי.

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

1. בודקים את הפרטים של משאב GCPSymphonyResource הרלוונטי:

   kubectl get gcpsr GCPSR_NAME -o yaml
   

   מחליפים את GCPSR_NAME בשם של משאב GCPSymphonyResource עם הבעיה הזו.

2. בודקים את התנאים של אחד מסוג Completed עם סטטוס True:

   status:
     availableMachines: 0
     conditions:
     -   lastTransitionTime: "2025-04-14T14:22:40.855099+00:00"
       message: GCPSymphonyResource g555dc430-f1a3-46bb-8b69-5c4c481abc25-2pzvc has
         no pods.
       reason: NoPods
       status: "True"        # This condition will ensure this
       type: Completed       # custom resource is cleaned up by the operator
     phase: WaitingCleanup
     returnedMachines:
     -   name: g555dc430-f1a3-46bb-8b69-5c4c481abc25-2pzvc-pod-0
       returnRequestId: 7fd6805f-9a00-41f9-afe9-c38aa35002db
       returnTime: "2025-04-14T14:22:39.373216+00:00"
   

   אם התנאי הזה לא מופיע בפרטי GCPSymphonyResource, אבל במקומו מופיע phase: WaitingCleanup, סימן שאירוע Completed אבד.

3. בודקים אם יש תרמילים שמשויכים ל-GCPSymphonyResource:

   kubectl get pods -l symphony.requestId=REQUEST_ID
   

   מחליפים את REQUEST_ID במזהה הבקשה.

4. אם לא קיימים פודים, מוחקים בבטחה את המשאב GCPSymphonyResource:

   kubectl delete gcpsr GCPSR_NAME
   

   מחליפים את GCPSR_NAME בשם של GCPSymphonyResource.

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

ה-Pod לא מצטרף לאשכול Symphony

הבעיה הזו מתרחשת כש-pod פועל ב-GKE, אבל הוא לא מופיע כמארח תקין באשכול Symphony.

הבעיה הזו מתרחשת אם תוכנת Symphony שפועלת בתוך ה-pod לא מצליחה להתחבר למארח הראשי של Symphony ולהירשם אליו. הבעיה הזו נובעת לרוב מבעיות בקישוריות לרשת או מהגדרה שגויה של לקוח Symphony בתוך הקונטיינר.

כדי לפתור את הבעיה, צריך לבדוק את היומנים של שירותי Symphony שפועלים בתוך ה-Pod.

1. משתמשים ב-SSH או ב-exec כדי לגשת ל-Pod ולהציג את היומנים:

   kubectl exec -it POD_NAME -- /bin/bash
   

   מחליפים את POD_NAME בשם של ה-Pod.

2. אם יש לכם קובץ sh בתוך ה-pod, היומנים של שדי ה-EGO וה-LIM נמצאים בספרייה $EGO_TOP/kernel/log. משתנה הסביבה $EGO_TOP מצביע על הרמה הבסיסית (root) של ההתקנה של IBM Spectrum Symphony:

   cd $EGO_TOP/kernel/log
   

   מידע נוסף על הערך של משתנה הסביבה $EGO_TOP זמין במאמר בעיות בשירות Symphony host factory.

3. בודקים את היומנים כדי לזהות שגיאות בהגדרות או ברשת שחוסמות את החיבור מ-GKE pod אל Symphony primary pod המקומי.

בקשת החזרת מכונה נכשלת

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

כשל בלוגיקה של ה-finalizer של האופרטור מונע את המחיקה הנקייה של ה-pod ושל המשאב המותאם אישית שמשויך אליו. הבעיה הזו עלולה לגרום למשאבים יתומים ולעלויות מיותרות.

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

kubectl delete gcpsymphonyresource RESOURCE_NAME

מחליפים את RESOURCE_NAME בשם המשאב.