Cassandra のトラブルシューティング ガイド

現在、Apigee ハイブリッド バージョン 1.8 のドキュメントを表示しています。このバージョンのサポートは終了しています。新しいバージョンにアップグレードする必要があります。詳細については、サポートされているバージョンをご覧ください。

Version 1.8 (unsupported)

   Supported versions:

• v1.12 (latest)                        
• v1.11                         
• v1.10                                        
• List of supported versions

   Unsupported versions:

• v1.9                                         
• v1.8                                         
• v1.7                                         
• v1.6                                         
• v1.5                                         
• v1.4                                         
• v1.3                                         
• v1.2                                         
• v1.1                                         

このトピックでは、Cassandra データストアのトラブルシューティングと問題の修正の手順について説明します。Cassandra は、ハイブリッド ランタイム アーキテクチャの cassandra コンポーネントで実行される永続データストアです。ランタイム サービス構成の概要もご覧ください。

Cassandra Pod が Pending 状態のままになる

症状

起動時の Cassandra Pod の状態が Pending のままです。

エラー メッセージ

kubectl を使用して Pod の状態を表示すると、1 つ以上の Cassandra Pod が Pending 状態で停止していることがわかります。Pending 状態は、Kubernetes がノード上の Pod をスケジュールできないことを示します。Pod を作成することはできません。次に例を示します。

kubectl get pods -n namespace

NAME                                     READY   STATUS      RESTARTS   AGE
adah-resources-install-4762w             0/4     Completed   0          10m
apigee-cassandra-default-0               0/1     Pending     0          10m
...

考えられる原因

Pod が保留状態のままになる原因は、いくつかあります。次に例を示します。

原因	説明
リソースの不足	Pod を作成するのに十分な CPU またはメモリがありません。
ボリュームが作成されていない	Pod が永続ボリュームの作成を待機しています。
Amazon EBS CSI ドライバがない	必要な Amazon EBS CSI ドライバがインストールされていません。

診断

kubectl を使用して Pod の状態を表示し、エラーの原因を特定します。次に例を示します。

kubectl -n namespace describe pods pod_name

次に例を示します。

kubectl describe pods apigee-cassandra-default-0 -n apigee

出力に次のいずれかの問題が表示されることがあります。

• 十分なリソースがない場合は、CPU またはメモリの不足を示す警告メッセージが表示されます。
• エラー メッセージに、Pod にバインドされていない即時 PersistentVolumeClaims（PVC）があることが示されている場合、その Pod は永続ボリュームを作成できません。

解決策

リソースの不足

Cassandra ノードプールを変更して、十分な CPU リソースとメモリリソースを確保します。詳細については、ノードプールのサイズを変更するをご覧ください。

永続ボリュームが作成されない

永続ボリュームの問題を特定する場合は、PersistentVolumeClaim（PVC）の状態を確認し、作成されない理由を特定します。

1. クラスタ内の PVC を一覧表示します。

   kubectl -n namespace get pvc
   
   NAME                                        STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
   cassandra-data-apigee-cassandra-default-0   Bound    pvc-b247faae-0a2b-11ea-867b-42010a80006e   10Gi       RWO            standard       15m
   ...

2. 障害が発生した Pod の PVC の情報を出力します。たとえば、次のコマンドは、Pod apigee-cassandra-default-0 にバインドされた PVC の情報を出力します。

   kubectl -n apigee describe pvc cassandra-data-apigee-cassandra-default-0
   
   Events:
     Type     Reason              Age                From                         Message
     ----     ------              ----               ----                         -------
     Warning  ProvisioningFailed  3m (x143 over 5h)  persistentvolume-controller  storageclass.storage.k8s.io "apigee-sc" not found

   この例では、apigee-sc という名前の StorageClass が存在しません。この問題を解決するには、デフォルトの StorageClass を変更するの説明に従って、不足している StorageClass をクラスタに作成します。

Pod のデバッグもご覧ください。

Amazon EBS CSI ドライバがない

ハイブリッド インスタンスが EKS クラスタで実行されている場合は、EKS クラスタが Amazon EBS コンテナ ストレージ インターフェース（CSI）ドライバを使用していることを確認します。詳しくは、 Amazon EBS CSI の移行に関するよくある質問をご覧ください。

Cassandra Pod が CrashLoopBackoff 状態のままになる

症状

起動時の Cassandra Pod の状態が CrashLoopBackoff のままです。

エラー メッセージ

kubectl を使用して Pod の状態を表示すると、1 つ以上の Cassandra Pod が CrashLoopBackoff 状態になっていることがわかります。この状態は、Kubernetes が Pod を作成できないことを示しています。次に例を示します。

kubectl get pods -n namespace

NAME                                     READY   STATUS            RESTARTS   AGE
adah-resources-install-4762w             0/4     Completed         0          10m
apigee-cassandra-default-0               0/1     CrashLoopBackoff  0          10m
...

考えられる原因

Pod が CrashLoopBackoff 状態のままになる原因は、いくつかあります。次に例を示します。

原因	説明
データセンターが以前のデータセンターと異なる	このエラーは、Cassandra Pod に以前のクラスタのデータが含まれた永続ボリュームがあり、新しい Pod が古いクラスタに参加できないことを示しています。これは通常、同じ Kubernetes ノードに以前の Cassandra クラスタの古い永続ボリュームが残っている場合に発生します。この問題は、クラスタで Cassandra を削除して再作成した場合に発生することがあります。
トラストストア ディレクトリが見つからない	このエラーは、Cassandra Pod が TLS 接続を作成できないことを示しています。これは通常、指定された鍵と証明書が無効か、存在しない場合、あるいはその他の問題がある場合に発生します。

診断

問題の原因を調べるには、Cassandra のエラーログを確認してください。

1. Pod を一覧表示して、失敗した Cassandra Pod の ID を取得します。

   kubectl get pods -n namespace

2. 失敗した Pod のログを確認します。

   kubectl logs pod_id -n namespace

解決策

Pod のログで次の手がかりを探します。

データセンターが以前のデータセンターと異なる

このログ メッセージが表示された場合:

Cannot start node if snitch's data center (us-east1) differs from previous data center

• クラスタ内に最新ではない PVC があるかどうかを確認し、あれば削除します。
• これが新規インストールの場合は、すべての PVC を削除して設定しなおします。次に例を示します。

  kubectl -n namespace get pvc
  kubectl -n namespace delete pvc cassandra-data-apigee-cassandra-default-0

トラストストア ディレクトリが見つからない

このログ メッセージが表示された場合:

Caused by: java.io.FileNotFoundException: /apigee/cassandra/ssl/truststore.p12
(No such file or directory)

キーと証明書がオーバーライド ファイルで提供されている場合は、それらが正しく、有効であることを確認します。次に例を示します。

cassandra:
  sslRootCAPath: path_to_root_ca-file
  sslCertPath: path-to-tls-cert-file
  sslKeyPath: path-to-tls-key-file

デバッグ用のクライアント コンテナを作成する

このセクションでは、cqlsh などの Cassandra デバッグ ユーティリティにアクセスできるクライアント コンテナを作成する方法について説明します。これらのユーティリティを使用すると、Cassandra テーブルに対してクエリを実行できるので、デバッグに役立ちます。

クライアント コンテナを作成する

クライアント コンテナを作成する手順は次のとおりです。

1. コンテナは、apigee-cassandra-user-setup Pod からの TLS 証明書を使用します。最初に、この証明書名を取得します。

   kubectl get secrets -n apigee --field-selector type=kubernetes.io/tls | grep apigee-cassandra-user-setup | awk '{print $1}'

   このコマンドは、証明書名を返します。例: apigee-cassandra-user-setup-rg-hybrid-b7d3b9c-tls

2. 新しいファイルを開き、次の Pod 仕様を貼り付けます。

   apiVersion: v1
   kind: Pod
   metadata:
     labels:
     name: cassandra-client-name   # For example: my-cassandra-client
     namespace: apigee
   spec:
     containers:
     - name: cassandra-client-name
       image: "gcr.io/apigee-release/hybrid/apigee-hybrid-cassandra-client:1.8.8"
       imagePullPolicy: Always
       command:
       - sleep
       - "3600"
       env:
       - name: CASSANDRA_SEEDS
         value: apigee-cassandra-default.apigee.svc.cluster.local
       - name: APIGEE_DML_USER
         valueFrom:
           secretKeyRef:
             key: dml.user
             name: apigee-datastore-default-creds
       - name: APIGEE_DML_PASSWORD
         valueFrom:
           secretKeyRef:
             key: dml.password
             name: apigee-datastore-default-creds
       volumeMounts:
       - mountPath: /opt/apigee/ssl
         name: tls-volume
         readOnly: true
     volumes:
     - name: tls-volume
       secret:
         defaultMode: 420
         secretName: your-secret-name    # For example: apigee-cassandra-user-setup-rg-hybrid-b7d3b9c-tls
     restartPolicy: Never

3. .yaml という拡張子を付けてファイルを保存します。例: my-spec.yaml
4. クラスタに仕様を適用します。

   kubectl apply -f your-spec-file.yaml -n apigee

5. コンテナにログインします。

   kubectl exec -n apigee cassandra-client -it -- bash

6. 次のコマンドを使用して、Cassandra cqlsh インターフェースに接続します。次のコマンドを正確に入力します。

   cqlsh ${CASSANDRA_SEEDS} -u ${APIGEE_DML_USER} -p ${APIGEE_DML_PASSWORD} --ssl

クライアント Pod の削除

次のコマンドを使用して、Cassandra クライアント Pod を削除します。

kubectl delete pods -n apigee cassandra-client

参考情報

Apigee と Apigee ハイブリッドのハンドブックの概要をご覧ください。