מדריך לפתרון בעיות ב-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 ממתין ליצירת נפח אחסון מתמיד.
חסר מנהל התקן CSI של Amazon EBS מנהל ההתקן הנדרש של Amazon EBS CSI לא מותקן.

אבחון

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

kubectl -n namespace describe pods pod_name

לדוגמה: 

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

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

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

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

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

חסר מנהל התקן CSI של Amazon EBS

אם מופעלת גרסה היברידית באשכול EKS, צריך לוודא שאשכול EKS משתמש במנהל התקן של ממשק אחסון הקונטיינרים (CSI) של Amazon EBS. פרטים נוספים זמינים במאמר שאלות נפוצות בנושא מיגרציה של Amazon EBS CSI.

תאי 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, כמו cqlsh. הכלים האלה מאפשרים לבצע שאילתות בטבלאות של Cassandra, והם יכולים להיות שימושיים למטרות ניפוי באגים.

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

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

  1. הקונטיינר משתמש באישור ה-TLS מ-pod‏ apigee-cassandra-user-setup. השלב הראשון הוא לאחזר את שם האישור הזה: 
    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 של הלקוח

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

kubectl delete pods -n apigee cassandra-client

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

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