מעבר לגיבוי אוטומטי במאזני עומסים חיצוניים של אפליקציות (ALB)

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

יתירות כשל ומעבר חזרה לגיבוי הם תהליכים אוטומטיים שמנתבים תעבורת נתונים אל מאזן עומסים וממנו. כש-Cloud DNS מזהה הפסקת שירות ומנתב את התנועה ממאזן העומסים הראשי למאזן העומסים לגיבוי, התהליך נקרא מעבר לגיבוי (failover). כש-Cloud DNS מבטל את ההפניה הזו ומפנה את התנועה למאזן העומסים הראשי, התהליך נקרא חזרה למצב תקין.

איך מעבר לגיבוי עובד

מעבר גלובלי לגיבוי אזורי למאזני עומסים חיצוניים של אפליקציות מתבצע על ידי יצירה של שני מאזני עומסים חיצוניים אזוריים או יותר באזורים שרוצים שהתעבורה תעבור אליהם לגיבוי. אפשר להשתמש רק במאזני עומסים חיצוניים אזוריים של אפליקציות (ALB) כמאזני עומסים לגיבוי. מאזני עומסים חיצוניים אזוריים של אפליקציות (ALB) לא רק מוגבלים לאזורים ספציפיים שלGoogle Cloud , אלא גם מבודדים ממאזני עומסים חיצוניים גלובליים של אפליקציות (ALB) או מתשתית קלאסית של מאזני עומסים של אפליקציות שפועלים באותו אזור.

מאזני עומסים חיצוניים אזוריים של אפליקציות (ALB) מתאימים במיוחד כמאזני עומסים למעבר אוטומטי (failover) למאזני עומסים חיצוניים גלובליים של אפליקציות, כי שניהם מבוססים על שרתי proxy של Envoy ומעבדים תנועה בדרכים דומות מאוד. ההתנהגות הזו שונה מזו של מאזן עומסים קלאסי של אפליקציות (ALB), שבו יש הבדלים משמעותיים באופן הטיפול בתעבורת נתונים.

לסיכום, התרחישים הבאים של מעבר לגיבוי נתמכים:

  • ממאזן עומסים גלובלי חיצוני של אפליקציות למאזן עומסים חיצוני אזורי של אפליקציות
  • ממאזן עומסים חיצוני אזורי של אפליקציות (ALB) למאזן עומסים חיצוני אזורי של אפליקציות (ALB)
  • ממאזן עומסים קלאסי של אפליקציות (ALB) למאזן עומסים חיצוני אזורי של אפליקציות (ALB)

תהליך העבודה של מעבר לשירות גיבוי וחזרה לשירות המקורי

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

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

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

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

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

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

    הערות נוספות:

    • כשיוצרים את בדיקת תקינות, צריך לציין בדיוק שלושה אזורי מקור. רק בבדיקות תקינות גלובליות אפשר לציין אזורי מקור.
    • נתמכות בדיקות תקינות של HTTP,‏ HTTPS ו-TCP.
    • הבדיקות של תקינות השרתים מגיעות למעשה מנקודת נוכחות (PoP) באינטרנט, במרחק קצר מהאזור שמוגדר כמקור של Google Cloud.

  2. ניתוב תעבורה למאזני עומסים לגיבוי

    אם מאזן העומסים הראשי מתחיל להיכשל בבדיקות התקינות, Google Cloud המערכת משתמשת במדיניות הניתוב של Cloud DNS ליתירות כשל כדי לקבוע איך לנתב את התעבורה למאזני העומסים לגיבוי.

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

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

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

  4. בדיקת מעבר לשירות גיבוי באופן תקופתי

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

הגדרת מעבר לגיבוי

כדי להגדיר יתירות כשל, מבצעים את השלבים הבאים:

  1. בודקים את ההגדרה של מאזן העומסים הראשי הקיים ומוודאים שהתכונות (כמו תכונות אבטחה, ניהול תעבורה ותכונות ניתוב, ו-CDN) שבהן נעשה שימוש במאזן העומסים הראשי זמינות במאזן העומסים החיצוני האזורי של הגיבוי. אם תכונות דומות לא זמינות, יכול להיות שמאזן העומסים הזה לא מתאים לגיבוי.
  2. יוצרים מאזן עומסים חיצוני אזורי של אפליקציות לגיבוי עם הגדרה שמשקפת את מאזן העומסים הראשי ככל האפשר.
  3. יוצרים את בדיקת התקינות ואת מדיניות הניתוב של DNS כדי לזהות הפסקות שירות ולנתב את התנועה ממאזן העומסים הראשי למאזן העומסים של הגיבוי במהלך יתירות כשל.

בדיקת ההגדרות של מאזן העומסים הראשי

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

כדי להימנע מפקקים, חשוב לעיין בהבדלים הבאים:

  • פריסות GKE. משתמשי GKE צריכים לדעת שמאזני עומסים שנפרסו באמצעות GKE Gateway תואמים יותר למנגנון המעבר לגיבוי (failover) הזה מאשר מאזני עומסים שנפרסו באמצעות GKE Ingress controller. הסיבה לכך היא ש-GKE Gateway תומך בהגדרה של מאזני עומסים חיצוניים של אפליקציות (ALB) ברמה הגלובלית וברמה האזורית. עם זאת, בקר GKE Ingress תומך רק ב-Application Load Balancer הקלאסי.

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

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

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

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

  • Backend buckets. מאזני עומסים חיצוניים אזוריים של אפליקציות (ALB) לא תומכים בקטגוריות של Cloud Storage כבק-אנד. אי אפשר להגדיר מעבר לגיבוי (failover) למאזני עומסים באמצעות בקט של קצה עורפי.

הגדרת מאזן העומסים לגיבוי

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

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

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

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

    • ‫Classic Application Load Balancer. עם מאזן העומסים הקלאסי של אפליקציות (ALB), קשה יותר להשיג שוויון בתכונות בין מאזן העומסים הראשי לבין מאזן העומסים לגיבוי, כי מאזן העומסים החיצוני האזורי של אפליקציות (ALB) הוא מאזן עומסים מבוסס-Envoy שמבצע עיבוד שונה של התעבורה. חשוב לבדוק היטב את המעבר לגיבוי ואת החזרה מגיבוי לפני הפריסה בסביבת הייצור.

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

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

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

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

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

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

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

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

שמירת קיבולת נוספת של תת-רשת של שרת proxy בלבד

כל מאזני העומסים האזוריים שמבוססים על Envoy באזור וברשת VPC חולקים את אותו מאגר של שרתי proxy של Envoy. במקרה של מעבר לגיבוי (failover), מאזני העומסים החיצוניים האזוריים של האפליקציות לגיבוי רואים עלייה בשימוש בשרת proxy כדי לטפל בתנועה של מעבר לגיבוי ממאזן העומסים הראשי. כדי לוודא שהקיבולת תמיד תהיה זמינה למאזני העומסים של הגיבוי, מומלץ לבדוק את הגודל של תת-הרשת של שרת ה-proxy בלבד. מומלץ לחשב את מספר השרתים הפרוקסי המשוער שנדרש לטיפול בתנועה באזור מסוים, ולהגדיל את הקיבולת אם צריך. המידע הזה גם עוזר לוודא שאירועי מעבר לגיבוי לא משבשים מאזני עומסים אחרים אזוריים שמבוססים על Envoy באותו אזור ובאותה רשת.

באופן כללי, שרת proxy אזורי חיצוני של מאזן עומסים של אפליקציות (ALB) יכול לנהל עד:

  • ‫600 (HTTP) או 150 (HTTPS) חיבורים חדשים בשנייה
  • ‫3,000 חיבורים פעילים
  • ‫1,400 בקשות לשנייה

אם אתם משתמשים במדיניות DNS כדי לפצל את התעבורה בין כמה מאזני עומסים לגיבוי באזורים שונים, אתם צריכים לקחת את זה בחשבון כשאתם מעריכים את דרישות ה-proxy לכל אזור ולכל רשת. תת-רשת גדולה יותר של שרתי proxy מאפשרת ל-Google Cloud Envoy להקצות מספר גדול יותר של שרתי proxy למאזן העומסים שלכם כשצריך.

אי אפשר להרחיב רשת משנה שמוגדרת רק כפרוקסי באותה דרך שבה מרחיבים טווח כתובות ראשי (באמצעות הפקודה expand-ip-range). במקום זאת, צריך ליצור תת-רשת גיבוי של שרת proxy בלבד שתואמת לצרכים שלכם, ואז להעביר אותה לתפקיד הפעיל.

מידע נוסף על שינוי הגודל של רשת משנה מסוג proxy-only מופיע במאמר שינוי הגודל או טווח הכתובות של רשת משנה מסוג proxy-only.

שיתוף קצה עורפי בין מאזני עומסים ראשיים לבין מאזני עומסים לגיבוי

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

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

  • צריך להגדיר את הכלי לשינוי גודל אוטומטי כך שיבצע שינוי גודל רק על סמך השימוש במעבד. שיטת ההתאמה של איזון העומסים לפי ניצול לא נתמכת.
  • גם בשירותים הגלובליים וגם בשירותים האזוריים לקצה העורפי צריך להשתמש רק במצב האיזון UTILIZATION. לא מומלץ להשתמש במצב איזון RATE כי יכול להיות שהמכונות יקבלו תעבורת נתונים כפולה ממאזני עומסים גלובליים ואזוריים במהלך תהליך יתירות הכשל.
  • צריך להגדיר את אמצעי הבקרה של הקטנת הקיבולת כדי למנוע את הקטנת הקיבולת של הקבוצה על ידי קנה המידה האוטומטי לפני הזמן במהלך השבתה, כשמתבצע מעבר של התנועה ממאזן העומסים הגלובלי למאזן העומסים האזורי. זמן ההשבתה הזה יכול להיות ארוך כמו סכום ה-TTL של ה-DNS בתוספת מרווח בדיקת התקינות שהוגדר.

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

הגדרת Cloud DNS ובדיקות תקינות

בקטע הזה מוסבר איך להשתמש ב-Cloud DNS ובGoogle Cloud בדיקות תקינות כדי להגדיר את סביבת Cloud Load Balancing לזיהוי הפסקות שירות ולניתוב תנועה למאזני העומסים של הגיבוי.

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

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

    gcloud compute health-checks create http HEALTH_CHECK_NAME \
    --global \
    --source-regions=SOURCE_REGION_1,SOURCE_REGION_2,SOURCE_REGION_3 \
    --use-serving-port \
    --check-interval=HEALTH_CHECK_INTERVAL \
    --healthy-threshold=HEALTHY_THRESHOLD \
    --unhealthy-threshold=UNHEALTHY_THRESHOLD \
    --request-path=REQUEST_PATH

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫HEALTH_CHECK_NAME: השם של בדיקת התקינות
    • ‫SOURCE_REGION: שלושת Google Cloudהאזורים שמהם מתבצעות בדיקות התקינות. צריך לציין בדיוק שלושה אזורי מקור.
    • ‫HEALTH_CHECK_INTERVAL: משך הזמן בשניות מתחילת בקשה לבדיקת תקינות (probe) אחת שהונפקה על ידי בודק אחד ועד לתחילת בקשה לבדיקת תקינות (probe) הבאה שהונפקה על ידי אותו בודק. הערך המינימלי שנתמך הוא 30 שניות. ערכים מומלצים מפורטים במאמר בנושא שיטות מומלצות.
    • ‫HEALTHY_THRESHOLD ו-UNHEALTHY_THRESHOLD: מספר הבדיקות הרצופות שצריכות להצליח או להיכשל כדי שהמכונה הווירטואלית תיחשב תקינה או לא תקינה. אם אחד מהם לא מצוין, Google Cloud משתמשת בסף ברירת מחדל של 2.
    • ‫REQUEST_PATH: נתיב כתובת ה-URL שאליוGoogle Cloud שולח בקשות לבדיקת תקינות. אם לא מציינים את הנתיב, Google Cloud נשלחות בקשות בדיקה לנתיב הבסיס, /. אם נקודות הקצה שנבדקות הן פרטיות, מה שלא אופייני לכתובות IP של כללי העברה חיצוניים, אפשר להגדיר את הנתיב הזה ל-/afhealthz.

  2. יוצרים קבוצה של רשומות DNS ב-Cloud DNS ומחילים עליה מדיניות ניתוב. צריך להגדיר את מדיניות הניתוב כך שתפתור את שם הדומיין לכתובת ה-IP של כלל ההעברה של מאזן העומסים הראשי, או, במקרה של כשל בבדיקת תקינות, לכתובת ה-IP של כלל ההעברה של אחד ממאזני העומסים לגיבוי.

    gcloud dns record-sets create DNS_RECORD_SET_NAME \
    --ttl=TIME_TO_LIVE \
    --type=RECORD_TYPE \
    --zone="MANAGED_ZONE_NAME" \
    --routing-policy-type=FAILOVER \
    --routing-policy-primary-data=PRIMARY_LOAD_BALANCER_FORWARDING_RULE \
    --routing-policy-backup-data_type=GEO \
    --routing-policy-backup-data="BACKUP_REGION_1=BACKUP_LOAD_BALANCER_1_IP_ADDRESS[;BACKUP_REGION_2=BACKUP_LOAD_BALANCER_2_IP_ADDRESS;BACKUP_REGION_3=BACKUP_LOAD_BALANCER_3_IP_ADDRESS]" \
    --health-check=HEALTH_CHECK_NAME \
    --backup-data-trickle-ratio=BACKUP_DATA_TRICKLE_RATIO

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫DNS_RECORD_SET_NAME: ה-DNS או שם הדומיין של קבוצת הרשומות שרוצים להוסיף – לדוגמה, test.example.com
    • ‫TIME_TO_LIVE: אורך החיים (TTL) של קבוצת הרשומות, בשניות. ערכים מומלצים מפורטים במאמר בנושא שיטות מומלצות.
    • ‫RECORD_TYPE: סוג הרשומה. לדוגמה, A
    • ‫MANAGED_ZONE_NAME: השם של האזור המנוהל שרוצים לנהל את קבוצות הרשומות שלו – לדוגמה, my-zone-name
    • ‫PRIMARY_LOAD_BALANCER_FORWARDING_RULE: שם כלל ההעברה של מאזן העומסים הראשי
    • ‫BACKUP_REGION: האזורים שבהם מאזני העומסים לגיבוי נפרסים
    • ‫BACKUP_LOAD_BALANCER_IP_ADDRESS: כתובות ה-IP של כללי ההעברה של מאזני העומסים לגיבוי שמתאימים לכל אזור
    • ‫BACKUP_DATA_TRICKLE_RATIO: היחס בין נפח התנועה שיישלח למאזני העומסים לגיבוי, גם כשמאזן העומסים הראשי תקין. היחס צריך להיות בין 0 ל-1, למשל 0.1. ערך ברירת המחדל הוא 0.

שיטות מומלצות

ריכזנו כאן כמה שיטות מומלצות שכדאי לזכור כשמגדירים את רשומת Cloud DNS ואת בדיקות התקינות:

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

    עם Cloud DNS של Google, אפשר לחשב את הגבול העליון של התקופה הזו באמצעות הנוסחה הבאה:

    Duration of outage = DNS TTL + Health Check Interval * Unhealthy Threshold

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

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

  • כדי לוודא שההגדרה של יתירות כשל פועלת כמצופה, אפשר להגדיר את מדיניות ניתוב ה-DNS כך שתמיד יישלח אחוז קטן של תעבורת נתונים למאזני העומסים של הגיבוי, גם כשמאזני העומסים הראשיים תקינים. אפשר לעשות זאת באמצעות הפרמטר --backup-data-trickle-ratio כשיוצרים את קבוצת רשומות ה-DNS.

    אפשר להגדיר את אחוז התנועה שמועבר לגיבוי כשבר בין 0 ל-1. הערך האופייני הוא 0.1, אבל Cloud DNS מאפשר לשלוח 100 אחוז מתעבורת הנתונים לכתובות ה-VIP של הגיבוי, כדי להפעיל יתירות כשל ידנית.