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

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

אסטרטגיות להשגת זמינות גבוהה

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

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

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

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

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

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

  

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

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

בקטעים הבאים מתואר איך בדיקות תקינות והפניית תנועה פועלות באזורים בתהליך עבודה טיפוסי:

1. שימוש בבדיקות תקינות כדי לזהות כשלים אזוריים

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

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

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

2. ניתוב תנועה על סמך מדיניות ניתוב

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

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

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

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

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

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

יצירת מאזני עומסים בכמה אזורים

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

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

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

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

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

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

יצירת בדיקת התקינות

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

הגדרת מעבר פעיל-סביל לגיבוי אזורי

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

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_REGIONAL_FORWARDING_RULE \
    --routing-policy-backup-data_type=GEO \
    --routing-policy-backup-data="BACKUP_REGION_1=BACKUP_LOAD_BALANCER_1_IP[;BACKUP_REGION_2=BACKUP_LOAD_BALANCER_2_IP]" \
    --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: השם של התחום המנוהל ב-Cloud DNS, למשל my-zone-name
• ‫PRIMARY_REGIONAL_FORWARDING_RULE: שם כלל ההעברה של מאזן העומסים הראשי החיצוני האזורי של אפליקציות (ALB)
• ‫BACKUP_REGION_1 ו-BACKUP_REGION_2: האזורים שבהם נפרסו מאזני העומסים החיצוניים האזוריים לגיבוי של האפליקציות
• ‫BACKUP_LOAD_BALANCER_1_IP ו-BACKUP_LOAD_BALANCER_2_IP: כתובות ה-IP החיצוניות של כלל ההעברה של מאזני העומסים החיצוניים האזוריים של האפליקציות לגיבוי
• ‫HEALTH_CHECK_NAME: השם של בדיקת התקינות
• ‫BACKUP_DATA_TRICKLE_RATIO: חלק מהתנועה (מ-0 עד 1, למשל 0.1) שיישלח למאזן העומסים האזורי לגיבוי במצב יציב, כדי לוודא שהגיבוי מוכן. ערך ברירת המחדל הוא 0.

הגדרת ניתוב בין אזורים פעילים

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

gcloud dns record-sets create DNS_RECORD_SET_NAME \
    --ttl=TIME_TO_LIVE \
    --type=RECORD_TYPE \
    --zone="MANAGED_ZONE_NAME" \
    --routing-policy-type="GEO" \
    --routing-policy-data="FORWARDING_RULE_NAME_A@REGION_A;FORWARDING_RULE_NAME_B@REGION_B[,;FORWARDING_RULE_NAME_C@REGION_C]" \
    --health-check=HEALTH_CHECK_NAME

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

• ‫DNS_RECORD_SET_NAME: ה-DNS או שם הדומיין של קבוצת הרשומות שרוצים להוסיף – לדוגמה, test.example.com
• ‫TIME_TO_LIVE: אורך החיים (TTL) של הרשומה, בשניות. ערכים מומלצים מפורטים במאמר בנושא שיטות מומלצות.
• ‫RECORD_TYPE: סוג הרשומה. לדוגמה, A
• ‫MANAGED_ZONE_NAME: השם של האזור המנוהל שרוצים לנהל את קבוצות הרשומות שלו, למשל my-zone-name
• ‫FORWARDING_RULE_NAME_A, ‏FORWARDING_RULE_NAME_B ו-FORWARDING_RULE_NAME_C: השמות של כללי ההעברה של מאזני העומסים בכל אזור תואם
• ‫REGION_A,‏ REGION_B ו-REGION_C: האזורים שבהם כל מאזן עומסים פרוס
• ‫HEALTH_CHECK_NAME: השם של בדיקת התקינות

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

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

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

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

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

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

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