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

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

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

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

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

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

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

  • מנת TCP עם הדגל SYN:

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

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

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

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

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

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

‫2. שלבים לבחירת ה-Backend

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

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

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

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

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

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

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

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

  • כל הקצוות העורפיים התקינים עם משקל שונה מאפס
  • כל הקצוות העורפיים הלא תקינים עם משקל שונה מאפס
  • כל הקצוות העורפיים התקינים עם משקל אפס
  • כל הקצוות העורפיים הלא תקינים עם משקל אפס

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

  • אם לפחות עורף אחד (ראשי או גיבוי) תקין, עורפי הקצה שעומדים בדרישות הם אלה ששייכים לקבוצה הראשונה מבין הקבוצות הבאות שלא ריקה:
    1. אם אין קצוות עורפיים ראשיים תקינים, הקצוות העורפיים שעומדים בדרישות הם כל הקצוות העורפיים התקינים למעבר לגיבוי.
    2. אם אין קצוות עורפיים תקינים למעבר לגיבוי, הקצוות העורפיים שעומדים בדרישות הם כל הקצוות העורפיים הראשיים התקינים.
    3. אם יחס המעבר לגיבוי מוגדר ל-0.0 (ערך ברירת המחדל), השרתים העורפיים שעומדים בדרישות הם כל השרתים העורפיים הראשיים שפועלים בצורה תקינה.
    4. אם היחס בין מספר השרתים העורפיים הראשיים התקינים לבין המספר הכולל של השרתים העורפיים הראשיים גדול או שווה ליחס יתירות הכשל שהוגדר, השרתים העורפיים שעומדים בדרישות הם כל השרתים העורפיים הראשיים התקינים.
    5. הקצוות העורפיים שעומדים בדרישות הם כל הקצוות העורפיים התקינים של יתירות כשל.
  • אם אין בקצה העורפי תקינים (ראשיים וגיבוי), קבוצת הקצוות העורפיים שעומדים בדרישות תלויה אך ורק בהגדרות של מדיניות המעבר לגיבוי:
    • אם מדיניות יתירות הכשל מוגדרת להפסקת חיבורים חדשים כשכל השרתים הראשיים ושרתי הגיבוי לא תקינים, קבוצת השרתים שעומדים בדרישות ריקה. כתוצאה מכך, מאזן העומסים משליך חבילות של חיבורים חדשים.
    • אם מדיניות המעבר לגיבוי (failover) לא מוגדרת להפסקת חיבורים חדשים כשכל השרתים הראשיים ושרתי הגיבוי לא תקינים, השרתים שעומדים בדרישות הם כל השרתים הראשיים הלא תקינים.

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

  • כששרת קצה עורפי אחד לפחות עם משקל שאינו אפס (ראשי או מעבר לגיבוי) תקין, שרתי הקצה העורפיים שעומדים בדרישות הם אלה ששייכים לקבוצה הראשונה מבין הקבוצות הבאות שלא ריקה:
    1. אם קבוצת הקצוות העורפיים הראשיים התקינים עם משקל שונה מאפס ריקה, הקצוות העורפיים שעומדים בדרישות הם כל הקצוות העורפיים לגיבוי התקינים עם משקל שונה מאפס.
    2. אם קבוצת הקצוות העורפיים התקינים ליתירות כשל עם משקל שונה מאפס ריקה, הקצוות העורפיים שעומדים בדרישות הם כל הקצוות העורפיים הראשיים התקינים עם משקל שונה מאפס.
    3. אם יחס המעבר לגיבוי מוגדר ל-0.0 (ערך ברירת המחדל), השרתים העורפיים שעומדים בדרישות הם כל השרתים העורפיים הראשיים עם משקל חיובי תקין.
    4. אם היחס בין מספר השרתים העורפיים הראשיים התקינים עם משקל שאינו אפס לבין המספר הכולל של השרתים העורפיים הראשיים גדול או שווה ליחס יתירות הכשל שהוגדר, השרתים העורפיים שעומדים בדרישות הם כל השרתים העורפיים הראשיים התקינים עם משקל שאינו אפס.
    5. הקצוות העורפיים שעומדים בדרישות הם כל הקצוות העורפיים התקינים של יתירות כשל, עם משקל שונה מאפס.
  • אם אין בקצה העורפי תקין עם משקל חיובי (ראשי וגיבוי), קבוצת הקצוות העורפיים שעומדים בדרישות תלויה בהגדרות של מדיניות המעבר לגיבוי:
    • אם מדיניות היתירות כשל מוגדרת להשמיט חיבורים חדשים כשאין שרתי בק-אנד ראשיים ויתירות כשל תקינים עם משקל חיובי, קבוצת שרתי הבק-אנד שעומדים בדרישות תהיה ריקה. כתוצאה מכך, מאזן העומסים משמיט חבילות של חיבורים חדשים.
    • אם מדיניות המעבר לגיבוי (failover) לא מוגדרת להפסקת חיבורים חדשים כשאין בקצה העורפי הראשי ובקצה העורפי של הגיבוי (failover) קצה עורפי תקין עם משקל שונה מאפס, הקצוות העורפיים שעומדים בדרישות הם אלה ששייכים לקבוצה הראשונה מבין הקבוצות הבאות שלא ריקה:
      1. כל הקצוות העורפיים הראשיים הלא תקינים עם משקל שונה מאפס
      2. כל הקצוות העורפיים הלא תקינים למעבר לגיבוי (failover) עם משקל שונה מאפס
      3. כל הקצוות העורפיים הראשיים התקינים עם משקל אפס
      4. כל הקצוות העורפיים של גיבוי למעבר אוטומטי תקינים עם משקל אפס
      5. כל הקצוות העורפיים הראשיים הלא תקינים עם משקל אפס
      6. כל הקצוות העורפיים הלא תקינים למעבר לגיבוי עם משקל אפס

‫2.2 בחירת קצה עורפי שעומד בדרישות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • התמדה של חיבורים בסביבות קצה עורפיות לא תקינות: אפשר להסיר רשומות מטבלת מעקב החיבורים אם סביבת קצה עורפית הופכת ללא תקינה. ההתנהגות הזו תלויה בגורמים שמפורטים במאמר Connection persistence on unhealthy backends.

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

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

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

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

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

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

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

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

שיטת הגיבוב לבחירת השרת העורפי הגדרת זיקה לסשן (session affinity)

גיבוב של 5 טפלים (מורכב מכתובת ה-IP של המקור, יציאת המקור, פרוטוקול, כתובת ה-IP של היעד ויציאת היעד) לחבילות נתונים לא מקוטעות שכוללות מידע על היציאה (חבילות TCP וחבילות UDP לא מקוטעות)

או

גיבוב של 3 טאפלים (מורכב מכתובת ה-IP של המקור, כתובת ה-IP של היעד ופרוטוקול) לחבילות UDP מפוצלות ולחבילות של כל הפרוטוקולים האחרים

 NONE1
או
CLIENT_IP_PORT_PROTO
גיבוב של 3 טאפלים
(מורכב מכתובת ה-IP של המקור, כתובת ה-IP של היעד והפרוטוקול)		 CLIENT_IP_PROTO
גיבוב של 2-tuple
(מורכב מכתובת ה-IP של המקור וכתובת ה-IP של היעד)		 CLIENT_IP

‫1 NONE קרבה לסשן לא מציינת שאין קרבה לסשן. במקום זאת, המשמעות היא שזיקה לסשן מתבצעת באמצעות גיבוב (hash) של 5 טאפלים או 3 טאפלים של מאפייני חבילות – באופן פונקציונלי, זהה להתנהגות שמתקבלת כשמגדירים את CLIENT_IP_PORT_PROTO.

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

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

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

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

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

  • אפשר לעקוב אחרי חיבורי UDP,‏ ESP ו-GRE בכל האפשרויות של שיוך סשנים חוץ מאשר NONE.

  • אי אפשר לעקוב אחרי פרוטוקולים אחרים, כמו ICMP ו-ICMPv6.

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

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

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

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

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

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

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

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

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

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

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

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

האפשרות Connection persistence on unhealthy backends (התמדה של חיבורים בקצוות עורפיים לא תקינים) התנהגות של חיבורים מתמשכים בקצוות עורפיים לא תקינים
כשמשתמשים במצב מעקב PER_CONNECTION (ברירת מחדל) כשמשתמשים במצב מעקב PER_SESSION
DEFAULT_FOR_PROTOCOL
  • ‫TCP: החיבורים נשמרים בשרתי קצה עורפיים לא תקינים (כל ההעדפות של הסשנים)
  • כל הפרוטוקולים האחרים: החיבורים אף פעם לא נשמרים בשרתי קצה לא תקינים
  • ‫TCP: חיבורים נשמרים בשרתי קצה עורפיים לא תקינים אם ההגדרה של שייכות לסשן היא NONE או CLIENT_IP_PORT_PROTO
  • כל הפרוטוקולים האחרים: החיבורים אף פעם לא נשמרים בשרתי קצה לא תקינים
NEVER_PERSIST כל הפרוטוקולים: החיבורים אף פעם לא נשמרים בקצוות עורפיים לא תקינים
ALWAYS_PERSIST

צריך להשתמש באפשרות הזו רק בתרחישי שימוש מתקדמים.
  • ‫TCP: החיבורים נשמרים בשרתי קצה עורפיים לא תקינים (כל ההעדפות של הסשנים)
  • ‫ESP, ‏ GRE, ‏ UDP: החיבורים נשמרים בשרתי קצה עורפיים לא תקינים אם הזיקה לסשן היא לא NONE
  • כל הפרוטוקולים האחרים: לא רלוונטיים כי אי אפשר לעקוב אחרי החיבורים שלהם
 אי אפשר להגדיר

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • מדיניות המקומיות (localityLbPolicy) צריכה להיות מוגדרת לערך WEIGHTED_MAGLEV.

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

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

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

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

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

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

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

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

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

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

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

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

מעבר לגיבוי (Failover)

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

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

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

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

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

מדיניות מעבר לגיבוי (failover)

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

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

יחס מעבר לגיבוי

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

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

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

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

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

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

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

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

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

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

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

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

טיפול בפיצול של UDP

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

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

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

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

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

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

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

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

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

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

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