כדי להגן מפני הפסקות בתשתית או שגיאות בהגדרות, אתם יכולים לתכנן אסטרטגיות של יתירות כשל למאזני עומסים גלובליים חיצוניים של אפליקציות (ALB). האסטרטגיות האלה משתמשות במאזני עומסים אזוריים חיצוניים של אפליקציות (ALB) ומנתבות אליהם תנועה ממאזן עומסים גלובלי חיצוני של אפליקציות (ALB), כדי לשמור על זמינות גבוהה בזמן הפסקות בתשתית הגלובלית או שגיאות בהגדרות האישיות.
בארכיטקטורה של יתירות כשל, פורסים מאזן עומסים ראשי ומאזן עומסים אחד או יותר לגיבוי:
- מאזן העומסים הראשי הוא מאזן העומסים הגלובלי החיצוני של אפליקציות (ALB) שמטפל בתנועה מהלקוחות במהלך הפעילות הרגילה.
- מאזן העומסים לגיבוי הוא מאזן עומסים חיצוני אזורי של אפליקציות (ALB) שמקבל תנועה כשמאזן העומסים הראשי נכשל בבדיקות התקינות.
מעבר אוטומטי במקרה של כשל וחזרה למצב תקין הם תהליכים אוטומטיים לניתוב תנועה:
- מעבר לגיבוי בעת כשל מתרחש כש-Cloud DNS מזהה הפסקה בשירות ומנתב את התנועה ממאזן העומסים הראשי למאזני העומסים לגיבוי.
- חזרה למצב תקין מתרחשת כש-Cloud DNS הופך את הניתוב הזה ומפנה מחדש את התנועה למאזן העומסים הראשי אחרי שבדיקות התקינות עוברות בהצלחה.
במסמך הזה מוסבר איך להגדיר יתירות כשל ממאזן עומסים גלובלי חיצוני של אפליקציות (ALB) למאזני עומסים אזוריים לגיבוי. אם אתם רוצים להגדיר יתירות כשל בין מאזני עומסים חיצוניים אזוריים של אפליקציות (ALB) באזורים שונים, קראו את המאמר זמינות גבוהה של מאזני עומסים חיצוניים אזוריים של אפליקציות (ALB).
למה כדאי להשתמש במאזני עומסים אזוריים לגיבוי במקרה כשל
מאזני עומסים חיצוניים אזוריים של אפליקציות (ALB) פועלים בצורה הטובה ביותר כמאזני עומסים ליתירות כשל של מאזני עומסים חיצוניים גלובליים של אפליקציות (ALB), בגלל המאפיינים הבאים:
- מאזני עומסים חיצוניים אזוריים של אפליקציות (ALB) הם עצמאיים בתוךGoogle Cloud אזורים נפרדים, והם גם מבודדים מכל תשתית של מאזן עומסים חיצוני גלובלי של אפליקציות שפועלת באותו אזור.
- מאזני עומסים חיצוניים של אפליקציות (ALB) ברמה האזורית וברמה הגלובלית מבוססים על שרתי proxy של Envoy, ומעבדים את התנועה בדרכים דומות.
כדי להטמיע יתירות כשל מגלובלי לאזורי במאזני עומסים חיצוניים גלובליים של אפליקציות, צריך ליצור שני מאזני עומסים אזוריים חיצוניים של אפליקציות או יותר באזורים שבהם רוצים להעביר את תעבורת הנתונים במקרה של כשל.
אסטרטגיות של יתירות כשל
כדי להטמיע יתירות כשל במאזני עומסים גלובליים חיצוניים של אפליקציות (ALB), אתם יכולים להשתמש באסטרטגיות הבאות:
- פעיל-סביל (יתירות כשל גלובלית-אזורית): אתם פורסים מאזן עומסים חיצוני אזורי אחד או יותר של אפליקציות (ALB) רק למטרות גיבוי. במצב יציב, Cloud DNS פותר את כתובת ה-IP של מאזן העומסים החיצוני הגלובלי של האפליקציות. אם מאזן העומסים הגלובלי נכשל, Cloud DNS מנתב את התנועה למאזני העומסים האזוריים לגיבוי. ההגדרה הזו משתמשת במדיניות ניתוב של יתירות כשל ב-Cloud DNS.
- פעיל-פעיל (מעקף גלובלי-אזורי): מאזן עומסים גלובלי חיצוני של אפליקציות (ALB) פועל כקצה קדמי (frontend) ומספק פונקציות של Cloud CDN, כמו שמירת נתונים במטמון קצה, שמעבירות בקשות למאזני עומסים אזוריים חיצוניים של אפליקציות (ALB) באמצעות קבוצות של נקודות קצה ברשת (NEG) עם שמות דומיינים שמוגדרים במלואם (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 מפעיל יתירות כשל.
- יתירות כשל: מדיניות הניתוב של יתירות הכשל ב-Cloud DNS מנתבת את תנועת הלקוחות ישירות למאזני העומסים החיצוניים האזוריים של האפליקציות לגיבוי. ההשפעה על זמן האחזור במהלך מעבר לגיבוי בעת כשל: מאזני עומסים אזוריים חיצוניים של אפליקציות סוגרים את החיבורים באזור ספציפי ב- Google Cloud , ולכן לקוחות שנמצאים רחוק מאזור היעד עשויים לחוות זמן אחזור ארוך יותר וזמני הלוך ושוב (RTT) ארוכים יותר בזמן שהמעבר לגיבוי בעת כשל פעיל.
- חזרה למצב תקין: אחרי שבדיקות התקינות מצליחות שוב, Cloud DNS משחזר באופן אוטומטי את התנועה למאזן העומסים הראשי בלי זמן השבתה, כי שני מאזני העומסים מטפלים בתנועה.
אסטרטגיית Active-active (מעקף מגלובלי לאזורי)
באסטרטגיית active-active, מאזן העומסים הגלובלי החיצוני של אפליקציות (ALB) משתמש ב-NEG מסוג FQDN באינטרנט (INTERNET_FQDN_PORT) כדי לשלוח תנועה למאזני עומסים אזוריים חיצוניים של אפליקציות (ALB) בשני אזורים או יותר.
איך פועל מעקף פעיל-פעיל
בהגדרה הבאה מוצג מעבר לגיבוי בעת כשל ממאזן עומסים גלובלי חיצוני של אפליקציות (ALB) לשני מאזני עומסים חיצוניים אזוריים של אפליקציות (ALB) לגיבוי, אחד בכל אזור שבו מאזן העומסים הגלובלי פרס את הקצוות העורפיים.
תהליך העבודה של יתירות כשל פעילה-פעילה:
- מצב יציב: התנועה זורמת מהלקוח אל מאזן העומסים הגלובלי החיצוני של אפליקציות (ALB).
מאזן העומסים הגלובלי משתמש בקבוצת נקודות קצה (NEG) ברשת עם FQDN באינטרנט מסוג
INTERNET_FQDN_PORTכדי להעביר את התנועה למאזני העומסים החיצוניים האזוריים הקרובים ביותר של אפליקציות (ALB). לאחר מכן, מאזני העומסים האזוריים מעבירים את תעבורת הנתונים לקצוות עורפיים מקומיים. - זיהוי כשלים: במצב יציב, אם מאזן עומסים חיצוני אזורי של אפליקציות (ALB) או האזור שלו נכשלים, מאזן העומסים החיצוני הגלובלי של אפליקציות (ALB) מזהה את הכשל באמצעות מדיניות בדיקת התקינות של Cloud DNS ב-NEG באינטרנט. מאזן העומסים הגלובלי מנתב באופן אוטומטי את התנועה מהאזור הלא תקין למאזני עומסים אזוריים תקינים.
- מעקף: אם יש הפסקה זמנית בפעילות של מאזן העומסים הגלובלי החיצוני של האפליקציות, כללי המדיניות של Cloud DNS לגיבוי במקרה כשל מזהים את הכשל ומנתבים את התנועה ישירות למאזני העומסים האזוריים החיצוניים של האפליקציות, תוך עקיפה מלאה של השכבה הגלובלית. ההשפעה על זמן האחזור במהלך המעקף: מאזן העומסים החיצוני הגלובלי של אפליקציות (ALB) מספק יתרונות לביצועים בקצה הרשת, כמו סגירת חיבורים קרוב יותר למשתמשים ושמירה במטמון קצה. כשתעבורת הנתונים עוקפת את מאזן העומסים הגלובלי, החיבורים של הלקוחות נוצרים ישירות עם כתובות ה-VIP האזוריות, מה שיכול להגדיל את זמן האחזור של החיבור ואת ה-RTT ללקוחות שנמצאים רחוק מבחינה גיאוגרפית.
- חזרה למצב תקין: כשמאזן העומסים הגלובלי עובר בדיקות תקינות ברצף, Cloud DNS מחזיר באופן אוטומטי את ה-VIP הגלובלי של Anycast בתגובות ה-DNS, ומשחזר את שכבת הניתוב הגלובלית בקצה הרשת.
בדיקת ההגדרות של מאזן העומסים הראשי
לפני שמגדירים את יתירות הכשל, צריך לוודא שמאזן העומסים החיצוני האזורי של אפליקציות (ALB) לגיבוי תומך בתכונות שבהן משתמש מאזן העומסים הראשי.
- במצב פעיל-פסיבי, מאזן העומסים האזורי לגיבוי צריך לתמוך בתכונות דומות כדי להשתלט על התנועה בצורה חלקה במהלך הפסקה זמנית בשירות.
- במצב פעיל-פעיל, צריך להגדיר את כללי הניתוב והאבטחה העיקריים ישירות ברמה האזורית, ואילו התכונות הגלובליות של הקצה, כמו Cloud CDN, נעקפות במהלך הפסקה גלובלית.
| תכונה | דרישות תאימות |
|---|---|
| פריסות של Google Kubernetes Engine | משתמשים ב-GKE Gateway כדי לפרוס גם מאזני עומסים ראשיים וגם מאזני עומסים לגיבוי. הסיבה לכך היא שמאזני עומסים שנפרסו באמצעות GKE Gateway תואמים יותר למנגנון יתירות הכשל הזה מאשר מאזני עומסים שנפרסו באמצעות בקר GKE Ingress. בקר ה-Ingress של GKE תומך רק במאזן העומסים הקלאסי של אפליקציות (ALB). |
| Cloud CDN | מאזני עומסים חיצוניים אזוריים של אפליקציות (ALB) לא תומכים ב-Cloud CDN. אם מתרחש יתירות כשל, הפעולות שמסתמכות על Cloud CDN מושפעות. |
| Cloud Armor | אם אתם משתמשים ב-Cloud Armor במאזן העומסים הראשי, הגדירו כללי מדיניות אבטחה אזוריים מקבילים של Cloud Armor במאזני העומסים לגיבוי. ב-Cloud Armor יש תכונות שונות שזמינות בהיקף אזורי לעומת היקף גלובלי. מידע נוסף זמין במאמרים מדיניות אבטחה אזורית של Cloud Armor ומדיניות אבטחה גלובלית של Cloud Armor. |
| אישורי SSL | מוודאים שסוג אישור ה-SSL שמשמש את מאזן העומסים הראשי תואם למאזן העומסים החיצוני האזורי של אפליקציות (ALB) לגיבוי. בטבלה הבאה מפורטים ההבדלים בין אישורי ה-SSL שזמינים במאזני עומסים גלובליים, אזוריים וקלאסיים. מידע נוסף זמין במאמרים אישורי SSL של Compute Engine ואישורי SSL של Certificate Manager. |
שיקולים לגבי מאזני עומסים אזוריים
מגדירים ופורסים מאזני עומסים חיצוניים אזוריים של אפליקציות (ALB) באזור שאליו רוצים להפנות את התנועה במקרה של כשל.
כשמגדירים את מאזן העומסים האזורי, חשוב לשים לב לשיקולים הבאים לגבי ארכיטקטורות של יתירות כשל או מעקף:
אתם צריכים להגדיר את התכונות של מאזן העומסים האזורי החיצוני של אפליקציות (ALB) לגיבוי כך שיהיו דומות ככל האפשר למאזן העומסים הראשי, כדי שהתנועה תעובד באופן דומה בשני הפריסות.
מאזן עומסים גלובלי חיצוני של אפליקציות (ALB). מאזני עומסים חיצוניים אזוריים של אפליקציות (ALB) תומכים ברוב התכונות של מאזני עומסים חיצוניים גלובליים של אפליקציות (ALB), עם כמה יוצאים מן הכלל. מאזן העומסים האזורי תומך גם באותן יכולות מתקדמות של ניהול תעבורת נתונים כמו מאזן העומסים הגלובלי, וכך קל יותר להשיג שוויון בין מאזני העומסים הראשיים והמשניים.
מאזן עומסים קלאסי של אפליקציות (ALB). במאזן העומסים הקלאסי של אפליקציות (ALB), קשה יותר להשיג שוויון בתכונות בין מאזן העומסים הראשי לבין מאזן העומסים לגיבוי, כי מאזן העומסים החיצוני האזורי של אפליקציות (ALB) הוא מאזן עומסים מבוסס-Envoy שמעבד את התנועה באופן שונה. חשוב לבדוק ביסודיות את יתירות הכשל ואת החזרה למצב תקין לפני הפריסה בסביבת הייצור.
כדי לראות את היכולות הספציפיות של מאזני העומסים של אפליקציות (ALB) ברמה האזורית, הגלובלית והקלאסית, קראו את דף ההשוואה בין התכונות של מאזני העומסים.
מומלץ להשתמש במסגרת אוטומציה כמו Terraform כדי להשיג ולשמור על עקביות בהגדרות של מאזני העומסים בפריסות הראשיות ובפריסות הגיבוי.
מאזני עומסים חיצוניים אזוריים של אפליקציות (ALB) תומכים גם במסלול פרימיום וגם במסלול רגיל של Network Service Tiers. אם זמן האחזור הוא לא הדאגה העיקרית שלכם במהלך יתירות כשל, מומלץ להגדיר את מאזני העומסים האזוריים החיצוניים של אפליקציות (ALB) לגיבוי באמצעות מסלול Standard. השימוש בתשתית של מסלול Standard מציע בידוד נוסף מהתשתית של מסלול פרימיום, שמשמשת מאזני עומסים חיצוניים גלובליים של אפליקציות (ALB).
חשוב לוודא שתת-הרשת של שרת ה-proxy בלבד גדולה מספיק כדי להתמודד עם העלייה בתעבורת הנתונים במהלך אירוע של יתירות כשל, בלי לשבש את הפעילות של מאזני עומסים אזוריים אחרים באותו אזור ובאותה רשת. לפרטים, ראו הזמנת קיבולת נוספת של רשת משנה לשרתי proxy בלבד.
במאמר הגדרת מאזן עומסים חיצוני אזורי של אפליקציות (ALB) עם קצוות עורפיים של קבוצות של מכונות וירטואליות מוסבר איך להגדיר מאזן עומסים חיצוני אזורי של אפליקציות (ALB).
הקצאת קיבולת נוספת לתת-רשת של שרת proxy בלבד
כל מאזני העומסים האזוריים מבוססי-Envoy באזור וברשת VPC חולקים את אותו מאגר של שרתי proxy של Envoy. באירוע של יתירות כשל, במאזני העומסים החיצוניים האזוריים של אפליקציות (ALB) לגיבוי יש עלייה בשימוש בשרת proxy כדי לטפל בתנועה של יתירות כשל ממאזן העומסים הראשי. כך אפשר להבטיח שאירועי יתירות כשל לא ישבשו מאזני עומסים אזוריים אחרים שמבוססים על Envoy באותו אזור ורשת.
כדי לוודא שתמיד יש קיבולת זמינה למאזני העומסים לגיבוי, בדקו את הגודל של תת-הרשת של שרת ה-proxy בלבד. מומלץ לחשב את המספר המשוער של שרתי ה-proxy שנדרשים כדי לטפל בתנועה באזור מסוים, ולהגדיל את הקיבולת לפי הצורך. למידע נוסף על מגבלות הקיבולת של שרתי proxy וחישובי גודל, קראו את הקטע חיוב על מכונות proxy במאמר "תמחור של Cloud Load Balancing".
אם אתם משתמשים בכללי מדיניות DNS כדי לפצל את התנועה בין כמה מאזני עומסים לגיבוי באזורים שונים, אתם צריכים לקחת את זה בחשבון כשאתם מעריכים את דרישות ה-proxy לכל אזור ורשת. תת-רשת גדולה יותר של שרתי proxy בלבד מאפשרת ל-Google Cloud להקצות מספר גדול יותר של שרתי proxy של Envoy למאזן העומסים, במקרה הצורך.
אי אפשר להרחיב רשת משנה של שרתי proxy בלבד באותו אופן שבו מרחיבים טווח כתובות ראשי (באמצעות הפקודה expand-ip-range). במקום זאת, צריך ליצור רשת משנה לגיבוי של שרתי proxy בלבד שעונה על הצרכים שלכם, ואז לקדם אותה לתפקיד הפעיל.
במאמר שינוי הגודל או טווח הכתובות של רשת משנה proxy-only מוסבר איך משנים את הגודל של רשת משנה proxy-only.
שיתוף של קצוות עורפיים בין מאזני עומסים ראשיים ומשניים
כדי להשיג יתירות תשתיתית מלאה, צריך להוסיף יתירות גם ברמת מאזן העומסים וגם ברמת הקצה העורפי. כלומר, צריך להגדיר את מאזני העומסים האזוריים החיצוניים של אפליקציות לגיבוי עם קצוות עורפיים (קבוצות של מכונות או קבוצות של נקודות קצה ברשת) שלא חופפים למאזני העומסים הראשיים.
אם אתם בוחרים להשתמש באותם רכיבי בק-אנד גם למאזן העומסים הראשי וגם למאזן העומסים לגיבוי, אתם צריכים ליצור כל מאזן עומסים אזורי חיצוני לגיבוי של אפליקציות (ALB) באזור שבו נמצאים רכיבי הבק-אנד האלה. בנוסף, אם הפעלתם התאמה אוטומטית לעומס בקבוצות של המכונות, אתם צריכים לעמוד בדרישות הבאות כדי לוודא שיתירות הכשל תפעל כמו שצריך:
- מגדירים את הכלי להתאמה לעומס (autoscaler) עם התאמה לעומס שמבוססת על מעבד (CPU) בלבד. אי אפשר לבצע התאמה לעומס (autoscaling) על סמך ניצול של מאזן העומסים.
- השירותים לקצה העורפי, גם הגלובליים וגם האזוריים, חייבים להשתמש רק במצב האיזון
UTILIZATION. אל תשתמשו במצב האיזוןRATE, כי המכונות שלכם עלולות לקבל פי 2 תנועה גם ממאזני עומסים גלובליים וגם ממאזני עומסים אזוריים במהלך תהליך יתירות הכשל. - מגדירים אמצעי בקרה לצמצום בהתאם לעומס (scale-in) כדי למנוע מהמידרוג האוטומטי לצמצם את הקבוצה מוקדם מדי במהלך זמן ההשבתה, כשתעבורת הנתונים עוברת ממאזן העומסים הגלובלי למאזן העומסים האזורי. זמן ההשבתה הזה יכול להיות ארוך כמו הסכום של DNS TTL (זמן חיים) בתוספת מרווח הזמן שהוגדר לבדיקת התקינות.
אם לא מגדירים נכון את ההתאמה האוטומטית לעומס, יכולה להתרחש הפסקה משנית בשירות במהלך יתירות כשל, כי אובדן התנועה ממאזן העומסים הגלובלי גורם לקבוצת המכונות להתכווץ במהירות לפני שמאזן העומסים האזורי משתלט.
הגדרת יתירות כשל פעילה-סבילה
כדי להגדיר יתירות כשל פעילה-סבילה:
- שיקולים שקשורים לארכיטקטורה: לפני שיוצרים משאבים, כדאי לעיין בשיקולים שקשורים למאזני עומסים אזוריים כדי לוודא שהתכונות תואמות, שקיבולת שרת ה-proxy מתאימה ושהדרישות של המערכת המשותפת להתאמה אוטומטית לעומס של קצה עורפי מתקיימות.
- הגדרת מאזן העומסים הראשי: מגדירים את מאזן העומסים החיצוני הגלובלי של האפליקציות עם שירותי קצה עורפי שפרוסים באזור אחד או יותר. איך מגדירים מאזן עומסים גלובלי חיצוני של אפליקציות (ALB)
- בדיקת ההגדרות של מאזן העומסים הראשי: ודאו שהתכונות (כמו אמצעי אבטחה, ניהול תעבורת נתונים, תכונות ניתוב ו-Cloud CDN) שבהן משתמש מאזן העומסים הראשי זמינות במאזן העומסים האזורי החיצוני של אפליקציות (ALB) לגיבוי. אם אין תכונות דומות, יכול להיות שמאזן העומסים הזה לא מתאים ליתירות כשל.
- הגדרת מאזני עומסים חיצוניים אזוריים של אפליקציות (ALB) לגיבוי: מגדירים מאזני עומסים חיצוניים אזוריים של אפליקציות (ALB) עצמאיים באזורים שבהם רוצים שתעבורת הנתונים תעבור במקרה של כשל. במאמר הגדרת מאזן עומסים חיצוני אזורי של אפליקציות (ALB) עם קצוות עורפיים של קבוצות של מכונות וירטואליות מוסבר איך מגדירים מאזן עומסים חיצוני אזורי של אפליקציות (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. מוסיפים נקודת קצה ל-NEG באינטרנט שמפנה ל-FQDN של רשומת ה-DNS האזורית, לדוגמהregional-api.example.com. מגדירים שירות לקצה העורפי של מאזן העומסים החיצוני הגלובלי של אפליקציות (ALB), מצרפים את קבוצת נקודות הקצה לאינטרנט ומפעילים את Cloud CDN או את Cloud Armor לפי הצורך. מגדירים את מפת URL, את שרת ה-proxy של HTTP(S) ביעד ואת כלל ההעברה הגלובלי.הגדרת DNS ליתירות כשל ולבדיקות תקינות: יוצרים את רשומת ה-DNS של השירות הראשי (לדוגמה,
api.example.com) באמצעות מדיניות ניתוב שלFAILOVER. חשוב לוודא שלקבוצת הרשומות יש נקודת קצה ראשית שמפנה לכתובת ה-IP של מאזן העומסים החיצוני הגלובלי של אפליקציות (ALB), ונקודות קצה לגיבוי שמפנות לכתובות ה-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 לגיבוי, כדי להפעיל ידנית יתירות כשל.בדיקה תקופתית של יתירות כשל ושל חזרה למצב תקין: כדאי לכלול בדיקות של יתירות כשל בתוכנית ההתאוששות מאסון (DR). בודקים גם שינויים הדרגתיים וגם שינויים פתאומיים בתנועה ממאזני העומסים הראשיים למאזני העומסים לגיבוי, ומוודאים שהתנועה חוזרת בצורה חלקה למאזן העומסים הראשי אחרי החזרה למצב תקין.