Datos incoherentes o sin datos para entidades en la IU híbrida o las API de administración

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

Síntoma

Los usuarios observan datos incoherentes o no se incluyen datos para entidades como productos de API, apps, desarrolladores, mapas de clave-valor (KVM) y almacenamiento en caché de forma intermitente en la interfaz de usuario híbrida (IU) de Apigee y a través de la API de administración.

Mensajes de error

No se conocen mensajes de error en esta situación.

Causas posibles

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 común de Cassandra.
No se ejecutó la reparación de nodetool. Es posible que el comando nodetool repair no se ejecute de forma periódica.
Problemas con la conectividad de red Es posible que haya problemas de conectividad de red entre Pods de Cassandra en centros de datos diferentes.

Pasos comunes de diagnóstico

  1. Recupera la información sobre una o más entidades para las que ves este problema, como productos de API, apps, entre otros, mediante la API de administración y verifica si puedes ver o no resultados diferentes cuando se los invoca varias veces.

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

    Obtén 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"

    Obtén apps:

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

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

    Obtén desarrolladores:

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

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

    Obtén mapas de clave-valor (KVM):

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

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

    Obtén almacenamiento en caché:

    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 ves datos o ves datos diferentes cuando se ejecutan las solicitudes a la API de administración anteriores, esto indica que observas el mismo problema que el que se observa en la IU.

Causa: Pods de Cassandra no conectados a los Pods de Cassandra de todos los centros de datos.

Si todos los Pods de Cassandra no están conectados en una implementación híbrida de Apigee multirregión al mismo anillo de Cassandra, es posible que todos los Pods de Cassandra no repliquen los datos. Como resultado, el plano de administración no recibirá el mismo conjunto de datos para la misma consulta de forma coherente. Sigue estos pasos para analizar esta situación:

Diagnóstico

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

    En la versión híbrida de Apigee menor que 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 versiones híbridas de Apigee mayor o igual que 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 en todos los centros de datos están conectados al anillo de Cassandra y en el estado Up and Normal (UN).

    Resultado de ejemplo de un anillo de Cassandra en buen 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
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

    Resultado de ejemplo 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 están en estado DL (Down and Leaving). Para obtener más información, consulta el estado de nodetool.

    • Si observas cualquier Pod de Cassandra en el estado DL (como se ve en el resultado de ejemplo anterior), esa sería la causa de este problema.
    • Cuando se realiza una solicitud para recuperar información sobre cualquier entidad por medio de la IU híbrida o la API de administración, si la solicitud llega a alguno de los Pods de Cassandra que no está disponible, no obtendrás datos.

Solución

Realiza los pasos que se proporcionan en la siguiente sección y asegúrate de que los Pods de Cassandra en el centro de datos problemático estén conectados al centro de datos original, como se describe en Implementación multirregional en GKE y GKE On-Prem | Apigee.

Causa: La reparación de la nodetool no se ejecutó

Si el comando nodetool repair no se ejecutó de forma periódica como una tarea de mantenimiento, existe la posibilidad de que existan datos incoherentes en todos los Pods de Cassandra. Sigue estos pasos para analizar esta situación:

Diagnóstico

  1. Crea un Pod de contenedor de cliente de Cassandra apigee-hybrid-cassandra-client para la depuración.
  2. Obtén una lista de 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. Obtén una lista de keyspaces:
    SELECT * from system_schema.keyspaces;

    Resultado de 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 los keyspaces del resultado anterior, enumera y consulta todas las entidades en cada centro de datos mediante CQLSH.

    Si la entidad que es incoherente es el producto de la API:

    select * from KMS_KEYSPACE.api_product;

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

    select * from KMS_KEYSPACE.app;

    Si la entidad que es incoherente es developer, sucede lo siguiente:

    select * from KMS_KEYSPACE.developer;

    Si la entidad que es incoherente es la asignación de clave-valor:

    select * from KVM_KEYSPACE.kvm_map_entry;

    Si la entidad que es incoherente es cache, sucede lo siguiente:

    select * from CACHE_KEYSPACE.cache_map_entry;
  6. Toma nota de los recuentos de registros a partir del resultado de cada una de las consultas anteriores.
  7. Repite los pasos anteriores para cada uno de los Pods de Cassandra en todos los centros de datos.
  8. Compara los recuentos de registros obtenidos de todos los Pods de Cassandra.
  9. Identifica los Pods de Cassandra que tienen datos incoherentes.

Solución

  1. Enumera los Pods de Cassandra y conéctate a un Pod de Cassandra específico que tenga 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 en cada centro de datos:

    En la versión híbrida de Apigee menor que 1.4.0:

    nodetool repair

    En versiones híbridas de Apigee mayor o igual que 1.4.0:

    nodetool -u JMX_USERNAME -pw JMX-PASSWORD repair
  3. Vuelve a realizar la sección de diagnóstico y verifica si los datos se replicaron o no de manera coherente en todos los Pods de Cassandra.
  4. Repite los pasos anteriores para todos los Pods de Cassandra que tuvieron datos incoherentes.

Causa: Problemas de conectividad de red

Si hay problemas de conectividad de red entre centros de datos, es posible que los datos de Cassandra no se repliquen de manera coherente en todos los Pods de Cassandra en su anillo. Sigue estos pasos para analizar esta situación

Diagnóstico

  1. Obtén una lista de todos los Pods de Cassandra: 
    # list cassandra pods
kubectl -n=apigee get pods -l app=apigee-cassandra
  2. Ejecuta el siguiente comando curl y Telnet en el primer Pod de Cassandra en el segundo centro de datos (dc-2) del primer Pod de Cassandra en el 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 Telnet ejecuta de forma correcta, se muestra 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 muestra 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

    La falla de conectividad del Pod de Cassandra en un centro de datos al Pod de Cassandra en otro centro de datos indica que debe haber una restricción de firewall o una especie de problema de conectividad de red.

Solución

  1. Si esta implementación híbrida de Apigee está en GKE, verifica si se establecieron reglas de firewall que bloquean el tráfico de un centro de datos a otro y analiza el problema de conectividad de red. Para ello consulta Descripción general de las reglas de firewall de VPC.
  2. Si esta implementación híbrida de Apigee está en GKE On-Prem, trabaja con el equipo de red relevante y analiza el problema de conectividad de red.

Se debe recopilar información de diagnóstico

Si el problema persiste incluso después de seguir las instrucciones anteriores, recopila la siguiente información de diagnóstico y, luego, comunícate con Asistencia de Apigee:

  1. El ID del proyecto de Google Cloud
  2. La organización híbrida de Apigee
  3. El archivo overrides.yaml, que enmascara la información sensible
  4. Estado del Pod 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