כדי להגן מפני הפסקות בשירותי התשתית או שגיאות בהגדרות, אתם יכולים לתכנן אסטרטגיות יתירות כשל עבור מאזני עומסים גלובליים חיצוניים של אפליקציות. השיטות האלה משתמשות במאזני עומסים אזוריים חיצוניים של אפליקציות (ALB) ומנתבות אליהם תנועה ממאזן עומסים גלובלי חיצוני של אפליקציות כדי לשמור על זמינות גבוהה במהלך הפסקות בשירותי התשתית הגלובלית או שגיאות בהגדרות.
בארכיטקטורת יתירות כשל, פורסים מאזן עומסים ראשי ומאזן עומסים אחד או יותר לגיבוי:
- מאזן העומסים הראשי הוא מאזן עומסים גלובלי חיצוני של אפליקציות (ALB) שמטפל בתנועת הלקוחות במהלך פעולות רגילות.
- מאזן העומסים לגיבוי הוא מאזן עומסים חיצוני אזורי של אפליקציות שמקבל תנועה אם מאזן העומסים הראשי לא עובר את בדיקות התקינות.
מעבר לגיבוי (Failover) וחזרה מגיבוי (Failback) הם תהליכים אוטומטיים של ניתוב תנועה:
- מעבר לגיבוי (Failover) מתרחש כש-Cloud DNS מזהה הפסקת שירות ומנתב את התעבורה ממאזן העומסים הראשי למאזני העומסים לגיבוי.
- חזרה למצב תקין מתרחשת כש-Cloud DNS הופך את הניתוב הזה ומפנה מחדש את התנועה למאזן העומסים הראשי אחרי שהבדיקות עוברות בהצלחה.
במסמך הזה מוסבר איך לבצע מעבר לגיבוי במקרה של כשל ממאזן עומסים גלובלי חיצוני של אפליקציות למאזני עומסים אזוריים לגיבוי. אם רוצים להגדיר יתירות כשל בין מאזני עומסים חיצוניים אזוריים של אפליקציות באזורים שונים, אפשר לעיין במאמר בנושא זמינות גבוהה למאזני עומסים חיצוניים אזוריים של אפליקציות.
למה כדאי להשתמש במאזני עומסים אזוריים למעבר לגיבוי (failover)
מאזני עומסים חיצוניים אזוריים של אפליקציות (ALB) מתאימים במיוחד כמאזני עומסים למעבר אוטומטי למקרה של כשל במאזני עומסים חיצוניים גלובליים של אפליקציות (ALB), בגלל המאפיינים הבאים:
- מאזני עומסים חיצוניים אזוריים של אפליקציות (ALB) הם עצמאיים בתוךGoogle Cloud אזורים ספציפיים, והם מבודדים גם מכל תשתית גלובלית של מאזני עומסים חיצוניים של אפליקציות שפועלת באותו אזור.
- מאזני עומסים חיצוניים אזוריים של אפליקציות (ALB) ומאזני עומסים חיצוניים גלובליים של אפליקציות (ALB) מבוססים על שרתי proxy של Envoy ומעבדים את התנועה בדרכים דומות.
כדי להטמיע מעבר גלובלי ליתירות כשל אזורית במאזני עומסים גלובליים חיצוניים של אפליקציות, צריך ליצור שני מאזני עומסים חיצוניים אזוריים או יותר באזורים שבהם רוצים שתעבורת הנתונים תעבור ליתירות כשל.
אסטרטגיות למעבר לגיבוי
אפשר להטמיע מעבר לגיבוי (failover) למאזני עומסים גלובליים חיצוניים של אפליקציות (ALB) באמצעות האסטרטגיות הבאות:
- פעיל-סביל (מעבר אוטומטי מגלובלי לאזורי): אתם פורסים מאזן עומסים חיצוני אזורי אחד או יותר של אפליקציות למטרות גיבוי בלבד. במצב יציב, Cloud DNS מתפרש ככתובת ה-IP של מאזן העומסים הגלובלי החיצוני של האפליקציות. אם מאזן העומסים הגלובלי נכשל, Cloud DNS מנתב את התנועה למאזני העומסים האזוריים של הגיבוי. ההגדרה הזו משתמשת במדיניות ניתוב ליתירות כשל של Cloud DNS.
- פעיל-פעיל (מעקף גלובלי לאזורי): מאזן עומסים גלובלי חיצוני של אפליקציות (ALB) פועל כחזית קצה שמספקת פונקציות של Cloud CDN, כמו שמירה במטמון קצה, שמעבירה בקשות למאזני עומסים אזוריים חיצוניים של אפליקציות באמצעות קבוצות של נקודות קצה ברשת (NEGs) עם שמות דומיין מלאים (FQDN). במצב יציב, התנועה זורמת ברצף דרך שתי שכבות איזון העומסים. אפשר להגדיר את זה באמצעות מדיניות ניתוב לפי מיקום גיאוגרפי ב-Cloud DNS. אם יש הפסקת חשמל במאזן העומסים הגלובלי, מדיניות ניתוב ה-DNS עוקפת את השכבה הגלובלית ומנתבת את תעבורת הלקוחות ישירות למאזני העומסים האזוריים.
מומלץ להשתמש באסטרטגיית active-active אם הארכיטקטורה שלכם לא מסתמכת על איזון עומסים גלובלי עם מודעות לקיבולת. עם זאת, אם האפליקציה שלכם דורשת איזון עומסים גלובלי בשרת העורפי כדי להפיץ את התנועה בין אזורים על סמך קיבולת השרת העורפי, כדאי להטמיע את האסטרטגיה של פעיל-סביל.
השוואה בין אסטרטגיות מעבר לגיבוי
בטבלה הבאה מוצגת השוואה בין אסטרטגיות של מעבר לגיבוי פעיל-סביל ומעבר לגיבוי פעיל-פעיל:
| מאפיין אסטרטגיה | פעיל-סביל | פעיל-פעיל |
|---|---|---|
| זרימת נתונים במצב יציב | לקוח ← מאזן עומסים גלובלי חיצוני של אפליקציות (ALB) ← קצה עורפי | לקוח ← מאזן עומסים גלובלי חיצוני של אפליקציות (ALB) ← מאזן עומסים חיצוני אזורי של אפליקציות (ALB) ← קצה עורפי |
| זרימת נתונים במצב כשל | לקוח ← מאזן עומסים חיצוני אזורי של אפליקציות (ALB) ← קצה עורפי. השירות יישאר זמין, אבל יכול להיות שיהיה זמן אחזור ארוך יותר בגלל אובדן היתרונות של ביצועים משופרים. |
לקוח ← מאזן עומסים חיצוני אזורי של אפליקציות (ALB) ← קצה עורפי (דילוג על מאזן העומסים הגלובלי החיצוני של אפליקציות). השירות יישאר זמין, אבל יכול להיות שיהיה זמן אחזור ארוך יותר בגלל אובדן היתרונות של ביצועים משופרים. |
| ניהול הגדרות | צריך לסנכרן הגדרות נפרדות בין מאזני עומסים גלובליים ואזוריים. | השכבה הגלובלית דורשת הגדרה מינימלית כי רוב הלוגיקה של האפליקציה נמצאת במאזני עומסים אזוריים. עם זאת, צריך לשכפל את כללי מדיניות האבטחה של קצה הרשת (Cloud Armor) ואת הגדרות סיום החיבור (אישורי TLS) בשתי השכבות. |
| אימות אמינות | מאזן העומסים החיצוני האזורי של האפליקציות (ALB) נמצא במצב סרק במצב יציב. מומלץ לבצע בדיקות תקופתיות או להשתמש בתנועה מדורגת של DNS. | תעבורת נתונים במצב יציב בודקת באופן רציף את מאזן העומסים האזורי החיצוני של אפליקציות (ALB). מומלץ לבצע בדיקות תקופתיות או להפנות תנועה באופן הדרגתי ישירות למאזן העומסים האזורי. |
| פריסה הדרגתית בטוחה | שינויים בהגדרות של מאזן עומסים גלובלי חיצוני של אפליקציות (ALB) חלים באופן גלובלי. שינויים במאזן עומסים חיצוני אזורי של אפליקציות (ALB) מבודדים, אבל תנועה במצב יציב לא בודקת אותם. | אפשר להחיל שינויים במאזן עומסים חיצוני אזורי של אפליקציות (ALB) באופן הדרגתי, מאזור לאזור. אם אזור נכשל, השכבה הגלובלית מנתבת את התעבורה ממנו באופן אוטומטי לאזורים תקינים. |
| איזון עומסים גלובלי בעורף | נתמך מאזן העומסים הגלובלי החיצוני של אפליקציות יכול לאזן את התנועה בין קצה עורפי באזורים שונים על סמך הקיבולת. |
מוגבלת מאזן העומסים הגלובלי החיצוני של אפליקציות מנתב את התנועה למאזן העומסים החיצוני האזורי של האפליקציות הקרוב ביותר. מאזן העומסים האזורי מאזן את התעבורה באופן מקומי בלבד, ולא מעביר תעבורה בין אזורים על סמך הקיבולת של הקצה העורפי. |
| עלות וחיוב | עמלות על עיבוד נתונים חלות על שכבת איזון עומסים אחת. במצב יציב, העלויות נובעות ממאזן העומסים הגלובלי החיצוני של האפליקציות. החיובים על מאזן העומסים החיצוני האזורי של האפליקציות חלים רק במהלך בדיקות או אירועי מעבר לגיבוי. | שתי שכבות איזון העומסים יוצרות חיובים על עיבוד נתונים בו-זמנית, כי התנועה זורמת דרך שתי הרמות – הגלובלית והאזורית – במצב יציב. |
| תרחיש שימוש מומלץ | עומסי עבודה שנדרש להם איזון עומסים מתקדם בקצה העורפי ברמה הגלובלית והעברת תעבורה בין אזורים על סמך קיבולת. | עומסי עבודה שמתוכננים סביב בידוד אזורי ומשתמשים בשכבה הגלובלית לביצועים ולשמירת נתונים במטמון בקצה הרשת. |
אסטרטגיה פעילה-סבילה
בסביבת פעילה-סבילה, אתם פורסים מאזני עומסים חיצוניים אזוריים עצמאיים של אפליקציות (ALB) באזור אחד או יותר לצד מאזן העומסים הראשי הגלובלי החיצוני של אפליקציות (ALB) או מאזן העומסים הקלאסי של אפליקציות (ALB).
איך פועל מעבר לגיבוי פעיל-סביל
ההגדרה הבאה מדגימה מעבר לגיבוי במקרה של כשל ממאזן עומסים גלובלי חיצוני של אפליקציות לשני מאזני עומסים חיצוניים אזוריים לגיבוי, אחד בכל אזור שבו מאזן העומסים הגלובלי פרס שרתי בק-אנד.
מעבר לגיבוי פעיל-סביל מתבצע לפי תהליך העבודה הבא:
- מצב יציב: Cloud DNS מנתב את כל תעבורת הלקוחות אל מאזן העומסים הגלובלי החיצוני של אפליקציות (ALB).
- זיהוי כשלים: Google Cloud נעשה שימוש בבדיקות תקינות שהוגדרו עם שלושה אזורי מקור כדי לזהות אם מאזן העומסים הראשי תקין. אם בדיקות התקינות שמקורן בשני אזורים או יותר נכשלות, Cloud DNS מפעיל יתירות כשל.
- מעבר לגיבוי (Failover): מדיניות הניתוב של Cloud DNS למעבר לגיבוי מנתבת את תעבורת הלקוחות ישירות למאזני העומסים החיצוניים האזוריים לגיבוי. השפעת זמן האחזור במהלך יתירות כשל: מאזני עומסים אזוריים חיצוניים של אפליקציות (ALB) מסיימים את החיבורים באזור מסוים Google Cloud , ולכן יכול להיות שזמן האחזור וזמני הלוך ושוב (RTT) יהיו ארוכים יותר ללקוחות שנמצאים רחוק מאזור היעד בזמן שיתירות כשל פעילה.
- חזרה לשירות (Failback): אחרי שבדיקות תקינות חוזרות להצלחה, Cloud DNS מחזיר באופן אוטומטי את התנועה למאזן העומסים הראשי ללא השבתה, כי שני מאזני העומסים משרתים תנועה.
אסטרטגיית פעיל-פעיל (מעקף גלובלי לאזורי)
בגישה של פעיל-פעיל, מאזן העומסים החיצוני הגלובלי של אפליקציות (ALB) משתמש ב-NEG של FQDN באינטרנט (INTERNET_FQDN_PORT) כדי לשלוח תנועה למאזני עומסים חיצוניים אזוריים של אפליקציות בשני אזורים או יותר.
איך עוקפים את המצב פעיל-פעיל
ההגדרה הבאה מדגימה מעבר לגיבוי במקרה של כשל ממאזן עומסים גלובלי חיצוני של אפליקציות לשני מאזני עומסים חיצוניים אזוריים לגיבוי, אחד בכל אזור שבו מאזן העומסים הגלובלי פרס שרתי בק-אנד.
מעבר לגיבוי פעיל-פעיל מתבצע לפי תהליך העבודה הבא:
- מצב יציב: תעבורת נתונים זורמת מהלקוח אל מאזן העומסים הגלובלי החיצוני של אפליקציות (ALB).
מאזן העומסים הגלובלי משתמש בקבוצה של נקודות קצה (endpoint) ברשת (NEG) מסוג
INTERNET_FQDN_PORTעם שם דומיין מלא (FQDN) באינטרנט, כדי להעביר תעבורה למאזני העומסים החיצוניים האזוריים הקרובים ביותר. לאחר מכן, מאזני העומסים האזוריים מעבירים את תעבורת הנתונים לקצה העורפי המקומי. - זיהוי כשלים: במצב יציב, אם מאזן עומסים חיצוני אזורי של אפליקציות או האזור שלו נכשל, מאזן העומסים החיצוני הגלובלי של האפליקציות מזהה את הכשל באמצעות מדיניות בדיקת התקינות של Cloud DNS ב-NEG באינטרנט. מאזן העומסים הגלובלי מנתב אוטומטית את התעבורה מהאזור הלא תקין למאזני עומסים אזוריים תקינים.
- מעקף: אם יש הפסקת שירות במאזן עומסים גלובלי חיצוני של אפליקציות (ALB), מדיניות הניתוב של Cloud DNS מזהה את הכשל ומנתבת את התעבורה ישירות למאזני עומסים חיצוניים אזוריים של אפליקציות (ALB), תוך עקיפה מלאה של השכבה הגלובלית. השפעה על זמן האחזור במהלך עקיפה: מאזן העומסים החיצוני הגלובלי של אפליקציות (ALB) מספק יתרונות בביצועים בקצה הרשת, כמו סיום חיבורים קרוב יותר למשתמשים ושמירת נתונים במטמון קצה. כשתעבורת הנתונים עוקפת את מאזן העומסים הגלובלי, נוצרים חיבורים ישירים בין הלקוחות לבין כתובות ה-VIP האזוריות, מה שעלול להגדיל את זמן האחזור של החיבורים ואת זמן הלוך ושוב (RTT) של לקוחות שנמצאים רחוק מבחינה גיאוגרפית.
- חזרה למצב תקין: כשמאזן העומסים הגלובלי עובר בדיקות תקינות רצופות, Cloud DNS מחדש באופן אוטומטי את ההחזרה של כתובת ה-VIP הגלובלית של Anycast בתשובות DNS, וכך משחזר את רמת הניתוב הגלובלית של קצה הרשת.
בדיקת ההגדרות של מאזן העומסים הראשי
לפני שמגדירים מעבר לגיבוי, צריך לוודא שמאזן העומסים החיצוני האזורי לגיבוי תומך בתכונות שבהן משתמש מאזן העומסים הראשי.
- במצב active-passive, מאזן העומסים האזורי לגיבוי צריך לתמוך בתכונות דומות כדי להשתלט על התנועה בצורה חלקה במהלך הפסקה זמנית בשירות.
- במצב פעיל-פעיל, צריך להגדיר את כללי הניתוב והאבטחה ישירות ברמה האזורית, אבל תכונות גלובליות של קצה הרשת, כמו Cloud CDN, לא פועלות במהלך הפסקת שירות גלובלית.
| תכונה | דרישות התאימות |
|---|---|
| פריסות של Google Kubernetes Engine | שימוש ב-GKE Gateway כדי לפרוס מאזני עומסים ראשיים וגיבויים. הסיבה לכך היא שמאזני עומסים שנפרסו באמצעות GKE Gateway תואמים יותר למנגנון היתירות כשל הזה מאשר מאזני עומסים שנפרסו באמצעות GKE Ingress controller. בקר GKE Ingress תומך רק ב-Application Load Balancer הקלאסי. |
| Cloud CDN | מאזני עומסים חיצוניים אזוריים של אפליקציות לא תומכים ב-Cloud CDN. אם מתרחש יתירות כשל, הפעולות שמסתמכות על Cloud CDN מושפעות. |
| Cloud Armor | אם אתם משתמשים ב-Cloud Armor במאזן העומסים הראשי, אתם צריכים להגדיר כללי מדיניות אבטחה אזוריים מקבילים של Cloud Armor במאזני העומסים לגיבוי. ל-Cloud Armor יש תכונות שונות שזמינות בהיקף אזורי לעומת היקף גלובלי. מידע נוסף זמין במאמרים בנושא מדיניות אבטחה אזורית של Cloud Armor ומדיניות אבטחה גלובלית של Cloud Armor. |
| אישורי SSL | מוודאים שסוג אישור ה-SSL שבו נעשה שימוש במאזן העומסים הראשי תואם למאזן העומסים החיצוני האזורי של האפליקציות לגיבוי. כדאי לעיין בהבדלים בין אישורי ה-SSL שזמינים במאזני עומסים גלובליים, אזוריים וקלאסיים. מידע נוסף זמין במאמרים בנושא אישורי SSL ב-Compute Engine ואישורי SSL ב-Certificate Manager. |
שיקולים לגבי מאזני עומסים אזוריים
מגדירים ופורסים מאזני עומסים חיצוניים אזוריים של אפליקציות באזור שבו רוצים להפנות מחדש את התנועה במקרה של כשל.
כשמגדירים מאזן עומסים אזורי, חשוב לקחת בחשבון את השיקולים הבאים לגבי ארכיטקטורות של מעבר לגיבוי או עקיפה:
אתם צריכים להגדיר את התכונות של מאזן העומסים החיצוני האזורי לגיבוי של אפליקציות (ALB) כך שיהיו דומות ככל האפשר למאזן העומסים הראשי, כדי שתעבורת הנתונים תעבור עיבוד דומה בשני ה-Deployment-ים (פריסות).
מאזן עומסים גלובלי חיצוני של אפליקציות (ALB). מאזני עומסים חיצוניים אזוריים של אפליקציות תומכים ברוב התכונות שנתמכות במאזני עומסים חיצוניים גלובליים של אפליקציות, עם כמה יוצאים מן הכלל. מאזן העומסים האזורי תומך גם באותן יכולות מתקדמות של ניהול תעבורה כמו מאזן העומסים הגלובלי, מה שמקל על השגת שוויון בין מאזני העומסים הראשי והגיבוי.
Classic Application Load Balancer. עם מאזן העומסים הקלאסי של אפליקציות (ALB), קשה יותר להשיג שוויון בתכונות בין מאזן העומסים הראשי לבין מאזן העומסים לגיבוי, כי מאזן העומסים החיצוני האזורי של אפליקציות (ALB) הוא מאזן עומסים מבוסס-Envoy שמבצע עיבוד שונה של התעבורה. חשוב לבדוק היטב את המעבר לגיבוי ואת החזרה מגיבוי לפני הפריסה בסביבת הייצור.
כדי לראות את היכולות הספציפיות של מאזני עומסים אזוריים, גלובליים וקלאסיים של אפליקציות, אפשר לעיין בדף ההשוואה בין התכונות של מאזני העומסים.
מומלץ להשתמש במסגרת אוטומציה כמו Terraform כדי להשיג ולשמור על עקביות בהגדרות של איזון העומסים, גם בפריסות הראשיות וגם בפריסות הגיבוי.
מאזני עומסים אזוריים חיצוניים של אפליקציות (ALB) תומכים במסלול פרימיום ובמסלול רגיל של Network Service Tiers. אם זמן האחזור הוא לא הדאגה העיקרית שלכם במהלך מעבר לגיבוי, מומלץ להגדיר את מאזני העומסים החיצוניים האזוריים לגיבוי באמצעות המסלול הרגיל. שימוש בתשתית של המסלול הרגיל מספק בידוד נוסף מהתשתית של מסלול הפרימיום שמשמשת מאזני עומסים גלובליים חיצוניים של אפליקציות.
חשוב לוודא שתת-הרשת של שרת ה-proxy בלבד גדולה מספיק כדי להכיל את תעבורת הנתונים המוגברת במהלך אירוע מעבר לגיבוי, בלי לשבש את הפעולה של מאזני עומסים אזוריים אחרים באותו אזור ובאותה רשת. פרטים נוספים זמינים במאמר בנושא הזמנת קיבולת נוספת של רשת משנה לשרתי proxy בלבד.
במאמר הגדרת מאזן עומסים חיצוני אזורי של אפליקציות (ALB) עם קבוצות של מכונות וירטואליות (VM) כבק-אנד מוסבר איך להגדיר מאזן עומסים חיצוני אזורי של אפליקציות (ALB).
שמירת קיבולת נוספת של תת-רשת של שרת proxy בלבד
כל מאזני העומסים האזוריים שמבוססים על Envoy באזור וברשת VPC חולקים את אותו מאגר של שרתי proxy של Envoy. במקרה של מעבר לגיבוי (failover), מאזני העומסים החיצוניים האזוריים של האפליקציות לגיבוי רואים עלייה בשימוש בשרת proxy כדי לטפל בתנועה של מעבר לגיבוי ממאזן העומסים הראשי. הזמנת קיבולת מספקת של שרת proxy מבטיחה שאירועי מעבר לגיבוי (failover) לא ישבשו מאזני עומסים אזוריים אחרים שמבוססים על Envoy באותו אזור ובאותה רשת.
כדי לוודא שהקיבולת תמיד זמינה למאזני העומסים של הגיבוי, צריך לבדוק את הגודל של תת-הרשת של שרת ה-proxy בלבד. מומלץ לחשב את מספר השרתים הפרוקסי המשוער שנדרש לטיפול בתנועת הגולשים באזור מסוים, ולהגדיל את הקיבולת לפי הצורך. מידע נוסף על מגבלות הקיבולת של שרת proxy ועל חישובי גודל זמין בקטע חיוב על מופע של שרת proxy במאמר בנושא תמחור של Cloud Load Balancing.
אם אתם משתמשים במדיניות DNS כדי לפצל את התעבורה בין כמה מאזני עומסים לגיבוי באזורים שונים, אתם צריכים לקחת את זה בחשבון כשאתם מעריכים את דרישות ה-proxy לכל אזור ולכל רשת. תת-רשת גדולה יותר של שרתי proxy מאפשרת ל-Google Cloud Envoy להקצות מספר גדול יותר של שרתי proxy למאזן העומסים שלכם כשצריך.
אי אפשר להרחיב תת-רשת של כתובות IP של שרת proxy באותה דרך שבה מרחיבים טווח כתובות ראשי (באמצעות הפקודה expand-ip-range). במקום זאת, צריך ליצור רשת משנה לגיבוי שכוללת רק שרת proxy ועונה על הצרכים שלכם, ואז להגדיר אותה כרשת המשנה הפעילה.
מידע נוסף על שינוי הגודל של רשת משנה מסוג proxy-only מופיע במאמר שינוי הגודל או טווח הכתובות של רשת משנה מסוג proxy-only.
שיתוף קצה עורפי בין מאזני עומסים ראשיים לבין מאזני עומסים לגיבוי
כדי להשיג יתירות מלאה בתשתית, צריך להוסיף יתירות ברמה של מאזן העומסים וברמת ה-Backend. כלומר, צריך להגדיר את מאזני העומסים החיצוניים האזוריים לגיבוי עם קצה עורפי (קבוצות של מופעים או קבוצות של נקודות קצה ברשת) שלא חופף למאזני העומסים הראשיים.
אם בוחרים במקום זאת להשתמש באותם בק-אנדים גם למאזני עומסים ראשיים וגם למאזני עומסים לגיבוי, צריך ליצור כל מאזן עומסים חיצוני אזורי לגיבוי באזור שבו נמצאים הבק-אנדים האלה. בנוסף, אם הפעלתם את התכונה 'התאמה אוטומטית לעומס' לקבוצות המכונות, אתם צריכים לעמוד בדרישות הבאות כדי להבטיח יתירות כשל תקינה:
- מגדירים את התכונה להתאמה אוטומטית לעומס (autoscaler) כך שתתבסס רק על התאמה לעומס של המעבד. אין תמיכה בהתאמה אוטומטית לעומס (autoscaling) על סמך ניצול מאזן העומסים.
- גם בשירותים הגלובליים וגם בשירותים האזוריים לקצה העורפי צריך להשתמש רק במצב האיזון
UTILIZATION. אל תשתמשו במצב איזון העומסיםRATEכי יכול להיות שהמכונות שלכם יקבלו תעבורת נתונים כפולה ממאזני עומסים גלובליים ואזוריים במהלך תהליך יתירות הכשל. - הגדרת אמצעי בקרה לצמצום קנה המידה כדי למנוע את צמצום קנה המידה של הקבוצה על ידי הכלי להתאמה אוטומטית לעומס (autoscaler) לפני הזמן במהלך השבתה, כשמתבצע מעבר של התנועה ממאזן העומסים הגלובלי למאזן העומסים האזורי. משך ההשבתה הזה יכול להיות ארוך כמו סכום אורך החיים (TTL) של ה-DNS בתוספת מרווח הבדיקה של תקינות השרת שהוגדר.
אם לא מגדירים את ההתאמה האוטומטית לעומס בצורה נכונה, עלולה להתרחש הפסקת שירות משנית במהלך מעבר לגיבוי (failover), כי אובדן התנועה ממאזן העומסים הגלובלי גורם לקבוצת המופעים להתכווץ במהירות לפני שמאזן העומסים האזורי משתלט.
הגדרת מעבר לגיבוי פעיל-פסיבי
כדי להגדיר מעבר לגיבוי פעיל-סביל, מבצעים את השלבים הבאים:
- בדיקת שיקולים לגבי הארכיטקטורה: לפני שיוצרים משאבים, כדאי לעיין בשיקולים לגבי מאזני עומסים אזוריים כדי לוודא שיש תאימות בין התכונות, קיבולת של שרת proxy ודרישות של קנה מידה אוטומטי של קצה עורפי משותף.
- מגדירים את מאזן העומסים הראשי: מגדירים את מאזן העומסים החיצוני הגלובלי של האפליקציות עם שירותי קצה עורפיים שמפוזרים באזור אחד או יותר. מידע נוסף על הגדרת מאזן עומסים גלובלי חיצוני של אפליקציות זמין במאמר הגדרת מאזן עומסים גלובלי חיצוני של אפליקציות.
- בדיקת ההגדרה של מאזן העומסים הראשי: מוודאים שהתכונות (כמו תכונות אבטחה, ניהול תעבורה ותכונות ניתוב, ו-Cloud CDN) שבהן נעשה שימוש במאזן העומסים הראשי זמינות במאזן העומסים האזורי החיצוני של האפליקציות לגיבוי. אם תכונות דומות לא זמינות, יכול להיות שמאזן העומסים הזה לא מתאים לגיבוי במקרה של כשל.
- מגדירים את מאזני העומסים החיצוניים האזוריים לגיבוי: מגדירים מאזני עומסים חיצוניים אזוריים עצמאיים באזורים שבהם רוצים שהתעבורה תעבור לגיבוי. במאמר הגדרת מאזן עומסים חיצוני אזורי של אפליקציות עם קצה עורפי של קבוצת מכונות וירטואליות מוסבר איך להגדיר מאזן עומסים של אפליקציות (ALB) חיצוני אזורי.
- הגדרת ניתוב DNS ובדיקות תקינות: יוצרים בדיקת תקינות למאזן העומסים הראשי ומגדירים מדיניות ניתוב ליתירות כשל ב-Cloud DNS כדי לזהות הפסקות שירות ולנתב את תעבורת הלקוחות למאזני עומסים אזוריים לגיבוי.
הגדרת מעקף פעיל-פעיל
כדי להגדיר את ארכיטקטורת active-active: פועלים לפי השלבים הבאים:
בדיקת שיקולים לגבי הארכיטקטורה: לפני שיוצרים משאבים, כדאי לעיין בשיקולים לגבי איזון עומסים אזורי כדי לוודא תאימות של תכונות, ולוודא שהקיבולת של רשת המשנה של ה-proxy בלבד יכולה להתמודד עם תנועה במצב יציב ועם תנועת גיבוי במקרה של כשל.
הגדרת מאזני עומסים חיצוניים אזוריים של אפליקציות (ALB): לפני שמגדירים מאזני עומסים אזוריים, כדאי לעיין במאמר תאימות תכונות ומגבלות. פריסת מאזני עומסים חיצוניים אזוריים של אפליקציות בשני אזורים או יותר עם שירותי הקצה העורפי, כתובות IP חיצוניות, אישורי SSL ומדיניות אבטחה אזורית של Cloud Armor. הוראות להגדרה מפורטות במאמר הגדרת מאזן עומסים של אפליקציות (ALB) חיצוני אזורי עם קצה עורפי של קבוצת מכונות וירטואליות.
הגדרת DNS למאזני עומסים אזוריים: יוצרים רשומת DNS (לדוגמה,
regional-api.example.com) שמפנה לכתובות ה-IP החיצוניות של מאזני העומסים האזוריים החיצוניים של האפליקציות באמצעות מדיניות של ניתוב לפי מיקום גיאוגרפי או חביון. מפעילים בדיקת תקינות של DNS ברשומה הזו כדי לזהות כשל באזור ספציפי ולנתב באופן אוטומטי את תעבורת הנתונים ממנו לאזורים תקינים אחרים.מגדירים את מאזן העומסים הגלובלי החיצוני של האפליקציות (ALB): מזמינים כתובת IP חיצונית גלובלית ויוצרים קבוצת נקודות קצה ברשת האינטרנט (NEG) מסוג
INTERNET_FQDN_PORT. מוסיפים נקודת קצה לקבוצת נקודות הקצה ברשת האינטרנט שמפנה ל-FQDN של רשומת ה-DNS האזורית, לדוגמה,regional-api.example.com. מגדירים שירות לקצה העורפי למאזן עומסים גלובלי חיצוני של אפליקציות (ALB), מצרפים את ה-NEG של האינטרנט ומפעילים את Cloud CDN או את Cloud Armor אם נדרש. מגדירים את מיפוי כתובות ה-URL, את שרת ה-proxy של HTTP(S) ביעד ואת כלל ההעברה הגלובלי.הגדרת DNS למעבר לגיבוי ולבדיקות תקינות: יוצרים את רשומת ה-DNS של השירות הראשי (לדוגמה,
api.example.com) באמצעות מדיניות ניתובFAILOVER. מוודאים שלקבוצת הרשומות יש נקודת קצה ראשית שמפנה לכתובת ה-IP של מאזן העומסים החיצוני הגלובלי של אפליקציות (ALB), ונקודות קצה לגיבוי שמפנות לכתובות ה-IP של כתובות ה-IP החיצוניות של מאזני העומסים החיצוניים האזוריים של אפליקציות (ALB). מגדירים בדיקת תקינות של DNS כדי לעקוב אחרי מאזן העומסים הגלובלי החיצוני של אפליקציות (ALB).
שיטות מומלצות
כשמגדירים את רשומת ה-Cloud DNS ואת בדיקות התקינות, חשוב לזכור את השיטות המומלצות הבאות::
חישוב משך ההשבתה: הזמן שנדרש כדי שהתנועה תעבור מאיזון העומסים הראשי לאיזון העומסים של הגיבוי תלוי ב-TTL של ה-DNS, במרווח בין בדיקות התקינות ובפרמטר סף התקינות של בדיקת התקינות:
עם Cloud DNS של Google, אפשר לחשב את הגבול העליון של התקופה הזו באמצעות הנוסחה הבאה:
Duration of outage = DNS TTL + Health Check Interval * Unhealthy Thresholdמגדירים את ערך ה-TTL של ה-DNS ל-30 עד 60 שניות. ערכי TTL גבוהים יותר מובילים לזמני מעבר ארוכים יותר לגיבוי, כי לקוחות באינטרנט ממשיכים לגשת למאזני העומסים החיצוניים הראשיים של האפליקציות גם אחרי ש-DNS עבר לגיבוי של מאזן העומסים החיצוני האזורי של האפליקציות.
הגדרת ספי בדיקת התקינות: מגדירים את הפרמטרים healthy and unhealthy threshold כדי למנוע מעברים אוטומטיים בעקבות שגיאות רשת זמניות. סף גבוה יותר יגרום לכך שיידרך יותר זמן עד שהתנועה תעבור לגיבוי של מאזני העומסים.
שימוש בתעבורת נתונים מדורגת לאימות: מגדירים את הדגל
--backup-data-trickle-ratioכדי לשלוח באופן רציף אחוז קטן של תעבורת נתונים למאזני העומסים של הגיבוי, גם כשמאזני העומסים הראשיים תקינים. כך מוודאים שתשתית הגיבוי פעילה ומוכנה לטפל בתנועה. אפשר להגדיר את אחוז התנועה שנשלחת למאזני העומסים של הגיבוי כשבר בין 0 ל-1. הערך האופייני הוא 0.1, אבל Cloud DNS מאפשר לשלוח 100% מתעבורת הנתונים לכתובות ה-VIP של הגיבוי, כדי להפעיל יתירות כשל ידנית.בדיקה תקופתית של מעבר לגיבוי (failover) וחזרה מגיבוי (failback): כדאי לכלול בדיקה של מעבר לגיבוי בתוכנית להתאוששות מאסון. מוודאים שיש מעבר הדרגתי וגם מעבר פתאומי בתעבורת הנתונים ממאזני העומסים הראשיים למאזני העומסים של הגיבוי, ומוודאים שהתעבורה חוזרת בצורה חלקה למאזן העומסים הראשי אחרי מעבר חזרה.