Probleme mit IBM Spectrum Symphony-Connectors beheben

In diesem Dokument erfahren Sie, wie Sie häufige Probleme mit der IBM Spectrum Symphony-Integration für Google Cloudbeheben. 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-Werksdienst

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 in der Regel /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 Bewältigung 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 den Status des konfigurierten Antragstellers, um festzustellen, ob er aktiviert ist und ob 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 source-Befehl 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 unter 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-Anfragende 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 Consumer und deren Arbeitslaststatus auf:

    egosh consumer list

  4. Suchen Sie in der Ausgabe nach dem Consumer, der Ihrer Arbeitslast zugeordnet ist, und prüfen Sie, ob die Arbeitslast aussteht. Wenn der Anfragesteller 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-Werksdienst 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 ist, 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 Logs, um detailliertere Logs 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 Umgebungsvariable $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-Logdatei ansehen, die sich unter Linux unter $EGO_TOP/hostfactory/log/hostfactory.hostname.log befindet.

Probleme mit dem Host-Fabrikprovider

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

Prüfen Sie die Anbieterlogs (hf-gce.log oder hf-gke.log) auf detaillierte Fehlermeldungen. Der Speicherort der Dateien hf-gce.log und hf-gke.log wird durch die Variable LOGFILE bestimmt, die in der Konfigurationsdatei des Bereitstellers 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 Hostvorlagenparameter 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 Containerimage-Namen, 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 Kubernetes-Operator-Problemen

Der Kubernetes-Operator verwaltet den Lebenszyklus eines Symphony-Pods. Die folgenden Abschnitte können Ihnen helfen, häufige Probleme zu beheben, die bei der Verwendung des Operators und dieser 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 Computeressourcen.

Verwenden Sie diese Statusfelder, um Probleme mit der GCPSymphonyResource-Ressource zu 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.

Verwenden Sie diese Statusfelder, um Probleme mit der MachineReturnRequest-Ressource zu 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-Image.
  • Einschränkungen des Ressourcenkontingents.

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 prüfen, um sicherzustellen, dass ausreichend Kapazität vorhanden ist:

    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 horizontal 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.
  • Es gibt Probleme mit der Knotenverbindung.

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 das MachineReturnRequest, um Details zum Rückgabeprozess 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. Prüfen Sie den machineEvents im MachineReturnRequest-Status auf bestimmte Fehlermeldungen:

    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 hängen bleiben.

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 nicht den Status WaitingCleanup hat:

    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 Bedingung Completed status 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 einen Completed-Vorgang 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 zu sehen ist, stattdessen aber phase: WaitingCleanup angezeigt wird, 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 gefahrlos löschen:

    kubectl delete gcpsr GCPSR_NAME

    Ersetzen Sie GCPSR_NAME durch den Namen Ihres GCPSymphonyResource.

  5. Wenn die Pods vor dem Löschen des 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 wird häufig durch Probleme mit der Netzwerkverbindung oder eine Fehlkonfiguration des Symphony-Clients im Container verursacht.

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 lokalen Symphony-Pod blockieren.

Retourenanfrage für Maschine fehlgeschlagen

Dieses Problem kann bei Scale-in-Vorgängen auftreten, wenn Sie eine benutzerdefinierte Ressource vom Typ MachineReturnRequest 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.