Données incohérentes/non observées pour les entités dans l'interface utilisateur hybride ou via les API de gestion

Vous consultez la documentation d'Apigee et d'Apigee hybrid.
Consultez la documentation d'Apigee Edge.

Remarque : Ce document ne s'applique qu'aux utilisateurs d'Apigee hybrid.

Symptôme

Les utilisateurs observent des données incohérentes ou aucune donnée pour les entités telles que les produits d'API, les applications, les développeurs, les mappages clé/valeur et le cache par intermittence sur l'interface utilisateur Apigee hybrid et via l'API de gestion.

Messages d'erreur

Dans ce scénario, aucun message d'erreur n'est connu.

Causes possibles :

Cause	Description
Pods Cassandra non connectés à l'anneau	Les pods Cassandra de tous les centres de données peuvent ne pas être connectés à l'anneau Cassandra commun.
La réparation de nodetool n'a pas été exécutée	La commande nodetool repair n'a peut-être pas été exécutée régulièrement.
Problèmes de connectivité réseau	Des problèmes de connectivité réseau peuvent se produire entre les pods Cassandra de différents centres de données.

Étapes de diagnostic courantes

1. Extrayez les informations d'une ou plusieurs entités pour lesquelles vous rencontrez ce problème, telles que des produits d'API, des applications, etc., à l'aide de l'API Management et vérifiez si vous risquez de ne pas voir les mêmes résultats si vous l'appelez plusieurs fois.

   Sur la ligne de commande, utilisez les exemples suivants pour obtenir vos identifiants d'authentification gcloud, définir les variables d'environnement et exécuter les commandes de l'API :

   Obtenir les produits d'API :

   TOKEN=$(gcloud auth print-access-token)
   ORG=ORGANIZATION_NAME
   
   curl -i -H "Authorization: Bearer $TOKEN" \
   "https://apigee.googleapis.com/v1/organizations/$ORG/apiproducts"
   

   Obtenir des applications

   TOKEN=$(gcloud auth print-access-token)
   ORG=ORGANIZATION_NAME
   
   curl -i -H "Authorization: Bearer $TOKEN" \
   "https://apigee.googleapis.com/v1/organizations/$ORG/apps"
   

   Obtenir des développeurs :

   TOKEN=$(gcloud auth print-access-token)
   ORG=ORGANIZATION_NAME
   
   curl -i -H "Authorization: Bearer $TOKEN" \
   "https://apigee.googleapis.com/v1/organizations/$ORG/developers"
   

   Obtenir les mappings clé-valeur (KVM) :

   TOKEN=$(gcloud auth print-access-token)
   ORG=ORGANIZATION_NAME
   
   curl -i -H "Authorization: Bearer $TOKEN" \
   "https://apigee.googleapis.com/v1/organizations/$ORG/keyvaluemaps"
   

   Obtenir des 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 vous ne voyez aucune donnée ou si voyez des données différentes lorsque les requêtes de l'API Management ci-dessus sont exécutées, cela indique que vous observez le même problème que celui observé dans l'UI.

Cause : pods Cassandra non connectés aux pods Cassandra de tous les centres de données

Dans un déploiement Apigee hybrid multirégional, si tous les pods Cassandra ne sont pas connectés au même anneau Cassandra, les données peuvent ne pas être répliquées par tous les pods Cassandra. Par conséquent, le plan de gestion ne reçoit pas systématiquement le même ensemble de données pour la même requête. Pour analyser ce scénario, procédez comme suit :

Diagnostic

1. Répertoriez les pods Cassandra :

# list cassandra pods
kubectl -n apigee get pods -l app=apigee-cassandra

2. Exécutez la commande suivante pour vérifier l'état de tous les pods Cassandra sur chaque centre de données.

   Avec une version Apigee hybrid < 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"
   

   Avec les versions Apigee hybrid >= 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. Vérifiez le résultat de la commande ci-dessus et vérifiez si tous les pods Cassandra de tous les centres de données sont connectés à l'anneau Cassandra et affichent l'état Up and normal (UN).

   Exemple de sortie d'un anneau Cassandra opérationnel :

   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
   

   Exemple de résultat d'un anneau Cassandra non opérationnel :

   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
   

   Notez que certains des pods Cassandra du résultat ci-dessus sont à l'état DL (Down and Leaving). Pour plus d'informations, consultez la section État de nodetool.

   • Si des pods Cassandra s'affichent à l'état DL (comme illustré dans l'exemple de résultat ci-dessus), cela est la cause de ce problème.
   • Lorsqu'une requête est effectuée pour récupérer des informations sur des entités via l'interface utilisateur hybride ou l'API Management, si la requête appelle l'un des pods Cassandra inactifs, vous n'obtenez aucune donnée.

Solution

Effectuez les étapes décrites dans la section suivante et assurez-vous que les pods Cassandra du centre de données problématique sont connectés au centre de données d'origine, comme décrit dans la section Déploiement multirégional sur GKE et GKE On-Prem | Apigee.

Cause : La réparation de Nodetool n'a pas été exécutée

Si la commande nodetool repair n'a pas été exécutée régulièrement en tant que tâche de maintenance, il est possible que les données soient incohérentes entre les pods Cassandra. Pour analyser ce scénario, procédez comme suit :

Diagnostic

1. Créez un pod de conteneur client Cassandra apigee-hybrid-cassandra-client pour le débogage.
   
2. Répertoriez tous les pods Cassandra :

   # list cassandra pods
   kubectl -n=apigee get pods -l app=apigee-cassandra
   

3. Connectez-vous à l'un des pods Cassandra à l'aide de CQLSH :

   cqlsh apigee-cassandra-default-0.apigee-cassandra-default.apigee.svc.cluster.local -u ddl_user --ssl
   

4. Répertoriez keyspaces :

   SELECT * from system_schema.keyspaces;

   Exemple de résultat :

   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. Identifiez l'élément keyspaces dans le résultat ci-dessus, répertoriez et interrogez toutes les entités de chaque centre de données à l'aide de CQLSH.

   Si l'entité qui est incohérente est un produit d'API :

   select * from KMS_KEYSPACE.api_product;

   Si l'entité incohérente est l'application (app) :

   select * from KMS_KEYSPACE.app;

   Si l'entité incohérente est developer :

   select * from KMS_KEYSPACE.developer;

   Si l'entité incohérente est le mappage de valeur-clé :

   select * from KVM_KEYSPACE.kvm_map_entry;

   Si l'entité incohérente est cache :

   select * from CACHE_KEYSPACE.cache_map_entry;

6. Notez le nombre d'enregistrements à partir du résultat de chacune des requêtes ci-dessus.
7. Répétez les étapes ci-dessus pour chacun des pods Cassandra dans tous les centres de données.
8. Comparez les nombres d'enregistrements obtenus de tous les pods Cassandra.
9. Identifiez les pods Cassandra contenant des données incohérentes.

Solution

1. Répertoriez les pods Cassandra et connectez-vous à un pod Cassandra spécifique dont les données sont incohérentes :

   # 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. Exécutez la commande nodetool repair sur chaque pod Cassandra dans chaque centre de données :

   Avec une version Apigee hybrid < 1.4.0 :

   nodetool repair

   Avec les versions Apigee hybrid >= 1.4.0 :

   nodetool -u JMX_USERNAME -pw JMX-PASSWORD repair

3. Suivez à nouveau la section de diagnostic et vérifiez si les données ont été répliquées de manière cohérente sur tous les pods Cassandra.
4. Répétez les étapes ci-dessus pour tous les pods Cassandra dont les données sont incohérentes.

Cause : problèmes de connectivité réseau

En cas de problèmes de connectivité réseau entre les centres de données, les données Cassandra peuvent ne pas être répliquées de manière cohérente sur tous les pods Cassandra de l'anneau Cassandra. Pour analyser ce scénario, procédez comme suit :

Diagnostic

1. Répertoriez tous les pods Cassandra :

   # list cassandra pods
   kubectl -n=apigee get pods -l app=apigee-cassandra
   

2. Exécutez la commande curl et connectez-vous par telnet vers le premier pod Cassandra du deuxième centre de données (dc-2) depuis le premier pod Cassandra du premier centre de données (dc-1) à l'aide du port. 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 le protocole telnet a réussi, un résultat semblable au suivant s'affiche :

   * 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. Sinon, une erreur semblable à la suivante s'affiche :

   * 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
   

   L'échec de la connectivité du pod Cassandra d'un centre de données au pod Cassandra d'un autre centre de données indique qu'il existe une restriction de pare-feu ou un problème de connectivité réseau.

Solution

1. Si ce déploiement Apigee hybrid est sur GKE, vérifiez si des règles de pare-feu sont définies pour bloquer le trafic d'un centre de données à un autre, et analysez le problème de connectivité réseau en vous reportant à Présentation des règles de pare-feu VPC
2. Si ce déploiement Apigee hybrid est basé sur GKE On-Prem, collaborez avec l'équipe réseau appropriée et analysez le problème de connectivité réseau.

Vous devez collecter des informations de diagnostic

Si le problème persiste, même après avoir suivi les instructions ci-dessus, rassemblez les informations de diagnostic suivantes, puis contactez l'assistance Apigee :

1. L'ID de projet Google Cloud
2. Organisation hybride Apigee
3. Le fichier overrides.yaml, en masquant toutes les informations sensibles
4. État du pod Kubernetes dans tous les espaces de noms :

   kubectl get pods -A > kubectl-pod-status`date +%Y.%m.%d_%H.%M.%S`.txt

5. Un objet Kubernetes cluster-info dump :

   # 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/*
   

Références

• Déploiement multirégional Apigee Hybrid sur GKE et GKE On-Prem
• Documentation Kubernetes
• Commande Cassandra nodetool Status