גיבוי ושחזור של אשכולות באמצעות bmctl

במאמר הזה מוסבר איך להשתמש ב-bmctl כדי לגבות ולשחזר אשכולות שנוצרו באמצעות תוכנת Distributed Cloud רק עבור bare metal. ההוראות האלה רלוונטיות לכל סוגי האשכולות.

Cloud Customer Care.

מה מגובה ומה לא מגובה

תהליך הגיבוי והשחזור של bmctl פועל בשכבת מישור הבקרה של Kubernetes, והוא שונה מפתרונות גיבוי אחרים. פתרונות גיבוי שאינם מבוססים על Kubernetes מתעדים את נתוני עומס העבודה, את האחסון הקבוע ואת מערכות ההפעלה של המארחים במכונות הפיזיות. תהליך הגיבוי והשחזור של bmctl משחזר את אשכולות Kubernetes בלי לגבות את הרכיבים האחרים האלה.

מצב מישור הבקרה (מגובה על ידי תהליך הגיבוי של bmctl)

‫bmctl מגבה את האובייקטים הבאים:

  • מאגר etcd. כל המשאבים של Kubernetes והאובייקטים המותאמים אישית שמגדירים את התצורה של האשכול ואת המצב שנבחר (לדוגמה, מפרטים של פודים, פריסות, ConfigMaps וסודות).
  • אישורי PKI. אישורים שמשמשים לתקשורת מאובטחת בתוך האשכול.
  • קובצי תצורה ומניפסטים של צמתים. הגדרות שקשורות לצמתי האשכול.

אחסון של עומס העבודה ושל זמן הריצה של המכונה הווירטואלית (לא מגובה בתהליך הגיבוי של bmctl)

‫bmctl לא מגבה את הנתונים הבאים:

  • מצב הפעולה של ה-pod והקונטיינר בזמן אמת. ‫bmctl לא שומר תהליכים פעילים ונתוני אפליקציות בזיכרון. אחרי שחזור, Kubernetes מפעיל מחדש את ה-pods מהמפרטים של etcd. כל מצב בזיכרון שלא נשמר יאבד.
  • אחסון מתמיד של נפח. ‫bmctl לא מגבה נתונים שמאוחסנים בכרכים קבועים, בכרכים שנוצרו על ידי מנהל הקצאות נפח אחסון מקומי (LVP) או במנהלי התקנים של אחסון חיצוני.
  • דיסקים של מכונות וירטואליות. ‫bmctl לא מגבה את התוכן של הכונן הקשיח הווירטואלי של המכונה הווירטואלית, כמו מסדי נתונים, קבצים או מצב מערכת ההפעלה בתוך המכונה הווירטואלית.

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

להריץ סוכני גיבוי בתוך מערכת ההפעלה של האורח במכונות וירטואליות של VM Runtime או לפרוס כלי גיבוי מקוריים של אפליקציות בעומסי עבודה של Kubernetes.

מערכות הפעלה של מארחים פיזיים (לא נתמכות)

מערכות הפעלה פיזיות של Linux בצמתים של Google Distributed Cloud נחשבות לתשתית חד-פעמית. ארכיטקטורת הרשת של Kubernetes לא תומכת בשחזור תמונות של מערכת הפעלה ברמת המארח. לכן, Google לא תומכת בהתקנה של סוכני גיבוי ברמת המארח של צד שלישי ישירות במערכת ההפעלה של המארח, או בשחזור של צמתים פיזיים מגיבויי תמונות ברמת מערכת ההפעלה או מצילומי מצב של דיסקים.

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

סוכני גיבוי רבים מתקינים מודולים קנייניים של ליבת המערכת או מנהלי התקנים של מסננים ברמת הבלוק כדי לעקוב אחרי שינויים ולנעול בלוקים של דיסקים מקומיים במהלך פעולות של צילום מצב. פעולות כאלה עלולות לגרום לבעיות הבאות:

  • מסד הנתונים etcd לא יכול להוסיף ליומני ה-write-ahead שלו, פעימות הלב של הצומת מסתיימות לפני הזמן, קונצנזוס Raft נכשל ואשכולות הופכים ללא יציבים.
  • מנהלי התקנים של ליבה של צד שלישי שלא נתמכים מתנגשים עם שגרות ליבה ברמה נמוכה ועם זמן הריצה של הקונטיינר, וגורמים לכך ששדרוגי האשכול נכשלים.
  • שחזור של צומת פיזי מגיבוי של אימג' או מקובץ snapshot של דיסק מפר את פרוטוקול ההסכמה של Raft. מסד הנתונים etcd יוצא מסנכרון עם היומנים בצמתים של מישור הבקרה, ומתרחשת פגיעה חמורה במצב האשכול.
  • צמתי העובדים יוצאים מסינכרון עם מקור האמת של שרת ה-API, כתובות ה-IP של Dataplane V2 ‏ (Cilium) מתנגשות והתנועה נחסמת.

כדי לשחזר צומת פיזי שבו הייתה תקלה במערכת ההפעלה או בחומרה, אל תשחזרו קובץ אימג' של מערכת ההפעלה. במקום זאת, צריך להסיר את הצומת מהאשכול, להתקין מחדש מערכת הפעלה בסיסית נקייה ולהוסיף מחדש את הצומת למאגר הצמתים. הוראות מפורטות לשחזור מופיעות במאמר בנושא איפוס של צומת שנכשל.

אם אתם צריכים עזרה נוספת, תוכלו לפנות אל Cloud Customer Care. אפשר גם לעיין במאמר קבלת תמיכה לקבלת מידע נוסף על מקורות מידע לתמיכה, כולל המקורות הבאים:
  • דרישות לפתיחת בקשת תמיכה
  • כלים שיעזרו לכם לפתור בעיות, כמו הגדרת הסביבה, היומנים והמדדים.
  • רכיבים נתמכים.

גיבוי של מקבץ

הפקודה bmctl backup cluster אורזת את נתוני ה-etcd של האשכול ואת אישורי ה-PKI בקובץ tar. מסד הנתונים etcd הוא מאגר הנתונים המרכזי של כל נתוני האשכול, והוא מכיל את כל אובייקטי Kubernetes והמשאבים המותאמים אישית שנדרשים לניהול מצב האשכול. אישורי ה-PKI מאמתים באמצעות TLS. הגיבוי של הנתונים מתבצע ממישור הבקרה של האשכול או מאחד ממישורי הבקרה של פריסת זמינות גבוהה (HA).

קובץ ה-tar של הגיבוי מכיל פרטי כניסה רגישים, כולל מפתחות של חשבון השירות ומפתח ה-SSH. אחסון קובצי הגיבוי במיקום מאובטח. כדי למנוע חשיפה לא מכוונת של קבצים, תהליך הגיבוי של Google Distributed Cloud משתמש רק בקבצים בזיכרון.

כדאי לגבות את האשכולות באופן קבוע כדי לוודא שנתוני התמונות המיידיות עדכניים יחסית. משנים את קצב הגיבויים כך שישקף את התדירות של שינויים משמעותיים באשכולות.

הגרסה של bmctl שבה אתם משתמשים לגיבוי אשכול חייבת להיות זהה לגרסה של האשכול המנהל.

אם התקנתם את Node Agent באשכולות, צריך שיהיה נפח אחסון פנוי של 12GB בספרייה /tmp בצומת האדמין ובכל צומתי היעד. אם אתם לא יכולים לשנות את הגודל של ספריית /tmp עבור צמתי היעד, כדאי לעיין במאמר שינוי קיבולת האחסון המקומי לצמתי יעד. אם אתם לא מצליחים לשנות את הגודל של ספריית /tmp בצומת האדמין, תוכלו לקרוא את המאמר שינוי קיבולת האחסון המקומי בצומת אדמין.

כדי לגבות אשכול:

  1. מוודאים שהאשכול פועל בצורה תקינה, עם פרטי כניסה תקינים וקישוריות SSH לכל הצמתים.

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

    כדי לבדוק את האשכול, משתמשים בפקודה הבאה:

    bmctl check cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫CLUSTER_NAME: שם האשכול שמתכננים לגבות.
    • ‫ADMIN_KUBECONFIG: הנתיב לקובץ kubeconfig של אשכול האדמין.

  2. מריצים את הפקודה הבאה כדי לוודא שאשכול היעד לא נמצא במצב של סנכרון:

    kubectl describe cluster CLUSTER_NAME -n CLUSTER_NAMESPACE --kubeconfig ADMIN_KUBECONFIG

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫CLUSTER_NAME: שם האשכול שרוצים לגבות.
    • ‫CLUSTER_NAMESPACE: מרחב השמות של האשכול. כברירת מחדל, מרחבי השמות של האשכולות ב-Google Distributed Cloud הם השם של האשכול עם הקידומת cluster-. לדוגמה, אם שם האשכול הוא test, שם מרחב השמות יהיה cluster-test.
    • ‫ADMIN_KUBECONFIG: הנתיב לקובץ kubeconfig של אשכול האדמין.

  3. בודקים את הקטע Status בפלט של הפקודה כדי לראות אם Conditions הוא מסוג Reconciling.

    כפי שמוצג בדוגמה הבאה, סטטוס של False עבור Conditions אלה מציין שהאשכול יציב ומוכן לגיבוי.

    ...
Status:
  ...
  Cluster State:  Running
  ...
  Control Plane Node Pool Status:
    ...
    Conditions:
      Last Transition Time:  2023-11-03T16:37:15Z
      Observed Generation:   1
      Reason:                ReconciliationCompleted
      Status:                False
      Type:                  Reconciling
  ...

  4. מריצים את הפקודה הבאה כדי לגבות את האשכול:

    bmctl backup cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫CLUSTER_NAME: שם האשכול שרוצים לגבות.
    • ‫ADMIN_KUBECONFIG: הנתיב לקובץ kubeconfig של אשכול האדמין.

    כברירת מחדל, קובץ ה-tar של הגיבוי נשמר בספריית Workspace ‏(bmctl-workspace, כברירת מחדל) בתחנת העבודה של האדמין. קובץ ה-tar נקרא CLUSTER_NAME_backup_TIMESTAMP.tar.gz, כאשר CLUSTER_NAME הוא שם האשכול שמגבים ו-TIMESTAMP הוא התאריך והשעה שבהם בוצע הגיבוי. לדוגמה, אם שם האשכול הוא testuser, קובץ הגיבוי נקרא testuser_backup_2006-01-02T150405Z0700.tar.gz.

    כדי לציין שם ומיקום אחרים לקובץ הגיבוי, משתמשים בדגל --backup-file.

התוקף של קובץ הגיבוי פג אחרי שנה, ותהליך השחזור של האשכול לא פועל עם קובצי גיבוי שתוקפם פג.

שחזור אוסף

שחזור אשכול מגיבוי הוא מוצא אחרון, וצריך להשתמש בו רק אם האשכול נכשל בצורה קריטית ואין דרך אחרת להחזיר אותו לשירות. לדוגמה, נתוני etcd פגומים או ש-Pod של etcd נמצא בלולאת קריסה.

קובץ ה-tar של הגיבוי מכיל פרטי כניסה רגישים, כולל מפתחות של חשבון השירות ומפתח ה-SSH. כדי למנוע חשיפה לא מכוונת של קבצים, בתהליך השחזור של Google Distributed Cloud נעשה שימוש רק בקבצים בזיכרון.

הגרסה של bmctl שבה משתמשים כדי לשחזר אשכול חייבת להיות זהה לגרסה של האשכול המנהל.

כדי לשחזר אשכול:

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

  2. מוודאים שחיבור ה-SSH בין הצמתים פועל עם מפתחות ה-SSH שבהם נעשה שימוש בזמן הגיבוי.

    מפתחות ה-SSH האלה מוחזרים כחלק מתהליך השחזור.

  3. מוודאים שמפתחות חשבונות השירות שבהם השתמשתם בזמן הגיבוי עדיין פעילים.

    מפתחות חשבון השירות האלה מוחזרים לאשכול המשוחזר.

  4. כדי לשחזר אשכול אדמין, אשכול היברידי או אשכול עצמאי, מריצים את הפקודה הבאה:

    bmctl restore cluster -c CLUSTER_NAME --backup-file BACKUP_FILE

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫CLUSTER_NAME: שם האשכול שמשחזרים.
    • ‫BACKUP_FILE: הנתיב והשם של קובץ הגיבוי שבו אתם משתמשים.

  5. כדי לשחזר אשכול משתמשים, מריצים את הפקודה הבאה:

    bmctl restore cluster -c CLUSTER_NAME --backup-file BACKUP_FILE \
    --kubeconfig ADMIN_KUBECONFIG

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫CLUSTER_NAME: שם האשכול שמשחזרים.
    • ‫BACKUP_FILE: הנתיב והשם של קובץ הגיבוי שבו אתם משתמשים.
    • ‫ADMIN_KUBECONFIG: הנתיב לקובץ kubeconfig של אשכול האדמין.

בסיום תהליך השחזור, נוצר קובץ kubeconfig חדש עבור האשכול ששוחזר.

בסיום השחזור, פועלים לפי השלבים הבאים כדי לוודא שהוא בוצע בהצלחה:

  1. מריצים את הפקודות הבאות כדי לוודא שהצומת מוכן ושתרמילי המערכת פועלים עם קובץ ה-kubeconfig שנוצר:

    יש שני סוגים של pods של etcd:

    • ‫etcd-HOST_NAME, שמתאים ל-Pod הראשי etcd
    • ‫etcd-events-HOST_NAME, שמתאים ל-Pod‏ etcd-events
    kubectl get pods -n kube-system --kubeconfig GENERATED_KUBECONFIG
kubectl get nodes --kubeconfig GENERATED_KUBECONFIG

  2. כדי לוודא שה-etcd תקין, מריצים את הפקודה הבאה לכל פוד etcd:

    kubectl exec ETCD_POD_NAME -n kube-system \
    --kubeconfig GENERATED_KUBECONFIG \
    -- /bin/sh -c 'ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
    --cacert=/etc/kubernetes/pki/etcd/ca.crt --key=/etc/kubernetes/pki/etcd/peer.key \
    --cert=/etc/kubernetes/pki/etcd/peer.crt endpoint health'

    אם חבר etcd תקין, התגובה אמורה להיראות כך:

    https://127.0.0.1:2379 is healthy: successfully committed proposal: took = 11.514177ms

  3. לכל Pod‏ etcd-events, מריצים את הפקודה הבאה כדי לוודא את התקינות של etcd-events:

    kubectl exec ETCD_EVENTS_POD_NAME -n kube-system \
    --kubeconfig GENERATED_KUBECONFIG \
    -- /bin/sh -c 'ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2382 \
    --cacert=/etc/kubernetes/pki/etcd/ca.crt --key=/etc/kubernetes/pki/etcd/peer.key \
    --cert=/etc/kubernetes/pki/etcd/peer.crt endpoint health'

    אם חבר etcd-events תקין, התגובה אמורה להיראות כך:

    https://127.0.0.1:2382 is healthy: successfully committed proposal: took = 14.308148ms

פתרון בעיות

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

לקבלת עזרה נוספת, אפשר לפנות אל התמיכה של Google.

נפח הזיכרון עומד להיגמר במהלך גיבוי או שחזור

יכול להיות שתקבלו הודעות שגיאה במהלך תהליך הגיבוי או השחזור, שלא ברור מהן מה הבעיה או מה צריך לעשות. אם תחנת העבודה שבה מריצים את הפקודה bmctl לא כוללת הרבה זיכרון RAM, יכול להיות שלא יהיה מספיק זיכרון כדי לבצע את תהליך הגיבוי או השחזור.

ב-Google Distributed Cloud מגרסה 1.13 ואילך אפשר להשתמש בפרמטר --use-disk בפקודת הגיבוי. כדי לשמור על הרשאות הקובץ, הפרמטר הזה משנה את הרשאות הקבצים, ולכן המשתמש שמריץ את הפקודה צריך להיות משתמש root (או להשתמש ב-sudo).

חסרות הרשאות לקבצים במהלך השחזור

אחרי משימת שחזור מוצלחת, יכול להיות שמחיקת bootstrap תיכשל עם הודעת שגיאה שדומה לדוגמה הבאה:

  Error: failed to restore node config files: sftp: "Failure" (SSH_FX_FAILURE)

השגיאה הזו יכולה להצביע על כך שאין הרשאת כתיבה לחלק מהספריות שנדרשות לשחזור.

ב-Google Distributed Cloud בגרסה 1.14 ואילך, הודעות השגיאה ברורות יותר לגבי הספריות שצריכות להיות בעלות הרשאת כתיבה. צריך לוודא שיש הרשאות כתיבה לספריות שדווחו, ולעדכן את ההרשאות בספריות לפי הצורך.

רענון של מפתח SSH אחרי גיבוי גורם לשיבוש בתהליך השחזור

יכול להיות שפעולות שקשורות ל-SSH במהלך תהליך השחזור ייכשלו אם מפתח ה-SSH יתעדכן אחרי הגיבוי. במקרה כזה, מפתח ה-SSH החדש לא יהיה תקף לתהליך השחזור.

כדי לפתור את הבעיה, אפשר להוסיף באופן זמני את מפתח ה-SSH המקורי בחזרה, ואז לבצע את השחזור. אחרי שתהליך השחזור יסתיים, תוכלו לסובב את מפתח ה-SSH.

אי אפשר ליצור גיבוי לצומת Node Agent

אם אתם משתמשים ב-Node Agent ומקבלים שגיאה שמודיעה שהגיבוי נכשל ביצירת קובץ ארכיון, כמו השגיאה הבאה:

  I0508 15:29:36.831790  657351 backup_cluster.go:255] Retrying backup node: 128.187.102.133, due to error: failed receive chunk data: rpc error: code = Unknown desc = archiver.CreateArchiveWithList
  failed: failed to create archive file: failed to copy data from file: var/lib/etcd-events/member/snap/db, file size: 26136576, copy bytes: 12478464,
  error: write /tmp/uploadFileTemp1561164777: no space left on device

בודקים שיש 12 GB של מקום פנוי בספרייה /tmp בצומת האדמין ובכל הצמתים של היעד. אם אי אפשר לשנות את הגודל של ספריית /tmp עבור צמתי היעד, אפשר לעיין במאמר הגדלת קיבולת האחסון המקומי לגיבויים של Node Agent.

אחרי שמוודאים שיש 12 GB של מקום פנוי בספרייה /tmp בצומת הניהול ובכל צומתי היעד, מנסים שוב לגבות.