Panduan pemecahan masalah Cassandra

Topik ini membahas langkah-langkah yang dapat Anda lakukan untuk memecahkan dan memperbaiki masalah terkait datastore Cassandra. Cassandra adalah datastore persisten yang berjalan di komponen cassandra arsitektur runtime hybrid. Lihat juga Ringkasan konfigurasi layanan runtime.

Pod Cassandra terjebak dalam status Tertunda

Gejala

Saat memulai, pod Cassandra tetap dalam status Tertunda.

Pesan error

Saat menggunakan kubectl untuk melihat status pod, Anda akan melihat bahwa satu atau beberapa pod Cassandra terjebak dalam status Pending. Status Pending menunjukkan bahwa Kubernetes tidak dapat menjadwalkan pod pada node: pod tidak dapat dibuat. Contoh:

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

Kemungkinan penyebab

Pod yang masih dalam status Menunggu Persetujuan dapat disebabkan oleh beberapa hal. Contoh:

Penyebab	Deskripsi
Resource tidak cukup	CPU atau memori yang tersedia tidak cukup untuk membuat pod.
Volume belum dibuat	Pod menunggu volume persisten dibuat.

Diagnosis

Gunakan kubectl untuk mendeskripsikan pod guna menentukan sumber error. Contoh:

kubectl -n namespace describe pods pod_name

Contoh:

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

Output mungkin menampilkan salah satu masalah yang mungkin terjadi berikut:

Jika masalahnya tidak mencukupi, Anda akan melihat pesan Peringatan yang menunjukkan CPU atau memori tidak mencukupi.
Jika pesan error menunjukkan bahwa pod memiliki PersistentVolumeClaims (PVC) langsung yang tidak terikat, artinya pod tidak dapat membuat Volume persistennya.

Resolusi

Resource tidak cukup

Mengubah kumpulan node Cassandra agar memiliki resource CPU dan memori yang memadai. Lihat Mengubah ukuran kumpulan node untuk mengetahui detailnya.

Volume persisten tidak dibuat

Jika Anda menentukan masalah volume persisten, jelaskan PersistentVolumeClaim (PVC) untuk menentukan alasan tidak dibuatnya masalah tersebut:

Cantumkan PVC di cluster:

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

Jelaskan PVC untuk pod yang gagal. Misalnya, perintah berikut menjelaskan PVC yang terikat dengan pod apigee-cassandra-default-0:

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

Perhatikan bahwa dalam contoh ini, StorageClass yang bernama apigee-sc tidak ada. Untuk mengatasi masalah ini, buat StorageClass yang hilang di cluster, seperti yang dijelaskan dalam Mengubah StorageClass default.

Lihat juga Men-debug Pod.

Pod Cassandra terjebak dalam status CrashLoopBackoff

Gejala

Saat memulai, pod Cassandra tetap dalam status CrashLoopBackoff.

Pesan error

Saat menggunakan kubectl untuk melihat status pod, Anda akan melihat bahwa satu atau beberapa pod Cassandra berada dalam status CrashLoopBackoff. Status ini menunjukkan bahwa Kubernetes tidak dapat membuat pod. Contoh:

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

Kemungkinan penyebab

Pod yang berada dalam status CrashLoopBackoff dapat disebabkan oleh beberapa hal. Contoh:

Penyebab	Deskripsi
Pusat data berbeda dengan pusat data sebelumnya	Error ini menunjukkan bahwa pod Cassandra memiliki volume persisten yang memiliki data dari cluster sebelumnya, dan pod baru tidak dapat bergabung dengan cluster lama. Hal ini biasanya terjadi jika volume persisten yang sudah tidak berlaku tetap ada dari cluster Cassandra sebelumnya pada node Kubernetes yang sama. Masalah ini dapat terjadi jika Anda menghapus dan membuat ulang Cassandra dalam cluster.
Direktori truststore tidak ditemukan	Error ini menunjukkan bahwa pod Cassandra tidak dapat membuat koneksi TLS. Hal ini biasanya terjadi saat kunci dan sertifikat yang diberikan tidak valid, hilang, atau mengalami masalah lainnya.

Penyebab

Deskripsi

Pusat data berbeda dengan pusat data sebelumnya

Error ini menunjukkan bahwa pod Cassandra memiliki volume persisten yang memiliki data dari cluster sebelumnya, dan pod baru tidak dapat bergabung dengan cluster lama. Hal ini biasanya terjadi jika volume persisten yang sudah tidak berlaku tetap ada dari cluster Cassandra sebelumnya pada node Kubernetes yang sama. Masalah ini dapat terjadi jika Anda menghapus dan membuat ulang Cassandra dalam cluster.

Direktori truststore tidak ditemukan

Error ini menunjukkan bahwa pod Cassandra tidak dapat membuat koneksi TLS. Hal ini biasanya terjadi saat kunci dan sertifikat yang diberikan tidak valid, hilang, atau mengalami masalah lainnya.

Diagnosis

Periksa log error Casssandra untuk menentukan penyebab masalah.

Tampilkan daftar pod untuk mendapatkan ID pod Cassandra yang gagal:
```
kubectl get pods -n namespace
```
Periksa log pod yang gagal:
```
kubectl logs pod_id -n namespace
```

Resolusi

Cari petunjuk berikut di log pod:

Pusat data berbeda dengan pusat data sebelumnya

Jika Anda melihat pesan log ini:

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

Periksa apakah ada PVC yang sudah usang atau lama di cluster dan hapus.

Jika ini adalah penginstalan baru, hapus semua PVC dan coba penyiapan lagi. Contoh:

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

Direktori truststore tidak ditemukan

Jika Anda melihat pesan log ini:

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

Pastikan bahwa kunci dan sertifikat yang diberikan dalam file penggantian sudah benar dan valid. Misalnya:

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

Kegagalan node

Gejala

Saat memulai, pod Cassandra tetap dalam status Menunggu Persetujuan. Masalah ini dapat mengindikasikan adanya kegagalan node yang mendasarinya.

Diagnosis

Tentukan pod Cassandra mana yang tidak berjalan:

$ 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

Periksa node pekerja. Jika salah satunya berada dalam status NotReady, berarti node tersebut telah gagal:

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

Resolusi

Keluarkan pod Cassandra yang mati dari gugus.

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

Hapus VolumeClaim dari node yang mati untuk mencegah pod Cassandra mencoba muncul pada node yang mati karena afinitasnya:
```
kubectl get pvc -n your_namespace
kubectl delete pvc volumeClaim_name -n your_namespace
```

Update template volume dan buat PersistentVolume untuk node yang baru ditambahkan. Berikut adalah contoh template volume:

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"]

Ganti nilai dengan nama host/IP baru dan terapkan template:
```
kubectl apply -f volume-template.yaml
```