מאזני עומסי רשת להעברת סיגנל ללא שינוי מפזרים את התעבורה הנכנסת בין מכונות זמינות בקצה העורפי. במסמך הזה מוסבר איך מאזן העומסים בוחר בקצה העורפי, עוקב אחרי חיבורים ומנהל את זיקה לסשן (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. השלבים לבחירת קצה עורפי
בחיבור חדש, מאזן העומסים משתמש בגיבוב עקבי כדי לבחור קצה עורפי מבין הקצוות העורפיים שעומדים בדרישות.
בשלבים הבאים מוסבר איך בוחרים קצה עורפי שעומד בדרישות לחיבור חדש, ואז מתעדים את החיבור הזה בטבלה למעקב אחרי חיבורים.
2.1 זיהוי של שרתי קצה שעומדים בדרישות
שרתי קצה עורפיים שעומדים בדרישות הם שרתי קצה עורפיים שיכולים לקבל חיבורים חדשים. בטבלה הבאה מוגדרת קבוצת השרתים העורפיים שעומדים בדרישות, בהתאם לשאלה אם מאזן העומסים משתמש ביתירות כשל והאם איזון עומסים משוקלל מופעל.
| מעבר לגיבוי (Failover) | איזון עומסים משוקלל | שרתי קצה עורפיים שעומדים בדרישות |
|---|---|---|
אם גם הגיבוי האוטומטי וגם איזון העומסים המשוקלל מושבתים, כל השרתים העורפיים המוגדרים הם שרתים עורפיים ראשיים. קבוצת השרתים העורפיים שעומדים בדרישות מוגדרת כך:
|
||
אם התכונה 'איזון עומסים במעבר לגיבוי' מושבתת והתכונה 'איזון עומסים משוקלל' מופעלת, השרתים העורפיים שעומדים בדרישות הם אלה ששייכים לקבוצה הראשונה מבין הקבוצות הבאות שלא ריקה:
|
||
כשתכונת איזון העומסים של יתירות כשל מופעלת ותכונת איזון העומסים המשוקלל מושבתת, מאזן העומסים משתמש במידע של בדיקות התקינות ובהגדרת מדיניות יתירות הכשל כדי להגדיר את קבוצת השרתים העורפיים שעומדים בדרישות:
|
||
אם מפעילים גם את התכונה של מעבר אוטומטי לגיבוי וגם את התכונה של איזון עומסים משוקלל, מאזן העומסים משתמש במידע על המשקל, במידע על בדיקות התקינות ובהגדרות של מדיניות המעבר האוטומטי לגיבוי כדי להגדיר את קבוצת השרתים העורפיים שעומדים בדרישות:
|
2.2 בחירת קצה עורפי שעומד בדרישות
מאזן העומסים שומר גיבובים של קצוות עורפיים שעומדים בדרישות, כשכל גיבוב של קצה עורפי ממופה למעגל יחידה. איזון עומסים משוקלל משנה את המיפוי של קצוות עורפיים שעומדים בדרישות למעגל, כך שקצוות עורפיים עם משקלים גבוהים יותר ייבחרו בסבירות גבוהה יותר, באופן יחסי למשקלים שלהם.
כשמעבדים מנה (packet) לחיבור שלא מופיע בטבלת מעקב החיבורים, מאזן העומסים מחשב גיבוב (hash) של מאפייני המנה וממפה את הגיבוב הזה לאותו מעגל יחידה, ובוחר קצה עורפי מתאים בהיקף המעגל. קבוצת המאפיינים של החבילה שמשמשת לחישוב הגיבוב של החבילה מוגדרת על ידי הגדרת הזיקה לסשן (session affinity). לדוגמה, אם זיקה לסשן (session affinity) שנבחרה מובילה לגיבוב של בחירת בק-אנד עם 2 או 3 ערכים, כל חיבורי ה-TCP מכתובת IP של מקור ממופים לאותו בק-אנד שעומד בדרישות.
- אם לא מגדירים במפורש את ההעדפה של סשן, ברירת המחדל היא
NONEsession affinity.
גיבוב עקבי מבטיח שמאזן העומסים יקצה חיבורים חדשים לשרתי קצה עורפיים שעומדים בדרישות באופן שממזער את שיבושי המיפוי, גם אם משתנה מספר שרתי הקצה העורפיים שעומדים בדרישות או המשקלים שלהם.
מאזן העומסים תמיד בוחר את אותו שרת קצה עורפי שעומד בדרישות לחיבור, ובאופן כללי יותר, תמיד בוחר את אותו שרת קצה עורפי שעומד בדרישות לכל החבילות עם מאפייני חבילה זהים כפי שמוגדר על ידי הגדרת הזיקה לסשן (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 יצירת רשומה בטבלה למעקב אחרי חיבורים
אחרי שבוחרים בק-אנד, מאזן העומסים (LB) יוצר רשומה בטבלת מעקב החיבורים אם זיקה לסשן (session affinity) שהוגדרה תומכת במעקב החיבורים של פרוטוקול החבילה.אם זיקת הסשן שהוגדרה לא תומכת במעקב אחר חיבורים עבור הפרוטוקול של המנה, מדלגים על השלב הזה.
אם זיקת הסשן שהוגדרה תומכת במעקב אחר חיבורים עבור הפרוטוקול של המנה, רשומת טבלת המעקב אחר החיבורים שנוצרת ממפה את מאפייני המנה לשרת העורפי שנבחר. השדות בכותרת החבילה שמשמשים למיפוי הזה תלויים במצב המעקב אחר החיבור ובזיקה לסשן (session affinity) שהגדרתם.
בטבלה שבקטע מצב מעקב אחר חיבורים מפורטים הפרוטוקולים שאפשר לעקוב אחריהם בהתאם לבחירות ההגדרה שלכם, ומאפייני החבילות שמשמשים לגיבוב בטבלת המעקב אחר החיבורים.
3. ניהול רשומות בטבלת מעקב החיבורים
מאזן העומסים מנהל את הרשומות בטבלת מעקב החיבורים בהתאם לאירועים ולכללים הבאים:
- רשומות לא פעילות מוסרות: רשומה בטבלת מעקב אחר חיבורים מוסרת אחרי שהחיבור לא היה פעיל במשך 60 שניות. מידע נוסף זמין במאמר בנושא פסק זמן של חוסר פעילות.
חיבורי 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 מושבתת. אם השינוי במצב בדיקת תקינות של שרת קצה שנבחר קודם חופף למעבר של קבוצת שרתי הקצה שעומדים בדרישות בין שרתי קצה ראשיים לשרתי קצה לגיבוי, רשומות בטבלת מעקב החיבורים מוסרות.
הפסקת חיבורים לשרתי קצה עורפיים שהוסרו, הופסקו או נמחקו: אם האפשרות הזו מופעלת, רשומות בטבלת מעקב החיבורים מוסרות אחרי פסק זמן מוגדר להפסקת החיבורים. הספירה עד לזמן הקצוב לתפוגה מתחילה כשמתקבלת הפקודה להסרה, להפסקה או למחיקה של שרת קצה עורפי. אם השבתתם את זמן להשלמת תהליך (connection draining) לשרתי קצה שהוסרו, הופסקו או נמחקו, הרשומות בטבלת מעקב החיבורים יוסרו כשהפקודה להסרה, להפסקה או למחיקה של שרת קצה תתקבל. מידע נוסף זמין במאמר הפעלת ניתוק הדרגתי של חיבורים.
זיקה לסשן (session affinity)
הגדרת זיקה לסשן (session affinity) במאזן עומסי רשת אזורי חיצוני להעברת סיגנל ללא שינוי מגדירה את הגיבוב של המנות לבחירת קצה עורפי, ובהתאם למצב המעקב אחרי חיבורים, את הגיבוב של המנות למעקב אחרי חיבורים.
אתם מגדירים את הזיקה לסשן (session affinity) בשירות לקצה העורפי, ולא בכל קבוצת מופעים של שרת עורפי (backend instance) או NEG. הזיקה לסשן קובעת אילו כתובות IP וכותרות Layer 4 משמשות לחישוב גיבוב של מאפייני מנות. הגיבוב של מאפייני החבילה משמש בשלבים של בחירת השרת העורפי.
מאזני עומסים אזוריים חיצוניים של רשתות להעברת סיגנל ללא שינוי תומכים בהגדרות הבאות של זיקה לסשן (session affinity).
| שיטת הגיבוב לבחירת השרת העורפי | הגדרת זיקה לסשן (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 קרבה לסשן לא מציינת שאין קרבה לסשן. במקום זאת, המשמעות היא שזיקה לסשן (session affinity) מתבצעת באמצעות גיבוב (hash) של 5 טאפלים או גיבוב של 3 טאפלים של מאפייני מנות – באופן פונקציונלי, זהה להתנהגות שמתקבלת כשמגדירים את CLIENT_IP_PORT_PROTO.
מדיניות מעקב אחר חיבורים
בקטע הזה מתוארות ההגדרות במדיניות מעקב החיבורים של מאזן העומסים:
מצב מעקב אחר חיבורים
בקטע הזה מוסבר מתי ואיך מאזן העומסים יוצר רשומות בטבלת מעקב החיבורים שלו. מאזני עומסי רשת אזוריים חיצוניים להעברת סיגנל ללא שינוי תומכים במעקב אחרי חיבורים על סמך פרוטוקול וזיקה לסשן (session affinity):חיבורי TCP תמיד ניתנים למעקב, בכל האפשרויות של זיקה לסשן.
אפשר לעקוב אחרי חיבורי UDP, ESP ו-GRE בכל האפשרויות של שיוך סשן חוץ מאשר
NONE.אי אפשר לעקוב אחרי חיבורים של כל הפרוטוקולים האחרים, כמו ICMP ו-ICMPv6.
כשאפשר לעקוב אחרי חיבורים, מצב המעקב אחרי החיבורים, הפרוטוקול והזיקה לסשן קובעים את קבוצת מאפייני החבילה שמשמשים ליצירת הגיבוב של החבילה בכל רשומה בטבלת המעקב אחרי החיבורים.
מצב מעקב החיבור יכול להיות אחד מהערכים הבאים:
PER_CONNECTION. זהו מצב מעקב החיבורים המוגדר כברירת מחדל והמפורט ביותר. כל חיבור מוגדר כגיבוב של 5 טופלים או כגיבוב של 3 טופלים של מאפייני מנות, בהתאם לשאלה אם פרטי היציאה קיימים במנה. מערכת מעקב אחרי מנות לא מקוטעות שכוללות מידע על יציאה (כמו מנות TCP ומנות UDP לא מקוטעות) באמצעות גיבוב של 5 טאפלים. כל שאר החבילות נרשמות באמצעות גיבוב של 3 טאפלים.
PER_SESSION. מצב מעקב החיבורים הפחות מפורט הזה משתמש בגיבוב שזהה לגיבוב של זיקה לסשן. בהתאם להעדפת הסשן שנבחרה, מצב המעקבPER_SESSIONיכול להתייחס לכמה חיבורים נפרדים כאל חיבור יחיד למטרות מעקב אחר חיבורים. כך תפחת התדירות שבה קישור נחשב חדש וכפוף לשלבי הבחירה של ה-Backend.
בטבלה הבאה מפורטים:
- הגיבובים של החבילות שמשמשים לבחירת השרת העורפי.
- הגיבוב של המנות שמשמש למעקב אחר חיבורים, על סמך מצב המעקב אחר החיבורים, הפרוטוקול וזיקה לסשן.
| זיקה לסשן (session affinity) | Packet hash לבחירת backend | Hash של חבילת נתונים למעקב אחר חיבור | |
|---|---|---|---|
כשמשתמשים במצב מעקב PER_CONNECTION (ברירת מחדל) |
כשמשתמשים במצב מעקב PER_SESSION |
||
NONE (ברירת מחדל) |
|
|
|
CLIENT_IP_PORT_PROTO |
|
|
|
CLIENT_IP_PROTO |
|
|
|
CLIENT_IP |
|
|
|
איך משנים את מצב מעקב החיבורים
התמדה של חיבורים בקצוות עורפיים לא תקינים
המשכיות החיבור בשרתי קצה עורפיים לא תקינים קובעת אם חיבורים קיימים יישארו במכונה וירטואלית או בנקודת קצה של שרת קצה עורפי שנבחרו קודם אחרי שהשרת הופך ללא תקין, בתנאי שהוא נשאר בקבוצת מופעים או ב-NEG עם איזון עומסים.
אלה האפשרויות הזמינות לגבי שמירת החיבור:
DEFAULT_FOR_PROTOCOL(ברירת מחדל)NEVER_PERSISTALWAYS_PERSIST
בטבלה הבאה מופיע סיכום של מצב החיבורים בהתאם למצבי קצה עורפיים לא תקינים, בהתאם לאפשרות של שמירת החיבור, לזיקה לסשן, למצב מעקב החיבור ולפרוטוקול.
| האפשרות Connection persistence on unhealthy backends | התנהגות של חיבורים מתמשכים בקצוות עורפיים לא תקינים | |
|---|---|---|
כשמשתמשים במצב מעקב PER_CONNECTION (ברירת מחדל) |
כשמשתמשים במצב מעקב PER_SESSION |
|
DEFAULT_FOR_PROTOCOL |
|
|
NEVER_PERSIST |
כל הפרוטוקולים: החיבורים אף פעם לא נשמרים בקצוות עורפיים לא תקינים | |
ALWAYS_PERSIST
צריך להשתמש באפשרות הזו רק בתרחישי שימוש מתקדמים. |
|
אי אפשר להגדיר |
כשמשכיות החיבור בחלק האחורי של השרתים הלא תקינים חלה על תנועת הנתונים, כל חיבור נמשך כל עוד קיים רשומה תואמת בטבלת מעקב החיבורים. מידע נוסף זמין בשלב ניהול רשומות בטבלת מעקב החיבורים.
כדי ללמוד איך לשנות את התנהגות ההתמדה של החיבור, אפשר לעיין במאמר הגדרת מדיניות מעקב אחר חיבורים.
התנהגות של חיבור 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נחשבות לחיבורים חדשים בשלב זיהוי שרתי קצה שעומדים בדרישות).
הזמן הקצוב לתפוגה של חוסר פעילות
הערכים בטבלאות מעקב החיבור יפוגו 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 שזכאים לשימוש משתנים לעיתים קרובות, איזון עומסים משוקלל עלול לפגוע בהעדפת סשן. מידע נוסף זמין בשלב בחירת קצה עורפי שעומד בדרישות.
אם אתם משתמשים באותה קבוצת מכונות או באותו NEG כקצה עורפי של שני שירותים לקצה העורפי או יותר של מאזן עומסים, אתם יכולים לדווח על משקל ייחודי לכל שירות לקצה העורפי באמצעות האסטרטגיה הבאה:
צריך להשתמש בבדיקת תקינות ייחודית של HTTP לכל שירות לקצה העורפי. כל בדיקת תקינות יכולה להשתמש ביעד ייחודי של יציאה או בפרמטר
request-path.מגדירים את המופעים או נקודות הקצה של ה-Backend כך שיגיבו עם מידע מתאים על המשקל לכל בדיקת תקינות.
מעבר לגיבוי (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, כולל. אם לא מציינים יחס מעבר לגיבוי, Cloud de Confiance משתמשים בערך ברירת המחדל 0.0. מומלץ להגדיר את יחס היתירות כשל למספר שמתאים לתרחיש השימוש שלכם, במקום להסתמך על ברירת המחדל הזו.
זמן להשלמת תהליך (connection draining) במעבר לגיבוי (failover)
הפסקת ניתוב תעבורה בגיבוי מעבר לשגיאה קובעת אם חיבור קיים יישמר במכונת קצה עורפית או בנקודת קצה שנבחרו קודם, כשקבוצת הקצוות העורפיים שעומדים בדרישות עוברת בין קצוות עורפיים ראשיים לבין קצוות עורפיים לגיבוי מעבר לשגיאה.
התכונה 'הפסקת החיבורים בהדרגה במעבר לגיבוי' מופעלת כברירת מחדל. בטבלה הבאה מפורט אם החיבורים נשמרים, בהתאם לאפשרות של זמן להשלמת תהליך (connection draining) במעבר ליתירות כשל ולפרוטוקול.
| זמן להשלמת תהליך (connection draining) באפשרות מעבר לשירות גיבוי | התנהגות כשקבוצת השרתים העורפיים שעומדים בדרישות עוברת בין שרתים עורפיים ראשיים לבין שרתים עורפיים למעבר לגיבוי |
|---|---|
| מופעלת (ברירת מחדל) |
מידע על הפרוטוקולים שאפשר לעקוב אחריהם בחיבור זמין בטבלה שבקטע מצב מעקב אחר חיבורים. |
| מושבת | כל הפרוטוקולים: החיבורים לא נשמרים כשקבוצת השרתים העורפיים שעומדים בדרישות עוברת בין שרתים עורפיים ראשיים לבין שרתים עורפיים למעבר לגיבוי. |
השבתת זמן להשלמת תהליך (connection draining) במעבר לגיבוי שימושית בתרחישים הבאים:
החלת תיקוני אבטחה על מכונות וירטואליות בעורף האתר. לפני תיקון, אפשר להגדיר ששרתי קצה ראשיים תקינים עם משקל שונה מאפס ייכשלו בבדיקות תקינות, או להגדיר את המשקלים שלהם לאפס. כך קצוות עורפיים שעומדים בדרישות יכולים להיות קצוות עורפיים תקינים לגיבוי עם משקל שונה מאפס. אם משביתים את ניתוק החיבורים במהלך יתירות כשל, מאזן העומסים מסיר רשומות מטבלת מעקב החיבורים, מחיל את השלבים של בחירת השרת העורפי על מנות נתונים עוקבות ומעביר אותן לשרת עורפי כשיר אחר. הקצה האחורי השונה סוגר את החיבור באמצעות איפוס TCP, כדי שמכונות וירטואליות של לקוחות יוכלו ליצור במהירות חיבור חדש למאזן העומסים.
מכונה וירטואלית אחת בבק-אנד לשמירה על עקביות הנתונים. אם אתם רוצים לוודא שקבוצת השרתים העורפיים שעומדים בדרישות לא כוללת יותר ממכונה וירטואלית אחת או נקודת קצה אחת, השבתת ניתוק החיבורים בהעברה אוטומטית מפחיתה את הסיכוי לחוסר עקביות בנתונים.
כאן מוסבר איך משביתים את ניתוק החיבורים בהעברה אוטומטית לגיבוי.
שיטות מומלצות והנחיות
כדי לשפר את מאזן עומסי הרשת האזורי החיצוני להעברת סיגנל ללא שינוי, אפשר לפעול לפי ההנחיות התפעוליות הבאות. בקטעים הבאים מפורטות הדרישות הטכניות לניהול מנות UDP מפוצלות ושיטות מומלצות לבדיקת חלוקת העומס מלקוח יחיד.
טיפול בפיצול של UDP
מאזני עומסים אזוריים חיצוניים של רשתות להעברת סיגנל ללא שינוי שמבוססים על שירותים לקצה העורפי יכולים לעבד מנות UDP עם פרגמנטים וגם מנות UDP ללא פרגמנטים. אם האפליקציה שלכם משתמשת במנות UDP מפוצלות, חשוב לזכור את הנקודות הבאות:
- יכול להיות שחבילות UDP יפוצלו לפני שיגיעו לרשת Cloud de Confiance VPC.
- Cloud de Confiance רשתות VPC מעבירות את פרגמנטים של UDP כשהם מגיעים (בלי לחכות שכל הפרגמנטים יגיעו).
- ציוד רשת שאינו שייך לרשתותCloud de Confiance , וציוד רשת מקומי, עשוי להעביר את פרגמנטים של UDP כשהם מגיעים, לעכב חבילות UDP מפוצלות עד שכל הפרגמנטים יגיעו, או להשליך חבילות UDP מפוצלות. פרטים נוספים זמינים במסמכי התיעוד של ספק הרשת או של ציוד הרשת.
אם אתם מצפים לחבילות UDP מקוטעות וצריכים לנתב אותן לאותם שירותים לקצה העורפי, השתמשו בפרמטרים הבאים של כלל ההעברה והגדרת שירות לקצה העורפי:
הגדרת כלל ההעברה: צריך להשתמש רק בכלל העברה אחד
UDPאוL3_DEFAULTלכל כתובת IP עם איזון עומסים, ולהגדיר את כלל ההעברה כך שיקבל תעבורה בכל היציאות. כך מובטח שכל הפרגמנטים יגיעו לאותו כלל העברה. למרות שלחבילות המפוצלות (מלבד החלק הראשון) אין יציאת יעד, הגדרת כלל ההעברה לעיבוד תנועה לכל היציאות מגדירה אותו גם לקבלת חלקי UDP שלא כוללים פרטי יציאה. כדי להגדיר את כל היציאות, משתמשים ב-Google Cloud CLI כדי להגדיר את--ports=ALLאו משתמשים ב-API כדי להגדיר אתallPortsל-True.הגדרת שירות לקצה העורפי: מגדירים את זיקה לסשן (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 של היעד של כלל ההעברה של מאזן העומסים מנותבות באופן מקומי במערכת ההפעלה של האורח של הלקוח, בגלל קיומו של נתיב מקומי לכלל ההעברה.
המאמרים הבאים
- כדי להגדיר מאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי עם שירות לקצה העורפי לתעבורת נתונים של TCP או UDP בלבד (תמיכה בתעבורת נתונים של IPv4 ו-IPv6), אפשר לעיין במאמר הגדרת מאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי עם שירות לקצה העורפי.
- כדי להגדיר מאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי לכמה פרוטוקולי IP (תמיכה בתעבורת IPv4 ו-IPv6), אפשר לעיין במאמר הגדרה של מאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי לכמה פרוטוקולי IP.
- כדי להגדיר מאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי עם קצה עורפי של NEG אזורי, אפשר לעיין במאמר הגדרת מאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי עם קצה עורפי של NEG אזורי.
- במאמר העברת מאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי ממאגר יעד לשירות אזורי לקצה העורפי מוסבר איך מעבירים מאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי ממאגר יעד לשירות אזורי לקצה העורפי.