現在、Apigee と Apigee ハイブリッドのドキュメントを表示しています。
Apigee Edge ドキュメントを表示する
症状
API プロダクト、アプリ、デベロッパー、Key-Value マップ（KVM）、キャッシュなどのエンティティについて、データの整合性がない、またはデータがないという現象が、Apigee ハイブリッドのユーザー インターフェース（UI）や管理 API を通じて断続的に発生します。
エラー メッセージ
このシナリオでは、エラー メッセージは表示されません。
考えられる原因
| 原因 | 説明 |
|---|---|
| Cassandra Pod がリングに接続していない | すべてのデータセンターの Cassandra Pod が共通の Cassandra リングに接続されていない可能性があります。 |
| nodetool の修復が実行されなかった | nodetool repair コマンドが定期的に実行されていなかった可能性があります。 |
| ネットワーク接続に関する問題 | 異なるデータセンターにある Cassandra Pod 間でネットワーク接続の問題が発生している可能性があります。 |
共通の診断手順
- API プロダクトやアプリなど、この問題が発生している 1 つ以上のエンティティの情報を Management 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"
Key-Value マップ（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"
- 上記の Management API リクエストが実行されたときにデータがまったく表示されないか、データが異なる場合は、UI に示されたものと同じ問題があることを示しています。
原因: すべてのデータセンターの Cassandra Pod に Cassandra Pod が接続されていない
マルチリージョン Apigee ハイブリッド デプロイでは、すべての Cassandra Pod が同じ Cassandra リングに接続されていない場合、すべての Cassandra Pod によってデータが複製されないことがあります。その結果、管理プレーンは、同じクエリに対して同じデータセットを受信できない可能性があります。このシナリオを分析する手順は次のとおりです。
診断
- Cassandra Pod を一覧表示します。
- 次のコマンドを実行して、各データセンターのすべての Cassandra Pod のステータスを確認します。
Apigee ハイブリッド バージョン 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 ハイブリッド バージョン 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"
- 上記のコマンドの結果を調べて、すべてのデータセンター内の Cassandra Pod がすべて 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 status をご覧ください。
- DL ステータスの Cassandra Pod が見つかった場合（上記の出力例を参照）、これが問題の原因です。
- ハイブリッド UI または Management API を使用してエンティティに関する情報を取得するリクエストがあった場合、そのリクエストがダウンしている Cassandra Pod にヒットすると、データは取得されません。
# list cassandra pods kubectl -n apigee get pods -l app=apigee-cassandra
解決策
GKE と GKE on-prem でのマルチリージョン デプロイ | Apigee で説明されているように、次のセクションで説明する手順で、問題のあるデータセンターの Cassandra Pod が元のデータセンターに接続されていることを確認します。
原因: nodetool repair が実行されなかった
メンテナンス タスクとして nodetool repair コマンドを定期的に実行していない場合、Cassandra Pod 全体のデータに整合性がなくなる可能性があります。このシナリオを分析する手順は次のとおりです。
診断
- デバッグ用の Cassandra クライアント コンテナ Pod
apigee-hybrid-cassandra-clientを作成します。
- すべての Cassandra Pod を一覧表示します。
# list cassandra pods kubectl -n=apigee get pods -l app=apigee-cassandra
- CQLSH を使用して Cassandra Pod のいずれかに接続します。
cqlsh apigee-cassandra-default-0.apigee-cassandra-default.apigee.svc.cluster.local -u ddl_user --ssl
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)
- 上記の結果から
keyspacesを特定し、CQLSH を使用して各データセンター内のすべてのエンティティを一覧表示して、クエリを実行します。整合性のないエンティティが API プロダクトである場合:
select * from KMS_KEYSPACE.api_product;
一貫性のないエンティティがアプリケーション（
app）の場合:select * from KMS_KEYSPACE.app;
一貫性のないエンティティが
developerの場合:select * from KMS_KEYSPACE.developer;
整合性のないエンティティが Key-Value マップの場合:
select * from KVM_KEYSPACE.kvm_map_entry;
一貫性のないエンティティが
cacheの場合:select * from CACHE_KEYSPACE.cache_map_entry;
- 上記の各クエリの出力からレコード数をメモします。
- すべてのデータセンターの Cassandra Pod について、上記の手順を繰り返します。
- すべての Cassandra Pod から取得したレコード数を比較します。
- 整合性のないデータがある Cassandra Pod を特定します。
解決策
- 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
- 各データセンターの Cassandra Pod で
nodetool repairコマンドを実行します。Apigee ハイブリッド バージョン 1.4.0 未満の場合:
nodetool repair
Apigee ハイブリッド バージョン 1.4.0 以降の場合:
nodetool -u JMX_USERNAME -pw JMX-PASSWORD repair
- 診断セクションの手順をもう一度繰り返し、データがすべての Cassandra Pod に一貫して複製されているかどうかを確認します。
- データが一致しないすべての Cassandra Pod に上記の手順を繰り返します。
原因: ネットワーク接続の問題
データセンター間でネットワーク接続の問題がある場合は、Cassandra が Cassandra リング内のすべての Cassandra Pod に一貫して複製されないことがあります。このシナリオを分析する手順は次のとおりです。
診断
- すべての Cassandra Pod を一覧表示します。
# list cassandra pods kubectl -n=apigee get pods -l app=apigee-cassandra
- 次の
curlコマンドを実行し、7001ポートを使用して、最初のデータセンター（dc-1）にある最初の Cassandra Pod から、2 つめのデータセンター（dc-2）にある最初の Cassandra Pod に telnet 接続します。kubectl -n apigee exec -it apigee-cassandra-default-0 bash -- curl -v telnet://DC_2_APIGEE_CASSANDRA_DEFAULT_0_POD_IP:7001
- 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)
- そうでない場合は、次のようなエラーが表示されます。
* 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 への接続に失敗した場合、ファイアウォール制限やネットワーク接続の問題があることを示しています。
解決策
- この Apigee ハイブリッドのデプロイが GKE にある場合、あるデータセンターから別のデータセンターへのトラフィックをブロックするファイアウォール ルールが設定されているかどうかを確認し、VPC ファイアウォール ルールの概要を参照してネットワーク接続の問題を分析します。
- この Apigee ハイブリッド デプロイが GKE On-Prem 上にある場合は、関連するネットワーキング チームと連携して、ネットワーク接続の問題を分析します。
診断情報の収集が必要な場合
前述の手順を踏んでも問題が解決しない場合は、次の診断情報を収集して Google Cloud カスタマーケアにご連絡ください。
- Google Cloud プロジェクト ID
- Apigee ハイブリッド組織
overrides.yamlファイル。機密情報をマスキングします。- すべての Namespace の Kubernetes Pod のステータス:
kubectl get pods -A > kubectl-pod-status`date +%Y.%m.%d_%H.%M.%S`.txt
- 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/*