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

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

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

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

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

דוגמאות לתרחישי שימוש

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

היגוי תעבורת נתונים: ניתוב מבוסס-כותרת

הפניית תנועה מאפשרת לכם להפנות תנועה למופעי שירות על סמך פרמטרים של HTTP, כמו כותרות בקשה. לדוגמה, אם המכשיר של המשתמש הוא מכשיר נייד עם user-agent:Mobile בכותרת הבקשה, ניתוב התנועה יכול לשלוח את התנועה הזו למופעי שירות שמוגדרים לטפל בתנועה ממכשירים ניידים, ולשלוח תנועה ללא user-agent:Mobile למופעים שמוגדרים לטפל בתנועה ממכשירים אחרים.

הפניית תנועה ב-Cloud Load Balancing. — **איור 1.** הפניית תנועה ב-Cloud Load Balancing (לחצו כדי להגדיל).

פעולות שקשורות לתנועה: פיצול תנועה על סמך משקל

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

לדוגמה, אפשר לשלוח 95% מהתנועה לגרסה הקודמת של השירות ו-5% לגרסה החדשה של השירות. אחרי שמוודאים שגרסת הייצור החדשה פועלת כמצופה, אפשר להגדיל בהדרגה את אחוז התנועה עד ש-100% מהתנועה יגיעו לגרסה החדשה של השירות. בדרך כלל משתמשים בפיצול תנועה כדי לפרוס גרסאות חדשות, לבצע בדיקות A/B, להעביר שירותים ולבצע תהליכים דומים.

פיצול תנועה ב-Cloud Load Balancing. — **איור 2.** חלוקת תנועה ב-Cloud Load Balancing (לחצו כדי להגדיל).

מדיניות תנועה: בקשת שיקוף

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

הרחבה באמצעות Service Extensions

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

אפשר להגדיר את התוספים האלה בנקודות שונות בנתיב העיבוד: הרשאה, קצה, ניתוב ותנועה.

אפשר גם להשתמש ב-Service Extensions כדי להגדיר תכונות מתקדמות, כמו העברה דינמית.

מידע נוסף זמין במאמר סקירה כללית של Service Extensions.

רכיבים של ניהול טראפיק

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

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

אפשר להגדיר ניהול תנועה ופעולות שקשורות לתנועה באמצעות מיפויי כתובות URL. Google Cloud המשאבים שמשויכים למיפויי כתובות URL כוללים את המשאבים הבאים:

כלל ניתוב
התאמה של כלל
פעולת הכלל

אפשר להגדיר מדיניות תנועה באמצעות שירותי קצה עורפי. Google Cloud משאבים שמשויכים לשירותי קצה עורפי כוללים את המשאבים הבאים:

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

בתרשים הבא מוצגים המשאבים שמשמשים להטמעה של כל תכונה.

מודל הנתונים של Cloud Load Balancing. — **איור 3.** מודל הנתונים של Cloud Load Balancing (לחצו כדי להגדיל).

הפניית בקשות לשרתי קצה עורפיים

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

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

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

כלל פשוט של מארח ונתיב
כלל מתקדם של מארח, נתיב ומסלול

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

כלל פשוט של מארח ונתיב

בכלל פשוט של מארח ונתיב, מפות URL פועלות כמו שמתואר בסקירה הכללית על מפות URL.

הדיאגרמה הבאה מציגה את התהליך הלוגי של כלל פשוט של אירוח ונתיב.

תרשים זרימה של מפת URL עם כלל פשוט של מארח ונתיב. — **איור 4.** תרשים של זרימת נתונים במפת URL עם כלל פשוט של מארח ונתיב (אפשר ללחוץ כדי להגדיל).

ההערכה הראשונית של הבקשה מתבצעת באמצעות כללי מארח. המארח הוא הדומיין שצוין בבקשה. אם הבקשה host תואמת לאחת מהרשומות בשדה hosts, נעשה שימוש בכלי להתאמת נתיבים שמשויך לרשומה.

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

כלל פשוט טיפוסי של מארח ונתיב יכול להיראות כך, כאשר תנועת הצפייה בסרטונים מועברת אל video-backend-service, וכל שאר התנועה מועברת אל web-backend-service.

gcloud compute url-maps describe lb-map

defaultService: regions/us-west1/backendServices/web-backend-service
hostRules:
- hosts:
  - '*'
  pathMatcher: pathmap
name: lb-map
pathMatchers:
- defaultService: regions/us-west1/backendServices/web-backend-service
  name: pathmap
  pathRules:
  - paths:
    - /video
    - /video/*
    service: regions/us-west1/backendServices/video-backend-service
region: regions/us-west1

כלל מתקדם של מארח, נתיב ומסלול

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

כמו בדוגמה הפשוטה הקודמת של כלל מארח ונתיב, אפשר להגדיר ניהול תנועה מתקדם באמצעות מפת URL. לדוגמה, במפת ה-URL הבאה מוגדר ניתוב שבו 95% מהתנועה מנותבים לשירות קצה עורפי אחד, ו-5% מהתנועה מנותבים לשירות קצה עורפי אחר.

gcloud compute url-maps describe lb-map

defaultService: regions/us-west1/backendServices/service-a
hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
name: lb-map
pathMatchers:
- defaultService: regions/us-west1/backendServices/service-a
  name: matcher1
  routeRules:
  - matchRules:
    - prefixMatch: ''
    routeAction:
      weightedBackendServices:
      - backendService: regions/us-west1/backendServices/service-a
        weight: 95
      - backendService: regions/us-west1/backendServices/service-b
        weight: 5
region: regions/us-west1

כללים למארחים

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

מידע נוסף מופיע במאמרי העזרה בנושא hostRules[] ו-defaultService של regional URL map API documentation.

דפוסי נתיבים

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

התאמה של נתיבים מורכבת מהרכיבים הבאים:

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

מידע נוסף מופיע במאמרים pathMatchers[], pathMatchers[].pathRules[] ו-pathMatchers[].routeRules[] במסמכי התיעוד של API של מפת URL אזוריות.

כללי הנתיבים

כללי נתיב (pathRules) מציינים נתיב URL אחד או יותר, כמו / או /video. כללי נתיב מיועדים בדרך כלל לסוג הניתוב הפשוט שמבוסס על מארח ונתיב שתואר קודם.

מידע נוסף מופיע בpathRules[] במסמכי העזרה בנושא מפת URL אזורית API.

כללי ניתוב

כלל ניתוב (routeRules) מתאים למידע בבקשה נכנסת ומקבל החלטה לגבי ניתוב על סמך ההתאמה.

כללי ניתוב יכולים להכיל מגוון של כללי התאמה שונים (matchRules) ומגוון של פעולות ניתוב שונות (routeAction).

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

הערה: האפשרויות והסמנטיקה של ההתאמה משתנות בהתאם לחלק של הבקשה שאתם מתאימים. מידע נוסף מופיע בmatchRules[] במסמכי העזרה בנושא מפת URL אזורית API.

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

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

הקודGoogle Cloud מבצע את הפעולות הבאות:

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

לכללי ניתוב יש כמה רכיבים, כמו שמתואר בטבלה הבאה.

רכיב של כלל ניתוב (`API field name`)	תיאור
עדיפות (`priority`)	מספר מ-0 עד 2,147,483,647 (כלומר, (2^31)-1) שמוקצה לכלל ניתוב בתוך התאמת נתיב נתונה. העדיפות קובעת את סדר ההערכה של כללי הניתוב. העדיפות של כלל יורדת ככל שהמספר שלו עולה, כך שכלל עם עדיפות `4` מוערך לפני כלל עם עדיפות `25`. הכלל הראשון שתואם לבקשה יופעל. יכולים להיות פערים במספרי העדיפות. אי אפשר ליצור יותר מכלל אחד עם אותה עדיפות.
תיאור (`description`)	תיאור אופציונלי באורך של עד 1,024 תווים.
שירות (`service`)	כתובת ה-URL המלאה או החלקית של משאב שירות לקצה העורפי שאליו התנועה מופנית אם הכלל הזה מתאים.
כללי התאמה (`matchRules`)	כלל אחד או יותר שמוערכים ביחס לבקשה. התנאים האלה `matchRules` יכולים להתאים לכל המאפיינים של בקשת ה-HTTP או לחלק מהם, כמו הנתיב, כותרות ה-HTTP והפרמטרים של השאילתה (GET). בתוך `matchRule`, כל הקריטריונים התואמים צריכים להתקיים כדי ש`routeActions` של `routeRule` יופעל. אם ל-`routeRule` יש כמה `matchRules`, ה-`routeActions` של `routeRule` יופעל אם בקשה תתאים לאחד מ-`matchRules` של `routeRule`.
פעולת ניתוב (`routeAction`)	מאפשרת לציין אילו פעולות יתבצעו כשמתקיימים הקריטריונים של כלל ההתאמה. הפעולות האלה כוללות פיצול תנועה, שכתוב של כתובות URL, ניסיון חוזר ושיקוף, הזרקת תקלות ומדיניות CORS.
פעולת הפניה אוטומטית (`urlRedirect`)	אפשר להגדיר פעולה שתגיב בהפניה אוטומטית של HTTP כשמתקיימים הקריטריונים של כלל ההתאמה. אי אפשר להשתמש בשדה הזה בשילוב עם פעולת ניתוב.
פעולה בכותרת (`headerAction`)	אפשר להגדיר כללי טרנספורמציה של כותרות בקשות ותגובות כשמתקיימים הקריטריונים ב-`matchRules`.

מידע נוסף מופיע במסמכי העזרה בנושא מפת URL אזורית API בשדות הבאים:

routeRules[]
routeRules[].priority
routeRules[].description
routeRules[].service
routeRules[].matchRules[]
routeRules[].routeAction
routeRules[].urlRedirect
routeRules[].headerAction

כללי התאמה

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

מארח: שם המארח הוא החלק של שם הדומיין בכתובת URL. לדוגמה, שם המארח בכתובת ה-URL ‏http://example.net/video/hd הוא example.net. בבקשה, שם המארח מגיע מהכותרת Host, כמו שמוצג בפקודת curl לדוגמה הזו, שבה 10.1.2.9 היא כתובת ה-IP של איזון העומסים:
```
curl -v http://10.1.2.9/video/hd --header 'Host: example.com'
```
הנתיבים מופיעים אחרי שם המארח – לדוגמה, /images. בכלל אפשר לציין אם כל הנתיב או רק החלק הראשון של הנתיב צריכים להיות זהים.
פרמטרים אחרים של בקשת HTTP, כמו כותרות HTTP, שמאפשרים התאמה של קובצי Cookie, וגם התאמה על סמך פרמטרים של שאילתה (משתני GET).

רשימה מלאה של כללי ההתאמה הנתמכים זמינה בpathMatchers[].routeRules[].matchRules[] במסמכי התיעוד של ה-API של מפת URL אזורית.

פעולות שקשורות למסלול

פעולות ניתוב הן פעולות ספציפיות שמתבצעות כשכלל ניתוב תואם למאפיינים של בקשה.

פעולת ניתוב (`API field name`)	תיאור
הפניות אוטומטיות (`urlRedirect`)	מחזירה קוד תגובה ניתן להגדרה 3xx. הוא גם מגדיר את כותרת התגובה `Location` עם ה-URI המתאים, ומחליף את המארח והנתיב כמו שצוין בפעולת ההפניה.
שינוי כתובות URL (`urlRewrite`)	הכתיבה מחדש של החלק של שם המארח בכתובת ה-URL, החלק של הנתיב בכתובת ה-URL או שניהם, לפני שליחת בקשה לשירות לקצה העורפי שנבחר.
שינויים בכותרות (`headerAction`)	הוספה או הסרה של כותרות בקשה לפני שליחת בקשה לשירות הקצה העורפי. אפשר גם להוסיף או להסיר כותרות תגובה אחרי שמקבלים תגובה משירות לקצה העורפי. ניסיון להוסיף ולהסיר את אותה כותרת יגרום להסרת הכותרת, אלא אם משתמשים בדגל `replace: True` עם הפעולה `requestHeadersToAdd`.
שיקוף תנועה (`requestMirrorPolicy`)	בנוסף להעברת הבקשה לשירות הקצה העורפי שנבחר, המערכת שולחת בקשה זהה לשירות הקצה העורפי המשוכפל שהוגדר על בסיס שליחה ללא אישור קבלה. מאזן העומסים לא מחכה לתגובה מהקצה העורפי שאליו הוא שולח את הבקשה המשוכפלת. שיכפול שימושי לבדיקת גרסה חדשה של שירות קצה עורפי. אפשר להשתמש בה גם כדי לנפות באגים בשגיאות בייצור בגרסת ניפוי הבאגים של שירות הקצה העורפי, במקום בגרסת הייצור. חשוב לשים לב למגבלות הבאות כשמשתמשים בשיקוף תנועה: שיקוף תנועה נתמך אם לשני שירותי הקצה העורפי יש קבוצות מופעי מכונה מנוהלים, קצה עורפי של NEGs אזוריים או קצה עורפי של NEGs היברידיים. אין תמיכה ב-NEGs לאינטרנט, ב-NEGs בלי שרת (serverless) ובקצה עורפי (backend) של Private Service Connect. בקשות לשירות לקצה העורפי המשוכפל לא יוצרות יומנים או מדדים עבור Cloud Logging ו-Cloud Monitoring.
חלוקת תנועה משוקללת (`weightedBackendServices`)	מאפשרת להפיץ תנועה של כלל תואם לכמה שירותים לקצה העורפי, באופן יחסי למשקל שהוגדר על ידי המשתמש והוקצה לכל שירות לקצה העורפי. היכולת הזו שימושית להגדרת פריסות מדורגות או בדיקות A/B. לדוגמה, אפשר להגדיר את פעולת המסלול כך ש-99% מהתנועה יישלחו לשירות שמריץ גרסה יציבה של אפליקציה, ו-1% מהתנועה יישלחו לשירות נפרד שמריץ גרסה חדשה יותר של אותה אפליקציה.
ניסיונות חוזרים (`retryPolicy`)	היא מגדירה את התנאים שבהם מאזן העומסים מנסה שוב בקשות שנכשלו, את משך ההמתנה של מאזן העומסים לפני הניסיון החוזר ואת המספר המקסימלי של ניסיונות חוזרים שמותרים. מידע נוסף על ניסיונות חוזרים זמין בקטע ניסיונות חוזרים בדף סקירה כללית של הפצת בקשות.
תם הזמן הקצוב (`timeout`)	מציינת את הזמן הקצוב לתפוגה של הנתיב שנבחר. הזמן הקצוב לתפוגה מחושב מהרגע שבו הבקשה עוברת עיבוד מלא ועד הרגע שבו התשובה עוברת עיבוד מלא. הזמן הקצוב לתפוגה כולל את כל הניסיונות החוזרים.
הזרקת תקלות (`faultInjectionPolicy`)	הוספת שגיאות כשמטפלים בבקשות כדי לדמות כשלים, כולל זמן אחזור גבוה, עומס יתר על השירות, כשלים בשירות וחלוקת הרשת למחיצות. התכונה הזו שימושית לבדיקת העמידות של שירות בפני תקלות מדומה.
הוספת עיכוב (`faultInjectionPolicy`)	הוספת עיכובים לחלק מהבקשות שמוגדר על ידי המשתמש לפני שליחת הבקשה לשירות העורפי שנבחר.
ביטול ההוספה (`faultInjectionPolicy`)	מגיב ישירות לחלק מהבקשות עם קודי מצב HTTP שהוגדרו על ידי המשתמש, במקום להעביר את הבקשות האלה לשירות לקצה העורפי.
מדיניות אבטחה (`corsPolicy`)	מדיניות שיתוף משאבים בין מקורות (CORS) מטפלת בהגדרות לאכיפת בקשות CORS.

אפשר לציין אחת מהפעולות הבאות של המסלול:

הפניית תנועה לשירות יחיד (service).
פיצול התנועה בין כמה שירותים (weightedBackendServices weight:x, כאשר x חייב להיות בין 0 ל-1000).
הפניה לכתובות URL אחרות (urlRedirect).

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

שיקוף תנועה (requestMirrorPolicy).
כתיבה מחדש של המארח והנתיב של כתובת ה-URL (urlRewrite).
ניסיון חוזר של בקשות שנכשלו (retryPolicy).
הגדרת זמן קצוב לתפוגה (timeout).
הוספת תקלות לאחוז מסוים מהתנועה (faultInjectionPolicy).
הוספת מדיניות CORS‏ (corsPolicy).
שינוי של כותרות בקשות או תגובות (headerAction).

מידע נוסף על ההגדרה והסמנטיקה של פעולות מסלול זמין במאמרים הבאים במאמרי העזרה של ה-API של מפת URL אזוריות:

urlRedirect
urlRewrite
headerAction
requestMirrorPolicy
weightedBackendServices
retryPolicy
timeout
faultInjectionPolicy
corsPolicy

הפניות אוטומטיות מ-HTTP ל-HTTPS

אם אתם צריכים להפנות תנועת HTTP ל-HTTPS, אתם יכולים ליצור שני כללי העברה עם כתובת IP משותפת.

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

מדיניות בנושא תנועה

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

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

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

התכונות הבאות של מדיניות התנועה מוגדרות בשירות העורף האזורי.

מדיניות תנועה (`API field name`)	תיאור
מדיניות מקומית לאיזון עומסים (`LocalityLbPolicy`)	בשירות קצה עורפי, חלוקת התנועה מבוססת על מצב איזון עומסים ועל מדיניות איזון עומסים לפי מיקום. מצב האיזון קובע את המשקל או את חלקיק התעבורה שצריך לשלוח לכל קצה עורפי (קבוצת מכונות או `GCE_VM_IP_PORT` NEG). מדיניות איזון העומסים (`LocalityLbPolicy`) קובעת איך מתבצע איזון העומסים בשרתי הקצה בענן באזור או בקבוצה. כששירות לקצה העורפי מקבל תנועה, הוא קודם מפנה את התנועה לעורף (קבוצת מופעים או `GCE_VM_IP_PORT` NEG) בהתאם למצב האיזון של העורף. אחרי שבוחרים קצה עורפי, תעבורת הנתונים מופצת בין המופעים או נקודות הקצה בכל אזור בהתאם למדיניות המיקום. במקרה של קבוצות אזוריות של מופעים מנוהלים, מדיניות המיקום חלה על כל אזור שמרכיב את הקבוצה. מידע על מצבי האיזון הנתמכים זמין במאמר מצב איזון. במאמר regional backend service API documentation (מסמכי העזרה בנושא API של שירות קצה עורפי אזורי) מופיע מידע על אלגוריתמים של מדיניות איזון עומסים שנתמכים.`localityLbPolicy`
זיקה לסשן (`consistentHash`)	כולל זיקה שמבוססת על קובצי Cookie של HTTP, זיקה שמבוססת על כותרות HTTP, זיקה שמבוססת על כתובת ה-IP של הלקוח, זיקה לסשן שמבוססת על קובצי Cookie עם שמירת מצב וזיקה לקובץ Cookie שנוצר. התכונה 'זיקה לסשן (session affinity)' מספקת ניסיון מיטבי לשלוח בקשות מלקוח מסוים לאותו בק-אנד כל עוד השרת תקין ויש לו קיבולת. מידע נוסף על זיקה לסשן (session affinity) זמין במאמר בנושא `consistentHash` במאמרי העזרה של ה-API של שירותי קצה עורפי אזוריים.
זיהוי חריגות (`outlierDetection`)	קבוצה של כללי מדיניות שמציינים את הקריטריונים להוצאה של מכונות וירטואליות או נקודות קצה לא תקינות ב-NEG, יחד עם קריטריונים שמגדירים מתי נקודת קצה או קצה עורפי נחשבים תקינים מספיק כדי לקבל תנועה שוב. מידע נוסף על זיהוי חריגות זמין במאמר בנושא `outlierDetection` בתיעוד ה-API של שירות קצה עורפי אזורי.
ניתוק מעגל (`circuitBreakers`)	מגדיר מגבלות עליונות על נפח החיבורים והבקשות לכל חיבור לשירות לקצה העורפי. מידע נוסף על ניתוק מעגלים זמין במאמר `circuitBreakers` בתיעוד ה-API של שירות קצה עורפי אזורי.

המאמרים הבאים

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

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