Risolvere i problemi relativi ai connettori IBM Spectrum Symphony

Questo documento ti aiuta a risolvere i problemi comuni relativi all'integrazione di IBM Spectrum Symphony per Google Cloud. In particolare, questo documento fornisce indicazioni per la risoluzione dei problemi per il servizio host factory di IBM Spectrum Symphony, i connettori per i provider Compute Engine e GKE e l'operatore Symphony per Kubernetes.

Problemi relativi al servizio di fabbrica dell'host Symphony

Questi problemi riguardano il servizio di fabbrica host Symphony centrale. Puoi trovare il file di log principale per questo servizio nel seguente percorso su Linux:

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

Imposta la variabile di ambiente $EGO_TOP quando carichi le variabili di ambiente della fabbrica di host. In IBM Spectrum Symphony, $EGO_TOP punta alla radice di installazione di Enterprise Grid Orchestrator (EGO), che è il gestore di risorse principale per il cluster. Il percorso di installazione predefinito per $EGO_TOP su Linux è in genere /opt/ibm/spectrumcomputing.

Il cluster non aggiunge nuove VM per i workload in attesa

Questo problema si verifica quando la coda di Symphony contiene job, ma la fabbrica host non riesce a eseguire il provisioning di nuove macchine virtuali (VM) per gestire il carico. Il file di log di fabbrica dell'host non contiene messaggi SCALE-OUT.

Questo problema si verifica in genere quando il richiedente Symphony non è configurato o abilitato correttamente. Per risolvere il problema, controlla lo stato del richiedente configurato per verificare che sia abilitato e che ci sia un carico di lavoro in attesa.

Individua il file di configurazione del richiedente. Il file si trova in genere in:
```
$HF_TOP/conf/requestors/hostRequestors.json
```
La variabile di ambiente $HF_TOP è definita nel tuo ambiente quando utilizzi il comando source. Il valore è il percorso della directory di installazione di primo livello per il servizio di fabbrica host IBM Spectrum Symphony.
Apri il file hostRequestors.json e individua la voce symAinst. In questa sezione, verifica che il parametro enabled sia impostato sul valore 1 e che l'elenco dei provider includa il nome dell'istanza del provider Google Cloud configurata.
- Per le configurazioni di Compute Engine, l'elenco dei provider deve mostrare il nome del provider Compute Engine che hai creato in Attiva l'istanza del provider durante l'installazione del provider Compute Engine.
- Per le configurazioni GKE, l'elenco dei provider deve mostrare il nome del provider GKE che hai creato in Abilita l'istanza del provider durante l'installazione del provider GKE.
Dopo aver confermato che il richiedente symAinst è abilitato, controlla se un consumer ha un workload in attesa che richiede uno scale-out.

Visualizza un elenco di tutti i consumer e lo stato del loro workload:
```
egosh consumer list
```
Nell'output, cerca il consumer associato al tuo workload e verifica che il workload sia in attesa. Se il richiedente è abilitato e un carico di lavoro è in attesa, ma il servizio di fabbrica host non avvia richieste di scalabilità orizzontale, controlla i log del servizio di fabbrica host per eventuali errori.

Il servizio di fabbrica dell'host non si avvia

Se il servizio di fabbrica dell'host non viene eseguito, segui questi passaggi per risolvere il problema:

Controlla lo stato del servizio HostFactory:
```
egosh service list
```
Nell'output, individua il servizio HostFactory e verifica che il campo STATE mostri lo stato STARTED.

Se il servizio HostFactory non è avviato, riavvialo:

egosh service stop HostFactory
egosh service start HostFactory

Altri errori e logging

Se riscontri altri errori con il servizio di fabbrica host, aumenta il livello di dettaglio dei log per ottenere log più dettagliati. Per farlo, segui questa procedura.

Apri il file hostfactoryconf.json per modificarlo. Il file si trova in genere in:
```
$EGO_TOP/hostfactory/conf/
```
Per ulteriori informazioni sul valore della variabile di ambiente $EGO_TOP, consulta Problemi con il servizio di fabbrica host di Symphony.

Aggiorna il valore di HF_LOGLEVEL da LOG_INFO a LOG_DEBUG:

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

Salva il file dopo aver apportato la modifica.

Per applicare la modifica, riavvia il servizio HostFactory:

egosh service stop HostFactory
egosh service start HostFactory

Dopo il riavvio, il servizio HostFactory genera log più dettagliati, che puoi utilizzare per risolvere problemi complessi. Puoi visualizzare questi log nel file di log principale della fabbrica host, che si trova in $EGO_TOP/hostfactory/log/hostfactory.hostname.log su Linux.

Problemi relativi al fornitore di fabbrica dell'host

I seguenti problemi si verificano all'interno degli script del provider di fabbrica host per Compute Engine o Google Kubernetes Engine.

Controlla i log del fornitore (hf-gce.log o hf-gke.log) per i messaggi di errore dettagliati. La posizione dei file hf-gce.log e hf-gke.log è determinata dalla variabile LOGFILE impostata nel file di configurazione del provider in Enable the provider instance.

La macchina virtuale o il pod non è stato sottoposto a provisioning

Questo problema potrebbe verificarsi dopo che i log del fornitore di fabbrica host mostrano una chiamata allo script requestMachines.sh, ma la risorsa non viene visualizzata nel progetto Google Cloud.

Per risolvere il problema, procedi nel seguente modo:

Controlla i log dello script del fornitore (hf-gce.log o hf-gke.log) per i messaggi di errore dell'API Google Cloud . La posizione dei file hf-gce.log e hf-gke.log è determinata dalla variabile LOGFILE impostata nel file di configurazione del provider in Attiva l'istanza del provider.
Verifica che il account di servizio disponga delle autorizzazioni IAM corrette:
1. Segui le istruzioni riportate in Visualizzare l'accesso attuale.
2. Verifica che il account di servizio disponga del ruolo IAM Amministratore istanze Compute (v1) (roles/compute.instanceAdmin.v1) sul progetto. Per saperne di più su come concedere i ruoli, consulta Gestisci l'accesso a progetti, cartelle e organizzazioni.
Per assicurarti che i parametri di Compute Engine nel modello di host siano validi, devi verificare quanto segue:
1. I parametri del modello host devono trovarsi nel file gcpgceinstprov_templates.json che hai creato quando hai configurato un'istanza del provider durante l'installazione del provider Compute Engine. I parametri più comuni da convalidare sono gcp_zone e gcp_instance_group.
2. Verifica che il gruppo di istanze impostato dal parametro gcp_instance_group esista. Per confermare il gruppo di istanze, segui le istruzioni riportate in Visualizzare le proprietà di un gruppo di istanze gestite utilizzando i valori del nome gcp_instance_group e della zona gcp_zone del file del modello.

Il pod rimane bloccato nello stato `Pending` o `Error` su GKE

Questo problema potrebbe verificarsi dopo che il log hf-gke mostra la creazione della risorsa GCPSymphonyResource, ma il pod corrispondente nel cluster GKE non raggiunge mai lo stato Running e potrebbe mostrare uno stato come Pending, ImagePullBackOff o CrashLoopBackOff.

Questo problema si verifica se si verifica un problema all'interno del cluster Kubernetes, ad esempio un nome di immagine container non valido, risorse di CPU o memoria insufficienti o un'impostazione di volume o di rete configurata in modo errato.

Per risolvere il problema, utilizza kubectl describe per esaminare gli eventi sia per la risorsa personalizzata sia per il pod per identificare la causa principale:

kubectl describe gcpsymphonyresource RESOURCE_NAME
kubectl describe pod POD_NAME

Sostituisci quanto segue:

RESOURCE_NAME: il nome della risorsa.
POD_NAME: il nome del pod.

Risoluzione dei problemi relativi all'operatore Kubernetes

L'operatore Kubernetes gestisce il ciclo di vita di un pod Symphony. Le seguenti sezioni possono aiutarti a risolvere i problemi comuni che potresti riscontrare con l'operatore e queste risorse.

Diagnosticare i problemi relativi ai campi di stato delle risorse

L'operatore Kubernetes gestisce i carichi di lavoro Symphony in GKE con due tipi di risorse principali:

La risorsa GCPSymphonyResource (GCPSR) gestisce il ciclo di vita dei pod di calcolo per i carichi di lavoro Symphony.
La risorsa MachineReturnRequest (MRR) gestisce il ritorno e la pulizia delle risorse di calcolo.

Utilizza questi campi di stato per diagnosticare i problemi relativi alla risorsa GCPSymphonyResource:

phase: La fase del ciclo di vita attuale della risorsa. Le opzioni sono Pending, Running, WaitingCleanup o Completed.
availableMachines: Il numero di pod di calcolo pronti.
conditions: condizioni di stato dettagliate con timestamp.
returnedMachines: Un elenco di pod restituiti.

Utilizza questi campi di stato per diagnosticare i problemi relativi alla risorsa MachineReturnRequest:

phase: La fase attuale della richiesta di reso. Le opzioni sono Pending, InProgress, Completed, Failed o PartiallyCompleted.
totalMachines: Il numero totale di macchine da restituire.
returnedMachines: Il numero di macchine restituite correttamente.
failedMachines: Il numero di macchine che non sono state restituite.
machineEvents: Dettagli sullo stato per macchina.

Risorsa `GCPSymphonyResource` bloccata nello stato `Pending`

Questo problema si verifica quando la risorsa GCPSymphonyResource rimane nello stato Pending e il valore di availableMachines non aumenta.

Questo problema può verificarsi per uno dei seguenti motivi:

Capacità dei nodi insufficiente nel cluster.
Problemi con il pull dell'immagine container.
Limitazioni della quota di risorse.

Per risolvere il problema:

Controlla lo stato dei pod per identificare eventuali problemi con i pull delle immagini o l'allocazione delle risorse:
```
kubectl describe pods -n gcp-symphony -l symphony.requestId=REQUEST_ID
```
Sostituisci REQUEST_ID con l'ID richiesta.
Ispeziona i nodi per assicurarti che la capacità sia sufficiente:
```
kubectl get nodes -o wide
```
I pod potrebbero mostrare lo stato Pending. Questo problema si verifica in genere quando il cluster Kubernetes deve essere scalato e richiede più tempo del previsto. Monitora i nodi per assicurarti che il control plane possa essere scalato orizzontalmente.

I pod non vengono restituiti

Questo problema si verifica quando crei un MachineReturnRequest (MRR), ma il numero di returnedMachines non aumenta.

Questo problema può verificarsi per i seguenti motivi:

I pod sono bloccati nello stato Terminating.
Esistono problemi di connettività dei nodi.

Per risolvere il problema:

Controlla se sono presenti pod bloccati nello stato Terminating:

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

Descrivi il MachineReturnRequest per ottenere informazioni dettagliate sulla procedura di reso:
```
kubectl describe mrr MRR_NAME -n gcp-symphony
```
Sostituisci MRR_NAME con il nome del tuo MachineReturnRequest.
Elimina manualmente l'oggetto risorsa personalizzato. Questa eliminazione attiva la logica di pulizia finale:
```
kubectl delete gcpsymphonyresource RESOURCE_NAME
```
Sostituisci RESOURCE_NAME con il nome della risorsa GCPSymphonyResource.

Numero elevato di macchine non riuscite in un `MachineReturnRequest`

Questo problema si verifica quando il conteggio failedMachines nello stato MachineReturnRequest è maggiore di 0. Questo problema può verificarsi per i seguenti motivi:

Timeout eliminazione pod.
Un nodo non è disponibile.

Per risolvere il problema:

Controlla machineEvents nello stato MachineReturnRequest per messaggi di errore specifici:
```
kubectl describe mrr MRR_NAME -n gcp-symphony
```
Cerca eventi di errore dei nodi o problemi di prestazioni del control plane:
1. Visualizza lo stato di tutti i nodi:
```
kubectl get nodes -o wide
```
2. Controllare un nodo specifico:
```
kubectl describe node NODE_NAME
```

I pod non vengono eliminati

Questo problema si verifica quando i pod eliminati sono bloccati nello stato Terminating o Error.

Questo problema può verificarsi per i seguenti motivi:

Un control plane o un operatore sovraccarico, che può causare timeout o eventi di limitazione API.
L'eliminazione manuale della risorsa padre GCPSymphonyResource.

Per risolvere il problema:

Controlla se la risorsa padre GCPSymphonyResource è ancora disponibile e non si trova nello stato WaitingCleanup:
```
kubectl describe gcpsymphonyresource RESOURCE_NAME
```
Se la risorsa GCPSymphonyResource padre non è più presente nel sistema, rimuovi manualmente il finalizzatore dal pod o dai pod. Il finalizer indica a Kubernetes di attendere che l'operatore Symphony completi le attività di pulizia prima che Kubernetes elimini completamente il pod. Innanzitutto, esamina la configurazione YAML per trovare il finalizzatore:
```
kubectl get pods -n gcp-symphony -l symphony.requestId=REQUEST_ID -o yaml
```
Sostituisci REQUEST_ID con l'ID richiesta associato ai pod.
Nell'output, cerca il campo finalizzatori nella sezione dei metadati. Dovresti visualizzare un output simile a questo snippet:
```
metadata:
...
finalizers:
-   symphony-operator/finalizer
```

Per rimuovere manualmente il finalizer dal pod o dai pod, utilizza il comando 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"}]'

Sostituisci REQUEST_ID con l'ID richiesta associato ai pod.

Le vecchie risorse Symphony non vengono eliminate automaticamente dal cluster GKE

Al termine di un workload e all'arresto dei relativi pod da parte di GKE, gli oggetti GCPSymphonyResource e MachineReturnRequest associati rimangono nel cluster GKE per un periodo di tempo superiore al periodo di pulizia previsto di 24 ore.

Questo problema si verifica quando un oggetto GCPSymphonyResource non dispone della condizione Completed status richiesta. La procedura di pulizia automatica dell'operatore dipende da questo stato per rimuovere l'oggetto. Per risolvere il problema, completa i seguenti passaggi:

Esamina i dettagli della risorsa GCPSymphonyResource in questione:
```
kubectl get gcpsr GCPSR_NAME -o yaml
```
Sostituisci GCPSR_NAME con il nome della risorsa GCPSymphonyResource con questo problema.

Esamina le condizioni per uno dei tipi Completed con stato 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"

Se questa condizione non è visibile nei dettagli di GCPSymphonyResource, ma viene visualizzato phase: WaitingCleanup, l'evento Completed è andato perso.

Controlla la presenza di pod associati a GCPSymphonyResource:
```
kubectl get pods -l symphony.requestId=REQUEST_ID
```
Sostituisci REQUEST_ID con l'ID richiesta.
Se non esistono pod, elimina in sicurezza la risorsa GCPSymphonyResource:
```
kubectl delete gcpsr GCPSR_NAME
```
Sostituisci GCPSR_NAME con il nome del tuo GCPSymphonyResource.
Se i pod esistevano prima dell'eliminazione di GCPSymphonyResource, devi eliminarli. Se i pod esistono ancora, segui i passaggi descritti nella sezione I pod non vengono eliminati.

Il pod non si unisce al cluster Symphony

Questo problema si verifica quando un pod viene eseguito in GKE, ma non viene visualizzato come host valido nel cluster Symphony.

Questo problema si verifica se il software Symphony in esecuzione all'interno del pod non riesce a connettersi e registrarsi con l'host principale di Symphony. Questo problema è spesso dovuto a problemi di connettività di rete o a una configurazione errata del client Symphony all'interno del container.

Per risolvere il problema, controlla i log dei servizi Symphony in esecuzione all'interno del pod.

Utilizza SSH o exec per accedere al pod e visualizzare i log:
```
kubectl exec -it POD_NAME -- /bin/bash
```
Sostituisci POD_NAME con il nome del pod.
Quando hai un pod all'interno del pod, i log dei daemon EGO e LIM si trovano nella directory $EGO_TOP/kernel/log. La variabile di ambiente $EGO_TOP punta alla radice dell'installazione di IBM Spectrum Symphony:
```
cd $EGO_TOP/kernel/log
```
Per ulteriori informazioni sul valore della variabile di ambiente $EGO_TOP, consulta Problemi con il servizio di fabbrica host di Symphony.
Esamina i log per individuare errori di configurazione o di rete che bloccano la connessione dal pod GKE al pod primario Symphony on-premise.

Richiesta di reso della macchina non riuscita

Questo problema potrebbe verificarsi durante le operazioni di riduzione della scalabilità quando crei una risorsa personalizzata MachineReturnRequest, ma l'oggetto si blocca e l'operatore non termina il pod Symphony corrispondente.

Un errore nella logica del finalizer dell'operatore impedisce l'eliminazione pulita del pod e della relativa risorsa personalizzata. Questo problema può portare a risorse orfane e costi inutili.

Per risolvere il problema, elimina manualmente la risorsa personalizzata, che dovrebbe attivare la logica di pulizia dell'operatore:

kubectl delete gcpsymphonyresource RESOURCE_NAME

Sostituisci RESOURCE_NAME con il nome della risorsa.

Risolvere i problemi relativi ai connettori IBM Spectrum Symphony Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Problemi relativi al servizio di fabbrica dell'host Symphony

Il cluster non aggiunge nuove VM per i workload in attesa

Il servizio di fabbrica dell'host non si avvia

Altri errori e logging

Problemi relativi al fornitore di fabbrica dell'host

La macchina virtuale o il pod non è stato sottoposto a provisioning

Il pod rimane bloccato nello stato Pending o Error su GKE

Risoluzione dei problemi relativi all'operatore Kubernetes

Diagnosticare i problemi relativi ai campi di stato delle risorse

Risorsa GCPSymphonyResource bloccata nello stato Pending

I pod non vengono restituiti

Numero elevato di macchine non riuscite in un MachineReturnRequest

I pod non vengono eliminati

Le vecchie risorse Symphony non vengono eliminate automaticamente dal cluster GKE

Il pod non si unisce al cluster Symphony

Richiesta di reso della macchina non riuscita

Risolvere i problemi relativi ai connettori IBM Spectrum Symphony

Il pod rimane bloccato nello stato `Pending` o `Error` su GKE

Risorsa `GCPSymphonyResource` bloccata nello stato `Pending`

Numero elevato di macchine non riuscite in un `MachineReturnRequest`