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

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

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

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

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

‫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)	שרתי קצה עורפיים שעומדים בדרישות
	אם לא מוגדרת מדיניות יתירות כשל, כל השרתים העורפיים המוגדרים הם שרתים עורפיים ראשיים. קבוצת השרתים העורפיים שעומדים בדרישות מוגדרת כך: אם לפחות עורף אחד תקין, קבוצת העורפים שעומדים בדרישות כוללת את כל העורפים התקינים. אם כל השרתים העורפיים לא תקינים, קבוצת השרתים העורפיים שעומדים בדרישות כוללת את כל השרתים העורפיים.
	כשמגדירים מדיניות מעבר לגיבוי, מאזן העומסים משתמש במידע של בדיקות התקינות ובהגדרות של מדיניות המעבר לגיבוי כדי להגדיר את קבוצת השרתים העורפיים שעומדים בדרישות: כאשר לפחות עורף אחד (ראשי או גיבוי) תקין, העורפים שעומדים בדרישות הם אלה ששייכים לקבוצה הראשונה מבין הקבוצות הבאות שלא ריקה: אם אין קצוות עורפיים ראשיים תקינים, הקצוות העורפיים שעומדים בדרישות הם כל הקצוות העורפיים התקינים למעבר לגיבוי. אם אין קצוות עורפיים תקינים למעבר לגיבוי, הקצוות העורפיים שעומדים בדרישות הם כל הקצוות העורפיים הראשיים התקינים. אם יחס המעבר לגיבוי מוגדר ל-`0.0` (ערך ברירת המחדל), השרתים העורפיים שעומדים בדרישות הם כל השרתים העורפיים הראשיים שפועלים בצורה תקינה. אם היחס בין מספר השרתים העורפיים הראשיים התקינים לבין המספר הכולל של השרתים העורפיים הראשיים גדול או שווה ליחס יתירות הכשל שהוגדר, השרתים העורפיים שעומדים בדרישות הם כל השרתים העורפיים הראשיים התקינים. הקצוות העורפיים שעומדים בדרישות הם כל הקצוות העורפיים התקינים של יתירות כשל. אם אין בקצה העורפי תקינים (ראשיים וגיבוי), קבוצת הקצוות העורפיים שעומדים בדרישות תלויה אך ורק בהגדרות של מדיניות המעבר לגיבוי: אם מדיניות יתירות הכשל מוגדרת להפסקת חיבורים חדשים כשכל השרתים הראשיים ושרתי הגיבוי לא תקינים, קבוצת השרתים שעומדים בדרישות ריקה. כתוצאה מכך, מאזן העומסים משליך חבילות של חיבורים חדשים. אם מדיניות המעבר לגיבוי (failover) לא מוגדרת להפסקת חיבורים חדשים כשכל השרתים הראשיים ושרתי הגיבוי לא תקינים, השרתים שעומדים בדרישות הם כל השרתים הראשיים הלא תקינים.

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

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

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

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

‫2.2 שינוי של שרתי קצה עורפיים שעומדים בדרישות לשימוש בתכונה 'תחום עניין משותף'

השלב הזה יידלג אם מתקיים אחד מהתנאים הבאים:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

זיקה לסשן (session affinity) והצעד הבא של מאזן העומסים

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

התמדה של חיבורים בשרתי קצה עורפיים לא תקינים קובעת אם חיבורים קיימים יישארו פעילים במכונה וירטואלית או בנקודת קצה של שרת קצה עורפי שנבחרו קודם, אחרי שהשרת הקצה העורפי הפך ללא תקין, בתנאי שהוא נשאר בקבוצת מופעים או ב-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, ‏ UDP: החיבורים נשארים בשרתי קצה עורפיים לא תקינים (כל ההעדפות של הסשנים)	אי אפשר להגדיר

כשמשכיות החיבור בחלק האחורי של המערכת (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 נחשבות לחיבורים חדשים בשלב זיהוי שרתי קצה שעומדים בדרישות).

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

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

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

זיקה לסשן (session affinity)	מצב מעקב אחר חיבורים	ברירת המחדל של הזמן הקצוב לתפוגה של חוסר פעילות	הזמן הקצוב המינימלי (בדקות) עד לכניסה למצב 'לא פעיל' שאפשר להגדיר	הזמן הקצוב לתפוגה המקסימלי של חוסר פעילות שאפשר להגדיר
כל טופל חיבור	`PER_CONNECTION`	‫600 שניות	‫60 שניות	‫600 שניות
‫1-tuple (`CLIENT_IP_NO_DESTINATION`) ‫2-tuple (`CLIENT_IP`) שלישייה (`CLIENT_IP_PROTO`)	`PER_SESSION`	‫600 שניות	‫60 שניות	‫57,600 שניות
‫5-tuple‏ (`NONE`, ‏ `CLIENT_IP_PORT_PROTO`)	`PER_SESSION`	‫600 שניות	‫60 שניות	‫600 שניות

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

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

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

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

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

מעבר לגיבוי (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) במעבר לגיבוי (failover)

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

מופעל (ברירת מחדל)

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

מושבת

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

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

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

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

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

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

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

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

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

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

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

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

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

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