在 Hybrid 界面中或通过 Management API 发现实体具有不一致数据或无数据

您正在查看 Apigee 和 Apigee Hybrid 文档。
查看 Apigee Edge 文档。

注意：本文档仅适用于 Apigee Hybrid 用户。

症状

用户在 Apigee Hybrid 界面 (UI) 中以及通过 Management API 不时观察到 API 产品、应用、开发者、键值映射 (KVM) 和缓存等实体具有不一致数据或无数据。

错误消息

在这种情况下，系统不显示错误消息。

可能的原因

原因	说明
Cassandra pod 未连接到环	所有数据中心的 Cassandra pod 可能都未连接到通用 Cassandra 环。
未执行 nodetool 修复	nodetool repair 命令可能没有定期执行。
网络连接问题	不同数据中心的 Cassandra pod 之间存在网络连接问题

常见诊断步骤

1. 使用 Management API 提取出现此问题的一个或多个实体的信息（例如 API 产品、应用等），并验证多次调用时是否会看到不同的结果。

   在命令行中，使用以下示例获取您的 gcloud 身份验证凭据、设置环境变量并运行 API 命令：

   获取 API 产品：

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

   获取应用：

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

   获取开发者：

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

   获取键值映射 (KVM)：

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

   获取缓存：

   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. 如果上述 Management API 请求执行时您没有看到任何数据或者看到不同的数据，则表示您观察到的问题与在界面中观察到的问题相同。

原因：Cassandra pod 未连接到所有数据中心的 Cassandra pod

在多区域 Apigee Hybrid 部署中，如果所有 Cassandra pod 未连接到相同的 Cassandra 环，那么部分 Cassandra pod 可能不会复制数据。因此，对于同一查询，管理层面不会一致地收到相同的数据集。请按照以下步骤分析此场景：

诊断

1. 列出 Cassandra pod：

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

2. 执行以下命令，检查每个数据中心所有 Cassandra pod 的状态。

   在低于 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"

   在 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. 检查上述命令的结果，并验证所有数据中心的所有 Cassandra pod 是否均已连接到 Cassandra 环并处于正常运行 (UN) 状态。

   运行状况良好的 Cassandra 环的输出示例：

   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

   运行状况不佳的 Cassandra 环的输出示例：

   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

   请注意，上述输出的某些 Cassandra pod 处于 DL（关闭和离开）状态。如需了解详情，请参阅 nodetool 状态。

   • 如果您发现有任何 Cassandra pod 处于 DL 状态（如上面的输出示例所示），那么这就是导致此问题的原因。
   • 当通过 Hybrid 界面或 Management API 发出请求以提取实体的信息时，如果请求命中已关闭的 Cassandra pod，您将不会收到任何数据。

解决方法

执行下一部分中提供的步骤，并确保有问题的数据中心中的 Cassandra pod 如 GKE 和 GKE On-Prem 上的多区域部署 | Apigee 所述连接到原始数据中心。

原因：未执行 nodetool 修复

如果 nodetool repair 命令未作为维护任务定期执行，Cassandra pod 之间可能存在不一致的数据。请按照以下步骤分析此场景：

诊断

1. 创建 Cassandra 客户端容器 Pod apigee-hybrid-cassandra-client 以用于调试。
   
2. 列出所有 Cassandra pod：

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

3. 使用 CQLSH 连接到其中一个 Cassandra pod：

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

4. 列出 keyspaces：

   SELECT * from system_schema.keyspaces;

   输出示例：

   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. 识别上述结果中的 keyspaces，使用 CQLSH 列出并查询每个数据中心中的所有实体。

   如果不一致的实体是 API 产品：

   select * from KMS_KEYSPACE.api_product;

   如果不一致的实体是应用 (app)：

   select * from KMS_KEYSPACE.app;

   如果不一致的实体是 developer：

   select * from KMS_KEYSPACE.developer;

   如果不一致的实体是键值映射：

   select * from KVM_KEYSPACE.kvm_map_entry;

   如果不一致的实体是 cache：

   select * from CACHE_KEYSPACE.cache_map_entry;

6. 记下上述每个查询的输出中的记录计数。
7. 对所有数据中心中的每个 Cassandra pod 重复上述步骤。
8. 比较从所有 Cassandra pod 获得的记录计数。
9. 确定具有不一致数据的 Cassandra pod。

解决方法

1. 列出 Cassandra pod 并连接到具有不一致数据的特定 Cassandra pod：

   # 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. 在每个数据中心的各 Cassandra pod 上执行 nodetool repair 命令：

   在低于 Apigee Hybrid 1.4.0 的版本中：

   nodetool repair

   在 Apigee Hybrid 1.4.0 及更高版本中：

   nodetool -u JMX_USERNAME -pw JMX-PASSWORD repair

3. 再次按照诊断部分中的步骤操作并验证数据是否一致地复制到所有 Cassandra pod。
4. 对具有不一致数据的所有 Cassandra pod 重复上述步骤。

原因：网络连接问题

如果数据中心之间存在网络连接问题，则 Cassandra 数据可能无法一致地复制到 Cassandra 环中的所有 Cassandra pod。请按照以下步骤分析此场景：

诊断

1. 列出所有 Cassandra pod：

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

2. 执行以下 curl 命令，并通过 telnet 使用端口 7001 从第一个数据中心的第一个 Cassandra pod (dc-1) 连接到第二个数据中心的第一个 (dc-2)：

     kubectl -n apigee exec -it apigee-cassandra-default-0 bash -- curl -v telnet://DC_2_APIGEE_CASSANDRA_DEFAULT_0_POD_IP:7001

3. 如果 telnet 成功，则会显示类似如下所示的输出：

   * 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. 否则会显示类似如下所示的错误：

   * 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

   一个数据中心的 Cassandra pod 到另一个数据中心的 Cassandra pod 连接失败，表明存在防火墙限制或某种网络连接问题。

解决方法

1. 如果此 Apigee Hybrid 部署是在 GKE 上，请检查是否设置了阻止一个数据中心到另一个数据中心的流量的防火墙规则，并参阅 VPC 防火墙规则概览来分析网络连接问题。
2. 如果此 Apigee Hybrid 部署是在 GKE On-Prem 上，请与相关网络团队合作分析网络连接问题。

必须收集的诊断信息

如果按照上述说明操作后问题仍然存在，请收集以下诊断信息，然后与 Google Cloud Customer Care 联系：

1. Google Cloud 项目 ID
2. Apigee Hybrid 组织
3. 遮盖所有敏感信息的 overrides.yaml 文件
4. 所有命名空间中的 Kubernetes pod 状态：

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

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

参考

• GKE 和 GKE On-Prem 上的 Apigee Hybrid 多区域部署
• Kubernetes 文档
• Cassandra nodetool 状态命令