Inkonsistente/keine Daten für Entitäten in Hybrid-UI oder über Management APIs beobachtet

Sie lesen gerade die Dokumentation zu Apigee und Apigee Hybrid.
Apigee Edge-Dokumentation aufrufen.

Hinweis: Dieses Dokument gilt nur für Nutzer von Apigee Hybrid.

Symptom

Nutzer beobachten inkonsistente Daten oder keine Daten für Entitäten wie API-Produkte, Apps, Entwickler, Schlüssel/Wert-Paar-Zuordnungen (Key Value Maps, KVM) und den Cache periodisch in der Benutzeroberfläche von Apigee Hybrid und über die Management API.

Fehlermeldungen

Fehlermeldungen sind in diesem Szenario nicht bekannt.

Mögliche Ursachen

Ursache	Beschreibung
Cassandra-Pods nicht mit dem Ring verbunden	Cassandra-Pods der Rechenzentren sind möglicherweise nicht mit dem gemeinsamen Cassandra-Ring verbunden.
Die Knotentoolreparatur wurde nicht ausgeführt.	Der Befehl nodetool repair wurde möglicherweise nicht regelmäßig ausgeführt.
Probleme mit der Netzwerkverbindung	Es können Probleme mit der Netzwerkverbindung zwischen Cassandra-Pods in verschiedenen Rechenzentren auftreten.

Allgemeine Diagnoseschritte

1. Rufen Sie mit der Management API die Informationen zu einer oder mehreren Entitäten ab, für die dieses Problem auftritt, z. B. die API-Produkte, Apps usw., und prüfen Sie, ob sich die Ergebnisse beim mehrmaligen Aufrufen unterscheiden.

   Verwenden Sie in der Befehlszeile die folgenden Beispiele, um Ihre Anmeldedaten für die gcloud-Authentifizierung abzurufen, Umgebungsvariablen festzulegen und API-Befehle auszuführen:

   API-Produkte abrufen:

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

   Apps abrufen:

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

   Entwickler abrufen:

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

   Schlüssel/Wert-Zuordnungen (Key Value Maps, KVMs) abrufen:

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

   Caches abrufen:

   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. Wenn Sie bei der Ausführung der oben genannten Management API-Anfragen keine Daten oder andere Daten sehen, weist dies auf das gleiche Problem hin, das auch in der UI beobachtet wurde.

Ursache: Cassandra-Pods nicht mit den Cassandra-Pods aller Rechenzentren verbunden

Wenn in einer multiregionalen Apigee Hybrid-Bereitstellung nicht alle Cassandra-Pods mit demselben Cassandra-Ring verbunden sind, werden Daten möglicherweise nicht von allen Cassandra-Pods repliziert. Daher erhält die Verwaltungsebene nicht immer das dasselbe Dataset für dieselbe Abfrage. Führen Sie die folgenden Schritte aus, um dieses Szenario zu analysieren:

Diagnose

1. Listen Sie die Cassandra-Pods auf:

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

2. Führen Sie den folgenden Befehl aus, um den Status aller Cassandra-Pods in jedem Rechenzentrum zu prüfen.

   In der Apigee Hybrid-Version < 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"

   In Apigee Hybrid-Versionen > = 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. Überprüfen Sie das Ergebnis des obigen Befehls und prüfen Sie, ob alle Cassandra-Pods in allen Rechenzentren mit dem Cassandra-Ring verbunden sind und den Status Up and Normal (UN) haben.

   Beispielausgabe eines fehlerfreien Cassandra-Rings:

   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

   Beispielausgabe eines fehlerhaften Cassandra-Rings:

   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

   Beachten Sie, dass einige Cassandra-Pods der obigen Ausgabe den Status DL (Down and Leaving) haben. Weitere Informationen finden Sie unter Knotentoolstatus.

   • Wenn Sie Cassandra-Pods im DL-Status sehen (wie in der obigen Beispielausgabe gezeigt), ist dies die Ursache des Problems.
   • Wenn eine Anfrage zum Abrufen der Informationen zu einer Entität über die Hybrid-UI oder die Management API erfolgt und die Anfrage auf einen der Cassandra-Pods trifft, die nicht erreichbar sind, erhalten Sie keine Daten.

Lösung

Führen Sie die im folgenden Abschnitt beschriebenen Schritte aus und achten Sie darauf, dass die Cassandra-Pods im problematischen Rechenzentrum mit dem ursprünglichen Rechenzentrum verbunden sind, wie unter Multiregionale Bereitstellung in GKE und GKE On-Prem | Apigee beschrieben.

Ursache: Die Knotentool-Reparatur wurde nicht ausgeführt

Wenn der Befehl nodetool repair nicht regelmäßig als Wartungsaufgabe ausgeführt wurde, kann es zu inkonsistenten Daten in Cassandra-Pods kommen. Führen Sie die folgenden Schritte aus, um dieses Szenario zu analysieren:

Diagnose

1. Erstellen Sie einen Cassandra-Client-Container-Pod apigee-hybrid-cassandra-client zum Debugging.
   
2. Listen Sie alle Cassandra-Pods auf:

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

3. Stellen Sie mit CQLSH eine Verbindung zu einem der Cassandra-Pods her:

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

4. Listen Sie keyspaces auf:

   SELECT * from system_schema.keyspaces;

   Beispielausgabe:

   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. Identifizieren Sie die keyspaces aus dem obigen Ergebnis, listen Sie mit CQLSH alle Entitäten in jedem Rechenzentrum auf und fragen Sie sie ab.

   Wenn die inkonsistente Entität das API-Produkt ist:

   select * from KMS_KEYSPACE.api_product;

   Wenn die inkonsistente Entität die Anwendung (app) ist:

   select * from KMS_KEYSPACE.app;

   Wenn die inkonsistente Entität developer ist:

   select * from KMS_KEYSPACE.developer;

   Wenn die inkonsistente Entität die Schlüsselwertzuordnung ist:

   select * from KVM_KEYSPACE.kvm_map_entry;

   Wenn die inkonsistente Entität cache ist:

   select * from CACHE_KEYSPACE.cache_map_entry;

6. Notieren Sie sich die Anzahl der Datensätze aus der Ausgabe jeder der oben genannten Abfragen.
7. Wiederholen Sie die oben genannten Schritte für jeden Cassandra-Pod in allen Rechenzentren.
8. Vergleichen Sie die Datensatzanzahl, die von allen Cassandra-Pods erhalten wurde.
9. Identifizieren Sie Cassandra-Pods mit inkonsistenten Daten.

Lösung

1. Listen Sie Cassandra-Pods auf und stellen Sie eine Verbindung zu bestimmten Cassandra-Pods her, die inkonsistente Daten hatten:

   # 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. Führen Sie den Befehl nodetool repair in jedem Cassandra-Pod in jedem Rechenzentrum aus:

   In der Apigee Hybrid-Version < 1.4.0:

   nodetool repair

   In Apigee Hybrid-Versionen > = 1.4.0:

   nodetool -u JMX_USERNAME -pw JMX-PASSWORD repair

3. Führen Sie den Diagnoseabschnitt noch einmal aus und prüfen Sie, ob Daten konsistent in allen Cassandra-Pods repliziert wurden.
4. Wiederholen Sie die obigen Schritte für alle Cassandra-Pods mit inkonsistenten Daten.

Ursache: Probleme mit der Netzwerkverbindung

Wenn Probleme mit der Netzwerkverbindung zwischen Rechenzentren auftreten, werden Cassandra-Daten möglicherweise nicht konsistent auf allen Cassandra-Pods im Cassandra-Ring repliziert. Führen Sie die folgenden Schritte aus, um dieses Szenario zu analysieren:

Diagnose

1. Listen Sie alle Cassandra-Pods auf:

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

2. Führen Sie den folgenden curl-Befehl und die Telnet-Verbindung zum ersten Cassandra-Pod im zweiten Rechenzentrum (dc-2) aus dem ersten Cassandra-Pod im ersten Rechenzentrum (dc-1) aus. Verwenden Sie dazu 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. Wenn die Telnet-Verbindung erfolgreich war, wird eine Ausgabe ähnlich der folgenden angezeigt:

   * 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. Andernfalls wird ein Fehler wie der folgende angezeigt:

   * 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

   Der Fehler bei der Verbindung vom Cassandra-Pod in einem Rechenzentrum zum Cassandra-Pod in einem anderen Rechenzentrum zeigt, dass eine Firewalleinschränkung oder ein Problem mit der Netzwerkverbindung vorliegt.

Lösung

1. Wenn sich diese Apigee Hybrid-Bereitstellung in GKE befindet, prüfen Sie, ob Firewallregeln vorhanden sind, die den Traffic von einem Rechenzentrum zu einem anderen blockieren, und analysieren Sie das Problem der Netzwerkverbindung. Verweisen Sie dazu auf Übersicht über VPC-Firewallregeln auf Ihrem Mobilgerät.
2. Wenn sich diese Apigee Hybrid-Bereitstellung in GKE On-Prem befindet, arbeiten Sie mit dem entsprechenden Netzwerkteam zusammen und analysieren Sie das Problem mit der Netzwerkverbindung.

Erfassen von Diagnoseinformationen erforderlich

Wenn das Problem auch nach Befolgen der obigen Anweisungen weiterhin besteht, sammeln Sie die folgenden Diagnoseinformationen und wenden Sie sich dann an Google Cloud Customer Care:

1. Die Google Cloud-Projekt-ID
2. Die Apigee Hybrid-Organisation
3. Die Datei overrides.yaml, wobei vertrauliche Informationen maskiert sind
4. Kubernetes-Pod-Status in allen Namespaces:

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

5. Ein 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/*

Verweise

• Multiregionale Bereitstellung in GKE und GKE On-Prem von Apigee Hybrid
• Kubernetes-Dokumentation
• Cassandra-Knotentool-Statusbefehl