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

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

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

תהליך הגיבוי והשחזור של bmctl לא כולל נפחים מתמשכים. כרכים שנוצרו על ידי מנהל הקצאות (provisioner) הכרכים המקומי (LVP) לא ישתנו.

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

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

גיבוי אשכול

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

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

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

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

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

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

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

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

שחזור אשכול

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

הערה: כדי לשפר את הביצועים של האשכול, Google Distributed Cloud משתמש במופע etcd נפרד לאחסון אובייקטים של אירועים. לאובייקטים האלה של אירועים יש אורך חיים (TTL) של שעה אחת. פעולת השחזור של האשכול יוצרת מופע חדש וריק של etcd-events, ולכן מאבדים את אובייקטי האירועים הקיימים. עם זאת, אובדן של אובייקטים מסוג Event לא משפיע על פעולת האשכול. צריך להתייחס לאירועים רק כאל נתונים משלימים, שמוצגים כמיטב המאמץ ומספקים מידע.

קובץ ה-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 שנוצר:

   יש שני סוגים של פודים של etcd:

   • ‫etcd-HOST_NAME, שמתאים לקפסולה הראשית 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.

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

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

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