מדריך לפתרון בעיות ב-Cassandra

במאמר הזה מוסבר איך לפתור בעיות במאגר הנתונים Cassandra. ‫Cassandra הוא מאגר נתונים קבוע שפועל ברכיב cassandra של ארכיטקטורת זמן הריצה ההיברידית. אפשר גם לעיין בסקירה כללית של הגדרת שירות בזמן ריצה.

תאי Cassandra תקועים במצב Pending

תיאור הבעיה

בזמן ההפעלה, ה-pods של Cassandra נשארים במצב Pending.

הודעת השגיאה

כשמשתמשים בפקודה kubectl כדי להציג את מצבי ה-pod, רואים שאחד או יותר מ-Cassandra pods תקועים במצב 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.
לא נוצר נפח ה-pod ממתין ליצירת נפח אחסון מתמיד.

אבחון

משתמשים ב-kubectl כדי לתאר את ה-pod ולקבוע את מקור השגיאה. לדוגמה:

kubectl -n namespace describe pods pod_name

לדוגמה: 

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

יכול להיות שיוצגו בתוצאה אחת מהבעיות האפשריות הבאות:

  • אם הבעיה היא משאבים לא מספיקים, תוצג הודעת אזהרה שמציינת שאין מספיק מעבד או זיכרון.
  • אם בהודעת השגיאה מצוין שה-pod כולל PersistentVolumeClaims (PVC)‎ לא מאוגדים מיידיים, זה אומר שה-pod לא יכול ליצור Persistent volume משלו.

רזולוציה

אין מספיק משאבים

משנים את מאגר הצמתים של 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. מתארים את ה-PVC של הפוד שנכשל. לדוגמה, הפקודה הבאה מתארת את ה-PVC שקשור לפוד 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

    שימו לב שבדוגמה הזו, StorageClass בשם apigee-sc לא קיים. כדי לפתור את הבעיה, צריך ליצור את StorageClass החסר באשכול, כמו שמוסבר במאמר שינוי ברירת המחדל של StorageClass.

אפשר לעיין גם במאמר ניפוי באגים ב-Pods.

תאי Cassandra תקועים במצב CrashLoopBackoff

תיאור הבעיה

במהלך ההפעלה, ה-pods של Cassandra נשארים במצב CrashLoopBackoff.

הודעת השגיאה

כשמשתמשים בפקודה kubectl כדי להציג את מצבי ה-pod, רואים שאחד או יותר מ-Cassandra pods נמצאים במצב 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 יש נפח אחסון קבוע עם נתונים מקלאסטר קודם, וה-pods החדשים לא יכולים להצטרף לקלאסטר הישן. זה קורה בדרך כלל כשנפחי אחסון מתמיד לא עדכניים נשארים מהאשכול הקודם של Cassandra באותו צומת Kubernetes. הבעיה הזו יכולה לקרות אם מוחקים את Cassandra באשכול ויוצרים אותו מחדש.
לא נמצאה ספריית Truststore השגיאה הזו מציינת שפוד Cassandra לא מצליח ליצור חיבור TLS. לרוב זה קורה כשהמפתחות והאישורים שסופקו לא תקפים, חסרים או שיש להם בעיות אחרות.

אבחון

כדי לזהות את הגורם לבעיה, צריך לבדוק את יומן השגיאות של Cassandra.

  1. מציגים את רשימת ה-Pods כדי לקבל את המזהה של ה-Pod של Cassandra שנכשל: 
    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

לא נמצאה ספריית Truststore

אם רואים את הודעת היומן הזו: 

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

כשל בצומת

תיאור הבעיה

כשמפעילים את Cassandra, ה-pods נשארים במצב Pending. הבעיה הזו יכולה להעיד על כשל בבסיס הצומת.

אבחון

  1. בודקים אילו פודים של Cassandra לא פועלים: 
    $ 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. בודקים את צמתי העובדים. אם אחד מהם במצב 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

רזולוציה

  1. מסירים את ה-pod של Cassandra שהפסיק לפעול מהאשכול. 
    $ kubectl exec -it apigee-cassandra-default-0 -- nodetool status
$ kubectl exec -it apigee-cassandra-default-0 -- nodetool removenode deadnode_hostID
  2. מסירים את VolumeClaim מהצומת המת כדי למנוע מ-Cassandra pod לנסות להפעיל את הצומת המת בגלל הקרבה: 
    kubectl get pvc -n your_namespace
kubectl delete pvc volumeClaim_name -n your_namespace
  3. מעדכנים את תבנית עוצמת הקול ויוצרים 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"]
  4. מחליפים את הערכים בשם המארח או בכתובת ה-IP החדשים ומחילים את התבנית: 
    kubectl apply -f volume-template.yaml

יצירת קונטיינר בצד הלקוח לצורך ניפוי באגים

בקטע הזה מוסבר איך ליצור קונטיינר לקוח שממנו אפשר לגשת אל כלי ניפוי הבאגים של Cassandra, כמו cqlsh. הכלים האלה מאפשרים לבצע שאילתות בטבלאות של Cassandra, והם יכולים להיות שימושיים למטרות ניפוי באגים.

יצירת מאגר תגים בצד הלקוח

כדי ליצור את מאגר התגים של הלקוח:

  1. הקונטיינר משתמש באישור ה-TLS מ-pod‏ apigee-cassandra-user-setup. השלב הראשון הוא לאחזר את שם האישור הזה: 
    kubectl get secrets -n apigee |grep "kubernetes.io/tls"|grep apigee-cassandra-user-setup|awk '{print $1}'

    הפקודה הזו מחזירה את שם האישור. לדוגמה: apigee-cassandra-user-setup-rg-hybrid-b7d3b9c-tls.

  2. לאחר מכן, מאחזרים את שם הסוד של מאגר הנתונים: 
    kubectl get secrets -n apigee | grep "datastore.*-creds" | awk '{print $1}'
  3. פותחים קובץ חדש ומדביקים בו את מפרט ה-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.5.10"
    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: default-datastore-creds  # The datastore secret name fetched previously.
    - name: APIGEE_DML_PASSWORD
      valueFrom:
        secretKeyRef:
          key: dml.password
          name: default-datastore-creds  # The datastore secret name fetched previously.
    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
  4. שומרים את הקובץ עם הסיומת .yaml. לדוגמה: my-spec.yaml.
  5. מחילים את המפרט על האשכול: 
    kubectl apply -f your-spec-file.yaml -n apigee
  6. מתחברים למאגר: 
    kubectl exec -n apigee cassandra-client -it -- bash
  7. מתחברים לממשק של Cassandra cqlsh באמצעות הפקודה הבאה. מזינים את הפקודה בדיוק כמו שהיא מוצגת: 
    cqlsh ${CASSANDRA_SEEDS} -u ${APIGEE_DML_USER} -p ${APIGEE_DML_PASSWORD} --ssl

מחיקת ה-pod של הלקוח

משתמשים בפקודה הזו כדי למחוק את ה-pod של לקוח Cassandra: 

kubectl delete pods -n apigee cassandra-client

מקורות מידע נוספים

מידע נוסף זמין במאמר מבוא ל-Apigee ולמדריכים בנושא Apigee Hybrid.