Vous consultez la documentation d'Apigee et d'Apigee hybrid.
Consultez la documentation d'Apigee Edge.
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
- 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"
- 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
- Répertoriez les pods Cassandra :
- 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"
- 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.
# list cassandra pods kubectl -n apigee get pods -l app=apigee-cassandra
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
- Créez un pod de conteneur client Cassandra
apigee-hybrid-cassandra-client
pour le débogage.
- Répertoriez tous les pods Cassandra :
# list cassandra pods kubectl -n=apigee get pods -l app=apigee-cassandra
- 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
- 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)
- 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;
- Notez le nombre d'enregistrements à partir du résultat de chacune des requêtes ci-dessus.
- Répétez les étapes ci-dessus pour chacun des pods Cassandra dans tous les centres de données.
- Comparez les nombres d'enregistrements obtenus de tous les pods Cassandra.
- Identifiez les pods Cassandra contenant des données incohérentes.
Solution
- 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
- 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
- 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.
- 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
- Répertoriez tous les pods Cassandra :
# list cassandra pods kubectl -n=apigee get pods -l app=apigee-cassandra
- 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
- 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)
- 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
- 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
- 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 Google Cloud Customer Care :
- L'ID de projet Google Cloud
- Organisation hybride Apigee
- Le fichier
overrides.yaml
, en masquant toutes les informations sensibles - É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
- 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