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

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

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

בחירת בק-אנד ומעקב אחרי חיבורים

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

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

1. בדיקה אם יש רשומה בטבלת מעקב החיבורים

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

• חבילת TCP עם הדגל SYN:

  • אם מצב מעקב החיבורים של מאזן העומסים הוא PER_CONNECTION, המשיכו לשלב זיהוי קצוות עורפיים מתאימים. במצב מעקב PER_CONNECTION, חבילת TCP עם הדגל SYN תמיד מייצגת חיבור חדש, בלי קשר לזיקה לסשן (session affinity) שהוגדרה.

  • אם מצב מעקב החיבורים של מאזן העומסים הוא PER_SESSION וגם הזיקה לסשן היא NONE או CLIENT_IP_PORT_PROTO, ממשיכים לשלב זיהוי של רכיבי backend שעומדים בדרישות. במצב מעקב PER_SESSION, חבילת TCP עם הדגל SYN מייצגת חיבור חדש רק כשמשתמשים באחת מהאפשרויות של זיקה לסשן (session affinity) עם 5 ערכים (NONE או CLIENT_IP_PORT_PROTO).

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

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

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

  • אם החבילה לא תואמת לרשומה בטבלת מעקב החיבורים, ממשיכים לשלב זיהוי קצוות עורפיים מתאימים.

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

2. שלבים לבחירת קצה עורפי

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

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

‫2.1 זיהוי של קצוות עורפיים שעומדים בדרישות

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

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

2.2 בחירת קצה עורפי מתאים

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

כשהמערכת לאיזון עומסים מעבדת חבילה של חיבור שלא נמצא בטבלת מעקב החיבורים, היא מחשבת גיבוב (hash) של מאפייני החבילה וממפה את הגיבוב לאותו מעגל יחידה, ובוחרת קצה עורפי מתאים בהיקף המעגל. קבוצת המאפיינים של חבילת הנתונים שמשמשת לחישוב ה-hash של חבילת הנתונים מוגדרת על ידי ההגדרה של הזיקה לסשן. לדוגמה, אם הזיקה לסשן שנבחרה מובילה לגיבוב של בחירת קצה עורפי עם 2 ערכים או 3 ערכים, כל חיבורי ה-TCP מכתובת IP של מקור ממופים לאותו קצה עורפי שעומד בדרישות.

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

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

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

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

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

  • אם מוסיפים או מסירים קצה עורפי כשיר, או משנים את המשקל שלו, גיבוב עקבי (consistent hashing) שואף לצמצם את השיבוש במיפויים לקצוות העורפיים הכשירים האחרים – כלומר, רוב החיבורים שממופים לקצוות עורפיים כשירים אחרים ממשיכים להיות ממופים לאותו קצה עורפי כשיר.

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

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

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

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

  • אם לשירות לקצה העורפי יש שני קצוות עורפיים מתאימים – הראשון עם משקל 1 והשני עם משקל 4 – לקצה העורפי המתאים הראשון יש סבירות בחירה של 20% (1÷(1+4)), ולקצה העורפי המתאים השני יש סבירות בחירה של 80% (4÷(1+4)).

  • אם לשירות לקצה העורפי יש שלושה קצוות עורפיים מתאימים – קצה עורפי מתאים a עם משקל 0, קצה עורפי מתאים b עם משקל 2 וקצה עורפי מתאים c עם משקל 6 – לקצה העורפי a יש הסתברות בחירה של 0% (0÷(0+2+6)), לקצה העורפי b יש הסתברות בחירה של 25% (2÷(0+2+6)) ולקצה העורפי c יש הסתברות בחירה של 75% (6÷(0+2+6)).

2.3 יצירת רשומה בטבלת מעקב אחרי חיבורים

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

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

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

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

3. ניהול רשומות בטבלת מעקב אחרי חיבורים

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

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

• חיבורי TCP סגורים: הרשומות בטבלת מעקב החיבורים של חיבורי TCP לא מוסרות כשחיבור TCP נסגר באמצעות חבילת FIN או RST. יכול להיות שהם יוסרו בהמשך כרשומה לא פעילה. כל חיבור TCP חדש תמיד נושא את הדגל SYN, וכפוף לעיבוד שמתואר בשלב בדיקת רשומה בטבלת מעקב החיבורים.

• כשהחיבורים לא נשמרים ביתירות כשל: כשמוגדר לפחות שרת backend אחד ליתירות כשל וההגדרה "זמן להשלמת תהליך (connection draining) ביתירות כשל" מושבתת, מאזן העומסים מסיר את כל הרשומות בטבלת מעקב החיבורים אחרי שקבוצת שרתי ה-backend המתאימים עוברת בין שרתי ה-backend הראשיים לבין שרתי ה-backend ליתירות כשל, בכפוף לכללים הבאים:

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

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

  מידע נוסף זמין במאמר זמן להשלמת תהליך (connection draining) במקרה של יתירות כשל.

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

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

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

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

זיקה לסשן (session affinity)

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

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

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

שיטת גיבוב לבחירת קצה עורפי	הגדרת הזיקה לסשן (session affinity)
גיבוב של 5 ערכים (שמורכב מכתובת ה-IP של המקור, היציאה של המקור, הפרוטוקול, כתובת ה-IP של היעד והיציאה של היעד) לחבילות נתונים לא מקוטעות שכוללות מידע על היציאה (חבילות נתונים של TCP וחבילות נתונים לא מקוטעות של UDP) או גיבוב (hash) של 3 ערכים (כתובת ה-IP של המקור, כתובת ה-IP של היעד והפרוטוקול) לחבילות UDP מקוטעות ולחבילות של כל שאר הפרוטוקולים	NONE‫1 או CLIENT_IP_PORT_PROTO
‫3-tuple hash (מורכב מכתובת ה-IP של המקור, כתובת ה-IP של היעד והפרוטוקול)	CLIENT_IP_PROTO
‫גיבוב (hash) של 2-tuple‏ (מורכב מכתובת ה-IP של המקור ומכתובת ה-IP של היעד)	CLIENT_IP

מדיניות מעקב אחרי חיבורים

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

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

מצב מעקב אחרי חיבורים

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

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

• אפשר לעקוב אחרי חיבורי UDP, ‏ ESP ו-GRE בכל האפשרויות של זיקה לסשן, חוץ מ- NONE. בזיקה לסשן (session affinity) NONE, אי אפשר לעקוב אחרי החיבור של הפרוטוקולים האלה.

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

כשאפשר לעקוב אחרי החיבור, מצב המעקב אחרי החיבור, הפרוטוקול והזיקה לסשן (session affinity) קובעים את קבוצת המאפיינים של החבילה שמשמשים ליצירת ה-hash של החבילה בכל רשומה בטבלת המעקב אחרי החיבור.

מצב המעקב אחרי החיבור יכול להיות אחד מהבאים:

• ‫PER_CONNECTION. זהו מצב מעקב החיבורים המפורט ביותר, והוא מוגדר כברירת מחדל. כל חיבור מוגדר כגיבוב (hash) של 5 ערכים או של 3 ערכים של מאפייני חבילות, בהתאם לשאלה אם פרטי היציאה קיימים בחבילה. חבילות לא מקוטעות שכוללות מידע על יציאות (כמו חבילות TCP וחבילות UDP לא מקוטעות) עוברות מעקב באמצעות גיבובים של 5-tuple. כל שאר החבילות עוברות מעקב באמצעות גיבובים של 3 ערכים.

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

בטבלה הבאה מפורטים:

• ערכי ה-hash של החבילות שמשמשים לבחירת הקצה העורפי.
• ערכי ה-hash של החבילות שמשמשים למעקב אחרי חיבורים, על סמך מצב המעקב אחרי חיבורים, הפרוטוקול והזיקה לסשן (session affinity).

זיקה לסשן (session affinity)	גיבוב (hash) של חבילה לבחירת קצה עורפי	גיבוב (hash) של מנות למעקב אחרי חיבורים
		כשמשתמשים במצב המעקב PER_CONNECTION (ברירת המחדל)	כשמשתמשים במצב המעקב PER_SESSION
‫NONE (ברירת מחדל)	TCP ו-UDP לא מקוטע: גיבוב של 5 ערכים ‫UDP מקוטע וכל שאר הפרוטוקולים: גיבוב של 3 ערכים	‫TCP: מעקב אחרי חיבורים מופעל, גיבוב (hash) של 5-tuple כל שאר הפרוטוקולים: מעקב החיבורים מושבת	‫TCP: מעקב אחרי חיבורים מופעל, גיבוב (hash) של 5-tuple כל שאר הפרוטוקולים: מעקב החיבורים מושבת
CLIENT_IP_PORT_PROTO	TCP ו-UDP לא מקוטע: גיבוב של 5 ערכים ‫UDP מקוטע וכל שאר הפרוטוקולים: גיבוב של 3 ערכים	‫TCP ו-UDP לא מקוטע: מעקב אחרי חיבורים מופעל, גיבוב (hash) של 5 ערכים ‫Fragmented UDP, ESP, and GRE: מעקב אחרי חיבורים מופעל, גיבוב של 3 ערכים כל שאר הפרוטוקולים: מעקב החיבורים מושבת	‫TCP ו-UDP לא מקוטע: מעקב אחרי חיבורים מופעל, גיבוב (hash) של 5 ערכים ‫Fragmented UDP, ESP, and GRE: מעקב אחרי חיבורים מופעל, גיבוב של 3 ערכים כל שאר הפרוטוקולים: מעקב החיבורים מושבת
CLIENT_IP_PROTO	כל הפרוטוקולים: גיבוב (hash) של 3 ערכים	‫TCP ו-UDP לא מקוטע: מעקב אחרי חיבורים מופעל, גיבוב (hash) של 5 ערכים ‫Fragmented UDP, ESP, and GRE: מעקב אחרי חיבורים מופעל, גיבוב של 3 ערכים כל שאר הפרוטוקולים: מעקב החיבורים מושבת	‫TCP, ‏ UDP, ‏ ESP, ‏ GRE: מעקב אחרי חיבורים מופעל, גיבוב של 3 ערכים כל שאר הפרוטוקולים: מעקב החיבורים מושבת
CLIENT_IP	כל הפרוטוקולים: גיבוב של 2-tuple	‫TCP ו-UDP לא מקוטע: מעקב אחרי חיבורים מופעל, גיבוב (hash) של 5 ערכים ‫Fragmented UDP, ESP, and GRE: מעקב אחרי חיבורים מופעל, גיבוב של 3 ערכים כל שאר הפרוטוקולים: מעקב החיבורים מושבת	‫TCP, ‏ UDP, ‏ ESP, ‏ GRE: מעקב אחרי חיבורים מופעל, גיבוב של 2-tuple כל שאר הפרוטוקולים: מעקב החיבורים מושבת

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

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

ההגדרה Connection persistence on unhealthy backends קובעת אם חיבורים קיימים יכולים להישאר ב-VM קודם שנבחר, אם ה-VM הקודם שנבחר הופך ללא תקין. כדי לשמר את החיבורים בקצוות עורפיים לא תקינים, ה-VM של הקצה העורפי צריך להישאר חבר בקבוצת מכונות עם איזון עומסים או ב-NEG, והשילוב של הפרוטוקול והזיקה לסשן צריך לתמוך במעקב אחרי חיבורים.

אלה האפשרויות הזמינות לשמירת החיבור:

• DEFAULT_FOR_PROTOCOL (ברירת מחדל)
• NEVER_PERSIST
• ALWAYS_PERSIST

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

האפשרות Connection persistence on unhealthy backends	התנהגות של שמירת החיבור בקצוות עורפיים לא תקינים
	כשמשתמשים במצב המעקב PER_CONNECTION (ברירת המחדל)	כשמשתמשים במצב המעקב PER_SESSION
DEFAULT_FOR_PROTOCOL	‫TCP (כל הזיקות לסשנים): החיבורים נשמרים ב-backend לא תקינים, בכפוף לאירועים ולכללים האחרים בשלב ניהול הרשומות בטבלת מעקב החיבורים כל שאר הפרוטוקולים: החיבורים לא נשמרים ב-backend לא תקינים	‫TCP (זיקות לסשן NONE ו-CLIENT_IP_PORT_PROTO): החיבורים נשארים ב-backend לא תקינים, בכפוף לאירועים ולכללים האחרים בשלב ניהול הרשומות בטבלת מעקב החיבורים ‫TCP (כל שאר הזיקות לסשן) וכל שאר הפרוטוקולים: החיבורים לא נשמרים ב-backend לא תקינים
NEVER_PERSIST	כל הפרוטוקולים: החיבורים לא נשמרים בקצוות עורפיים לא תקינים
ALWAYS_PERSIST האפשרות הזו מיועדת רק לתרחישים מתקדמים.	‫TCP (כל הזיקות לסשנים); ESP, ‏ GRE, ‏ UDP (כל הזיקות לסשנים חוץ מ- NONE): החיבורים נשמרים ב-backend לא תקינים, בכפוף לאירועים ולכללים האחרים בשלב ניהול הרשומות בטבלת מעקב החיבורים. ‫ESP, ‏ GRE, ‏ UDP (זיקה לסשן (session affinity) של NONE): לא רלוונטי כי אי אפשר לעקוב אחרי החיבור שלהם	אי אפשר להגדיר את זה

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

התנהגות של שמירת חיבורי TCP בקצוות עורפיים לא תקינים

מאזן העומסים משתמש במעקב אחרי חיבורים באמצעות גיבוב של 5 רכיבים לחיבורי TCP במצבים הבאים:

• כשמשתמשים במצב המעקב PER_CONNECTION (כל הזיקות לסשן), או
• כשמשתמשים במצב המעקב PER_SESSION, וגם הזיקה לסשן היא או NONE או CLIENT_IP_PORT_PROTO.

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

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

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

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

זמן להשלמת תהליך (connection draining) של שירותי backend שהוסרו, הופסקו או נמחקו

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

• מכונה וירטואלית (VM) מוסרת מקבוצת שרתי עורפי (backend instance) (כולל נטישת מכונה בקבוצת מופעי מכונה מנוהלים לקצה העורפי)
• מכונה וירטואלית נעצרת או נמחקת (כולל פעולות אוטומטיות כמו עדכונים בהדרגה או הקטנת קבוצת מופעי מכונה מנוהלים בקצה העורפי)
• נקודת קצה מוסרת מקבוצה של נקודות קצה ברשת (NEG) בקצה העורפי

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

איזון עומסים משוקלל

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

• המדיניות בנושא מיקום (localityLbPolicy) חייבת להיות מוגדרת כ-WEIGHTED_MAGLEV.

• בדיקת התקינות חייבת להיות בדיקת תקינות מסוג HTTP ששולחת כותרת תגובה מיוחדת:

  • שם השדה של כותרת התגובה חייב להיות X-Load-Balancing-Endpoint-Weight.
  • ערכי השדות של כותרת התגובה יכולים להיות בטווח שבין 0 ל-1000, כולל.

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

שיקולים לגבי איזון עומסים משוקלל

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

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

• איזון עומסים משוקלל מאפשר לשרת בק-אנד שנמצא בעומס יתר או שנכנס למצב תחזוקה להסיר את עצמו מרשימת שרתי הבק-אנד הזמינים לחיבורים חדשים. כדי לעשות את זה, ה-backend העמוס שולח את כותרת התגובה X-Load-Balancing-Endpoint-Weight: 0 (ויכול להמשיך לעבור או להיכשל בבדיקת התקינות של מאזן העומסים). זה עובד כי כל הקצוות העורפיים עם משקל שאינו אפס (ללא קשר למצב של בדיקת התקינות) הם קצוות עורפיים מתאימים שמועדפים יותר בשלב זיהוי קצוות עורפיים מתאימים.

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

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

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

  • צריך להשתמש בבדיקת תקינות ייחודית של HTTP לכל שירות לקצה העורפי. בכל בדיקת תקינות אפשר להשתמש ביציאת יעד ייחודית או בפרמטר request-path.

  • מגדירים את השרתים העורפיים או נקודות הקצה (endpoints) כך שיגיבו עם מידע מתאים על המשקל של כל בדיקת תקינות.

יתירות כשל

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

• קצוות עורפיים ראשיים הם מכונות וירטואליות או נקודות קצה בקבוצת מכונות או ב-NEG שמוגדרים כקבוצת קצוות עורפיים ראשית.
• קצוות עורפיים לגיבוי הם מכונות וירטואליות או נקודות קצה בקבוצת מכונות או ב-NEG שמוגדרים כקבוצת קצוות עורפיים לגיבוי.

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

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

• לפחות קבוצת קצה עורפי ראשית אחת שאינה ריקה
• לפחות קבוצת קצה עורפי אחת של יתירות כשל שלא ריקה

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

• מצב התקינות של כל קצה עורפי
• יחס יתירות הכשל במדיניות יתירות הכשל
• ההגדרה drop traffic if backends are unhealthy במדיניות יתירות הכשל
• אם אתם משתמשים ביתירות כשל לבד או בשילוב עם איזון עומסים משוקלל

מדיניות יתירות כשל

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

• ‫Failover ratio: מספר בין 0.0 ל-1.0, כולל.
• ‫Drop traffic if backends are unhealthy: ערך בוליאני שקובע את ההתנהגות של מאזן העומסים כמוצא אחרון. ההגדרה failover ratio וההגדרה drop traffic if backends are unhealthy פועלות יחד עם גורמים אחרים כדי לשלוט בקבוצת הקצוות העורפיים המתאימים.
• זמן להשלמת תהליך (connection draining) ביתירות כשל: ערך בוליאני שקובע אם החיבורים נשארים ב-backend שנבחר קודם, כשהקבוצה של ה-backends המתאימים עוברת בין ה-backend הראשי ל-backend של יתירות הכשל.

יחס יתירות כשל

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

זמן להשלמת תהליך (connection draining) במעבר לגיבוי בעת כשל (failover)

ההגדרה זמן להשלמת תהליך (connection draining) ביתירות כשל קובעת אם חיבור קיים נמשך ב-VM או בנקודת קצה (endpoint) של קצה עורפי שנבחרו קודם, כשקבוצת הקצוות העורפיים המתאימים עוברת בין קצוות עורפיים ראשיים לבין קצוות עורפיים של יתירות כשל.

התכונה "זמן להשלמת תהליך (connection draining) במקרה של יתירות כשל" מופעלת כברירת מחדל. בטבלה הבאה מפורט אם החיבורים נשמרים, בהתאם לאפשרות ולפרוטוקול של זמן להשלמת תהליך (connection draining) במקרה של יתירות כשל:

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

השבתת זמן להשלמת תהליך (connection draining) במעבר לגיבוי בעת כשל שימושית בתרחישים הבאים:

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

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

במאמר הגדרת מדיניות של יתירות כשל מוסבר איך משביתים את הזמן להשלמת תהליך ביתירות כשל.

שיטות מומלצות והנחיות

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

טיפול בפרגמנטציה של UDP

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

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

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

• הגדרת כלל העברה: משתמשים רק בכלל העברה אחד של UDP או L3_DEFAULT לכל כתובת IP של מאזן עומסים, ומגדירים את כלל ההעברה כך שיקבל תנועה בכל היציאות. כך כל החלקים מגיעים לאותו כלל העברה. למרות שבחבילות המפוצלות (חוץ מהחלק הראשון) אין יציאת יעד, הגדרת כלל ההעברה לעיבוד תנועה בכל היציאות מגדירה אותו גם לקבלת חלקי UDP שאין בהם מידע על יציאה. כדי להגדיר את כל היציאות, משתמשים ב-Google Cloud CLI כדי להגדיר את --ports=ALL או משתמשים ב-API כדי להגדיר את allPorts לערך True.

• הגדרת שירות לקצה העורפי: מגדירים את הזיקה לסשן של השירות לקצה העורפי לערך CLIENT_IP (גיבוב של 2-tuple) או לערך CLIENT_IP_PROTO (גיבוב של 3-tuple), כדי שאותו קצה עורפי ייבחר לחבילות UDP שכוללות מידע על יציאות ולפרגמנטים של UDP (מלבד הפרגמנט הראשון) שאין בהם מידע על יציאות. מגדירים את מצב מעקב החיבורים של שירות הקצה העורפי ל-PER_SESSION, כדי שהרשומות בטבלת מעקב החיבורים ייווצרו באמצעות אותם ערכי גיבוב של 2-tuple או 3-tuple.

בדיקה מלקוח אחד

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

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

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

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

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

• כדי להגדיר מאזן עומסי רשת חיצוני עם שירות לקצה העורפי לתנועת TCP או UDP בלבד (תמיכה בתנועת IPv4 ו-IPv6), קראו את המאמר הגדרת מאזן עומסי רשת חיצוני עם שירות לקצה העורפי.
• כדי להגדיר מאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי לכמה פרוטוקולי IP (תמיכה בתעבורת נתונים ב-IPv4 וב-IPv6), קראו את המאמר הגדרת מאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי לכמה פרוטוקולי IP.
• כדי להגדיר מאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי עם קצה עורפי של קבוצת נקודות קצה ברשת (NEG) באזור, קראו את המאמר הגדרה של מאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי עם קבוצות נקודות קצה ברשת (NEG) באזור.
• במאמר העברת מאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי ממאגר יעד לשירות לקצה העורפי מוסבר איך מעבירים מאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי ממאגר יעד לקצה העורפי לשירות אזורי לקצה העורפי.