Resolución de problemas y limitaciones conocidas en el servicio Content-Aware Storage (CAS )

Los pasos habituales para solucionar problemas y las limitaciones del servicio CAS.

El control de acceso a las consultas CAS no es compatible con IBM Fusion 2.10.1

Planteamiento del problema
Las versiones 2.10.1 y anteriores IBM Fusion no admiten la función CAS ACL que se introdujo en CAS v1.0.4.
Causa

El punto final /api/v1/querysearch sigue utilizando el método de autenticación nativo de IBM Fusion en lugar de CAS ACL.

Resolución

Para omitir temporalmente la autenticación de IBM Fusion para el punto final /querysearch , realice los siguientes pasos:

  1. En el espacio de nombres fusion , abra el terminal para el pod isf-proxy-XXXX :
    cd /etc/nginx
    vi nginx.conf
  2. Localice el bloque /querysearch y elimine la siguiente línea:
    auth_request /auth;

    El código actualizado debe tener el siguiente aspecto:

    location /api/v1/querysearch {
      set $upstreamem 'https://query-search.ibm-cas.svc.cluster.local:8000';
      proxy_pass $upstreamem$request_uri;
    }
  3. Guarde y salga del editor:
    wq!
  4. Recargar NGINX:
    nginx -s reload
  5. Repita la operación con la segunda vaina isf-proxy .
    Nota: Esta solución es necesaria después de cada actualización del pod isf-proxy .

Error en query_service configmap and deployment

Planteamiento del problema
Cuando se actualiza CAS de v1.0.3 a v1.0.4, debe añadirse un ConfigMap y algunas configuraciones de implantación para evitar errores en el procesamiento de listas de control de acceso (ACL).
Causa
La API del servicio de consulta no funciona cuando se proporciona un token de proveedor de identidades (IDP) externo.
Resolución
  1. Cree lo siguiente ConfigMap:
    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: query-search-config
      namespace: ibm-cas
    data:
      use_self_cert: 'false'
  2. Actualizar el despliegue de búsqueda de consultas:
    1. Establezca el atributo readOnlyRootFilesystem en "true".
    2. En la sección env del despliegue del servicio de consulta, añada la siguiente entrada:
      - name: ENABLE_FILE_LEVEL_SECURITY
        value: false
    3. En la sección volumes , añada la siguiente sección:
      - name: query-search-config
        configMap:
          name: query-search-config
          defaultMode: 420
      - name: ibm-cas-cabundle
        configMap:
          name: openshift-service-ca.crt
          items:
          - key: service-ca.crt
            path: service-ca.crt
    4. En la sección volumeMounts , añada la siguiente sección:
      - name: "query-search-config"
        readOnly: true
        mountPath: "/etc/config/cm/"
      - name: ibm-cas-cabundle
        readOnly: true
        mountPath: /etc/config/cabundle

El pod nv-ingest está en imagepullback error

Planteamiento del problema
El pod nv-ingest se encuentra en estado de error imagepullback debido a demasiadas peticiones de docker.io.
Causa y resolución
  1. Causa :

    Demasiadas solicitudes para docker.io.

    Resolución : Autentificarse en docker.io.

  2. Causa :

    El pod nv-ingest no es capaz de extraer la imagen correctamente.

    Resolución : Consulte NVIDIA para solucionar el problema.

Falla la ingesta de CAS

Planteamiento del problema
La ingesta de CAS falla con el siguiente error en los registros de los pods cast-runtime :

2025-03-26 22:46:36,725 - ERROR - Error durante la obtención, reintentando... 
Error: HTTPSConnectionPool(host='nv-ingest. nv-ingest.svc.cluster.local ', port=7670 ): 
Max retries exceeded with url: /v1/fetch_job/ (Causado por SSLError(SSLError(1, '[SSL] record layer failure ( _ssl.c:1006 )')))
Causa
Implica que el servicio https NVIDIA NIM no está disponible.
Resolución
  1. Vaya a cast-runtime deployment.
  2. En el parámetro value , cambie https por http:
    - name: NVMM_NIM_SERVICE
    value: https://nv-ingest.nv-ingest.svc.cluster.local
    por:
    - name: NVMM_NIM_SERVICE
    value: http://nv-ingest.nv-ingest.svc.cluster.local
    

Error en semantic_search

Planteamiento del problema
En el pod de búsqueda de consultas, se pueden producir los siguientes errores durante una semantic_search:

ERROR: querysearch/semantic_search failed Error de conexión.
Traceback (última llamada más reciente):
File " /opt/app-root/lib64/python3.11/site-packages/httpx/_transports/default.py", line 101, in map_httpcore_exceptions
rendimiento
File " /opt/app-root/lib64/python3.11/site-packages/httpx/_transports/default.py", line 250, in handle_request
resp = self._pool.handle_request (req)
File " /opt/app-root/lib64/python3.11/site-packages/httpcore/_backends/sync.py", line 154, in start_tls
con map_exceptions(exc_map):
File " /usr/lib64/python3.11/contextlib.py ", line 158, in __exit__
self.gen.throw (tipo, valor, seguimiento)
File " /opt/app-root/lib64/python3.11/site-packages/httpcore/_exceptions.py", line 14, in map_exceptions
raise to_exc(exc) from exc
Causa
Implica que la versión TLS del NVIDIA no está disponible.
Resolución
  1. Reducción del despliegue de búsqueda de consultas.
  2. En el despliegue de búsqueda de consultas, cambie el valor de la variable:
    - name: NVMM_EMBED_SERVICE
    value: 'https://nv-ingest-embedqa.nv-ingest.svc.cluster.local'
    por:
    - name: NVMM_EMBED_SERVICE
    value: 'http://nv-ingest-embedqa.nv-ingest.svc.cluster.local'
  3. Si el servicio NVMM Nemo Ranking está habilitado en cas Install CR entonces por favor cambie el valor de abajo en el despliegue de búsqueda de consultas. Cambia el valor de la variable:
    - name: NVMM_NEMO_RANKER_SERVICE
    value: 'https://nemo-ranker-text-reranking-nim.nv-ingest.svc.cluster.local'

    por:

    - name: NVMM_NEMO_RANKER_SERVICE
    value: 'http://nemo-ranker-text-reranking-nim.nv-ingest.svc.cluster.local'
    
  4. Vuelve a escalar el despliegue a su número original.

Fuente de datos bloqueada en estado de error "Conectando

Planteamiento del problema
La fuente de datos creada puede quedar bloqueada en un estado de "conexión" por diferentes motivos. Para realizar un diagnóstico adecuado, compruebe los registros del operador CAS para encontrar el mensaje de error.
Causa y resolución
Las posibles causas de este error son las siguientes:
  1. Causa:

    El usuario Scale CSI no tiene suficientes privilegios para la creación de Watchers.

    ERROR DEVUELTO POR sConn.CreateWatch4Fileset =========>
            =====> [ EFSSG0012C Permiso denegado: Tu(s) rol(es): [csiadmin, containeroperator], obligatorio
            rol(es): [admin, storageadmin, securityadmin]] No se puede activar la vigilancia en clúster para la fuente
            castFS:root​

    Resolución:

    Añada el usuario CSI de Scale al grupo Administrador de almacenamiento en Scale como se especifica Configurar usuario de Scale para permitir la creación de vigilancias.

  2. Causa:

    Kafka falta la autenticación ConfigMap.

    2025-03-28T18:21:10Z ERROR Error de reconciliación {"controller": "datasource", "controllerGroup": " cas.isf.ibm.com ", "controllerKind": "DataSource", "DataSource": {"name":"mc-test","namespace":"ibm-cas"}, "namespace": "ibm-cas", "name": "mc-test", "reconcileID": " 9aeda80b-4706-408a-9c05-ffcb39cb877e ", "error": "panic: odd number of arguments passed as key-value pairs for logging [recovered]"}

    Resolución:

    Cree el ConfigMap para la autenticación Kafka como se explica en Configurar manualmente para conectarse a Kafka broker.

  3. Causa:

    Se deniega el acceso a los FV estáticos creados por la fuente de datos. Si se detecta un problema funcional en relación con la accesibilidad estática de los FV, podría estar relacionado con un error de acceso denegado. Para validarlo, acceda a la ruta de montaje utilizando la vaina generada por DocumentProcessor. Tenga en cuenta que el pod tiene el mismo nombre que DocumentProcessor.

    (app-root) sh-5.1$ cd /gpfs/gpfs3/fileset_sample​
    bash: cd: /app-root: Permiso denegado

    Resolución:

    Añada un GID conocido al Fileset en Scale y añada una anotación al Datasource en CAS como se describe en el paso 8.

Limitaciones conocidas

  • Cada dominio debe utilizar una única ubicación de fuente de datos, es decir, una única ruta de Escala o una única ubicación S3. Actualmente, CAS no permite compartir la misma ubicación de fuente de datos entre varios dominios.
  • La compatibilidad con CAS en Azure Red Hat OpenShift ( ARO ) tiene requisitos de licencia adicionales respecto a Red Hat debido a la necesidad de cambiar el número máximo de hilos para los pods. Para más información, consulte la base de conocimientos Red Hat.