Soluciona problemas de los conectores de IBM Spectrum Symphony

Este documento te ayuda a resolver problemas comunes con la integración de IBM Spectrum Symphony para Google Cloud. Específicamente, este documento proporciona orientación para solucionar problemas del servicio de fábrica de hosts de IBM Spectrum Symphony, los conectores para los proveedores de Compute Engine y GKE y el operador de Symphony para Kubernetes.

Problemas con el servicio de fábrica del host de Symphony

Estos problemas se relacionan con el servicio central de fábrica de hosts de Symphony. Puedes encontrar el archivo de registro principal de este servicio en la siguiente ubicación en Linux:

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

Estableces la variable de entorno $EGO_TOP cuando cargas las variables de entorno de la fábrica de host. En IBM Spectrum Symphony, $EGO_TOP apunta a la raíz de instalación del Enterprise Grid Orchestrator (EGO), que es el administrador de recursos principal del clúster. La ruta de instalación predeterminada para $EGO_TOP en Linux suele ser /opt/ibm/spectrumcomputing.

El clúster no agrega VMs nuevas para las cargas de trabajo pendientes

Este problema ocurre cuando la cola de Symphony contiene trabajos, pero la fábrica de hosts no puede aprovisionar máquinas virtuales (VM) nuevas para administrar la carga. El archivo de registro de la fábrica de host no contiene mensajes SCALE-OUT.

Este problema suele ocurrir cuando el solicitante de Symphony no está configurado o habilitado correctamente. Para resolver el problema, verifica el estado del solicitante configurado para comprobar que esté habilitado y que haya una carga de trabajo pendiente.

Ubica el archivo de configuración del solicitante. Por lo general, el archivo se encuentra en la siguiente ubicación:
```
$HF_TOP/conf/requestors/hostRequestors.json
```
La variable de entorno $HF_TOP se define en tu entorno cuando usas el comando source. El valor es la ruta de acceso al directorio de instalación de nivel superior para el servicio de fábrica de hosts de IBM Spectrum Symphony.
Abre el archivo hostRequestors.json y busca la entrada symAinst. En esa sección, verifica que el parámetro enabled esté establecido en un valor de 1 y que la lista de proveedores incluya el nombre de la instancia del proveedor Google Cloud que configuraste.
- En el caso de las configuraciones de Compute Engine, la lista de proveedores debe mostrar el nombre del proveedor de Compute Engine que creaste en Habilita la instancia del proveedor durante la instalación del proveedor de Compute Engine.
- En el caso de las configuraciones de GKE, la lista de proveedores debe mostrar el nombre del proveedor de GKE que creaste en Habilita la instancia del proveedor durante la instalación del proveedor de GKE.
Después de confirmar que el solicitante de symAinst está habilitado, verifica si un consumidor tiene una carga de trabajo pendiente que requiere una expansión.

Para ver una lista de todos los consumidores y el estado de sus cargas de trabajo, haz lo siguiente:
```
egosh consumer list
```
En el resultado, busca el consumidor asociado a tu carga de trabajo y verifica que esté pendiente. Si el solicitante está habilitado y hay una carga de trabajo pendiente, pero el servicio de HostFactory no inicia solicitudes de expansión, consulta los registros del servicio de HostFactory para ver si hay errores.

No se inicia el servicio de fábrica del host

Si el servicio de fábrica del host no se ejecuta, sigue estos pasos para resolver el problema:

Verifica el estado del servicio HostFactory:
```
egosh service list
```
En el resultado, busca el servicio HostFactory y verifica que el campo STATE muestre el estado STARTED.

Si el servicio HostFactory no se inició, reinícialo:

egosh service stop HostFactory
egosh service start HostFactory

Otros errores y registros

Si encuentras otros errores con el servicio de Host Factory, aumenta la verbosidad del registro para obtener registros más detallados. Para ello, completa los siguientes pasos:

Abre el archivo hostfactoryconf.json para editarlo. Por lo general, el archivo se encuentra en la siguiente ubicación:
```
$EGO_TOP/hostfactory/conf/
```
Para obtener más información sobre el valor de la variable de entorno $EGO_TOP, consulta Problemas con el servicio de fábrica de hosts de Symphony.

Actualiza el valor de HF_LOGLEVEL de LOG_INFO a LOG_DEBUG:

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

Guarda el archivo después de realizar el cambio.

Para que el cambio se aplique, reinicia el servicio de HostFactory:

egosh service stop HostFactory
egosh service start HostFactory

Después de reiniciar, el servicio HostFactory genera registros más detallados que puedes usar para solucionar problemas complejos. Puedes ver estos registros en el archivo de registro principal de la fábrica de hosts, que se encuentra en $EGO_TOP/hostfactory/log/hostfactory.hostname.log en Linux.

Problemas con el proveedor de fábrica del host

Los siguientes problemas ocurren en los scripts del proveedor de la fábrica de host para Compute Engine o Google Kubernetes Engine.

Revisa los registros del proveedor (hf-gce.log o hf-gke.log) para obtener mensajes de error detallados. La ubicación de los archivos hf-gce.log y hf-gke.log se determina con la variable LOGFILE establecida en el archivo de configuración del proveedor en Habilita la instancia del proveedor.

No se aprovisionó la máquina virtual o el pod

Este problema puede ocurrir después de que los registros del proveedor de la fábrica de host muestren una llamada a la secuencia de comandos requestMachines.sh, pero el recurso no aparece en tu proyecto de Google Cloud.

Para resolver el problema, sigue estos pasos:

Revisa los registros de la secuencia de comandos del proveedor (hf-gce.log o hf-gke.log) para ver si hay mensajes de error de la API de Google Cloud . La ubicación de los archivos hf-gce.log y hf-gke.log se determina según la variable LOGFILE establecida en el archivo de configuración del proveedor en Habilita la instancia del proveedor.
Verifica que la cuenta de servicio tenga los permisos de IAM correctos:
1. Sigue las instrucciones en Cómo ver el acceso actual.
2. Verifica que la cuenta de servicio tenga el rol de IAM de Administrador de instancias de Compute (v1) (roles/compute.instanceAdmin.v1) en el proyecto. Para obtener más información sobre cómo otorgar roles, consulta Administra el acceso a proyectos, carpetas y organizaciones.
Para asegurarte de que los parámetros de Compute Engine en tu plantilla de host sean válidos, debes verificar lo siguiente:
1. Los parámetros de la plantilla del host deben estar en el archivo gcpgceinstprov_templates.json que creaste cuando configuraste una instancia del proveedor durante la instalación del proveedor de Compute Engine. Los parámetros más comunes para validar son gcp_zone y gcp_instance_group.
2. Verifica que exista el grupo de instancias establecido por el parámetro gcp_instance_group. Para confirmar el grupo de instancias, sigue las instrucciones en Cómo ver las propiedades de un MIG con el nombre gcp_instance_group y los valores de zona gcp_zone del archivo de plantilla.

El Pod se atasca en el estado `Pending` o `Error` en GKE

Este problema puede ocurrir después de que el registro de hf-gke muestre que se creó el recurso GCPSymphonyResource, pero el Pod correspondiente en el clúster de GKE nunca alcanza el estado Running y puede mostrar un estado como Pending, ImagePullBackOff o CrashLoopBackOff.

Este problema se produce si hay un problema dentro del clúster de Kubernetes, como un nombre de imagen de contenedor no válido, recursos de CPU o memoria insuficientes, o un volumen o una configuración de red mal configurados.

Para resolver este problema, usa kubectl describe para inspeccionar los eventos del recurso personalizado y del pod, y así identificar la causa raíz:

kubectl describe gcpsymphonyresource RESOURCE_NAME
kubectl describe pod POD_NAME

Reemplaza lo siguiente:

RESOURCE_NAME: el nombre del recurso.
POD_NAME: Es el nombre del Pod.

Soluciona problemas del operador de Kubernetes

El operador de Kubernetes administra el ciclo de vida de un pod de Symphony. Las siguientes secciones pueden ayudarte a solucionar problemas habituales que puedes encontrar con el operador y estos recursos.

Diagnostica problemas con los campos de estado de los recursos

El operador de Kubernetes administra las cargas de trabajo de Symphony en GKE con dos tipos de recursos principales:

El recurso GCPSymphonyResource (GCPSR) administra el ciclo de vida de los pods de procesamiento para las cargas de trabajo de Symphony.
El recurso MachineReturnRequest (MRR) controla la devolución y la limpieza de los recursos de procesamiento.

Usa estos campos de estado para diagnosticar problemas con el recurso GCPSymphonyResource:

phase: Es la fase actual del ciclo de vida del recurso. Las opciones son Pending, Running, WaitingCleanup o Completed.
availableMachines: Es la cantidad de Pods de procesamiento que están listos.
conditions: Son las condiciones de estado detalladas con marcas de tiempo.
returnedMachines: Es una lista de los Pods devueltos.

Usa estos campos de estado para diagnosticar problemas con el recurso MachineReturnRequest:

phase: Es la fase actual de la solicitud de devolución. Las opciones son Pending, InProgress, Completed, Failed o PartiallyCompleted.
totalMachines: Es la cantidad total de máquinas que se devolverán.
returnedMachines: Es la cantidad de máquinas que se devolvieron correctamente.
failedMachines: Es la cantidad de máquinas que no se devolvieron.
machineEvents: Son los detalles del estado por máquina.

Recurso `GCPSymphonyResource` atascado en el estado `Pending`

Este problema ocurre cuando el recurso GCPSymphonyResource permanece en el estado Pending y el valor de availableMachines no aumenta.

Este problema puede ocurrir por uno de los siguientes motivos:

Capacidad de nodo insuficiente en tu clúster
Problemas para extraer la imagen del contenedor
Limitaciones de cuotas de recursos

Para solucionar este problema, sigue estos pasos:

Verifica el estado de los pods para identificar cualquier problema con las extracciones de imágenes o la asignación de recursos:
```
kubectl describe pods -n gcp-symphony -l symphony.requestId=REQUEST_ID
```
Reemplaza REQUEST_ID por el ID de tu solicitud.
Inspecciona los nodos para asegurarte de que tengan capacidad suficiente:
```
kubectl get nodes -o wide
```
Es posible que los Pods muestren un estado Pending. Este problema suele ocurrir cuando el clúster de Kubernetes necesita aumentar su escala y tarda más de lo esperado. Supervisa los nodos para asegurarte de que el plano de control pueda realizar un escalamiento horizontal.

No se devuelven los Pods

Este problema ocurre cuando creas un MachineReturnRequest (MRR), pero la cantidad de returnedMachines no aumenta.

Este problema puede ocurrir por los siguientes motivos:

Los Pods están atascados en el estado Terminating.
Hay problemas de conectividad de nodos.

Para solucionar este problema, sigue estos pasos:

Verifica si hay Pods atascados en el estado Terminating:

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

Describe el MachineReturnRequest para obtener detalles sobre el proceso de devolución:
```
kubectl describe mrr MRR_NAME -n gcp-symphony
```
Reemplaza MRR_NAME por el nombre del MachineReturnRequest.
Borra manualmente el objeto del recurso personalizado. Esta eliminación activa la lógica de limpieza final:
```
kubectl delete gcpsymphonyresource RESOURCE_NAME
```
Reemplaza RESOURCE_NAME por el nombre del recurso GCPSymphonyResource.

Gran cantidad de máquinas con errores en un `MachineReturnRequest`

Este problema ocurre cuando el recuento de failedMachines en el estado MachineReturnRequest es mayor que 0. Este problema puede ocurrir por los siguientes motivos:

Se agotó el tiempo de espera para borrar el Pod.
Un nodo no está disponible.

Para solucionar este problema, sigue estos pasos:

Verifica el machineEvents en el estado MachineReturnRequest para ver mensajes de error específicos:
```
kubectl describe mrr MRR_NAME -n gcp-symphony
```
Busca eventos de falla de nodos o problemas de rendimiento del plano de control:
1. Obtén el estado de todos los nodos:
```
kubectl get nodes -o wide
```
2. Para inspeccionar un nodo específico, haz lo siguiente:
```
kubectl describe node NODE_NAME
```

No se borran los Pods

Este problema se produce cuando los Pods borrados se quedan en estado Terminating o Error.

Este problema puede ocurrir por los siguientes motivos:

Un plano de control o un operador sobrecargado, lo que puede provocar tiempos de espera agotados o eventos de limitación de la API
Es el borrado manual del recurso principal GCPSymphonyResource.

Para solucionar este problema, sigue estos pasos:

Verifica si el recurso principal GCPSymphonyResource sigue disponible y no está en el estado WaitingCleanup:
```
kubectl describe gcpsymphonyresource RESOURCE_NAME
```
Si el recurso principal GCPSymphonyResource ya no está en el sistema, quita manualmente el finalizador del pod o los pods. El finalizador le indica a Kubernetes que espere a que el operador de Symphony complete sus tareas de limpieza antes de que Kubernetes borre por completo el pod. Primero, inspecciona la configuración de YAML para encontrar el finalizador:
```
kubectl get pods -n gcp-symphony -l symphony.requestId=REQUEST_ID -o yaml
```
Reemplaza REQUEST_ID por el ID de la solicitud asociado a los Pods.
En el resultado, busca el campo finalizers dentro de la sección metadata. Deberías ver un resultado similar a este fragmento:
```
metadata:
...
finalizers:
-   symphony-operator/finalizer
```

Para quitar manualmente el finalizador del Pod o los Pods, usa el 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"}]'

Reemplaza REQUEST_ID por el ID de la solicitud asociado a los Pods.

Los recursos antiguos de Symphony no se borran automáticamente del clúster de GKE

Después de que se completa una carga de trabajo y GKE detiene sus pods, los objetos GCPSymphonyResource y MachineReturnRequest asociados permanecen en tu clúster de GKE durante más tiempo que el período de limpieza esperado de 24 horas.

Este problema ocurre cuando un objeto GCPSymphonyResource no tiene la condición Completed status obligatoria. El proceso de limpieza automático del operador depende de este estado para quitar el objeto. Para resolver este problema, realiza los siguientes pasos:

Revisa los detalles del recurso GCPSymphonyResource en cuestión:
```
kubectl get gcpsr GCPSR_NAME -o yaml
```
Reemplaza GCPSR_NAME por el nombre del recurso GCPSymphonyResource que tiene este problema.

Revisa las condiciones de un tipo Completed con un estado de 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 esta condición no se ve en los detalles de GCPSymphonyResource, pero se muestra phase: WaitingCleanup, se perdió el evento Completed.

Verifica si hay Pods asociados con GCPSymphonyResource:
```
kubectl get pods -l symphony.requestId=REQUEST_ID
```
Reemplaza REQUEST_ID por el ID de la solicitud.
Si no existen Pods, borra de forma segura el recurso GCPSymphonyResource:
```
kubectl delete gcpsr GCPSR_NAME
```
Reemplaza GCPSR_NAME por el nombre del GCPSymphonyResource.
Si los Pods existían antes de que borraras el GCPSymphonyResource, debes borrarlos. Si los Pods aún existen, sigue los pasos de la sección No se borran los Pods.

El Pod no se une al clúster de Symphony

Este problema se produce cuando un pod se ejecuta en GKE, pero no aparece como un host válido en el clúster de Symphony.

Este problema se produce si el software de Symphony que se ejecuta dentro del pod no puede conectarse ni registrarse con el host principal de Symphony. Este problema suele deberse a inconvenientes de conectividad de red o a una configuración incorrecta del cliente de Symphony dentro del contenedor.

Para resolver este problema, revisa los registros de los servicios de Symphony que se ejecutan dentro del pod.

Usa SSH o exec para acceder al Pod y ver los registros:
```
kubectl exec -it POD_NAME -- /bin/bash
```
Reemplaza POD_NAME por el nombre del pod.
Cuando tienes un sh dentro del pod, los registros de los daemons de EGO y LIM se encuentran en el directorio $EGO_TOP/kernel/log. La variable de entorno $EGO_TOP apunta a la raíz de la instalación de IBM Spectrum Symphony:
```
cd $EGO_TOP/kernel/log
```
Para obtener más información sobre el valor de la variable de entorno $EGO_TOP, consulta Problemas con el servicio de fábrica de host de Symphony.
Examina los registros en busca de errores de configuración o de red que bloqueen la conexión del pod de GKE al pod principal de Symphony local.

Falla la solicitud de devolución de la máquina

Este problema puede ocurrir durante las operaciones de reducción cuando creas un recurso personalizado MachineReturnRequest, pero el objeto se bloquea y el operador no finaliza el pod de Symphony correspondiente.

Una falla en la lógica del finalizador del operador impide el borrado limpio del pod y su recurso personalizado asociado. Este problema puede generar recursos huérfanos y costos innecesarios.

Para resolver este problema, borra manualmente el recurso personalizado, lo que debería activar la lógica de limpieza del operador:

kubectl delete gcpsymphonyresource RESOURCE_NAME

Reemplaza RESOURCE_NAME por el nombre del recurso.

Soluciona problemas de los conectores de IBM Spectrum Symphony Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.

Problemas con el servicio de fábrica del host de Symphony

El clúster no agrega VMs nuevas para las cargas de trabajo pendientes

No se inicia el servicio de fábrica del host

Otros errores y registros

Problemas con el proveedor de fábrica del host

No se aprovisionó la máquina virtual o el pod

El Pod se atasca en el estado Pending o Error en GKE

Soluciona problemas del operador de Kubernetes

Diagnostica problemas con los campos de estado de los recursos

Recurso GCPSymphonyResource atascado en el estado Pending

No se devuelven los Pods

Gran cantidad de máquinas con errores en un MachineReturnRequest

No se borran los Pods

Los recursos antiguos de Symphony no se borran automáticamente del clúster de GKE

El Pod no se une al clúster de Symphony

Falla la solicitud de devolución de la máquina

Soluciona problemas de los conectores de IBM Spectrum Symphony

El Pod se atasca en el estado `Pending` o `Error` en GKE

Recurso `GCPSymphonyResource` atascado en el estado `Pending`

Gran cantidad de máquinas con errores en un `MachineReturnRequest`