מאזני עומסי רשת להעברת סיגנל ללא שינוי מחלקים את התעבורה הנכנסת בין מכונות זמינות בקצה העורפי. במאמר הזה מוסבר איך מאזן העומסים בוחר בקצה העורפי, עוקב אחרי חיבורים ומנהל את זיקה לסשן (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).
- מעקב אחר חיבורים לא נתמך: אם השילוב של הפרוטוקול והזיקה לסשן לא תומך במעקב אחר חיבורים, ממשיכים לשלב זיהוי קצה עורפי שעומד בדרישות. כדי לדעת אילו פרוטוקולים ניתנים למעקב אחרי חיבורים, עיינו בטבלה שבקטע מצב מעקב אחרי חיבורים.
כל שאר החבילות: מאזן העומסים בודק אם החבילה תואמת לרשומה קיימת בטבלת מעקב החיבורים. רמת הפירוט של הגיבוב (hash) של המנה שמשמש לבדיקה של רשומה קיימת בטבלת מעקב החיבורים תלויה במצב מעקב החיבורים ובזיקה לסשן (session affinity) שהגדרתם. מידע נוסף מופיע בטבלה שבקטע מצב מעקב אחר חיבורים.
אם המנה תואמת לרשומה בטבלת מעקב החיבורים, מאזן העומסים שולח את המנה לקצה העורפי שנבחר קודם.
אם החבילה לא תואמת לרשומה בטבלת מעקב החיבורים, ממשיכים לשלב זיהוי קצוות עורפיים מתאימים.
מידע על משך הזמן שבו רשומה בטבלת מעקב החיבורים נשמרת ועל התנאים שבהם היא נשמרת מופיע בשלב ניהול רשומות בטבלת מעקב החיבורים.
2. שלבים לבחירת קצה עורפי
בחיבור חדש, מאזן העומסים משתמש בגיבוב עקבי כדי לבחור קצה עורפי מבין הקצוות העורפיים שעומדים בדרישות.
בשלבים הבאים מוסבר איך לבחור בקצה עורפי מתאים לחיבור חדש, ואז לתעד את החיבור הזה בטבלת מעקב אחרי חיבורים.
2.1 זיהוי שרתי קצה עורפיים שעומדים בדרישות
שרתי קצה עורפיים שעומדים בדרישות הם שרתי קצה עורפיים שיכולים לקבל חיבורים חדשים. בטבלה הבאה מוגדרת קבוצת השרתים העורפיים שעומדים בדרישות, בהתאם לשאלה אם מאזן העומסים משתמש ביתירות כשל והאם איזון עומסים משוקלל מופעל.
| יתירות כשל | איזון עומסים משוקלל | קצוות עורפיים שעומדים בדרישות |
|---|---|---|
כששתי התכונות, יתירות כשל ואיזון עומסים משוקלל, מושבתות, כל הקצוות העורפיים שהוגדרו הם קצוות עורפיים ראשיים. קבוצת השרתים העורפיים שעומדים בדרישות מוגדרת כך:
|
||
אם התכונה 'איזון עומסים במעבר לגיבוי' מושבתת והתכונה 'איזון עומסים משוקלל' מופעלת, השרתים העורפיים שעומדים בדרישות הם אלה ששייכים לקבוצה הראשונה מבין הקבוצות הבאות שלא ריקה:
|
||
כשהתכונה "איזון עומסים עם יתירות כשל" מופעלת והתכונה "איזון עומסים משוקלל" מושבתת, מאזן העומסים משתמש במידע מבדיקת התקינות ובהגדרות של מדיניות יתירות הכשל כדי להגדיר את קבוצת ה-backend המתאימים:
|
||
אם מפעילים גם את התכונה של מעבר אוטומטי לגיבוי וגם את התכונה של איזון עומסים משוקלל, מאזן העומסים משתמש במידע על המשקל, במידע על בדיקות התקינות ובהגדרות של מדיניות המעבר האוטומטי לגיבוי כדי להגדיר את קבוצת השרתים העורפיים שעומדים בדרישות:
|
2.2 בחירת קצה עורפי מתאים
מאזן העומסים שומר גיבובים של קצוות עורפיים שעומדים בדרישות, כשכל גיבוב של קצה עורפי ממופה למעגל יחידה. איזון עומסים משוקלל משנה את האופן שבו קצוות עורפיים כשירים ממופים למעגל, כך שסביר יותר שייבחרו קצוות עורפיים עם משקלים גבוהים יותר, באופן יחסי למשקלים שלהם.
כשמאזן העומסים מעבד מנה (packet) של חיבור שלא מופיע בטבלת מעקב החיבורים, הוא מחשב גיבוב (hash) של מאפייני המנה וממפה את הגיבוב לאותו מעגל יחידה, ובוחר קצה עורפי מתאים בהיקף המעגל. קבוצת המאפיינים של חבילת הנתונים שמשמשת לחישוב ה-hash של חבילת הנתונים מוגדרת על ידי ההגדרה של הזיקה לסשן. לדוגמה, אם הזיקה לסשן שנבחרה מובילה לגיבוב (hash) של בחירת קצה עורפי עם 2 ערכים או 3 ערכים, כל חיבורי ה-TCP מכתובת IP של מקור ממופים לאותו קצה עורפי שעומד בדרישות.
- אם לא מגדירים במפורש זיקה לסשן, ברירת המחדל היא הזיקה לסשן
NONE.
גיבוב עקבי מבטיח שמאזן העומסים יקצה חיבורים חדשים לשרתי קצה עורפיים שעומדים בדרישות באופן שממזער שיבושים במיפוי, גם אם משתנה מספר שרתי הקצה העורפיים שעומדים בדרישות או המשקלים שלהם.
מאזן העומסים תמיד בוחר את אותו קצה עורפי מתאים לחיבור, ובאופן כללי יותר, תמיד בוחר את אותו קצה עורפי מתאים לכל החבילות עם מאפייני חבילה זהים, כפי שמוגדר בהגדרת הזיקה לסשן, במצבים הבאים:
אם לא מוגדר איזון עומסים משוקלל, כשקבוצת הקצוות העורפיים המתאימים לא משתנה.
אם מוגדר איזון עומסים משוקלל, כשקבוצת השרתים העורפיים שעומדים בדרישות לא משתנה והמשקל של כל שרת עורפי שעומד בדרישות נשאר קבוע.
אם מוסיפים או מסירים קצה עורפי שעומד בדרישות, או משנים את המשקל שלו, הגיבוב העקבי נועד לצמצם את השיבוש במיפוי לקצוות עורפיים אחרים שעומדים בדרישות. כלומר, רוב החיבורים שממופים לקצוות עורפיים אחרים שעומדים בדרישות ממשיכים להיות ממופים לאותו קצה עורפי שעומד בדרישות.
בנוסף, גיבוב עקבי מבטיח שמאזן העומסים יפיץ את החיבורים החדשים בין השרתים העורפיים שעומדים בדרישות בצורה הוגנת ככל האפשר. לכל הגיבובים האפשריים של חבילות, כפי שמוגדרים בהגדרת הזיקה לסשן (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 שניות אם לא מעובדים חבילות חדשות של תעבורת נכנסת על ידי Maglev. מידע נוסף זמין במאמר זמן קצוב לתפוגה במצב חוסר פעילות.
חיבורי TCP סגורים: הרשומות בטבלת מעקב החיבורים של חיבורי TCP לא מוסרות כשחיבור TCP נסגר באמצעות חבילת
FINאוRST. יכול להיות שהם יוסרו בהמשך כרשומה לא פעילה. כל חיבור TCP חדש תמיד נושא את הדגלSYN, והוא כפוף לעיבוד שמתואר בשלב בדיקה אם יש רשומה בטבלת מעקב החיבורים.כשהחיבורים לא נשמרים ביתירות כשל: כשמוגדר לפחות שרת backend אחד ליתירות כשל וההגדרה "זמן להשלמת תהליך (connection draining) ביתירות כשל" מושבתת, מאזן העומסים מסיר את כל הרשומות בטבלת מעקב החיבורים אחרי שקבוצת שרתי ה-backend המתאימים עוברת בין שרתי ה-backend הראשיים לבין שרתי ה-backend ליתירות כשל, בכפוף לכללים הבאים:
מאזן העומסים לא מסיר באופן יזום רשומות מטבלת מעקב החיבורים ברגע שקבוצת הקצוות העורפיים המתאימים עוברת בין קצוות עורפיים ראשיים לבין קצוות עורפיים של יתירות כשל. במקום זאת, מאזן העומסים מסיר כל רשומה בטבלת מעקב החיבורים כשמגיע החבילה הבאה לחיבור, בתנאי שקבוצת השרתים העורפיים שעומדים בדרישות לא חזרה למצב הקודם.
אם קבוצת הקצוות העורפיים המתאימים עוברת בין קצוות עורפיים ראשיים וקצוות עורפיים של יתירות כשל ובחזרה (לדוגמה, מראשי ליתירות כשל, ואז בחזרה לראשי), ולא הגיעו חבילות לחיבור בין אירועי המעבר, הרשומה בטבלת מעקב החיבורים נשמרת, אלא אם סיבה או אירוע אחרים מסירים את הרשומה בטבלת מעקב החיבורים.
מידע נוסף זמין במאמר הפסקת פעילות של חיבורים במעבר לגיבוי בעת כשל.
כשהחיבורים לא נשמרים ב-backend לא תקינים: כששמירת החיבורים ב-backend לא תקינים מושבתת בפרוטוקול של החבילה, מאזן העומסים מסיר רשומות בטבלת מעקב החיבורים ב-backend לא תקינים לפי הכללים הבאים:
מנגנון איזון העומסים לא מסיר באופן יזום רשומות בטבלת מעקב החיבורים של בקאנד שנבחר בעבר, ברגע שהבקאנד הופך ללא תקין. במקום זאת, מאזן העומסים מסיר רשומה מטבלת מעקב החיבורים כשמגיע החבילה הבאה לחיבור, בתנאי שהקצה העורפי שנבחר קודם עדיין לא תקין. המערכת מתייחסת לחבילות הבאות של החיבור כאל חיבור חדש, כי מאזן העומסים בוחר קצה עורפי חדש שעומד בדרישות ויוצר רשומה חדשה בטבלת מעקב החיבורים.
אם קצה עורפי שנבחר בעבר משתנה מתקין ללא תקין, ואז חוזר להיות תקין, ולא הגיעו מנות לחיבור בזמן שהקצה העורפי שנבחר בעבר היה לא תקין, הרשומה בטבלת מעקב החיבורים נשמרת, אלא אם סיבה או אירוע אחרים מסירים את הרשומה בטבלת מעקב החיבורים.
זמן להשלמת תהליך (connection draining) של שירותי backend שהוסרו, הופסקו או נמחקו: אם מופעל זמן להשלמת תהליך של שירותי backend שהוסרו, הופסקו או נמחקו, הרשומות בטבלת מעקב החיבורים יוסרו אחרי זמן קצוב לתפוגה של השלמת התהליך, שאפשר להגדיר. הספירה לאחור עד לזמן הקצוב לתפוגה מתחילה כשמתקבלת הפקודה להסיר (לנטוש), לעצור או למחוק קצה עורפי (כולל פקודות מחיקה שנובעות מצמצום אנכי של קבוצת מופעי מכונה מנוהלים). אם מושבתת האפשרות של זמן להשלמת תהליך (connection draining) ב-backend שהוסר, הופסק או נמחק, הרשומות בטבלת מעקב החיבורים יוסרו כשתתקבל הפקודה להסיר, להפסיק או למחוק את ה-backend. איך מפעילים זמן להשלמת תהליך (connection draining)
זיקה לסשן (session affinity)
הגדרת זיקה לסשן (session affinity) במאזן עומסי רשת אזורי חיצוני להעברת סיגנל ללא שינוי מגדירה את הגיבוב של המנות לבחירת בק-אנד, ובהתאם למצב המעקב אחר החיבורים, את הגיבוב של המנות למעקב אחר החיבורים.
מגדירים את הזיקה לסשן בשירות לקצה העורפי, ולא בכל קבוצת מכונות או קבוצת נקודות קצה ברשת (NEG) בקצה העורפי. הזיקה לסשן קובעת אילו כותרות של IP ושל שכבה 4 משמשות לחישוב גיבוב (hash) של מאפייני החבילה. הגיבוב של מאפייני החבילה משמש בשלבי הבחירה של הקצה העורפי.
במאזני עומסי רשת חיצוניים אזוריים להעברת סיגנל ללא שינוי אפשר להשתמש בהגדרות הבאות של זיקה לסשן (session affinity).
| שיטת גיבוב לבחירת קצה עורפי | הגדרת הזיקה לסשן (session affinity) |
|---|---|
|
גיבוב של 5 טופלים (מורכב מכתובת ה-IP של המקור, יציאת המקור, פרוטוקול, כתובת ה-IP של היעד ויציאת היעד) לחבילות לא מקוטעות שכוללות מידע על יציאה (חבילות TCP וחבילות UDP לא מקוטעות) אוגיבוב (hash) של 3 ערכים (כתובת ה-IP של המקור, כתובת ה-IP של היעד והפרוטוקול) לחבילות UDP מקוטעות ולחבילות של כל שאר הפרוטוקולים |
NONE1
או CLIENT_IP_PORT_PROTO
|
| גיבוב של 3 טפלים (מורכב מכתובת ה-IP של המקור, כתובת ה-IP של היעד והפרוטוקול) |
CLIENT_IP_PROTO |
| גיבוב (hash) של 2-tuple (מורכב מכתובת ה-IP של המקור ומכתובת ה-IP של היעד) |
CLIENT_IP |
1 NONE קרבה לסשן לא מציינת שאין קרבה לסשן. במקום זאת, המשמעות היא שזיקה לסשן (session affinity) מתבצעת באמצעות גיבוב (hash) של 5 טאפלים או 3 טאפלים של מאפייני חבילות – באופן פונקציונלי, זהה להתנהגות שמתקבלת כשמגדירים את CLIENT_IP_PORT_PROTO.
מדיניות מעקב אחרי חיבורים
בקטע הזה מתוארות ההגדרות במדיניות מעקב החיבורים של מאזן העומסים:
מצב מעקב אחרי חיבורים
בקטע הזה מוסבר מתי ואיך מאזן העומסים יוצר רשומות בטבלת מעקב החיבורים שלו. מאזני עומסי רשת אזוריים חיצוניים להעברת סיגנל ללא שינוי תומכים במעקב אחרי חיבורים על סמך פרוטוקול וזיקה לסשן (session affinity):תמיד אפשר לעקוב אחרי חיבורי TCP, בכל האפשרויות של זיקה לסשן.
אפשר לעקוב אחרי חיבורי UDP, ESP ו-GRE בכל האפשרויות של זיקה לסשן, חוץ מ-
NONE. בזיקה לסשן (session affinity)NONE, אי אפשר לעקוב אחרי החיבור של הפרוטוקולים האלה.כל הפרוטוקולים האחרים, כמו ICMP ו-ICMPv6, לא מאפשרים מעקב אחר חיבורים, בכל האפשרויות של זיקה לסשן (session affinity).
כשאפשר לעקוב אחרי חיבורים, מצב המעקב אחרי החיבורים, הפרוטוקול והזיקה לסשן קובעים את קבוצת מאפייני החבילה שמשמשים ליצירת הגיבוב של החבילה בכל רשומה בטבלת המעקב אחרי החיבורים.
מצב המעקב אחרי החיבור יכול להיות אחד מהבאים:
PER_CONNECTION. זהו מצב מעקב החיבורים שמוגדר כברירת מחדל והוא הכי מפורט. כל חיבור מוגדר כגיבוב של 5 טאפלים או כגיבוב של 3 טאפלים של מאפייני חבילות, בהתאם לשאלה אם פרטי היציאה מופיעים בחבילה. מנות לא מקוטעות שכוללות פרטי יציאה (כמו מנות TCP ומנות UDP לא מקוטעות) נרשמות ביומן באמצעות גיבוב של 5 טופלים. כל שאר החבילות עוברות מעקב באמצעות גיבובים של 3 ערכים.
PER_SESSION. מצב מעקב חיבורים פחות מפורט זה משתמש בגיבוב שזהה לגיבוב של זיקה לסשן. בהתאם להעדפת הסשן שנבחרה, מצב המעקבPER_SESSIONיכול להתייחס לכמה חיבורים נפרדים כאל חיבור יחיד למטרות מעקב אחר חיבורים. כך החיבור נחשב לחדש בתדירות נמוכה יותר, והוא כפוף לשלבים לבחירת קצה עורפי.
בטבלה הבאה מפורטים:
- ערכי ה-hash של החבילות שמשמשים לבחירת הקצה העורפי.
- הגיבוב של המנות שמשמש למעקב אחר חיבורים, על סמך מצב המעקב אחר החיבורים, הפרוטוקול וזיקה לסשן.
| זיקה לסשן (session affinity) | גיבוב (hash) של חבילה לבחירת קצה עורפי | גיבוב (hash) של מנות למעקב אחר חיבורים | |
|---|---|---|---|
כשמשתמשים במצב מעקב PER_CONNECTION (ברירת מחדל) |
כשמשתמשים במצב מעקב PER_SESSION |
||
NONE (ברירת מחדל) |
|
|
|
CLIENT_IP_PORT_PROTO |
|
|
|
CLIENT_IP_PROTO |
|
|
|
CLIENT_IP |
|
|
|
כדי ללמוד איך לשנות את מצב מעקב החיבורים, ראו הגדרת מדיניות מעקב חיבורים.
שמירת החיבור בקצוות עורפיים לא תקינים
התמדה של חיבורים בשרתי קצה עורפיים לא תקינים קובעת אם חיבורים קיימים יכולים להישאר במכונה וירטואלית של שרת קצה עורפי שנבחרה קודם, אם המכונה הווירטואלית שנבחרה קודם הופכת ללא תקינה. כדי לשמר את החיבורים בקצוות עורפיים לא תקינים, ה-VM של הקצה העורפי צריך להישאר חבר בקבוצת מכונות עם איזון עומסים או ב-NEG, והשילוב של הפרוטוקול והזיקה לסשן צריך לתמוך במעקב אחרי חיבורים.
אלה האפשרויות הזמינות לשמירת החיבור:
DEFAULT_FOR_PROTOCOL(ברירת מחדל)NEVER_PERSISTALWAYS_PERSIST
בטבלה הבאה מתוארת ההתנהגות של שמירת החיבורים בשרתי backend לא תקינים, בהתאם לאפשרות של שמירת החיבורים בשרתי backend לא תקינים, למצב מעקב החיבורים, לזיקה לסשן ולפרוטוקול.
| האפשרות Connection persistence on unhealthy backends | התנהגות של חיבורים קבועים בקצוות עורפיים לא תקינים | |
|---|---|---|
כשמשתמשים במצב המעקב PER_CONNECTION (ברירת המחדל) |
כשמשתמשים במצב מעקב PER_SESSION |
|
DEFAULT_FOR_PROTOCOL |
|
|
NEVER_PERSIST |
כל הפרוטוקולים: החיבורים לא נשמרים בקצוות עורפיים לא תקינים | |
ALWAYS_PERSIST
צריך להשתמש באפשרות הזו רק בתרחישים מתקדמים לדוגמה. |
|
אי אפשר להגדיר |
כדי ללמוד איך לשנות את ההתנהגות של התמדת החיבור, קראו את המאמר הגדרת מדיניות למעקב אחרי חיבורים.
התנהגות של שמירת חיבורי TCP בקצוות עורפיים לא תקינים
מאזן העומסים משתמש במעקב אחר חיבורי גיבוב של 5 טאפלים לחיבורי TCP במצבים הבאים:
- כשמשתמשים במצב מעקב
PER_CONNECTION(כל הזיקות לסשן), או - כשמשתמשים במצב המעקב
PER_SESSION, וגם הזיקה לסשן היא אוNONEאוCLIENT_IP_PORT_PROTO.
כשמגדירים למאזן העומסים מעקב אחרי חיבורים באמצעות גיבוב של 5 ערכים לחיבורי TCP, חשוב לזכור את ההתנהגויות הבאות:
- אם הקצה העורפי הלא תקין ממשיך להגיב לחבילות, החיבור נמשך עד שהוא מאופס או נסגר (על ידי הקצה העורפי הלא תקין או על ידי הלקוח).
- אם ה-backend הלא תקין שולח חבילת איפוס TCP (RST) או לא מגיב לחבילות, יכול להיות שהלקוח ינסה שוב עם חיבור חדש, ויאפשר למאזן העומסים לבחור backend מתאים אחר. (מנות TCP
SYNנחשבות לחיבורים חדשים בשלב זיהוי שרתי קצה שעומדים בדרישות).
זמן קצוב לתפוגה של חוסר פעילות
התוקף של הרשומות בטבלאות מעקב החיבורים פג 60 שניות אחרי שמאזן העומסים מעבד את החבילה האחרונה שתאמה לרשומה. אי אפשר לשנות את ערך הזמן הקצוב לתפוגה של חוסר פעילות.זמן להשלמת תהליך (connection draining) לשרתי קצה עורפיים שהוסרו, הופסקו או נמחקו
התכונה "זמן להשלמת תהליך" מאפשרת להגדיר את משך הזמן המינימלי שבו החיבורים הקיימים יישארו בטבלת מעקב החיבורים של מאזן העומסים, כשאחד מהמקרים הבאים מתרחש:
- מכונה וירטואלית (VM) מוסרת מקבוצת שרתי עורפי (backend instance) (כולל נטישת מכונה בקבוצת מופעי מכונה מנוהלים לקצה העורפי)
- מכונה וירטואלית נעצרת או נמחקת (כולל פעולות אוטומטיות כמו עדכונים בהדרגה או הקטנת קבוצת מופעי מכונה מנוהלים בקצה העורפי)
- נקודת קצה הוסרה מקבוצה של נקודות קצה ברשת (NEG) בקצה העורפי
כברירת מחדל, האפשרות "זמן להשלמת תהליך" מושבתת כשמסירים, עוצרים או מוחקים את הקצוות העורפיים. מידע נוסף זמין במאמר הפעלת זמן להשלמת תהליך (connection draining).
איזון עומסים משוקלל
איזון עומסים משוקלל משפיע על ה-backends שעומדים בדרישות להיות backend בשלבי הבחירה של ה-backend. כל מכונה וירטואלית או נקודת קצה בקצה העורפי מדווחת על המשקל שלה למאזן העומסים באמצעות בדיקת תקינות מסוג HTTP וכותרת תגובה מותאמת אישית. כדי להשתמש באיזון עומסים משוקלל, צריך להגדיר את הפרטים הבאים בשירות לקצה העורפי של מאזן העומסים:
- הגדרת המדיניות של המיקום (
localityLbPolicy) חייבת להיותWEIGHTED_MAGLEV. בדיקת תקינות צריכה להיות בדיקת תקינות HTTP ששולחת כותרת תגובה מיוחדת:
- שם השדה בכותרת התגובה חייב להיות
X-Load-Balancing-Endpoint-Weight. - ערכי השדות בכותרת התגובה יכולים להיות בין
0ל-1000, כולל.
- שם השדה בכותרת התגובה חייב להיות
מידע נוסף זמין במאמר בנושא הגדרת איזון עומסים משוקלל.
שיקולים לגבי איזון עומסים משוקלל
איזון עומסים משוקלל שימושי בתרחישים הבאים, שבהם הקצה העורפי יכול להמשיך לעבד את החיבורים הקיימים שלו:
איזון עומסים משוקלל מאפשר לקצה עורפי שמעבד חיבורים ארוכים או חיבורים שכוללים כמויות גדולות של נתונים, להורות למאזן העומסים להפחית את מספר החיבורים החדשים שהוא מקבל.
איזון עומסים משוקלל מאפשר לשרת בק-אנד שנמצא בעומס יתר או שנכנס למצב תחזוקה להסיר את עצמו מרשימת שרתי הבק-אנד הזמינים לחיבורים חדשים. כדי לעשות את זה, ה-backend העמוס שולח את כותרת התגובה
X-Load-Balancing-Endpoint-Weight: 0(ויכול להמשיך לעבור או להיכשל בבדיקת התקינות של מאזן העומסים). השיטה הזו עובדת כי כל הקצוות העורפיים עם משקל שונה מאפס (ללא קשר לסטטוס בדיקת התקינות) הם קצוות עורפיים מתאימים יותר בשלב זיהוי קצוות עורפיים מתאימים.
כשמשתמשים באיזון עומסים, חשוב לזכור את הנקודות הבאות:
אם המשקלים של קצוות עורפיים כשירים משתנים לעיתים קרובות, איזון עומסים משוקלל עלול לפגוע בזיקה לסשן. מידע נוסף זמין בשלב בחירת קצה עורפי שעומד בדרישות.
אם אתם משתמשים באותה קבוצת מכונות או באותה קבוצת נקודות קצה ברשת (NEG) בתור קצה עורפי של שני שירותים לקצה העורפי של מאזן העומסים או יותר, אתם יכולים לדווח על משקל ייחודי לכל שירות לקצה העורפי באמצעות האסטרטגיה הבאה:
משתמשים בבדיקת תקינות ייחודית של HTTP לכל שירות לקצה העורפי. בכל בדיקת תקינות אפשר להשתמש ביציאת יעד ייחודית או בפרמטר
request-path.מגדירים את שרתי ה-Backend (backend instance) או נקודות הקצה כך שיגיבו עם מידע מתאים על המשקל לכל בדיקת תקינות.
יתירות כשל
תכונת יתירות הכשל מאפשרת לכם להשפיע על קבוצת השרתים העורפיים המתאימים, על ידי סיווג של קבוצות שרתים עורפיים או קבוצות של נקודות קצה ברשת (NEG) בקצה העורפי ונקודות הקצה שלהן באופן הבא:
- קצוות עורפיים ראשיים הם מכונות וירטואליות או נקודות קצה בקבוצת מכונות או ב-NEG שמוגדרים כקבוצת קצוות עורפיים ראשית.
- קצוות עורפיים לגיבוי הם מכונות וירטואליות או נקודות קצה בקבוצת מכונות או ב-NEG שמוגדרים כקבוצת קצוות עורפיים לגיבוי.
כברירת מחדל, כשמוסיפים קבוצת מופעים או NEG לשירות backend, קבוצת המופעים או ה-NEG הן קבוצת backend ראשית. אפשר להוסיף עד 50 קבוצות עורפיות ראשיות ו-50 קבוצות עורפיות ליתירות כשל לשירות לקצה העורפי.
כדי להפעיל את תכונת יתירות הכשל, צריך להגדיר את שירות הקצה העורפי של מאזן העומסים עם שני הרכיבים הבאים:
- לפחות קבוצת קצה עורפי ראשית אחת שאינה ריקה
- לפחות קבוצת עורף חלופית אחת לא ריקה
כשיתירות כשל מופעלת, הגורמים הבאים קובעים את קבוצת השרתים העורפיים שעומדים בדרישות:
- מצב התקינות של כל קצה עורפי
- יחס היתירות כשל במדיניות היתירות כשל
- ההגדרה drop traffic if backends are unhealthy במדיניות המעבר לגיבוי (failover)
- אם אתם משתמשים ביתירות כשל לבד או בשילוב עם איזון עומסים משוקלל
מדיניות יתירות כשל
אפשר לשנות את ההגדרות הבאות במדיניות יתירות הכשל של שירות לקצה העורפי. מדיניות יתירות הכשל רלוונטית רק אם יתירות הכשל מופעלת.
- Failover ratio: מספר בין
0.0ל-1.0, כולל. - Drop traffic if backends are unhealthy: ערך בוליאני שקובע את ההתנהגות של מאזן העומסים כמוצא אחרון. ההגדרה יחס יתירות הכשל וההגדרה הפסקת התנועה אם השרתים העורפיים לא תקינים פועלות יחד עם גורמים אחרים כדי לשלוט בקבוצת השרתים העורפיים שעומדים בדרישות.
- הפסקת החיבורים במעבר לגיבוי: ערך בוליאני שקובע אם החיבורים נשמרים בשרתי קצה עורפיים שנבחרו קודם, כשהקבוצה של שרתי קצה עורפיים שעומדים בדרישות עוברת בין שרתי קצה עורפיים ראשיים לבין שרתי קצה עורפיים לגיבוי.
יחס יתירות כשל
יחס יתירות הכשל קובע מתי קבוצת הקצוות העורפיים המתאימים עוברת בין הקצוות העורפיים הראשיים לבין הקצוות העורפיים של יתירות הכשל. היחס יכול להיות מספר בין 0.0 ל-1.0, כולל. אם לא מציינים יחס יתירות כשל, Google Cloud משתמש בערך ברירת המחדל 0.0. מומלץ להגדיר את יחס יתירות הכשל למספר שמתאים לתרחיש לדוגמה שלכם, ולא להסתמך על ברירת המחדל הזו.
הפסקת הפעילות של החיבור במעבר לגיבוי בעקבות כשל
ההגדרה זמן להשלמת תהליך (connection draining) ביתירות כשל קובעת אם חיבור קיים נמשך ב-VM או בנקודת קצה (endpoint) של קצה עורפי שנבחרו קודם, כשקבוצת הקצוות העורפיים המתאימים עוברת בין קצוות עורפיים ראשיים לבין קצוות עורפיים של יתירות כשל.
התכונה 'הפסקת החיבורים בהעברה אוטומטית לגיבוי' מופעלת כברירת מחדל. בטבלה הבאה מפורט אם החיבורים נשמרים, בהתאם לאפשרות של זמן להשלמת תהליך (connection draining) במעבר לגיבוי ולפרוטוקול.
| זמן להשלמת תהליך (connection draining) באפשרות של יתירות כשל | ההתנהגות כשקבוצת הקצוות העורפיים המתאימים עוברת בין קצוות עורפיים ראשיים לבין קצוות עורפיים של יתירות כשל |
|---|---|
| מופעל (ברירת מחדל) |
מידע על הפרוטוקולים שניתן לעקוב אחרי החיבורים שלהם מופיע בטבלה שבקטע מצב מעקב אחרי חיבורים. |
| מושבת | כל הפרוטוקולים: החיבורים לא נשמרים כשקבוצת השרתים העורפיים שעומדים בדרישות עוברת בין שרתים עורפיים ראשיים לבין שרתים עורפיים למעבר לגיבוי. |
השבתת זמן להשלמת תהליך (connection draining) במעבר לגיבוי בעת כשל שימושית בתרחישים הבאים:
החלת תיקוני אבטחה על מכונות וירטואליות בעורף האתר. לפני התיקון, אתם יכולים להגדיר שרתי backend ראשיים תקינים עם משקל שאינו אפס כך שייכשלו בבדיקות התקינות, או להגדיר את המשקלים שלהם לאפס. כך, קצוות עורפיים שעומדים בדרישות יכולים להיות קצוות עורפיים תקינים של גיבוי עם משקל חיובי. אם משביתים את זמן ההשלמה של התהליך במקרה של יתירות כשל, מאזן העומסים מסיר את הרשומות בטבלת המעקב אחרי החיבורים, מחיל את השלבים לבחירת קצה עורפי על החבילות הבאות ומעביר אותן לקצה עורפי מתאים אחר. לאחר מכן, הקצה האחורי השונה סוגר את החיבור באמצעות איפוס TCP, כדי שמכונות וירטואליות של לקוחות יוכלו ליצור במהירות חיבור חדש למאזן העומסים.
מכונה וירטואלית אחת בקצה העורפי לעקביות בנתונים. אם אתם צריכים לוודא שבקבוצת הקצוות העורפיים שעומדים בדרישות יש רק מכונה וירטואלית אחת או נקודת קצה אחת, השבתת הזמן להשלמת תהליך (connection draining) במקרה של יתירות כשל מפחיתה את הסיכוי לחוסר עקביות בנתונים.
במאמר הגדרת מדיניות של יתירות כשל מוסבר איך משביתים את הזמן להשלמת תהליך ביתירות כשל.
שיטות מומלצות והנחיות
כדי לבצע אופטימיזציה של מאזן עומסי רשת אזורי חיצוני להעברת סיגנל ללא שינוי, אפשר לפעול לפי ההנחיות התפעוליות האלה. בקטעים הבאים מפורטות דרישות טכניות לניהול מנות UDP מפוצלות ושיטות מומלצות לבדיקת חלוקת העומס מלקוח יחיד.
טיפול בפרגמנטציה של UDP
מאזני עומסי רשת אזוריים חיצוניים להעברת סיגנל ללא שינוי שמבוססים על שירותים לקצה העורפי יכולים לעבד מנות UDP עם פרגמנטים וגם מנות UDP ללא פרגמנטים. אם האפליקציה משתמשת בחבילות UDP מקוטעות, חשוב לזכור את הדברים הבאים:
- יכול להיות שחבילות UDP יפוצלו לפני שיגיעו לרשת VPC של Google Cloud.
- 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(גיבוב של 2-tuple) או ל-CLIENT_IP_PROTO(גיבוב של 3-tuple), כדי שאותו בק-אנד ייבחר עבור מנות UDP שכוללות פרטי יציאה ומקטעים של UDP (מלבד המקטע הראשון) שחסרים בהם פרטי יציאה. מגדירים את מצב מעקב החיבורים של שירות הקצה העורפי ל-PER_SESSION, כדי שהרשומות בטבלת מעקב החיבורים ייווצרו באמצעות אותם ערכי גיבוב של 2-tuple או 3-tuple.
בדיקה מלקוח אחד
כשבודקים מאזן עומסי רשת חיצוני אזורי להעברת סיגנל ללא שינוי מלקוח אחד, חשוב לזכור את הנקודות הבאות:
אם מכונת הלקוח הווירטואלית היא לא קצה עורפי של מאזן העומסים: חיבורים חדשים מעובדים כמו שמתואר בשלבים של בחירת קצה עורפי ומעקב אחרי חיבורים. בשלב בחירת קצה עורפי מתאים, מאזן העומסים יוצר גיבוב (hash) של מאפייני החבילה בהתאם לזיקה לסשן (session affinity).
חשוב לזכור שכל האפשרויות של זיקה לסשן מסתמכות לפחות על כתובת ה-IP של הלקוח, ויכול להיות שחיבורים מאותו לקוח יופצו לאותו קצה עורפי שעומד בדרישות בתדירות גבוהה יותר ממה שאתם מצפים. לכן, אי אפשר ליצור מודל מדויק של ההתפלגות הכוללת של חיבורים חדשים על ידי התחברות למאזן עומסי רשת אזורי חיצוני של רשתות להעברת סיגנל ללא שינוי מלקוח אחד.
אם מכונת הלקוח הווירטואלית היא גם מכונת קצה עורפי של מאזן העומסים: חיבורים חדשים לא מעובדים בפועל על ידי מאזן העומסים. חבילות יוצאות עם כתובת ה-IP של היעד של כלל ההעברה של מאזן העומסים מנותבות באופן מקומי בתוך מערכת ההפעלה של הלקוח, בגלל הנוכחות של נתיב מקומי לכלל ההעברה.
המאמרים הבאים
- כדי להגדיר מאזן עומסי רשת חיצוני עם שירות לקצה העורפי לתנועת TCP או UDP בלבד (תמיכה בתנועת IPv4 ו-IPv6), קראו את המאמר הגדרת מאזן עומסי רשת חיצוני עם שירות לקצה העורפי.
- כדי להגדיר מאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי לכמה פרוטוקולי IP (תמיכה בתעבורת נתונים ב-IPv4 וב-IPv6), קראו את המאמר הגדרת מאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי לכמה פרוטוקולי IP.
- כדי להגדיר מאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי עם קצה עורפי של NEG אזורי, אפשר לעיין במאמר הגדרת מאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי עם קצה עורפי של NEG אזורי.
- במאמר העברת מאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי ממאגר יעד לשירות לקצה העורפי מוסבר איך מעבירים מאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי ממאגר יעד לקצה העורפי לשירות אזורי לקצה העורפי.