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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    כדי לקבל את התוצאות הטובות ביותר, מומלץ להשתמש ב-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 שזמינים במאזני עומסים גלובליים, אזוריים וקלאסיים. פרטים נוספים מופיעים בסעיפים הבאים:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  2. יוצרים קבוצה של רשומות Cloud 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 של הגיבוי, כדי להפעיל יתירות כשל ידנית.