Probleme mit IBM Spectrum Symphony-Connectors beheben

Dieses Dokument hilft Ihnen, häufige Probleme mit der IBM Spectrum Symphony-Integration für Google Cloudzu beheben. Dieses Dokument enthält insbesondere Informationen zur Fehlerbehebung für den IBM Spectrum Symphony-Hostfactory-Dienst, die Connectors für Compute Engine- und GKE-Anbieter sowie den Symphony-Operator für Kubernetes.

Probleme mit dem Symphony-Host-Factory-Service

Diese Probleme beziehen sich auf den zentralen Symphony-Host-Factory-Dienst. Die Hauptlogdatei für diesen Dienst finden Sie unter Linux an folgendem Speicherort:

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

Sie legen die Umgebungsvariable $EGO_TOP fest, wenn Sie die Umgebungsvariablen der Host-Factory laden. In IBM Spectrum Symphony verweist $EGO_TOP auf das Installationsstammverzeichnis des Enterprise Grid Orchestrator (EGO), der der zentrale Ressourcenmanager für den Cluster ist. Der Standardinstallationspfad für $EGO_TOP unter Linux ist normalerweise /opt/ibm/spectrumcomputing.

Cluster fügt keine neuen VMs für ausstehende Arbeitslasten hinzu

Dieses Problem tritt auf, wenn die Symphony-Warteschlange Jobs enthält, die Host-Factory jedoch keine neuen virtuellen Maschinen (VMs) zur Verwaltung der Last bereitstellen kann. Die Host-Fabrikprotokolldatei enthält keine SCALE-OUT-Meldungen.

Dieses Problem tritt in der Regel auf, wenn der Symphony-Anforderer nicht richtig konfiguriert oder aktiviert ist. Prüfen Sie zur Behebung des Problems den Status des konfigurierten Antragstellers, um zu bestätigen, dass er aktiviert ist und eine ausstehende Arbeitslast vorhanden ist.

  1. Suchen Sie die Konfigurationsdatei des Antragstellers. Die Datei befindet sich normalerweise unter:

    $HF_TOP/conf/requestors/hostRequestors.json

    Die Umgebungsvariable $HF_TOP wird in Ihrer Umgebung definiert, wenn Sie den Befehl „source“ verwenden. Der Wert ist der Pfad zum Installationsverzeichnis der obersten Ebene für den IBM Spectrum Symphony-Hostfactory-Dienst.

  2. Öffnen Sie die Datei hostRequestors.json und suchen Sie den Eintrag symAinst. Prüfen Sie in diesem Abschnitt, ob der Parameter enabled auf den Wert 1 festgelegt ist und ob die Anbieterliste den Namen Ihrer konfigurierten Google Cloud Anbieterinstanz enthält.

    • Bei Compute Engine-Konfigurationen muss in der Anbieterliste der Name des Compute Engine-Anbieters angezeigt werden, den Sie während der Installation des Compute Engine-Anbieters in Anbieterinstanz aktivieren erstellt haben.
    • Bei GKE-Konfigurationen muss in der Anbieterliste der Name des GKE-Anbieters angezeigt werden, den Sie während der Installation des GKE-Anbieters in Anbieterinstanz aktivieren erstellt haben.

  3. Nachdem Sie bestätigt haben, dass der symAinst-Anfragesteller aktiviert ist, prüfen Sie, ob für einen Consumer eine ausstehende Arbeitslast vorhanden ist, die eine horizontale Skalierung erfordert.

    So rufen Sie eine Liste aller Nutzer und ihres Arbeitslaststatus auf:

    egosh consumer list

  4. Suchen Sie in der Ausgabe nach dem Ihrer Arbeitslast zugeordneten Consumer und prüfen Sie, ob die Arbeitslast aussteht. Wenn der Anforderer aktiviert ist und eine Arbeitslast aussteht, der Host Factory-Dienst jedoch keine Scale-out-Anfragen initiiert, prüfen Sie die Host Factory-Dienstlogs auf Fehler.

Host-Fabrikdienst startet nicht

Wenn der Host-Fabrikdienst nicht ausgeführt wird, führen Sie die folgenden Schritte aus, um das Problem zu beheben:

  1. Prüfen Sie den Status des HostFactory-Dienstes:

    egosh service list

    Suchen Sie in der Ausgabe nach dem Dienst HostFactory und prüfen Sie, ob im Feld STATE der Status STARTED angezeigt wird.

  2. Wenn der HostFactory-Dienst nicht gestartet wurde, starten Sie ihn neu:

    egosh service stop HostFactory
egosh service start HostFactory

Andere Fehler und Logging

Wenn Sie andere Fehler mit dem Host Factory-Dienst feststellen, erhöhen Sie die Ausführlichkeit der Protokolle, um detailliertere Protokolle zu erhalten. Führen Sie dazu folgende Schritte aus:

  1. Öffnen Sie die Datei hostfactoryconf.json zur Bearbeitung. Die Datei befindet sich in der Regel unter:

    $EGO_TOP/hostfactory/conf/

    Weitere Informationen zum Wert der Umgebungsvariablen $EGO_TOP finden Sie unter Probleme mit dem Symphony-Host-Factory-Dienst.

  2. Aktualisieren Sie den Wert HF_LOGLEVEL von LOG_INFO auf LOG_DEBUG:

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

  3. Speichern Sie die Datei, nachdem Sie die Änderung vorgenommen haben.

  4. Damit die Änderung wirksam wird, starten Sie den Dienst HostFactory neu:

    egosh service stop HostFactory
egosh service start HostFactory

Nach dem Neustart generiert der HostFactory-Dienst detailliertere Logs, die Sie zur Fehlerbehebung bei komplexen Problemen verwenden können. Sie können sich diese Logs in der Haupt-Host-Factory-Logdatei ansehen, die sich unter Linux unter $EGO_TOP/hostfactory/log/hostfactory.hostname.log befindet.

Probleme mit dem Host-Fabrikanbieter

Die folgenden Probleme treten in den Host Factory-Anbieterskripten für Compute Engine oder Google Kubernetes Engine auf.

Detaillierte Fehlermeldungen finden Sie in den Anbieterlogs (hf-gce.log oder hf-gke.log). Der Speicherort der Dateien hf-gce.log und hf-gke.log wird durch die Variable LOGFILE bestimmt, die in der Konfigurationsdatei des Anbieters unter Anbieterinstanz aktivieren festgelegt ist.

Virtuelle Maschine oder Pod wird nicht bereitgestellt

Dieses Problem kann auftreten, wenn in den Host-Factory-Provider-Logs ein Aufruf des requestMachines.sh-Skripts zu sehen ist, die Ressource aber nicht in Ihrem Google Cloud-Projekt angezeigt wird.

Führen Sie die folgenden Schritte aus, um das Problem zu beheben:

  1. Prüfen Sie die Protokolle des Anbieterskripts (hf-gce.log oder hf-gke.log) auf Fehlermeldungen von der Google Cloud API. Der Speicherort der Dateien hf-gce.log und hf-gke.log wird durch die Variable LOGFILE bestimmt, die in der Konfigurationsdatei des Anbieters unter Anbieterinstanz aktivieren festgelegt ist.

  2. Prüfen Sie, ob das Dienstkonto die richtigen IAM-Berechtigungen hat:

    1. Folgen Sie der Anleitung unter Aktuellen Zugriff ansehen.
    2. Prüfen Sie, ob das Dienstkonto die IAM-Rolle Compute Instance Admin (v1) (roles/compute.instanceAdmin.v1) für das Projekt hat. Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff auf Projekte, Ordner und Organisationen verwalten.

  3. Damit die Compute Engine-Parameter in Ihrer Hostvorlage gültig sind, müssen Sie Folgendes überprüfen:

    1. Die Parameter der Hostvorlage müssen in der Datei gcpgceinstprov_templates.json enthalten sein, die Sie bei der Installation des Compute Engine-Anbieters beim Einrichten einer Anbieterinstanz erstellt haben. Die häufigsten Parameter, die validiert werden müssen, sind gcp_zone und gcp_instance_group.

    2. Prüfen Sie, ob die mit dem Parameter gcp_instance_group festgelegte Instanzgruppe vorhanden ist. Wenn Sie die Instanzgruppe bestätigen möchten, folgen Sie der Anleitung unter Eigenschaften einer MIG ansehen. Verwenden Sie dazu die Werte für gcp_instance_group (Name) und gcp_zone (Zone) aus der Vorlagendatei.

Pod bleibt in GKE im Status Pending oder Error hängen

Dieses Problem kann auftreten, nachdem im hf-gke-Log die Erstellung der GCPSymphonyResource-Ressource angezeigt wird, der entsprechende Pod im GKE-Cluster jedoch nie den Status Running erreicht und möglicherweise einen Status wie Pending, ImagePullBackOff oder CrashLoopBackOff aufweist.

Dieses Problem tritt auf, wenn es ein Problem im Kubernetes-Cluster gibt, z. B. einen ungültigen Containernamen, unzureichende CPU- oder Arbeitsspeicherressourcen oder eine falsch konfigurierte Volume- oder Netzwerkeinstellung.

Verwenden Sie kubectl describe, um die Ereignisse für die benutzerdefinierte Ressource und den Pod zu prüfen und die Ursache zu ermitteln:

kubectl describe gcpsymphonyresource RESOURCE_NAME
kubectl describe pod POD_NAME

Ersetzen Sie Folgendes:

  • RESOURCE_NAME ist der Name der -Ressource.
  • POD_NAME: der Name des Pods.

Fehlerbehebung bei Problemen mit Kubernetes-Operatoren

Der Kubernetes-Operator verwaltet den Lebenszyklus eines Symphony-Pods. In den folgenden Abschnitten finden Sie Informationen zur Fehlerbehebung bei häufigen Problemen, die mit dem Operator und diesen Ressourcen auftreten können.

Probleme mit Ressourcenstatusfeldern diagnostizieren

Der Kubernetes-Operator verwaltet Symphony-Arbeitslasten in GKE mit zwei primären Ressourcentypen:

  • Mit der GCPSymphonyResource-Ressource (GCPSR) wird der Lebenszyklus von Compute-Pods für Symphony-Arbeitslasten verwaltet.
  • Die MachineReturnRequest-Ressource (MRR) verarbeitet die Rückgabe und Bereinigung von Rechenressourcen.

Anhand dieser Statusfelder können Sie Probleme mit der GCPSymphonyResource-Ressource diagnostizieren:

  • phase: Die aktuelle Lebenszyklusphase der Ressource. Die Optionen sind Pending, Running, WaitingCleanup oder Completed.
  • availableMachines: Die Anzahl der Compute-Pods, die bereit sind.
  • conditions: Detaillierte Statusbedingungen mit Zeitstempeln.
  • returnedMachines: Eine Liste der zurückgegebenen Pods.

Anhand dieser Statusfelder können Sie Probleme mit der MachineReturnRequest-Ressource diagnostizieren:

  • phase: Die aktuelle Phase der Rückgabeanfrage. Die Optionen sind Pending, InProgress, Completed, Failed oder PartiallyCompleted.
  • totalMachines: Die Gesamtzahl der zurückzugebenden Maschinen.
  • returnedMachines: Die Anzahl der erfolgreich zurückgegebenen Geräte.
  • failedMachines: Die Anzahl der Geräte, die nicht zurückgegeben wurden.
  • machineEvents: Statusdetails pro Maschine.

GCPSymphonyResource-Ressource hängt im Status Pending fest

Dieses Problem tritt auf, wenn die GCPSymphonyResource-Ressource im Status Pending verbleibt und der Wert von availableMachines nicht steigt.

Dieses Problem kann folgende Ursachen haben:

  • Unzureichende Knotenkapazität in Ihrem Cluster.
  • Probleme beim Abrufen des Container-Images.
  • Ressourcenkontingentbeschränkungen.

So lösen Sie dieses Problem:

  1. Prüfen Sie den Status der Pods, um Probleme mit dem Abrufen von Images oder der Ressourcenzuweisung zu erkennen:

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

    Ersetzen Sie REQUEST_ID durch Ihre Anfrage-ID.

  2. Knoten auf ausreichende Kapazität prüfen:

    kubectl get nodes -o wide

  3. Für Pods wird möglicherweise der Status Pending angezeigt. Dieses Problem tritt in der Regel auf, wenn der Kubernetes-Cluster skaliert werden muss und dies länger als erwartet dauert. Überwachen Sie die Knoten, um sicherzustellen, dass die Steuerungsebene skaliert werden kann.

Pods werden nicht zurückgegeben

Dieses Problem tritt auf, wenn Sie einen MachineReturnRequest (MRR) erstellen, die Anzahl der returnedMachines jedoch nicht steigt.

Das Problem kann folgende Ursachen haben:

  • Pods bleiben im Status Terminating hängen.
  • Es gibt Probleme mit der Knotenkonnektivität.

So lösen Sie dieses Problem:

  1. Prüfen Sie, ob Pods im Status Terminating hängen bleiben:

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

  2. Beschreiben Sie die MachineReturnRequest, um Details zum Retourenprozess zu erhalten:

    kubectl describe mrr MRR_NAME -n gcp-symphony

    Ersetzen Sie MRR_NAME durch den Namen Ihres MachineReturnRequest.

  3. Löschen Sie das benutzerdefinierte Ressourcenobjekt manuell. Durch das Löschen wird die endgültige Bereinigungslogik aktiviert:

    kubectl delete gcpsymphonyresource RESOURCE_NAME

    Ersetzen Sie RESOURCE_NAME durch den Namen der GCPSymphonyResource-Ressource.

Hohe Anzahl fehlgeschlagener Maschinen in einem MachineReturnRequest

Dieses Problem tritt auf, wenn die Anzahl der failedMachines im Status MachineReturnRequest größer als 0 ist. Das Problem kann folgende Ursachen haben:

  • Zeitüberschreitung beim Löschen des Pods.
  • Ein Knoten ist nicht verfügbar.

So lösen Sie dieses Problem:

  1. Suchen Sie im MachineReturnRequest-Status nach bestimmten Fehlermeldungen:machineEvents

    kubectl describe mrr MRR_NAME -n gcp-symphony

  2. Suchen Sie nach Ereignissen zu Knotenausfällen oder Leistungsproblemen der Steuerungsebene:

    1. Rufen Sie den Status aller Knoten ab:

      kubectl get nodes -o wide

    2. Einen bestimmten Knoten prüfen:

      kubectl describe node NODE_NAME

Pods werden nicht gelöscht

Dieses Problem tritt auf, wenn gelöschte Pods im Status Terminating oder Error verbleiben.

Das Problem kann folgende Ursachen haben:

  • Eine überlastete Steuerungsebene oder ein überlasteter Operator, was zu Zeitüberschreitungen oder API-Drosselungsereignissen führen kann.
  • Die manuelle Löschung der übergeordneten GCPSymphonyResource-Ressource.

So lösen Sie dieses Problem:

  1. Prüfen Sie, ob die übergeordnete Ressource GCPSymphonyResource noch verfügbar ist und sich nicht im Status WaitingCleanup befindet:

    kubectl describe gcpsymphonyresource RESOURCE_NAME

  2. Wenn die übergeordnete GCPSymphonyResource-Ressource nicht mehr im System vorhanden ist, entfernen Sie den Finalizer manuell aus dem Pod oder den Pods. Der Finalizer weist Kubernetes an, zu warten, bis der Symphony-Operator seine Bereinigungsaufgaben abgeschlossen hat, bevor Kubernetes den Pod vollständig löscht. Sehen Sie sich zuerst die YAML-Konfiguration an, um den Finalizer zu finden:

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

    Ersetzen Sie REQUEST_ID durch die Anforderungs-ID, die den Pods zugeordnet ist.

  3. Suchen Sie in der Ausgabe im Abschnitt „metadata“ nach dem Feld „finalizers“. Die Ausgabe sollte in etwa so aussehen:

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

  4. Verwenden Sie den Befehl kubectl patch, um den Finalizer manuell aus dem Pod oder den Pods zu entfernen:

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

    Ersetzen Sie REQUEST_ID durch die Anforderungs-ID, die den Pods zugeordnet ist.

Alte Symphony-Ressourcen werden nicht automatisch aus dem GKE-Cluster gelöscht

Nachdem eine Arbeitslast abgeschlossen ist und GKE die zugehörigen Pods beendet hat, verbleiben die zugehörigen GCPSymphonyResource- und MachineReturnRequest-Objekte länger als der erwartete Bereinigungszeitraum von 24 Stunden in Ihrem GKE-Cluster.

Dieses Problem tritt auf, wenn einem GCPSymphonyResource-Objekt die erforderliche Completed status-Bedingung fehlt. Der automatische Bereinigungsprozess des Betreibers hängt von diesem Status ab, um das Objekt zu entfernen. So beheben Sie das Problem:

  1. Sehen Sie sich die Details der betreffenden GCPSymphonyResource-Ressource an:

    kubectl get gcpsr GCPSR_NAME -o yaml

    Ersetzen Sie GCPSR_NAME durch den Namen der GCPSymphonyResource-Ressource mit diesem Problem.

  2. Prüfen Sie die Bedingungen für eine Bedingung vom Typ Completed mit dem Status 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"

    Wenn diese Bedingung nicht in den GCPSymphonyResource-Details angezeigt wird, stattdessen aber phase: WaitingCleanup, ist das Completed-Ereignis verloren gegangen.

  3. Prüfen Sie, ob Pods mit der GCPSymphonyResource verknüpft sind:

    kubectl get pods -l symphony.requestId=REQUEST_ID

    Ersetzen Sie REQUEST_ID durch die Anforderungs-ID.

  4. Wenn keine Pods vorhanden sind, können Sie die GCPSymphonyResource-Ressource sicher löschen:

    kubectl delete gcpsr GCPSR_NAME

    Ersetzen Sie GCPSR_NAME durch den Namen Ihres GCPSymphonyResource.

  5. Wenn die Pods vor dem Löschen von GCPSymphonyResource vorhanden waren, müssen Sie sie löschen. Wenn die Pods noch vorhanden sind, folgen Sie der Anleitung im Abschnitt Pods werden nicht gelöscht.

Pod tritt dem Symphony-Cluster nicht bei

Dieses Problem tritt auf, wenn ein Pod in GKE ausgeführt wird, aber nicht als gültiger Host im Symphony-Cluster angezeigt wird.

Dieses Problem tritt auf, wenn die Symphony-Software, die im Pod ausgeführt wird, keine Verbindung zum primären Symphony-Host herstellen und sich dort nicht registrieren kann. Dieses Problem ist oft auf Probleme mit der Netzwerkkonnektivität oder eine falsche Konfiguration des Symphony-Clients im Container zurückzuführen.

Prüfen Sie zur Behebung dieses Problems die Logs der Symphony-Dienste, die im Pod ausgeführt werden.

  1. Verwenden Sie SSH oder exec, um auf den Pod zuzugreifen und die Logs anzusehen:

    kubectl exec -it POD_NAME -- /bin/bash

    Ersetzen Sie POD_NAME durch den Namen des Pods.

  2. Wenn Sie eine Shell im Pod haben, befinden sich die Logs für die EGO- und LIM-Daemons im Verzeichnis $EGO_TOP/kernel/log. Die Umgebungsvariable $EGO_TOP verweist auf das Stammverzeichnis der IBM Spectrum Symphony-Installation:

    cd $EGO_TOP/kernel/log

    Weitere Informationen zum Wert der Umgebungsvariable $EGO_TOP finden Sie unter Probleme mit dem Symphony-Host-Factory-Dienst.

  3. Prüfen Sie die Logs auf Konfigurations- oder Netzwerkfehler, die die Verbindung vom GKE-Pod zum primären Symphony-Pod vor Ort blockieren.

Anfrage zur Rückgabe der Maschine fehlgeschlagen

Dieses Problem kann bei Scale-in-Vorgängen auftreten, wenn Sie eine benutzerdefinierte MachineReturnRequest-Ressource erstellen, das Objekt jedoch hängen bleibt und der Operator den entsprechenden Symphony-Pod nicht beendet.

Ein Fehler in der Finalizer-Logik des Operators verhindert das vollständige Löschen des Pods und der zugehörigen benutzerdefinierten Ressource. Dieses Problem kann zu verwaisten Ressourcen und unnötigen Kosten führen.

Löschen Sie die benutzerdefinierte Ressource manuell, um dieses Problem zu beheben. Dadurch sollte die Bereinigungslogik des Operators aktiviert werden:

kubectl delete gcpsymphonyresource RESOURCE_NAME

Ersetzen Sie RESOURCE_NAME durch den Namen der Ressource.