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

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

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

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

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

‫

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

הגדרת 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 נשלחות בקשות בדיקה לנתיב הבסיס, /. אם נקודות הקצה שנבדקות הן פרטיות, וזה לא אופייני לכתובות IP של כללי העברה חיצוניים, אפשר להגדיר את הנתיב הזה ל-/afhealthz.

2. ב-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) של הרשומה, בשניות. ערכים מומלצים מפורטים במאמר בנושא שיקולים לגבי DNS.
   • ‫RECORD_TYPE: סוג הרשומה. לדוגמה, A
   • ‫MANAGED_ZONE_NAME: השם של האזור המנוהל שרוצים לנהל את קבוצות הרשומות שלו, למשל my-zone-name
   • ‫FORWARDING_RULE_NAME: השמות של כללי ההעברה של מאזן העומסים בכל REGION
   • ‫REGION: האזורים שבהם כל מאזן עומסים נפרס

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

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

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

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

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

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

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