הסבר על ההשפעה של כשלים ב-Google Distributed Cloud

‫Google Distributed Cloud נועד להגביל את היקף התקלות ולתת עדיפות לפונקציונליות שקריטית להמשכיות עסקית. במסמך הזה מוסבר איך הפונקציונליות של האשכולות מושפעת כשיש כשל. המידע הזה יכול לעזור לכם לתת עדיפות לתחומים שבהם צריך לפתור בעיות.

הפונקציונליות המרכזית של Google Distributed Cloud כוללת את הקטגוריות הבאות:

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

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

מצבי כשל

הסוגים הבאים של כשלים יכולים להשפיע על הביצועים של אשכולות Google Distributed Cloud.

כשל במארח ESXi

בתרחיש הכשל הזה, מארח ESXi שמריץ מכונות וירטואליות (VM) שמארחות צמתי Kubernetes עלול להפסיק לפעול או להפוך למחולק ברשת.

הפעלת עומסי עבודה ניהול עומסי עבודה ניהול אשכולות משתמשים ניהול אשכולות אדמין
שיבוש שיבוש אפשרי ושחזור אוטומטי שיבוש אפשרי ושחזור אוטומטי שיבוש ושחזור אוטומטי שיבוש ושחזור אוטומטי
הסבר

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

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

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

כשל ב-VM

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

הפעלת עומסי עבודה ניהול עומסי עבודה ניהול אשכולות משתמשים ניהול אשכולות אדמין
שיבוש שיבוש אפשרי ושחזור אוטומטי שיבוש אפשרי ושחזור אוטומטי שיבוש ושחזור אוטומטי/ידני שיבוש ושחזור ידני
הסבר

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

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

 אם מכונה וירטואלית של מישור הבקרה באשכול משתמשים שאינו HA או יותר ממכונה וירטואלית אחת של מישור הבקרה באשכול משתמשים HA נכשלת, יש שיבוש. אם יש כשל במכונה הווירטואלית של מישור הבקרה או במכונות הווירטואליות של העובדים באשכול האדמין, תהיה הפרעה. אם המכונה הווירטואלית של מישור הבקרה באשכול האדמין נכשלת, יש שיבוש.
התאוששות המערכת משחזרת באופן אוטומטי את ה-VM שנכשל אם תיקון אוטומטי של הצומת מופעל באשכול המשתמש. המכונה הווירטואלית שנכשלה משוחזרת באופן אוטומטי אם תיקון אוטומטי של הצומת מופעל באשכול האדמין.

אם ההגדרה node auto-repair מופעלת באשכול האדמין, מכונת ה-VM של העובד שנכשלה באשכול האדמין משוחזרת אוטומטית.

כדי לשחזר את המכונה הווירטואלית של מישור הבקרה של אשכול הניהול, אפשר לעיין במאמר בנושא תיקון המכונה הווירטואלית של מישור הבקרה של אשכול הניהול.

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

כשל באחסון

בתרחיש הכשל הזה, התוכן בקובץ VMDK עלול להיות פגום בגלל כיבוי לא תקין של מכונה וירטואלית, או שכישלון במאגר נתונים עלול לגרום לאובדן של נתונים של etcd ושל PersistentVolumes (PVs).

כשל ב-etcd

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

אם מאגר הנתונים של etcd באשכול משתמשים שאינו HA או יותר מרפליקה אחת של etcd באשכול משתמשים HA נכשל, יש שיבוש.

אם הרפליקה של etcd באשכול אדמין נכשלת, יש שיבוש.

 אם הרפליקה של etcd באשכול אדמין נכשלת, יש שיבוש.
מניעה — ב-Google Distributed Cloud יש תהליך ידני לשחזור אחרי כשל. ב-Google Distributed Cloud יש תהליך ידני לשחזור מהכשל. ב-Google Distributed Cloud יש תהליך ידני לשחזור מהכשל.

כשל ב-PV של אפליקציית משתמש

הפעלת עומסי עבודה ניהול עומסי עבודה ניהול אשכולות משתמשים ניהול אשכולות אדמין
שיבוש יכול להיות שתהיה הפרעה ללא שיבושים ללא שיבושים ללא שיבושים
הסבר

עומסי העבודה שמשתמשים ב-PV שנכשל מושפעים.

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

 — — —

כשל במאזן העומסים

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

הפעלת עומסי עבודה ניהול עומסי עבודה ניהול אשכולות משתמשים ניהול אשכולות אדמין
שיבוש ושחזור ידני
הסבר

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

השיבוש בשירות עשוי להימשך עד 2 שניות כשמשתמשים ב-Seesaw, ו עד 300 שניות כשמשתמשים ב-F5.

משך השיבוש במעבר לגיבוי (failover) של MetalLB גדל ככל שמספר הצמתים של איזון העומסים גדל. אם יש פחות מ-5 צמתים, ההפרעה נמשכת עד 10 שניות.
התאוששות

מערכת Seesaw HA מזהה באופן אוטומטי את הכשל ועוברת לשימוש במופע הגיבוי.

ב-Google Distributed Cloud יש תהליך ידני לשחזור במקרה של כשל ב-Seesaw.

שחזור של אשכול פגום

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

שחזור אחרי כשלים במארח ESXi

‫Google Distributed Cloud מסתמך על vSphere HA כדי לספק שחזור מכשל של מארח ESXi. ‏vSphere HA יכול לעקוב באופן רציף אחרי מארחי ESXi ולהפעיל מחדש את המכונות הווירטואליות באופן אוטומטי במארחים אחרים לפי הצורך. השינוי הזה שקוף למשתמשי Google Distributed Cloud.

שחזור אחרי כשלים במכונות וירטואליות

כשלים ב-VM יכולים לכלול את הדברים הבאים:

  • מחיקה לא צפויה של מכונה וירטואלית.

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

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

  • השחתה של מערכת קבצים מסוג overlay ב-Docker.

  • אובדן של מכונת VM במישור הבקרה של האדמין בגלל כשל בשדרוג.

  • בעיות במערכת ההפעלה.

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

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

שחזור אחרי כשלים באחסון

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

המידע על מצב האשכול ועומסי העבודה של המשתמשים מאוחסן במקומות הבאים:

  • ‫etcd: לכל אשכול (אשכול אדמין ואשכול משתמשים) יש מסד נתונים של etcd שבו מאוחסן המצב (אובייקטים של Kubernetes) של האשכול.
  • ‫PersistentVolumes: משמש גם את רכיבי המערכת וגם את עומסי העבודה של המשתמשים.

שחזור מנתונים פגומים או אובדן נתונים ב-etcd

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

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

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

כדי שתוכלו לשחזר (למצב עדכני של האשכול) נתונים פגומים או אבודים מ-etcd, אתם צריכים לגבות את נתוני etcd אחרי כל פעולה במחזור החיים של האשכול (לדוגמה, יצירה, עדכון או שדרוג). כדי לגבות את נתוני etcd, אפשר לעיין במאמרים בנושא גיבוי של אשכול אדמין וגיבוי של אשכול משתמשים.

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

הכשל של פגם בנתונים או אובדן נתונים ב-etcd יכול לקרות בתרחישים הבאים:

  • צומת יחיד באשכול etcd עם שלושה צמתים (אשכול משתמש HA) נשבר באופן קבוע בגלל נתונים פגומים או אובדן נתונים. במקרה הזה, רק צומת אחד נשבר ועדיין יש קוורום של etcd. התרחיש הזה יכול לקרות באשכול HA, שבו הנתונים של אחת מהרפליקות של etcd פגומים או אבדו. אפשר לפתור את הבעיה בלי אובדן נתונים על ידי החלפת הרפליקה של etcd שנכשלה ברפליקה חדשה במצב נקי. מידע נוסף זמין במאמר החלפת רפליקה של etcd שנכשלה.

  • שני צמתים באשכול etcd עם שלושה צמתים (אשכול משתמש HA) נשברו באופן קבוע בגלל פגיעה בנתונים או אובדן נתונים. הקוורום אבד, ולכן החלפת העותקים של etcd שנכשלו בעותקים חדשים לא עוזרת. צריך לשחזר את מצב האשכול מנתוני הגיבוי. מידע נוסף זמין במאמר בנושא שחזור אשכול משתמשים מגיבוי (זמינות גבוהה).

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

שחזור אחרי השחתה או אובדן של PV באפליקציית משתמש

אתם יכולים להשתמש בפתרונות אחסון מסוימים של שותפים כדי לגבות ולשחזר PersistentVolumes של אפליקציות משתמשים. רשימת שותפי האחסון שעברו את תהליך ההסמכה ל-Google Distributed Cloud מופיעה במאמר GDC Ready Storage Partners.

שחזור אחרי כשלים במאזן העומסים

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

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

לגבי מאזני עומסים משולבים (F5), צריך לפנות אל התמיכה של F5.

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

המאמרים הבאים

לקבלת עזרה נוספת, אפשר לפנות אל Cloud Customer Care.

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