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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• איך ZONAL_AFFINITY_STAY_WITHIN_ZONE עובד

• איך ZONAL_AFFINITY_SPILL_CROSS_ZONE ויחס ההעברה פועלים

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

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

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

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

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

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

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

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

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

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

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

אתם מגדירים את הזיקה לסשן (session affinity) בשירות לקצה העורפי, ולא בכל קבוצת מופעים של שרת עורפי (backend instance) או 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-tuple‏ (מורכב רק מכתובת ה-IP של המקור)	CLIENT_IP_NO_DESTINATION

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

זיקה לסשן (session affinity)	‫Packet hash לבחירת backend	Hash של חבילת נתונים למעקב אחר חיבור
		כשמשתמשים במצב מעקב 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	כל הפרוטוקולים: גיבוב (hash) של 2-tuple	‫TCP ו-UDP לא מפולח: מעקב חיבורים מופעל, גיבוב של 5 טאפלים ‫UDP עם פרגמנטים וכל שאר הפרוטוקולים: מעקב אחר חיבורים מופעל, גיבוב של 3 טאפלים	כל הפרוטוקולים: מעקב אחר חיבורים מופעל, גיבוב של 2 טאפלים
CLIENT_IP_NO_DESTINATION	כל הפרוטוקולים: גיבוב של 1-tuple	‫TCP ו-UDP לא מפולח: מעקב חיבורים מופעל, גיבוב של 5 טאפלים ‫UDP עם פרגמנטים וכל שאר הפרוטוקולים: מעקב אחר חיבורים מופעל, גיבוב של 3 טאפלים	כל הפרוטוקולים: מעקב אחר חיבורים מופעל, גיבוב של 1-tuple

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

זיקה לסשן (session affinity)	מצב מעקב אחר חיבורים	הזמן הקצוב לתפוגה של חוסר פעילות שמוגדר כברירת מחדל	הזמן הקצוב המינימלי שניתן להגדרה עד לכניסה למצב 'לא פעיל'	הזמן הקצוב לתפוגה המקסימלי של חוסר פעילות שאפשר להגדיר
כל טופל חיבור	PER_CONNECTION	‫600 שניות	‫60 שניות	‫600 שניות
‫1-tuple (CLIENT_IP_NO_DESTINATION) ‫2-tuple (CLIENT_IP) 3-tuple (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) מספק כמות מינימלית של זמן שניתן להגדרה, כדי שחיבורים קיימים יישארו בטבלת מעקב החיבורים של מאזן העומסים (LB), כשמתרחש אחד מהמקרים הבאים:

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

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

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

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

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

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

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

• לפחות קבוצה ראשית אחת לא ריקה של שרתים לעורף
• לפחות קבוצת עורף אחת לגיבוי שלא ריקה

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

• מצב התקינות של כל שרת קצה עורפי
• יחס היתירות כשל במדיניות היתירות כשל
• ההגדרה drop traffic if backends are unhealthy במדיניות המעבר לגיבוי (failover)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• יכול להיות שחבילות UDP יפוצלו לפני שיגיעו לרשת Google Cloud VPC.
• 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 (גיבוב של 2-tuple) או ל-CLIENT_IP_PROTO (גיבוב של 3-tuple) כדי שאותו בק-אנד ייבחר עבור מנות UDP שכוללות מידע על יציאה ופרגמנטים של UDP (מלבד הפרגמנט הראשון) שחסר בהם מידע על יציאה. מגדירים את מצב מעקב החיבורים של שירות ה-Backend ל-PER_SESSION כדי שערכי הטבלה של מעקב החיבורים יבנו באמצעות אותם גיבובים של 2-tuple או 3-tuple.

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

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

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

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

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

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

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