透過 Management API 或混合型使用者介面中的實體資料不一致/找不到

您正在查看 Apigee 和 Apigee Hybrid 說明文件。
查看 Apigee Edge 說明文件。

問題

使用者在 Apigee 混合型使用者介面 (UI) 和 Management API 中，間歇性地發現實體 (例如 API 產品、應用程式、開發人員、鍵值對應 (KVM) 和快取) 的資料不一致或找不到。

錯誤訊息

在這種情況下，系統不會顯示任何錯誤訊息。

可能原因

原因	說明
Cassandra pod 未連線至環	所有資料中心的 Cassandra 吊掛叢集可能不會連線至常見的 Cassandra 環。
未執行 nodetool 修復作業	nodetool repair 指令可能未定期執行。
網路連線問題	不同資料中心的 Cassandra 吊掛叢集之間可能會發生網路連線問題。

常見的診斷步驟

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 要求時沒有看到任何資料或看到不同的資料，表示您觀察到的情況與 UI 相同。

原因：Cassandra pod 未連線至所有資料中心的 Cassandra pod

在多區域 Apigee 混合部署中，如果所有 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 容器是否已連線至 Cassandra 環，並處於「Up and Normal (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 (Down and Leaving) 狀態。詳情請參閱 nodetool 狀態。

   • 如果您發現任何 Cassandra 集合節點處於 DL 狀態 (如上方範例輸出內容所示)，那就是這個問題的原因。
   • 透過混合型 UI 或 Management API 要求擷取任何實體的資訊時，如果要求命中任何已關閉的 Cassandra Pod，就不會取得任何資料。

解決方法

請按照下文所述步驟操作，確保有問題的資料中心中的 Cassandra Pod 已連線至原始資料中心，詳情請參閱「GKE 和 GKE 內部部署的多區域部署作業 | 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 容器：

   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 容器重複上述步驟。
8. 比較從所有 Cassandra 容器取得的記錄計數。
9. 找出資料不一致的 Cassandra Pod。

解決方法

1. 列出 Cassandra 容器，並連線至資料不一致的特定 Cassandra 容器：

   # 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 指令，並使用 7001 連線至第一個資料中心 (dc-1) 的第一個 Cassandra 容器，再透過該容器連線至第二個資料中心 (dc-2) 的第一個 Cassandra 容器：

     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 混合式部署是在 GKE 上執行，請檢查是否設定了任何防火牆規則，以便封鎖從一個資料中心傳送至另一個資料中心的流量，並參閱 VPC 防火牆規則總覽，分析網路連線問題。
2. 如果這個 Apigee 混合式部署作業是在 GKE 地端上執行，請與相關網路團隊合作，並分析網路連線問題。

必須收集診斷資訊

如果問題在按照上述操作說明後仍未解決，請收集下列診斷資訊，然後與 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 狀態指令