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

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

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

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

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

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

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

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

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

  

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

במאמר הגדרת מאזן עומסים חיצוני אזורי של אפליקציות (ALB) עם קצוות עורפיים של קבוצות של מכונות וירטואליות מוסבר איך מגדירים מאזן עומסים חיצוני אזורי של אפליקציות (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: משך הזמן בשניות מתחילת בדיקה אחת שבוצעה על ידי בודק מסוים, ועד לתחילת הבדיקה הבאה שבוצעה על ידי אותו בודק. הערך המינימלי שנתמך הוא 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: האזורים שבהם נפרסו מאזני העומסים החיצוניים האזוריים של אפליקציות (ALB) לגיבוי
• ‫BACKUP_LOAD_BALANCER_1_IP ו-BACKUP_LOAD_BALANCER_2_IP: כתובות ה-IP החיצוניות של כללי ההעברה של מאזני העומסים החיצוניים האזוריים של אפליקציות (ALB) לגיבוי
• ‫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: השם של בדיקת התקינות

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

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