Cassandra のログを表示する

Cassandra は、Apigee Hybrid ランタイムに Apigee Core Persistence Services(CPS)を提供するために使用されるランタイム データストアです。Cassandra はファイルシステム上で状態を管理する必要がある分散データシステムなので、Cassandra データベースは Kubernetes の StatefulSet ノードプールにデプロイされます。

データストアに格納された、Message Processor がポリシーを実行するために必要なエンティティは次のとおりです。

  • 鍵管理システム(KMS)データ(会社、デベロッパー、デベロッパー アプリ、API プロダクト、API キーなど)
  • Key-Value マップ(KVM)データ
  • レスポンス キャッシュ データ
  • OAuth データ(アクセス トークン、更新トークン、認証コードなど)
  • 割り当てデータ(バケット、カウンタなど)

Cassandra ログファイル

ログは、インストール環境で発生した問題のトラブルシューティングに役立ちます。詳細については、ロギングをご覧ください。

エラーのトラブルシューティング

このセクションでは、Hybrid の Cassandra リングに関する問題のトラブルシューティングと解決方法について説明します。

ログファイル

ログは、インストール環境で発生した問題のトラブルシューティングに役立ちます。詳細については、ロギングをご覧ください。

ノードの障害を診断して修復する

Cassandra ポッドが起動に失敗した場合や Pending ステータスから変化しない場合は、ノードに問題があると考えることができます。このような問題は、基になるノードの障害を示している場合があります。ノードの障害を診断して修復する手順は次のとおりです。

  1. ポッドのリストを取得して、実行中でないポッドがあるかどうかを確認します。
    $ kubectl get pods -n your_namespace
            NAME          READY   STATUS    RESTARTS   AGE
            cassandra-0   0/1     Pending   0          13s
            cassandra-1   1/1     Running   0          8d
            cassandra-2   1/1     Running   0          8d
  2. ワーカーノードを確認します。NotReady 状態のノードがあれば、それが障害ノードです。
    kubectl get nodes -n your_namespace
        NAME                          STATUS   ROLES    AGE   VERSION
        ip-10-30-1-190.ec2.internal   Ready    <none>   8d    v1.13.2
        ip-10-30-1-22.ec2.internal    Ready    master   8d    v1.13.2
        ip-10-30-1-36.ec2.internal    NotReady <none>   8d    v1.13.2
        ip-10-30-2-214.ec2.internal   Ready    <none>   8d    v1.13.2
        ip-10-30-2-252.ec2.internal   Ready    <none>   8d    v1.13.2
        ip-10-30-2-47.ec2.internal    Ready    <none>   8d    v1.13.2
        ip-10-30-3-11.ec2.internal    Ready    <none>   8d    v1.13.2
        ip-10-30-3-152.ec2.internal   Ready    <none>   8d    v1.13.2
        ip-10-30-3-5.ec2.internal     Ready    <none>   8d    v1.13.2
  3. ダウンしている Cassandra ポッドをクラスタから削除します。
    $ kubectl exec -it apigee-cassandra-0 -- nodetool status
        $ kubectl exec -it apigee-cassandra-0 -- nodetool removenode deadnode_hostID
  4. アフィニティによって Cassandra ポッドがデッドノードで起動しないようにするため、デッドノードから VolumeClaim を削除します。
    kubectl get pvc -n your_namespace
        kubectl delete pvc volumeClaim_name -n your_namespace
  5. ボリューム テンプレートを更新し、新しく追加されたノードの PersistentVolume を作成します。ボリューム テンプレートの例を次に示します。
    apiVersion: v1
        kind: PersistentVolume
        metadata:
          name: cassandra-data-3
        spec:
          capacity:
            storage: 100Gi
          accessModes:
          - ReadWriteOnce
          persistentVolumeReclaimPolicy: Retain
          storageClassName: local-storage
          local:
            path: /apigee/data
          nodeAffinity:
            "required":
              "nodeSelectorTerms":
              - "matchExpressions":
                - "key": "kubernetes.io/hostname"
                  "operator": "In"
                  "values": ["ip-10-30-1-36.ec2.internal"]
  6. 値を新しいホスト名または IP に置き換え、テンプレートを適用します。
    kubectl apply -f volume-template.yaml