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

במסמך הזה מוסבר איך לפתור בעיות נפוצות בשילוב של IBM Spectrum Symphony עם Google Cloud. באופן ספציפי, במסמך הזה מפורטות הנחיות לפתרון בעיות שקשורות לשירות IBM Spectrum Symphony host factory, למחברים של ספקי Compute Engine ו-GKE ול-Symphony Operator for 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, אבל מפעל המארחים לא מצליח להקצות מכונות וירטואליות חדשות לניהול העומס. קובץ היומן של המארח 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 host factory.

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) (roles/compute.instanceAdmin.v1) בפרויקט. מידע נוסף על הקצאת תפקידים מופיע במאמר ניהול הגישה לפרויקטים, לתיקיות ולארגונים.

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

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

   2. מוודאים שקבוצת המופעים שהוגדרה על ידי הפרמטר gcp_instance_group קיימת. כדי לאשר את קבוצת המופעים, פועלים לפי ההוראות במאמר הצגת המאפיינים של MIG, באמצעות הערכים של השם 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 operator מנהל את מחזור החיים של Symphony pod. בקטעים הבאים מוסבר איך לפתור בעיות נפוצות שקשורות לאופרטור ולמקורות המידע האלה.

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

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

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

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

• ‫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
      

ה-Pods לא נמחקים

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

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

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

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

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

   kubectl describe gcpsymphonyresource RESOURCE_NAME
   

2. אם משאב האב GCPSymphonyResource כבר לא נמצא במערכת, צריך להסיר את ה-finalizer מה-pod או מה-pods באופן ידני. ה-finalizer אומר ל-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

הבעיה הזו מתרחשת כשפוד פועל ב-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 מצביע על שורש ההתקנה של 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 בשם המשאב.