Tipps zur Fehlerbehebung für Cassandra

Sie sehen sich gerade die Version 1.6 der Apigee Hybrid-Dokumentation an. This version is end of life. You should upgrade to a newer version. Weitere Informationen finden Sie unter Unterstützte Versionen.

Version 1.6 (unsupported)

Unterstützte Versionen:

• v1.13 (aktuellste Version)                        
• v1.12                         
• v1.11                         
• Liste der unterstützten Versionen

Nicht unterstützte Versionen:

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

In diesem Thema werden Schritte erläutert, mit denen Sie Probleme mit dem Cassandra-Datenspeicher beheben können. Cassandra ist ein nichtflüchtiger Datenspeicher, der in der Komponente cassandra der Hybridlaufzeitarchitektur ausgeführt wird. Weitere Informationen finden Sie unter Laufzeitdienst-Konfiguration – Übersicht.

Cassandra-Pods verbleiben im Status "Ausstehend"

Symptom

Nach dem Start verbleiben die Cassandra-Pods im Status Ausstehend.

Fehlermeldung

Wenn Sie den Pod-Status mit kubectl aufrufen, sehen Sie, dass ein oder mehrere Cassandra-Pods im Status Pending verbleiben. Der Status Pending gibt an, dass Kubernetes den Pod auf einem Knoten nicht planen kann: Der Pod kann nicht erstellt werden. Beispiel:

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
...

Mögliche Ursachen

Ein Pod, der im Status "Ausstehend" verbleibt, kann mehrere Ursachen haben. Beispiel:

Ursache	Beschreibung
Unzureichende Ressourcen	Es ist nicht genügend CPU oder Arbeitsspeicher zum Erstellen des Pods verfügbar.
Volume nicht erstellt	Der Pod wartet auf die Erstellung des nichtflüchtigen Volumes.

Diagnose

Verwenden Sie kubectl, um den Pod zu beschreiben und die Ursache des Fehlers zu ermitteln. Beispiel:

kubectl -n namespace describe pods pod_name

Beispiel:

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

Die Ausgabe kann eines der folgenden möglichen Probleme anzeigen:

• Wenn unzureichende Ressourcen das Problem sind, wird eine Warnmeldung angezeigt, dass die CPU oder der Arbeitsspeicher nicht ausreicht.
• Wenn in der Fehlermeldung darauf hingewiesen wird, dass der Pod ungebundene sofortige PersistentVolumeClaims (PVC) hat, kann der Pod kein nichtflüchtiges Volume erstellen.

Lösung

Unzureichende Ressourcen

Ändern Sie den Cassandra-Knotenpool so, dass er über ausreichende CPU- und Speicherressourcen verfügt. Weitere Informationen finden Sie unter Größe eines Knotenpools anpassen.

Kein nichtflüchtiges Volume erstellt

Wird ein Problem mit einem nichtflüchtigen Volume festgestellt, so beschreiben Sie den PVC (PersistentVolumeClaim), um festzustellen, warum er nicht erstellt wird:

1. Listen Sie die PVCs im Cluster auf:

   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. Beschreiben Sie den PVC für den Pod, der fehlschlägt. Mit dem folgenden Befehl wird beispielsweise der PVC beschrieben, der an den Pod apigee-cassandra-default-0 gebunden ist:

   kubectl 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

   Beachten Sie, dass in diesem Beispiel die StorageClass namens apigee-sc nicht vorhanden ist. Erstellen Sie zum Beheben dieses Problems die fehlende StorageClass im Cluster, wie unter Standard-StorageClass ändern beschrieben.

Weitere Informationen finden Sie unter Pods debuggen.

Cassandra-Pods verbleiben im CrashLoopBackoff-Status

Symptom

Während des Starts verbleiben die Cassandra-Pods im Status CrashLoopBackoff.

Fehlermeldung

Wenn Sie den Pod-Status mit kubectl aufrufen, sehen Sie, dass sich ein oder mehrere Cassandra-Pods im Status CrashLoopBackoff befinden. Dieser Status gibt an, dass Kubernetes den Pod nicht erstellen kann. Beispiel:

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
...

Mögliche Ursachen

Ein Pod, der im Status CrashLoopBackoff verbleibt, kann mehrere Ursachen haben. Beispiel:

Ursache	Beschreibung
Rechenzentrum unterscheidet sich vom vorherigen Rechenzentrum	Dieser Fehler weist darauf hin, dass der Cassandra-Pod ein nichtflüchtiges Volume mit Daten aus einem vorherigen Cluster hat und die neuen Pods dem alten Cluster nicht mehr beitreten können. Dies geschieht in der Regel, wenn veraltete nichtflüchtige Volumes vom vorherigen Cassandra-Cluster auf demselben Kubernetes-Knoten erhalten bleiben. Dieses Problem kann auftreten, wenn Sie Cassandra im Cluster löschen und neu erstellen.
Truststore-Verzeichnis nicht gefunden	Dieser Fehler zeigt an, dass der Cassandra-Pod keine TLS-Verbindung herstellen kann. Dies ist in der Regel der Fall, wenn die bereitgestellten Schlüssel und Zertifikate ungültig, fehlen oder andere Probleme sind.

Diagnose

Prüfen Sie das Cassandra-Fehlerlog, um die Ursache des Problems zu ermitteln.

1. Listen Sie die Pods auf, um die ID des Cassandra-Pods zu erhalten, der fehlschlägt:

   kubectl get pods -n namespace

2. Prüfen Sie das Log des fehlerhaften Pods:

   kubectl logs pod_id -n namespace

Lösung

Suchen Sie die folgenden Hinweise im Log des Pods:

Rechenzentrum unterscheidet sich vom vorherigen Rechenzentrum

Wenn dieser Logeintrag angezeigt wird:

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

• Prüfen Sie, ob der Cluster veraltete oder alte PVCs enthält und löschen Sie diese.
• Wenn es sich um eine Neuinstallation handelt, löschen Sie alle PVCs und wiederholen die Einrichtung. Beispiel:

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

Truststore-Verzeichnis nicht gefunden

Wenn dieser Logeintrag angezeigt wird:

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

Prüfen Sie den Schlüssel und die Zertifikate korrekt und gültig sind, sofern sie in der Überschreibungsdatei angegeben sind. Beispiel:

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

Knotenfehler

Symptom

Nach dem Start verbleiben die Cassandra-Pods im Status "Ausstehend". Dieses Problem kann auf einen Knotenfehler hindeuten.

Diagnose

1. Ermitteln Sie, welche Cassandra-Pods nicht ausgeführt werden:

   $ kubectl get pods -n your_namespace
       NAME                  READY   STATUS    RESTARTS   AGE
       cassandra-default-0   0/1     Pending   0          13s
       cassandra-default-1   1/1     Running   0          8d
       cassandra-default-2   1/1     Running   0          8d

2. Prüfen Sie die Worker-Knoten: Wenn einer den Status NotReady hat, ist dies der Knoten, der fehlgeschlagen ist:

   kubectl get nodes -n your_namespace
   NAME                                              STATUS   ROLES    AGE   VERSION            INTERNAL-IP
   gke-hybrid-cluster-apigee-data-178811f1-lv5j      Ready    <none>   34d   v1.21.5-gke.1302   10.138.15.198
   gke-hybrid-cluster-apigee-data-d63b8b8d-n41g      NotReady <none>   34d   v1.21.5-gke.1302   10.138.15.200
   gke-hybrid-cluster-apigee-data-ec752c0b-b1cr      Ready    <none>   34d   v1.21.5-gke.1302   10.138.15.199
   gke-hybrid-cluster-apigee-runtime-ba502ff4-57mq   Ready    <none>   34d   v1.21.5-gke.1302   10.138.15.204
   gke-hybrid-cluster-apigee-runtime-ba502ff4-hwkb   Ready    <none>   34d   v1.21.5-gke.1302   10.138.15.203
   gke-hybrid-cluster-apigee-runtime-bfa558e0-08vw   Ready    <none>   34d   v1.21.5-gke.1302   10.138.15.201
   gke-hybrid-cluster-apigee-runtime-bfa558e0-xvsc   Ready    <none>   34d   v1.21.5-gke.1302   10.138.15.202
   gke-hybrid-cluster-apigee-runtime-d12de7df-693w   Ready    <none>   34d   v1.21.5-gke.1302   10.138.15.241
   gke-hybrid-cluster-apigee-runtime-d12de7df-fn0w   Ready    <none>   34d   v1.21.5-gke.1302   10.138.15.206

Lösung

1. Entfernen Sie den inaktiven Cassandra-Pod aus dem Cluster.

   $ kubectl exec -it apigee-cassandra-default-0 -- nodetool status
   $ kubectl exec -it apigee-cassandra-default-0 -- nodetool removenode deadnode_hostID

2. Entfernen Sie den VolumeClaim vom angestorbenen Knoten, um den Cassandra-Pod daran zu hindern, aufgrund der Affinität an den Dead-Knoten zu geraten:

   kubectl get pvc -n your_namespace
   kubectl delete pvc volumeClaim_name -n your_namespace

3. Aktualisieren Sie die Volume-Vorlage und erstellen Sie PersistentVolume für den neu hinzugefügten Knoten. Hier ein Beispiel für eine Volume-Vorlage:

   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": ["gke-hybrid-cluster-apigee-data-d63b8b8d-n41g"]

4. Ersetzen Sie die Werte durch den neuen Hostnamen bzw. die neue IP-Adresse und wenden Sie die Vorlage an:

   kubectl apply -f volume-template.yaml

Client-Container zur Fehlerbehebung erstellen

In diesem Abschnitt wird erläutert, wie Sie einen Client-Container erstellen, über den Sie auf Cassandra-Debugging-Dienstprogramme wie cqlsh zugreifen können. Diese Dienstprogramme können zum Abfragen von Cassandra-Tabellen und für Fehlerbehebungszwecke nützlich sein.

Client-Container erstellen

So erstellen Sie den Client-Container:

1. Der Container verwendet das TLS-Zertifikat aus dem Pod apigee-cassandra-user-setup. Der erste Schritt besteht darin, diesen Zertifikatsnamen abzurufen:

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

   Dieser Befehl gibt den Zertifikatsnamen zurück. Beispiel: apigee-cassandra-user-setup-rg-hybrid-b7d3b9c-tls.

2. Öffnen Sie eine neue Datei und fügen Sie folgende Pod-Spezifikation in diese ein:

   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.6.9"
       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. Speichern Sie die Datei mit der Erweiterung .yaml. Beispiel: my-spec.yaml
4. Wenden Sie die Spezifikation auf Ihren Cluster an:

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

5. Melden Sie sich beim Container an:

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

6. Stellen Sie mit dem folgenden Befehl eine Verbindung zur Cassandra-Schnittstelle cqlsh her. Geben Sie den Befehl genau so ein:

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

Client-Pod löschen

Verwenden Sie diesen Befehl, um den Cassandra-Client-Pod zu löschen:

kubectl delete pods -n apigee cassandra-client

Weitere Informationen

Einführung in Apigee- und Apigee Hybrid-Playbooks