Résoudre les problèmes liés aux connecteurs IBM Spectrum Symphony

Ce document vous aide à résoudre les problèmes courants liés à l'intégration d'IBM Spectrum Symphony pour Google Cloud. Plus précisément, ce document fournit des conseils de dépannage pour le service IBM Spectrum Symphony Host Factory, les connecteurs pour les fournisseurs Compute Engine et GKE, et l'opérateur Symphony pour Kubernetes.

Problèmes liés au service d'usine de l'hôte Symphony

Ces problèmes sont liés au service central de fabrique d'hôtes Symphony. Vous trouverez le fichier journal principal de ce service à l'emplacement suivant sous Linux :

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

Vous définissez la variable d'environnement $EGO_TOP lorsque vous chargez les variables d'environnement de la fabrique d'hôtes. Dans IBM Spectrum Symphony, $EGO_TOP pointe vers la racine d'installation de l'Enterprise Grid Orchestrator (EGO), qui est le gestionnaire de ressources principal du cluster. Le chemin d'installation par défaut de $EGO_TOP sur Linux est généralement /opt/ibm/spectrumcomputing.

Le cluster n'ajoute pas de VM pour les charges de travail en attente

Ce problème se produit lorsque la file d'attente Symphony contient des jobs, mais que la fabrique d'hôtes ne parvient pas à provisionner de nouvelles machines virtuelles (VM) pour gérer la charge. Le fichier journal de l'usine hôte ne contient aucun message SCALE-OUT.

Ce problème se produit généralement lorsque le demandeur Symphony n'est pas correctement configuré ni activé. Pour résoudre le problème, vérifiez l'état du demandeur configuré pour vous assurer qu'il est activé et qu'il existe une charge de travail en attente.

Localisez le fichier de configuration du demandeur. Le fichier se trouve généralement à l'emplacement suivant :
```
$HF_TOP/conf/requestors/hostRequestors.json
```
La variable d'environnement $HF_TOP est définie dans votre environnement lorsque vous utilisez la commande source. La valeur correspond au chemin d'accès au répertoire d'installation de premier niveau pour le service de fabrique d'hôtes IBM Spectrum Symphony.
Ouvrez le fichier hostRequestors.json et recherchez l'entrée symAinst. Dans cette section, vérifiez que le paramètre enabled est défini sur la valeur 1 et que la liste des fournisseurs inclut le nom de votre instance de fournisseur Google Cloud configurée.
- Pour les configurations Compute Engine, la liste des fournisseurs doit afficher le nom du fournisseur Compute Engine que vous avez créé dans Activer l'instance de fournisseur lors de l'installation du fournisseur Compute Engine.
- Pour les configurations GKE, la liste des fournisseurs doit afficher le nom du fournisseur GKE que vous avez créé dans Activer l'instance de fournisseur lors de l'installation du fournisseur GKE.
Après avoir confirmé que le demandeur symAinst est activé, vérifiez si un consommateur a une charge de travail en attente qui nécessite un scale-out.

Affichez la liste de tous les consommateurs et l'état de leur charge de travail :
```
egosh consumer list
```
Dans le résultat, recherchez le consommateur associé à votre charge de travail et vérifiez que la charge de travail est en attente. Si le demandeur est activé et qu'une charge de travail est en attente, mais que le service HostFactory n'initie pas de requêtes de scale-out, vérifiez les journaux du service HostFactory pour détecter les erreurs.

Le service d'usine de l'hôte ne démarre pas

Si le service d'usine hôte ne s'exécute pas, procédez comme suit pour résoudre le problème :

Vérifiez l'état du service HostFactory :
```
egosh service list
```
Dans le résultat, recherchez le service HostFactory et vérifiez que le champ STATE affiche l'état STARTED.

Si le service HostFactory n'est pas démarré, redémarrez-le :

egosh service stop HostFactory
egosh service start HostFactory

Autres erreurs et journalisation

Si vous rencontrez d'autres erreurs avec le service de fabrique d'hôtes, augmentez la verbosité des journaux pour obtenir des journaux plus détaillés. Pour ce faire, procédez comme suit :

Ouvrez le fichier hostfactoryconf.json pour le modifier. Le fichier se trouve généralement à l'emplacement suivant :
```
$EGO_TOP/hostfactory/conf/
```
Pour en savoir plus sur la valeur de la variable d'environnement $EGO_TOP, consultez Problèmes liés au service de fabrique d'hôtes Symphony.

Remplacez la valeur LOG_INFO de HF_LOGLEVEL par LOG_DEBUG :

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

Enregistrez le fichier après avoir effectué la modification.
Pour que la modification prenne effet, redémarrez le service HostFactory :
```
egosh service stop HostFactory
egosh service start HostFactory
```

Après le redémarrage, le service HostFactory génère des journaux plus détaillés, que vous pouvez utiliser pour résoudre les problèmes complexes. Vous pouvez consulter ces journaux dans le fichier journal principal de la fabrique d'hôtes, situé à l'adresse $EGO_TOP/hostfactory/log/hostfactory.hostname.log sous Linux.

Problèmes liés au fournisseur d'usine hôte

Les problèmes suivants se produisent dans les scripts du fournisseur de fabrique d'hôtes pour Compute Engine ou Google Kubernetes Engine.

Consultez les journaux du fournisseur (hf-gce.log ou hf-gke.log) pour obtenir des messages d'erreur détaillés. L'emplacement des fichiers hf-gce.log et hf-gke.log est déterminé par la variable LOGFILE définie dans le fichier de configuration du fournisseur dans Activer l'instance du fournisseur.

La machine virtuelle ou le pod n'est pas provisionné

Ce problème peut se produire après que les journaux du fournisseur de fabrique hôte affichent un appel au script requestMachines.sh, mais que la ressource n'apparaît pas dans votre projet Google Cloud.

Pour résoudre ce problème, procédez comme suit :

Consultez les journaux du script du fournisseur (hf-gce.log ou hf-gke.log) pour voir s'ils contiennent des messages d'erreur provenant de l'API Google Cloud . L'emplacement des fichiers hf-gce.log et hf-gke.log est déterminé par la variable LOGFILE définie dans le fichier de configuration du fournisseur sous Activer l'instance du fournisseur.
Vérifiez que le compte de service dispose des autorisations IAM appropriées :
1. Suivez les instructions de la section Afficher les accès actuels.
2. Vérifiez que le compte de service dispose du rôle IAM Administrateur d'instances Compute (v1) (roles/compute.instanceAdmin.v1) sur le projet. Pour en savoir plus sur l'attribution de rôles, consultez Gérer l'accès aux projets, aux dossiers et aux organisations.
Pour vous assurer que les paramètres Compute Engine de votre modèle d'hôte sont valides, vous devez vérifier les points suivants :
1. Les paramètres du modèle d'hôte doivent figurer dans le fichier gcpgceinstprov_templates.json que vous avez créé lorsque vous avez configuré une instance de fournisseur lors de l'installation du fournisseur Compute Engine. Les paramètres les plus courants à valider sont gcp_zone et gcp_instance_group.
2. Vérifiez que l'ensemble de groupes d'instances défini par le paramètre gcp_instance_group existe. Pour confirmer le groupe d'instances, suivez les instructions de la section Afficher les propriétés d'un MIG en utilisant les valeurs gcp_instance_group et gcp_zone du fichier de modèle.

Pod bloqué à l'état `Pending` ou `Error` sur GKE

Ce problème peut se produire après que le journal hf-gke indique que la ressource GCPSymphonyResource a été créée, mais que le pod correspondant dans le cluster GKE n'atteint jamais l'état Running et peut afficher un état tel que Pending, ImagePullBackOff ou CrashLoopBackOff.

Ce problème se produit en cas de problème au sein du cluster Kubernetes, par exemple un nom d'image de conteneur non valide, des ressources de processeur ou de mémoire insuffisantes, ou un paramètre de volume ou de réseau mal configuré.

Pour résoudre ce problème, utilisez kubectl describe afin d'inspecter les événements de la ressource personnalisée et du pod pour identifier la cause première :

kubectl describe gcpsymphonyresource RESOURCE_NAME
kubectl describe pod POD_NAME

Remplacez les éléments suivants :

RESOURCE_NAME : nom de la ressource.
POD_NAME : nom du pod.

Résoudre les problèmes liés aux opérateurs Kubernetes

L'opérateur Kubernetes gère le cycle de vie d'un pod Symphony. Les sections suivantes peuvent vous aider à résoudre les problèmes courants que vous pouvez rencontrer avec l'opérateur et ces ressources.

Diagnostiquer les problèmes liés aux champs d'état des ressources

L'opérateur Kubernetes gère les charges de travail Symphony dans GKE avec deux principaux types de ressources :

La ressource GCPSymphonyResource (GCPSR) gère le cycle de vie des pods de calcul pour les charges de travail Symphony.
La ressource MachineReturnRequest (MRR) gère le retour et le nettoyage des ressources de calcul.

Utilisez ces champs d'état pour diagnostiquer les problèmes liés à la ressource GCPSymphonyResource :

phase : phase actuelle du cycle de vie de la ressource. Les options sont Pending, Running, WaitingCleanup ou Completed.
availableMachines : nombre de pods de calcul prêts.
conditions : conditions d'état détaillées avec des codes temporels.
returnedMachines : liste des pods renvoyés.

Utilisez ces champs d'état pour diagnostiquer les problèmes liés à la ressource MachineReturnRequest :

phase : phase actuelle de la demande de retour. Les options sont Pending, InProgress, Completed, Failed ou PartiallyCompleted.
totalMachines : nombre total de machines à renvoyer.
returnedMachines : nombre de machines renvoyées avec succès.
failedMachines : nombre de machines qui n'ont pas été renvoyées.
machineEvents : détails de l'état par machine.

Ressource `GCPSymphonyResource` bloquée à l'état `Pending`

Ce problème se produit lorsque la ressource GCPSymphonyResource reste à l'état Pending et que la valeur de availableMachines n'augmente pas.

Ce problème peut survenir pour l'une des raisons suivantes :

La capacité des nœuds de votre cluster est insuffisante.
Problèmes liés à l'extraction de l'image de conteneur.
Limites de quota de ressources.

Pour remédier à ce problème :

Vérifiez l'état des pods pour identifier les problèmes d'extraction d'images ou d'allocation de ressources :
```
kubectl describe pods -n gcp-symphony -l symphony.requestId=REQUEST_ID
```
Remplacez REQUEST_ID par l'ID de votre demande.
Inspectez les nœuds pour vous assurer que leur capacité est suffisante :
```
kubectl get nodes -o wide
```
Les pods peuvent afficher l'état Pending. Ce problème se produit généralement lorsque le cluster Kubernetes doit être mis à l'échelle et que cela prend plus de temps que prévu. Surveillez les nœuds pour vous assurer que le plan de contrôle peut effectuer un scaling horizontal.

Les pods ne sont pas retournés

Ce problème se produit lorsque vous créez un MachineReturnRequest (MRR), mais que le nombre de returnedMachines n'augmente pas.

Ce problème peut survenir pour les raisons suivantes :

Les pods sont bloqués à l'état Terminating.
Des problèmes de connectivité des nœuds sont détectés.

Pour remédier à ce problème :

Recherchez les pods bloqués à l'état Terminating :

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

Décrivez le MachineReturnRequest pour obtenir des informations sur la procédure de retour :
```
kubectl describe mrr MRR_NAME -n gcp-symphony
```
Remplacez MRR_NAME par le nom de votre MachineReturnRequest.
Supprimez manuellement l'objet de ressource personnalisée. Cette suppression active la logique de nettoyage final :
```
kubectl delete gcpsymphonyresource RESOURCE_NAME
```
Remplacez RESOURCE_NAME par le nom de la ressource GCPSymphonyResource.

Nombre élevé de machines en échec dans un `MachineReturnRequest`

Ce problème survient lorsque le nombre de failedMachines dans l'état MachineReturnRequest est supérieur à 0. Ce problème peut survenir pour les raisons suivantes :

Le délai de suppression du pod a expiré.
Un nœud n'est pas disponible.

Pour remédier à ce problème :

Consultez l'état MachineReturnRequest de machineEvents pour obtenir des messages d'erreur spécifiques :
```
kubectl describe mrr MRR_NAME -n gcp-symphony
```
Recherchez les événements d'échec de nœud ou les problèmes de performances du plan de contrôle :
1. Obtenez l'état de tous les nœuds :
```
kubectl get nodes -o wide
```
2. Inspecter un nœud spécifique :
```
kubectl describe node NODE_NAME
```

Les pods ne sont pas supprimés

Ce problème se produit lorsque des pods supprimés sont bloqués à l'état Terminating ou Error.

Ce problème peut survenir pour les raisons suivantes :

Un plan de contrôle ou un opérateur surchargé, qui peut entraîner des événements de délai avant expiration ou de limitation de l'API.
Suppression manuelle de la ressource parente GCPSymphonyResource.

Pour remédier à ce problème :

Vérifiez si la ressource GCPSymphonyResource parente est toujours disponible et n'est pas à l'état WaitingCleanup :
```
kubectl describe gcpsymphonyresource RESOURCE_NAME
```
Si la ressource parente GCPSymphonyResource n'est plus dans le système, supprimez manuellement le finaliseur du ou des pods. Le finaliseur indique à Kubernetes d'attendre que l'opérateur Symphony termine ses tâches de nettoyage avant que Kubernetes ne supprime complètement le pod. Commencez par inspecter la configuration YAML pour trouver le finaliseur :
```
kubectl get pods -n gcp-symphony -l symphony.requestId=REQUEST_ID -o yaml
```
Remplacez REQUEST_ID par l'ID de la requête associée aux pods.
Dans le résultat, recherchez le champ "finalizers" dans la section "metadata". Un résultat semblable à l'extrait suivant doit s'afficher :
```
metadata:
...
finalizers:
-   symphony-operator/finalizer
```

Pour supprimer manuellement le finaliseur du ou des pods, utilisez la commande 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"}]'

Remplacez REQUEST_ID par l'ID de la requête associée aux pods.

Les anciennes ressources Symphony ne sont pas supprimées automatiquement du cluster GKE

Une fois qu'une charge de travail est terminée et que GKE arrête ses pods, les objets GCPSymphonyResource et MachineReturnRequest associés restent dans votre cluster GKE plus longtemps que la période de nettoyage de 24 heures prévue.

Ce problème se produit lorsqu'un objet GCPSymphonyResource ne comporte pas la condition Completed status requise. Le processus de nettoyage automatique de l'opérateur dépend de cet état pour supprimer l'objet. Pour résoudre ce problème, procédez comme suit :

Examinez les détails de la ressource GCPSymphonyResource en question :
```
kubectl get gcpsr GCPSR_NAME -o yaml
```
Remplacez GCPSR_NAME par le nom de la ressource GCPSymphonyResource concernée par ce problème.

Examinez les conditions de type Completed avec l'état 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"

Si cette condition n'est pas visible dans les détails de GCPSymphonyResource, mais que phase: WaitingCleanup s'affiche à la place, l'événement Completed a été perdu.

Recherchez les pods associés à GCPSymphonyResource :
```
kubectl get pods -l symphony.requestId=REQUEST_ID
```
Remplacez REQUEST_ID par l'ID de la demande.
S'il n'existe aucun pod, supprimez la ressource GCPSymphonyResource en toute sécurité :
```
kubectl delete gcpsr GCPSR_NAME
```
Remplacez GCPSR_NAME par le nom de votre GCPSymphonyResource.
Si les pods existaient avant la suppression de GCPSymphonyResource, vous devez les supprimer. Si les pods existent toujours, suivez la procédure décrite dans la section Les pods ne sont pas supprimés.

Le pod ne rejoint pas le cluster Symphony

Ce problème se produit lorsqu'un pod s'exécute dans GKE, mais qu'il n'apparaît pas comme un hôte valide dans le cluster Symphony.

Ce problème se produit si le logiciel Symphony exécuté dans le pod ne parvient pas à se connecter à l'hôte principal Symphony ni à s'y enregistrer. Ce problème est souvent dû à des problèmes de connectivité réseau ou à une mauvaise configuration du client Symphony dans le conteneur.

Pour résoudre ce problème, vérifiez les journaux des services Symphony exécutés dans le pod.

Utilisez SSH ou exec pour accéder au pod et afficher les journaux :
```
kubectl exec -it POD_NAME -- /bin/bash
```
Remplacez POD_NAME par le nom du pod.
Lorsque vous avez un sh à l'intérieur du pod, les journaux des daemons EGO et LIM se trouvent dans le répertoire $EGO_TOP/kernel/log. La variable d'environnement $EGO_TOP pointe vers la racine de l'installation IBM Spectrum Symphony :
```
cd $EGO_TOP/kernel/log
```
Pour en savoir plus sur la valeur de la variable d'environnement $EGO_TOP, consultez Problèmes liés au service de fabrique d'hôtes Symphony.
Examinez les journaux pour détecter les erreurs de configuration ou de réseau qui bloquent la connexion entre le pod GKE et le pod principal Symphony sur site.

Échec de la demande de retour de la machine

Ce problème peut se produire lors d'opérations de réduction lorsque vous créez une ressource personnalisée MachineReturnRequest, mais que l'objet reste bloqué et que l'opérateur ne met pas fin au pod Symphony correspondant.

Un échec dans la logique du finaliseur de l'opérateur empêche la suppression propre du pod et de sa ressource personnalisée associée. Ce problème peut entraîner des ressources orphelines et des coûts inutiles.

Pour résoudre ce problème, supprimez manuellement la ressource personnalisée, ce qui devrait activer la logique de nettoyage de l'opérateur :

kubectl delete gcpsymphonyresource RESOURCE_NAME

Remplacez RESOURCE_NAME par le nom de la ressource.

Résoudre les problèmes liés aux connecteurs IBM Spectrum Symphony Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Problèmes liés au service d'usine de l'hôte Symphony

Le cluster n'ajoute pas de VM pour les charges de travail en attente

Le service d'usine de l'hôte ne démarre pas

Autres erreurs et journalisation

Problèmes liés au fournisseur d'usine hôte

La machine virtuelle ou le pod n'est pas provisionné

Pod bloqué à l'état Pending ou Error sur GKE

Résoudre les problèmes liés aux opérateurs Kubernetes

Diagnostiquer les problèmes liés aux champs d'état des ressources

Ressource GCPSymphonyResource bloquée à l'état Pending

Les pods ne sont pas retournés

Nombre élevé de machines en échec dans un MachineReturnRequest

Les pods ne sont pas supprimés

Les anciennes ressources Symphony ne sont pas supprimées automatiquement du cluster GKE

Le pod ne rejoint pas le cluster Symphony

Échec de la demande de retour de la machine

Résoudre les problèmes liés aux connecteurs IBM Spectrum Symphony

Pod bloqué à l'état `Pending` ou `Error` sur GKE

Ressource `GCPSymphonyResource` bloquée à l'état `Pending`

Nombre élevé de machines en échec dans un `MachineReturnRequest`