בדף הזה מתוארות אפשרויות לזמינות גבוהה ב-Google Distributed Cloud (תוכנה בלבד) ל-VMware.
פונקציונליות בסיסית
התקנה של Google Distributed Cloud for VMware שכוללת רק תוכנה כוללת אשכול אדמין ואשכול משתמש אחד או יותר.
אשכול האדמין מנהל את מחזור החיים של אשכולות המשתמשים, כולל יצירה, עדכונים, שדרוגים ומחיקה של אשכולות משתמשים. באשכול האדמין, ה-admin master מנהל את צמתי העובדים של האדמין, שכוללים user masters (צמתים שמריצים את מישור הבקרה של אשכולות המשתמשים המנוהלים) וצמתי תוספים (צמתים שמריצים את רכיבי התוספים שתומכים בפונקציונליות של אשכול האדמין).
לכל אשכול משתמשים, לאשכול האדמין יש צומת אחד ללא זמינות גבוהה או שלושה צמתים עם זמינות גבוהה שמריצים את מישור הבקרה. מישור הבקרה כולל את שרת Kubernetes API, את מתזמן Kubernetes, את מנהל הבקרה של Kubernetes וכמה בקרי קריטיים לאשכול המשתמשים.
זמינות מישור הבקרה של אשכול המשתמשים היא קריטית לפעולות של עומסי עבודה, כמו יצירה, הגדלה והקטנה של עומסי עבודה וסיום שלהם. במילים אחרות, הפסקת פעולה של מישור הבקרה לא משפיעה על עומסי העבודה הפועלים, אבל עומסי העבודה הקיימים מאבדים את יכולות הניהול משרת Kubernetes API אם מישור הבקרה שלו לא זמין.
עומסי עבודה ושירותים בקונטיינרים נפרסים בצמתי העובדים של אשכול המשתמשים. כל צומת עובד בודד לא צריך להיות קריטי לזמינות האפליקציה, כל עוד האפליקציה נפרסת עם יחידות Pod מיותרות שמתוזמנות בכמה צמתי עובד.
הפעלת זמינות גבוהה
ב-vSphere וב-Google Distributed Cloud יש מספר תכונות שמשפרות את הזמינות הגבוהה (HA).
vSphere HA ו-vMotion
מומלץ להפעיל את שתי התכונות הבאות באשכול vCenter שמארח את אשכולות Google Distributed Cloud:
התכונות האלה משפרות את הזמינות ואת השחזור במקרה של כשל במארח ESXi.
vCenter HA משתמש בכמה מארחי ESXi שהוגדרו כאשכול כדי לספק שחזור מהיר מהפסקות חשמל וזמינות גבוהה (HA) חסכונית לאפליקציות שפועלות במכונות וירטואליות. מומלץ להקצות לאשכול vCenter עוד מארחים ולהפעיל את התכונה vSphere HA Host Monitoring עם הערך Host Failure Response שמוגדר ל-Restart VMs. לאחר מכן, המכונות הווירטואליות יכולות להיות מופעלות מחדש באופן אוטומטי במארחים זמינים אחרים במקרה של כשל במארח ESXi.
vMotion מאפשר מיגרציה פעילה של מכונות וירטואליות ממארח ESXi אחד למארח אחר ללא השבתה. במקרה של תחזוקה מתוכננת של המארח, אפשר להשתמש במיגרציה פעילה של vMotion כדי להימנע מזמן השבתה של האפליקציה לחלוטין ולהבטיח את המשכיות העסקית.
קלאסטר אדמין
Google Distributed Cloud תומך ביצירת אשכולות אדמין בזמינות גבוהה (HA). ל клаסטר אדמין HA יש שלושה צמתים שמריצים רכיבי control-plane. מידע על הדרישות והמגבלות מופיע במאמר בנושא אשכול אדמין עם זמינות גבוהה.
שימו לב: חוסר זמינות של מישור הבקרה של אשכול האדמין לא משפיע על הפונקציונליות של אשכול המשתמש הקיים או על עומסי העבודה שפועלים באשכולות המשתמשים.
יש שני צמתי תוספים באשכול אדמין. אם אחד מהם מושבת, השני עדיין יכול להפעיל את פעולות אשכול האדמין. לצורך יתירות, Google Distributed Cloud מפזרת שירותים קריטיים של תוספים, כמו kube-dns, על שני הצמתים של התוספים.
אם מגדירים את antiAffinityGroups.enabled לערך true בקובץ ההגדרה של אשכול האדמין, Google Distributed Cloud יוצר באופן אוטומטי כללי אנטי-אפיניות של vSphere DRS עבור הצמתים של התוסף, וכתוצאה מכך הם מתפרסים על פני שני מארחים פיזיים לצורך זמינות גבוהה.
אשכול משתמשים
כדי להפעיל זמינות גבוהה באשכול משתמשים, צריך להגדיר את masterNode.replicas ל-3 בקובץ ההגדרות של אשכול המשתמשים. אם Controlplane V2 מופעל באשכול המשתמשים (מומלץ), שלושת הצמתים של מישור הבקרה פועלים באשכול המשתמשים.
באשכולות משתמשים מדור קודם עם זמינות גבוהה שלא מופעל בהם Controlplane V2, שלושת צמתי מישור הבקרה פועלים באשכול האדמין. בכל צומת של מישור הבקרה פועלת גם רפליקה של etcd. אשכול המשתמשים ממשיך לפעול כל עוד פועל מישור בקרה אחד וקיים קוורום של etcd. כדי להשיג קוורום ב-etcd
צריך ששניים מתוך שלושת העותקים של etcd יפעלו.
אם מגדירים את antiAffinityGroups.enabled ל-true בקובץ ההגדרות של אשכול האדמין, Google Distributed Cloud יוצר באופן אוטומטי כללי anti-affinity של vSphere DRS לשלושת הצמתים שמריצים את מישור הבקרה של אשכול המשתמשים.
כתוצאה מכך, מכונות ה-VM האלה מתפרסות על פני שלושה מארחים פיזיים.
בנוסף, Google Distributed Cloud יוצר כללי אנטי-אפיניות של vSphere DRS עבור צמתי העובדים באשכול המשתמשים, וכתוצאה מכך הצמתים האלה מתפרסים על פני לפחות שלושה מארחים פיזיים. כמה כללי אנטי-אפיניות של DRS משמשים לכל מאגר צמתים של אשכול משתמשים, בהתאם למספר הצמתים. כך מוודאים שצמתי העובדים יוכלו למצוא מארחים להפעלה, גם אם מספר המארחים קטן ממספר מכונות ה-VM במאגר הצמתים של אשכול המשתמשים. מומלץ לכלול עוד מארחים פיזיים באשכול vCenter. כדאי גם להגדיר את DRS כך שיהיה אוטומטי לחלוטין, כדי שבמקרה שמארח מסוים לא יהיה זמין, DRS יוכל להפעיל מחדש מכונות וירטואליות במארחים זמינים אחרים באופן אוטומטי, בלי להפר את כללי האנטי-אפיניות של המכונות הווירטואליות.
ב-Google Distributed Cloud יש תווית צומת מיוחדת, onprem.gke.io/failure-domain-name, שהערך שלה מוגדר לשם המארח הבסיסי של ESXi. אפליקציות של משתמשים שרוצים זמינות גבוהה יכולות להגדיר כללי podAntiAffinity עם התווית הזו כtopologyKey כדי לוודא שפודים של האפליקציה שלהם מפוזרים על פני מכונות וירטואליות שונות וגם על פני מארחים פיזיים.
אפשר גם להגדיר כמה מאגרי צמתים עבור אשכול משתמשים עם מאגרי נתונים שונים ותוויות צמתים מיוחדות. באופן דומה, אפשר להגדיר podAntiAffinityכללים עם התווית המיוחדת של הצומת כtopologyKey כדי להשיג זמינות גבוהה יותר במקרה של כשלים במאגר הנתונים.
כדי להשיג זמינות גבוהה לעומסי עבודה של משתמשים, צריך לוודא שיש מספיק עותקים משוכפלים באשכול המשתמשים בקטע nodePools.replicas. כך אפשר להבטיח את המספר הרצוי של צמתי עובדים באשכול המשתמשים במצב פעיל.
אתם יכולים להשתמש במאגרי נתונים נפרדים לאשכולות של אדמינים ולאשכולות של משתמשים כדי לבודד את הכשלים שלהם.
מאזן עומסים
יש שני סוגים של מאזני עומסים שאפשר להשתמש בהם כדי להשיג זמינות גבוהה.
מאזן עומסים MetalLB בחבילה
כדי להשיג זמינות גבוהה (HA) באמצעות מאזן העומסים MetalLB שכלול בחבילה, צריך יותר מצומת אחד עם enableLoadBalancer: true.
MetalLB מפזר את השירותים בין הצמתים של מאזן העומסים, אבל לכל שירות יש רק צומת מוביל אחד שמטפל בכל התנועה של השירות הזה.
במהלך שדרוג האשכול, יש זמן השבתה מסוים כשצמתי איזון העומסים משודרגים. משך השיבוש של המעבר לגיבוי (failover) ב-MetalLB גדל ככל שמספר הצמתים של מאזן העומסים גדל. אם יש פחות מ-5 צמתים, השיבוש יימשך עד 10 שניות.
איזון עומסים ידני
באיזון עומסים ידני, אתם מגדירים את Google Distributed Cloud כך שישתמש במאזן עומסים לפי בחירתכם, כמו F5 BIG-IP או Citrix. אתם מגדירים זמינות גבוהה במאזן העומסים, ולא ב-Google Distributed Cloud.
שימוש בכמה אשכולות לצורך תוכנית התאוששות מאסון (DR)
פריסת אפליקציות בכמה אשכולות בכמה שרתים של vCenter יכולה לספק זמינות גלובלית גבוהה יותר ולהגביל את רדיוס ההשפעה במהלך הפסקות שירות.
במקרה כזה, המערכת משתמשת באשכול הקיים במרכז הנתונים המשני לצורך תוכנית התאוששות מאסון (DR), במקום להגדיר אשכול חדש. הנה סיכום כללי של השלבים לביצוע הפעולה הזו:
יוצרים עוד אשכול אדמין ואשכול משתמשים במרכז הנתונים המשני. בארכיטקטורה מרובת האשכולות הזו, אנחנו דורשים מהמשתמשים להגדיר שני אשכולות אדמין בכל מרכז נתונים, וכל אשכול אדמין מפעיל אשכול משתמשים.
למשתמש המשני יש מספר מינימלי של צמתי עובד (שלושה), והוא נמצא במצב המתנה פעיל (תמיד פועל).
אפשר לשכפל פריסות של אפליקציות בשני מרכזי vCenter באמצעות סנכרון תצורות, או להשתמש בגישה המועדפת שהיא שימוש בשרשרת כלים קיימת של DevOps (CI/CD, Spinnaker) לאפליקציות.
במקרה של אסון, אפשר לשנות את הגודל של אשכול המשתמשים למספר הצמתים.
בנוסף, נדרש מעבר גיבוי אוטומטי של DNS כדי לנתב את התעבורה בין האשכולות למרכז הנתונים המשני.