No coinciden los datos de las entidades de la interfaz de usuario híbrida ni las usan las API de administración.

Estás consultando la documentación de Apigee y Apigee Hybrid.
Consulta la documentación de Apigee Edge.

Síntoma

Los usuarios observan datos incoherentes o ningún dato de entidades como productos de API, aplicaciones, desarrolladores, mapas de valores clave (KVM) y caché de forma intermitente en la interfaz de usuario (IU) híbrida de Apigee y a través de la API Management.

Mensajes de error

No se muestra ningún mensaje de error en este caso.

Posibles motivos

Causa Descripción
Los pods de Cassandra no están conectados al anillo Es posible que los pods de Cassandra de todos los centros de datos no estén conectados al anillo de Cassandra común.
No se ha ejecutado la reparación de nodetool Es posible que el comando nodetool repair no se haya ejecutado periódicamente.
Problemas de conectividad de red Puede que haya problemas de conectividad de red entre los pods de Cassandra de diferentes centros de datos.

Pasos de diagnóstico habituales

  1. Obtén información sobre una o varias entidades en las que se produce este problema (por ejemplo, productos de API o aplicaciones) mediante la API Management y comprueba si obtienes resultados diferentes al invocarla varias veces.

    En la línea de comandos, usa los siguientes ejemplos para obtener tus credenciales de autenticación gcloud , definir variables de entorno y ejecutar comandos de la API:

    Obtener productos de API:

    TOKEN=$(gcloud auth print-access-token)
ORG=ORGANIZATION_NAME

curl -i -H "Authorization: Bearer $TOKEN" \
"https://apigee.googleapis.com/v1/organizations/$ORG/apiproducts"

    Descargar aplicaciones:

    TOKEN=$(gcloud auth print-access-token)
ORG=ORGANIZATION_NAME

curl -i -H "Authorization: Bearer $TOKEN" \
"https://apigee.googleapis.com/v1/organizations/$ORG/apps"

    Obtener desarrolladores:

    TOKEN=$(gcloud auth print-access-token)
ORG=ORGANIZATION_NAME

curl -i -H "Authorization: Bearer $TOKEN" \
"https://apigee.googleapis.com/v1/organizations/$ORG/developers"

    Obtener mapas de valores de clave (KVMs):

    TOKEN=$(gcloud auth print-access-token)
ORG=ORGANIZATION_NAME

curl -i -H "Authorization: Bearer $TOKEN" \
"https://apigee.googleapis.com/v1/organizations/$ORG/keyvaluemaps"

    Get Caches:

    TOKEN=$(gcloud auth print-access-token)
ORG=ORGANIZATION_NAME
ENV=ENVIRONMENT_NAME

curl -i -H "Authorization: Bearer $TOKEN" \
"https://apigee.googleapis.com/v1/organizations/$ORG/environments/$ENV/caches"
  2. Si no ve datos o ve datos diferentes al ejecutar las solicitudes de la API Management anteriores, significa que está experimentando el mismo problema que en la interfaz de usuario.

Causa: los pods de Cassandra no están conectados a los pods de Cassandra de todos los centros de datos

En una implementación híbrida de Apigee multirregional, si no todos los pods de Cassandra están conectados al mismo anillo de Cassandra, es posible que no todos los pods de Cassandra repliquen los datos. Por lo tanto, el plano de gestión no recibirá el mismo conjunto de datos para la misma consulta de forma coherente. Para analizar esta situación, sigue estos pasos:

Diagnóstico

  1. Lista de pods de Cassandra:
    2. # list cassandra pods
kubectl -n apigee get pods -l app=apigee-cassandra
  2. Ejecuta el siguiente comando para comprobar el estado de todos los pods de Cassandra en cada centro de datos.

    En la versión de Apigee Hybrid anterior a la 1.4.0:

    # check cassandra cluster status
kubectl -n apigee get pods \
-l app=apigee-cassandra \
--field-selector=status.phase=Running \
-o custom-columns=name:metadata.name --no-headers \
| xargs -I{} sh -c "echo {}; kubectl -n apigee exec {} -- nodetool status"

    En las versiones de Apigee Hybrid iguales o posteriores a la 1.4.0:

    # check cassandra cluster status
kubectl -n apigee get pods \
-l app=apigee-cassandra \
--field-selector=status.phase=Running \
-o custom-columns=name:metadata.name --no-headers \
| xargs -I{} sh -c "echo {}; kubectl -n apigee exec {} -- nodetool -u jmxuser -pw JMXUSER_PASSWORD status"
  3. Comprueba el resultado del comando anterior y verifica si todos los pods de Cassandra de todos los centros de datos están conectados al anillo de Cassandra y tienen el estado Activo y normal (UN).

    Ejemplo de salida de un anillo de Cassandra correcto:

    kubectl -n apigee get pods \
-l app=apigee-cassandra \
--field-selector=status.phase=Running \
-o custom-columns=name:metadata.name --no-headers \
| xargs -I{} sh -c "echo {}; kubectl -n apigee exec {} -- nodetool -u jmxuser -pw iloveapis123 status"

apigee-cassandra-default-0
Datacenter: dc-1
================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address    Load       Tokens       Owns (effective)  Host ID                               Rack
UN  10.0.2.18  1.32 MiB   256          100.0%            2e6051fe-e3ed-4858-aed0-ac9be5270e97  ra-1
UN  10.0.4.10  1.49 MiB   256          100.0%            2396e17f-94fd-4d7d-b55e-35f491a5c1cc  ra-1
UN  10.0.3.14  1.38 MiB   256          100.0%            579cf76e-7d6d-46c8-8319-b7cd74ee87c8  ra-1
Datacenter: dc-2
================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address    Load       Tokens       Owns (effective)  Host ID                               Rack
UN  10.8.1.12  1.31 MiB   256          100.0%            3e9f24bf-2c10-4cfd-8217-5be6245c2b9c  ra-1
UN  10.8.2.19  1.24 MiB   256          100.0%            1d2e803d-aa31-487b-9503-1e18297efc04  ra-1
UN  10.8.4.4   1.28 MiB   256          100.0%            d15ffeef-7929-42c2-a3b1-a3feb85a857b  ra-1

apigee-cassandra-default-1
Datacenter: dc-1
================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address    Load       Tokens       Owns (effective)  Host ID                               Rack
UN  10.0.2.18  1.32 MiB   256          100.0%            2e6051fe-e3ed-4858-aed0-ac9be5270e97  ra-1
UN  10.0.4.10  1.49 MiB   256          100.0%            2396e17f-94fd-4d7d-b55e-35f491a5c1cc  ra-1
UN  10.0.3.14  1.38 MiB   256          100.0%            579cf76e-7d6d-46c8-8319-b7cd74ee87c8  ra-1
Datacenter: dc-2
================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address    Load       Tokens       Owns (effective)  Host ID                               Rack
UN  10.8.1.12  1.31 MiB   256          100.0%            3e9f24bf-2c10-4cfd-8217-5be6245c2b9c  ra-1
UN  10.8.2.19  1.24 MiB   256          100.0%            1d2e803d-aa31-487b-9503-1e18297efc04  ra-1
UN  10.8.4.4   1.28 MiB   256          100.0%            d15ffeef-7929-42c2-a3b1-a3feb85a857b  ra-1

apigee-cassandra-default-2
Datacenter: dc-1
================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address    Load       Tokens       Owns (effective)  Host ID                               Rack
UN  10.0.2.18  1.32 MiB   256          100.0%            2e6051fe-e3ed-4858-aed0-ac9be5270e97  ra-1
UN  10.0.4.10  1.49 MiB   256          100.0%            2396e17f-94fd-4d7d-b55e-35f491a5c1cc  ra-1
UN  10.0.3.14  1.38 MiB   256          100.0%            579cf76e-7d6d-46c8-8319-b7cd74ee87c8  ra-1
Datacenter: dc-2
================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address    Load       Tokens       Owns (effective)  Host ID                               Rack
UN  10.8.1.12  1.31 MiB   256          100.0%            3e9f24bf-2c10-4cfd-8217-5be6245c2b9c  ra-1
UN  10.8.2.19  1.24 MiB   256          100.0%            1d2e803d-aa31-487b-9503-1e18297efc04  ra-1
UN  10.8.4.4   1.28 MiB   256          100.0%            d15ffeef-7929-42c2-a3b1-a3feb85a857b  ra-1

    Ejemplo de salida de un anillo de Cassandra en mal estado:

    kubectl -n apigee get pods \
-l app=apigee-cassandra \
--field-selector=status.phase=Running \
-o custom-columns=name:metadata.name --no-headers \
| xargs -I{} sh -c "echo {}; kubectl -n apigee exec {} -- nodetool -u jmxuser -pw iloveapis123 status"

apigee-cassandra-default-0
Datacenter: dc-1
================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address    Load       Tokens       Owns (effective)  Host ID                               Rack
UN  10.0.2.18  1.32 MiB   256          100.0%            2e6051fe-e3ed-4858-aed0-ac9be5270e97  ra-1
DL  10.0.4.10  1.49 MiB   256          100.0%            2396e17f-94fd-4d7d-b55e-35f491a5c1cc  ra-1
DL  10.0.3.14  1.38 MiB   256          100.0%            579cf76e-7d6d-46c8-8319-b7cd74ee87c8  ra-1
Datacenter: dc-2
================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address    Load       Tokens       Owns (effective)  Host ID                               Rack
UN  10.8.1.12  1.31 MiB   256          100.0%            3e9f24bf-2c10-4cfd-8217-5be6245c2b9c  ra-1
UN  10.8.2.19  1.24 MiB   256          100.0%            1d2e803d-aa31-487b-9503-1e18297efc04  ra-1
DL  10.8.4.4   1.28 MiB   256          100.0%            d15ffeef-7929-42c2-a3b1-a3feb85a857b  ra-1

apigee-cassandra-default-1
Datacenter: dc-1
================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address    Load       Tokens       Owns (effective)  Host ID                               Rack
UN  10.0.2.18  1.32 MiB   256          100.0%            2e6051fe-e3ed-4858-aed0-ac9be5270e97  ra-1
UN  10.0.4.10  1.49 MiB   256          100.0%            2396e17f-94fd-4d7d-b55e-35f491a5c1cc  ra-1
UN  10.0.3.14  1.38 MiB   256          100.0%            579cf76e-7d6d-46c8-8319-b7cd74ee87c8  ra-1
Datacenter: dc-2
================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address    Load       Tokens       Owns (effective)  Host ID                               Rack
UN  10.8.1.12  1.31 MiB   256          100.0%            3e9f24bf-2c10-4cfd-8217-5be6245c2b9c  ra-1
UN  10.8.2.19  1.24 MiB   256          100.0%            1d2e803d-aa31-487b-9503-1e18297efc04  ra-1
UN  10.8.4.4   1.28 MiB   256          100.0%            d15ffeef-7929-42c2-a3b1-a3feb85a857b  ra-1

apigee-cassandra-default-2
Datacenter: dc-1
================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address    Load       Tokens       Owns (effective)  Host ID                               Rack
UN  10.0.2.18  1.32 MiB   256          100.0%            2e6051fe-e3ed-4858-aed0-ac9be5270e97  ra-1
UN  10.0.4.10  1.49 MiB   256          100.0%            2396e17f-94fd-4d7d-b55e-35f491a5c1cc  ra-1
UN  10.0.3.14  1.38 MiB   256          100.0%            579cf76e-7d6d-46c8-8319-b7cd74ee87c8  ra-1
Datacenter: dc-2
================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address    Load       Tokens       Owns (effective)  Host ID                               Rack
UN  10.8.1.12  1.31 MiB   256          100.0%            3e9f24bf-2c10-4cfd-8217-5be6245c2b9c  ra-1
UN  10.8.2.19  1.24 MiB   256          100.0%            1d2e803d-aa31-487b-9503-1e18297efc04  ra-1
UN  10.8.4.4   1.28 MiB   256          100.0%            d15ffeef-7929-42c2-a3b1-a3feb85a857b  ra-1

    Ten en cuenta que algunos de los pods de Cassandra del resultado anterior tienen el estado DL (Down and Leaving) (Inactivo y saliendo). Para obtener más información, consulta nodetool status.

    • Si observas algún pod de Cassandra con el estado DL (como se muestra en el ejemplo de salida anterior), será la causa de este problema.
    • Cuando se hace una solicitud para obtener información sobre cualquier entidad a través de la interfaz de usuario híbrida o de la API Management, si la solicitud llega a alguno de los pods de Cassandra que no funcionan, no obtendrás ningún dato.

Resolución

Sigue los pasos que se indican en la siguiente sección y asegúrate de que los pods de Cassandra del centro de datos problemático estén conectados al centro de datos original, tal como se describe en Despliegue multirregional en GKE y GKE On-Prem | Apigee.

Causa: No se ha ejecutado la reparación de nodetool

Si el comando nodetool repair no se ha ejecutado periódicamente como tarea de mantenimiento, es posible que los datos de los pods de Cassandra no sean coherentes. Para analizar esta situación, sigue estos pasos:

Diagnóstico

  1. Crea un pod de contenedor de cliente de Cassandra apigee-hybrid-cassandra-client para depurar.
  2. Lista todos los pods de Cassandra: 
    # list cassandra pods
kubectl -n=apigee get pods -l app=apigee-cassandra
  3. Conéctate a uno de los pods de Cassandra mediante CQLSH: 
    cqlsh apigee-cassandra-default-0.apigee-cassandra-default.apigee.svc.cluster.local -u ddl_user --ssl
  4. Lista keyspaces: 
    SELECT * from system_schema.keyspaces;

    Ejemplo:

    ddl_user@cqlsh> SELECT keyspace_name from system_schema.keyspaces;

 keyspace_name
-----------------------------
                 system_auth
 cache_PROJECT_ID_hybrid
               system_schema
   kms_PROJECT_ID_hybrid
   kvm_PROJECT_ID_hybrid
   rtc_PROJECT_ID_hybrid
          system_distributed
                      system
                      perses
               system_traces
 quota_PROJECT_ID_hybrid

(11 rows)
  5. Identifica el keyspaces del resultado anterior, enumera y consulta todas las entidades de cada centro de datos mediante CQLSH.

    Si la entidad que no cumple los requisitos es un producto de API:

    select * from KMS_KEYSPACE.api_product;

    Si la entidad que no es coherente es la aplicación (app):

    select * from KMS_KEYSPACE.app;

    Si la entidad que no es coherente es developer:

    select * from KMS_KEYSPACE.developer;

    Si la entidad que no es coherente es un mapa de valores clave:

    select * from KVM_KEYSPACE.kvm_map_entry;

    Si la entidad que no es coherente es cache:

    select * from CACHE_KEYSPACE.cache_map_entry;
  6. Anota el número de registros de la salida de cada una de las consultas anteriores.
  7. Repite los pasos anteriores con cada uno de los pods de Cassandra de todos los centros de datos.
  8. Compara el número de registros obtenidos de todos los pods de Cassandra.
  9. Identifica los pods de Cassandra que tienen datos incoherentes.

Resolución

  1. Lista los pods de Cassandra y conéctate al pod de Cassandra específico que tenía datos incoherentes: 
    # list cassandra pods
kubectl -n=apigee get pods -l app=apigee-cassandra

# connect to one cassandra pod
kubectl -n=apigee exec -it apigee-cassandra-default-0 bash
  2. Ejecuta el comando nodetool repair en cada pod de Cassandra de cada centro de datos:

    En la versión de Apigee Hybrid anterior a la 1.4.0:

    nodetool repair

    En las versiones de Apigee Hybrid iguales o posteriores a la 1.4.0:

    nodetool -u JMX_USERNAME -pw JMX-PASSWORD repair
  3. Vuelve a seguir la sección de diagnóstico y comprueba si los datos se han replicado en todos los pods de Cassandra de forma coherente.
  4. Repite los pasos anteriores con todos los pods de Cassandra que tengan datos incoherentes.

Causa: problemas de conectividad de red

Si hay problemas de conectividad de red entre los centros de datos, es posible que los datos de Cassandra no se repliquen de forma coherente en todos los pods de Cassandra del anillo de Cassandra. Para analizar esta situación, sigue estos pasos:

Diagnóstico

  1. Lista todos los pods de Cassandra: 
    # list cassandra pods
kubectl -n=apigee get pods -l app=apigee-cassandra
  2. Ejecuta el siguiente comando curl y conecta por telnet al primer pod de Cassandra del segundo centro de datos (dc-2) desde el primer pod de Cassandra del primer centro de datos (dc-1) mediante el puerto 7001: 
      kubectl -n apigee exec -it apigee-cassandra-default-0 bash -- curl -v telnet://DC_2_APIGEE_CASSANDRA_DEFAULT_0_POD_IP:7001
  3. Si la conexión Telnet se ha realizado correctamente, se mostrará un resultado similar al siguiente: 
    * Rebuilt URL to: telnet://10.0.4.10:7001/
*   Trying 10.0.4.10...
* TCP_NODELAY set
* Connected to 10.0.4.10 (10.0.4.10) port 7001 (#0)
  4. De lo contrario, se mostrará un error similar al siguiente: 
    * Rebuilt URL to: telnet://10.0.4.10:7001/
*   Trying 10.0.4.10...
* TCP_NODELAY set
* connect to 10.0.4.10 port 7001 failed: Connection refused
* Failed to connect to 10.0.4.10 port 7001: Connection refused
* Closing connection 0
curl: (7) Failed to connect to 10.0.4.10 port 7001: Connection refused

    Si se produce un fallo de conectividad desde el pod de Cassandra de un centro de datos al pod de Cassandra de otro centro de datos, significa que debe haber una restricción de firewall o algún tipo de problema de conectividad de red.

Resolución

  1. Si esta implementación híbrida de Apigee está en GKE, comprueba si hay reglas de cortafuegos definidas que bloqueen el tráfico de un centro de datos a otro y analiza el problema de conectividad de red consultando la descripción general de las reglas de cortafuegos de VPC.
  2. Si esta implementación híbrida de Apigee se encuentra en GKE On-Prem, colabora con el equipo de redes correspondiente y analiza el problema de conectividad de red.

Debe recoger información de diagnóstico

Si el problema persiste incluso después de seguir las instrucciones anteriores, reúne la siguiente información de diagnóstico y ponte en contacto con el equipo de Asistencia de Google Cloud:

  1. El ID del proyecto de Google Cloud
  2. La organización de Apigee Hybrid
  3. El archivo overrides.yaml, que oculta la información sensible
  4. Estado de los pods de Kubernetes en todos los espacios de nombres: 
    kubectl get pods -A > kubectl-pod-status`date +%Y.%m.%d_%H.%M.%S`.txt
  5. Un cluster-info dump de Kubernetes: 
    # generate kubernetes cluster-info dump
kubectl cluster-info dump -A --output-directory=/tmp/kubectl-cluster-info-dump

# zip kubernetes cluster-info dump
zip -r kubectl-cluster-info-dump`date +%Y.%m.%d_%H.%M.%S`.zip /tmp/kubectl-cluster-info-dump/*

Referencias