מאזני עומסי רשת להעברת נתונים מחלקים את תעבורת הנתונים הנכנסת בין מכונות הקצה העורפי הזמינות. במאמר הזה מוסבר איך מאזן העומסים בוחר בקצה העורפי, עוקב אחרי חיבורים ומנהל את זיקה לסשן (session affinity), איזון עומסים משוקלל ויתירות כשל.
כדי לבצע אופטימיזציה של הגדרת איזון העומסים, חשוב להבין איך כל התכונות האלה פועלות יחד, וכך להבטיח ביצועים אמינים וניצול יעיל של המשאבים. המנגנונים האלה חיוניים לאפליקציות שנדרשת בהן התמדה של סשנים, והם מאפשרים לאפליקציות לשמור על התנהגות עקבית בכל אינטראקציה של משתמש.
בחירת בק-אנד ומעקב אחרי חיבורים
בחירת הקצה העורפי ומעקב אחר החיבורים פועלים יחד כדי לאזן בין כמה חיבורים בקצוות עורפיים שונים, ולנתב את כל החבילות של כל חיבור לאותו קצה עורפי. כדי לעשות את זה, צריך אסטרטגיה שמורכבת משני חלקים. קודם כול, נבחר קצה עורפי באמצעות גיבוב עקבי. הבחירה הזו מתועדת בטבלה למעקב אחרי חיבורים.
בשלבים הבאים מתוארים בחירת הקצה העורפי ומעקב אחר החיבורים.
1. בדיקה אם יש רשומה בטבלת מעקב החיבורים
מאזן העומסים קובע אם חבילה שמאזנים את העומס שלה שייכת לחיבור חדש או לחיבור קיים, באמצעות התהליך הבא:
חבילת TCP עם הדגל
SYN:אם מצב מעקב החיבורים של מאזן העומסים הוא
PER_CONNECTION, ממשיכים לשלב זיהוי שרתי קצה עורפיים שעומדים בדרישות. בPER_CONNECTIONמצב מעקב, מנהרת TCP עם הדגלSYNתמיד מייצגת חיבור חדש, ללא קשר להגדרת הזיקה לסשן (session affinity).אם מצב מעקב החיבורים של מאזן העומסים הוא
PER_SESSIONוגם הזיקה לסשן היאNONEאוCLIENT_IP_PORT_PROTO, ממשיכים לשלב זיהוי של קצוות עורפיים מתאימים. בPER_SESSIONמצב מעקב, מנה של TCP עם הדגלSYNמייצגת חיבור חדש רק כשמשתמשים באחת מהאפשרויות של זיקה להפעלת 5-tuple (NONEאוCLIENT_IP_PORT_PROTO).
כל שאר החבילות: מאזן העומסים בודק אם החבילה תואמת לרשומה קיימת בטבלת מעקב החיבורים. רמת הפירוט של הגיבוב (hash) של המנה שמשמש לבדיקה של רשומה קיימת בטבלת מעקב החיבורים תלויה במצב מעקב החיבורים ובזיקה לסשן (session affinity) שהגדרתם. מידע נוסף מופיע בטבלה שבקטע מצב מעקב אחרי חיבורים.
אם החבילה תואמת לרשומה בטבלת מעקב החיבורים, מאזן העומסים שולח את החבילה לקצה העורפי שנבחר קודם לכן.
אם החבילה לא תואמת לרשומה בטבלת מעקב החיבורים, ממשיכים לשלב זיהוי קצוות עורפיים מתאימים.
בשלב ניהול הרשומות בטבלת מעקב החיבורים מוסבר כמה זמן נשמרת רשומה בטבלת מעקב החיבורים ובאילו תנאים.
2. שלבים לבחירת קצה עורפי
בחיבור חדש, מאזן העומסים משתמש בגיבוב עקבי (consistent hashing) כדי לבחור קצה עורפי מבין הקצוות העורפיים המתאימים.
בשלבים הבאים מוסבר איך לבחור בקצה עורפי מתאים לחיבור חדש, ואז לתעד את החיבור הזה בטבלה למעקב אחרי חיבורים.
2.1 זיהוי שרתי קצה עורפיים שעומדים בדרישות
שרתי קצה עורפיים שעומדים בדרישות הם שרתי קצה עורפיים שיכולים לקבל חיבורים חדשים. בטבלה הבאה מוגדרת קבוצת השרתים העורפיים שעומדים בדרישות, בהתאם לשאלה אם מאזן העומסים משתמש במעבר לגיבוי (failover).
| יתירות כשל | קצוות עורפיים שעומדים בדרישות |
|---|---|
כשהתכונה 'איזון עומסים במעבר לגיבוי' מושבתת, כל השרתים העורפיים שהוגדרו הם שרתים עורפיים ראשיים. קבוצת השרתים העורפיים שעומדים בדרישות מוגדרת באופן הבא:
|
|
כשהתכונה "איזון עומסים עם יתירות כשל" מופעלת, מאזן העומסים משתמש במידע מבדיקת התקינות ובהגדרות של מדיניות יתירות הכשל כדי להגדיר את קבוצת ה-backend המתאימים:
|
2.2 שינוי קצה העורף המתאים לשימוש בתכונה 'תחום עניין משותף'
השלב הזה לא יתבצע אם מתקיים אחד מהתנאים הבאים:
- ההגדרה Zonal affinity מושבתת
- הלקוח לא תואם לזמינות אזורית
- התאמה אזורית לא מתרחשת עם האזור של לקוח תואם
אם מופעלת התאמה לאזור, הלקוח תואם להתאמה לאזור ומתרחשת התאמה לאזור, חיבורים חדשים מהלקוח מנותבים לקבוצה מותאמת של קצוות עורפיים שעומדים בדרישות. למידע נוסף, קראו את המאמרים הבאים:
2.3 בחירת קצה עורפי מתאים
מאזן העומסים שומר גיבובים (hashes) של קצוות עורפיים מתאימים, כשכל גיבוב של קצה עורפי ממופה למעגל יחידה.
כשהמערכת לאיזון עומסים מעבדת חבילה של חיבור שלא נמצא בטבלת מעקב החיבורים, היא מחשבת גיבוב (hash) של מאפייני החבילה וממפה את הגיבוב לאותו מעגל יחידה, ובוחרת קצה עורפי מתאים בהיקף המעגל. קבוצת מאפייני החבילה שמשמשת לחישוב הגיבוב (hash) של החבילה מוגדרת על ידי הגדרת זיקה לסשן (session affinity). לדוגמה, אם הזיקה לסשן שנבחרה מובילה לגיבוב של בחירת קצה עורפי עם 2 ערכים או 3 ערכים, כל חיבורי ה-TCP מכתובת IP של מקור ממופים לאותו קצה עורפי שעומד בדרישות.
- אם לא מגדירים במפורש זיקה לסשן, ברירת המחדל היא
NONEזיקה לסשן.
גיבוב עקבי מבטיח שמאזן העומסים יקצה חיבורים חדשים לקצוות עורפיים מתאימים, באופן שיצמצם את השיבושים במיפוי גם אם מספר הקצוות העורפיים המתאימים ישתנה.
מאזן העומסים תמיד בוחר את אותו קצה עורפי מתאים לחיבור, ובאופן כללי יותר, תמיד בוחר את אותו קצה עורפי מתאים לכל החבילות עם מאפייני חבילה זהים, כפי שמוגדרים בהגדרת הזיקה לסשן, אם קבוצת הקצוות העורפיים המתאימים לא משתנה.
אם מוסיפים או מסירים קצה עורפי שעומד בדרישות, הגיבוב העקבי נועד לצמצם את השיבוש במיפויים לקצוות העורפיים האחרים שעומדים בדרישות. כלומר, רוב החיבורים שממופים לקצוות עורפיים אחרים שעומדים בדרישות ממשיכים להיות ממופים לאותו קצה עורפי שעומד בדרישות.
בנוסף, גיבוב עקבי מבטיח שמאזן העומסים יפיץ את החיבורים החדשים בין השרתים העורפיים שעומדים בדרישות בצורה הוגנת ככל האפשר. לכל הגיבובים האפשריים של מנות, כפי שמוגדר בהגדרת הזיקה לסשן (session affinity) (ובאופן ספציפי יותר, לכל החיבורים האפשריים כשהזיקה לסשן (session affinity) מובילה לגיבוב של 5 טופלים לבחירת ה-Backend):
כשמוסיפים קצה עורפי מתאים, כ-
1/Nחיבורים חדשים ממופים לקצה העורפי החדש שנוסף. במצב כזה,Nהוא מספר ה-backends אחרי שמוסיפים את ה-backend החדש.כשמסירים קצה עורפי מתאים, כ-
1/Nחיבורים חדשים ממופים לאחד מ-N-1הקצוות העורפיים שנותרו. במצב כזה,Nהוא מספר הקצוות העורפיים לפני שהקצה העורפי המתאים הוסר.
2.4 יצירת רשומה בטבלת מעקב אחרי חיבורים
אחרי שבוחרים קצה עורפי, מאזן העומסים יוצר רשומה בטבלת מעקב אחר חיבורים. הערך בטבלת מעקב החיבורים ממפה את מאפייני החבילה לקצה העורפי שנבחר. השדות בכותרת של המנה שמשמשים למיפוי הזה תלויים במצב מעקב החיבורים ובזיקה לסשן (session affinity) שהגדרתם.בטבלה שבקטע מצב מעקב אחרי חיבורים מפורטים מאפייני החבילות שמשמשים לגיבוב בטבלת המעקב אחרי חיבורים.
3. ניהול של רשומות בטבלת מעקב החיבורים
מאזן העומסים מנהל את הרשומות בטבלת המעקב אחרי החיבורים, בהתאם לאירועים ולכללים הבאים:
רשומות לא פעילות מוסרות: רשומה בטבלת מעקב החיבורים מוסרת אחרי פרק זמן מסוים אם מאזן העומסים לא מעבד חבילות נכנסות חדשות. אם לא מגדירים זמן קצוב מותאם אישית לתפוגה של מצב המתנה, מאזן העומסים משתמש בזמן קצוב מותאם אישית לתפוגה של מצב המתנה של 600 שניות. מידע נוסף זמין במאמר בנושא פסק זמן של חוסר פעילות.
רשומות מוצאות מהטבלה כשהטבלאות למעקב אחרי חיבורי לקוחות מלאות: הטבלאות למעקב אחרי חיבורים למאזני עומסים פנימיים מסוג passthrough מיושמות במערכות לקוח, כמו מארח שמריץ מכונה וירטואלית, מארח שמפעיל חיבור VLAN או מארח שמריץ מנהרת Cloud VPN. כשטבלת מעקב החיבורים של הלקוח מלאה, היא מסירה את הרשומות של החיבורים שהיו בשימוש הכי פחות לאחרונה.
חיבורי TCP סגורים: רשומות בטבלת מעקב החיבורים של חיבורי TCP לא מוסרות כשחיבור TCP נסגר עם מנות
FINאוRST. יכול להיות שהם יוסרו בהמשך כרשומה לא פעילה. כל חיבור TCP חדש תמיד נושא את הדגלSYN, וכפוף לעיבוד שמתואר בשלב בדיקת רשומה בטבלת מעקב החיבורים.כשהחיבורים לא נשמרים ביתירות כשל: כשמוגדר לפחות שרת backend אחד ליתירות כשל וההגדרה "זמן להשלמת תהליך (connection draining) ביתירות כשל" מושבתת, מאזן העומסים מסיר את כל הרשומות בטבלת מעקב החיבורים אחרי שקבוצת שרתי ה-backend המתאימים עוברת בין שרתי ה-backend הראשיים לבין שרתי ה-backend ליתירות כשל, בכפוף לכללים הבאים:
מאזן העומסים לא מסיר באופן יזום רשומות מטבלת מעקב החיבורים ברגע שקבוצת הקצוות העורפיים המתאימים עוברת בין קצוות עורפיים ראשיים לבין קצוות עורפיים של יתירות כשל. במקום זאת, מאזן העומסים מסיר כל רשומה בטבלת מעקב החיבורים כשמגיע החבילה הבאה לחיבור, בתנאי שקבוצת השרתים העורפיים שעומדים בדרישות לא חזרה למצב הקודם.
אם קבוצת ה-backends המתאימים עוברת בין ה-backends הראשיים ל-backends של יתירות כשל ובחזרה (לדוגמה, מראשי ליתירות כשל, ואז בחזרה לראשי), ולא הגיעו חבילות לחיבור בין אירועי המעבר, הרשומה בטבלת מעקב החיבורים נשמרת, אלא אם סיבה או אירוע אחרים מסירים את הרשומה בטבלת מעקב החיבורים.
מידע נוסף זמין במאמר זמן להשלמת תהליך (connection draining) במקרה של יתירות כשל.
אם החיבורים לא נשמרים בשרתי קצה עורפיים לא תקינים: אם האפשרות שמירת חיבורים בשרתי קצה עורפיים לא תקינים מושבתת עבור פרוטוקול החבילה, מאזן העומסים מסיר רשומות מטבלת מעקב החיבורים בשרתי קצה עורפיים לא תקינים לפי הכללים הבאים:
מאזן העומסים לא מסיר באופן יזום רשומות מטבלת מעקב החיבורים לשרת קצה עורפי שנבחר קודם, ברגע ששרת הקצה העורפי הופך ללא תקין. במקום זאת, מאזן העומסים מסיר רשומה מטבלת מעקב החיבורים כשמגיע החבילה הבאה לחיבור, בתנאי שהקצה העורפי שנבחר קודם עדיין לא תקין. המנות הבאות של החיבור מטופלות כחיבור חדש, כי מאזן העומסים בוחר קצה עורפי חדש שעומד בדרישות ויוצר רשומה חדשה בטבלת מעקב החיבורים.
אם קצה עורפי שנבחר בעבר משתנה מתקין ללא תקין, ואז חוזר להיות תקין, ולא הגיעו מנות לחיבור בזמן שהקצה העורפי שנבחר בעבר היה לא תקין, הרשומה בטבלת מעקב החיבורים נשמרת, אלא אם סיבה או אירוע אחרים מסירים את הרשומה בטבלת מעקב החיבורים.
זמן להשלמת תהליך (connection draining) של שירותי backend שהוסרו, הופסקו או נמחקו: אם מופעל זמן להשלמת תהליך של שירותי backend שהוסרו, הופסקו או נמחקו, הרשומות בטבלת מעקב החיבורים יוסרו אחרי זמן קצוב לתפוגה של השלמת התהליך, שאפשר להגדיר. הספירה עד לזמן הקצוב לתפוגה מתחילה כשמתקבלת הפקודה להסרה (ביטול), לעצירה או למחיקה של קצה עורפי (כולל פקודות מחיקה שהן תוצאה של הקטנת קבוצת מופעים מנוהלת). אם זמן ההשלמה של תהליך (connection draining) מושבת עבור קצוות עורפיים שהוסרו, הופסקו או נמחקו, הרשומות בטבלת מעקב החיבורים יוסרו כשתתקבל הפקודה להסיר, להפסיק או למחוק קצה עורפי. איך מפעילים את זמן ההשלמה של התהליך
זיקה לסשן (session affinity)
ההגדרה של הזיקה לסשן במאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי קובעת את גיבוב החבילות לבחירת הקצה העורפי, ובהתאם למצב מעקב החיבורים, את גיבוב החבילות למעקב אחרי החיבורים.
אתם מגדירים את הזיקה לסשן בשירות לקצה העורפי, ולא בכל קבוצת מכונות או NEG בקצה העורפי. הזיקה לסשן קובעת אילו כתובות IP וכותרות Layer 4 משמשות לחישוב גיבוב של מאפייני חבילות. הגיבוב של מאפייני החבילה משמש בשלבי הבחירה של הקצה העורפי.
מאזני עומסי רשת פנימיים להעברת סיגנל ללא שינוי תומכים בהגדרות הבאות של זיקה לסשן.
| שיטת גיבוב לבחירת קצה עורפי | הגדרת הזיקה לסשן (session affinity) |
|---|---|
|
גיבוב של 5 ערכים (שמורכב מכתובת ה-IP של המקור, היציאה של המקור, הפרוטוקול, כתובת ה-IP של היעד והיציאה של היעד) לחבילות נתונים לא מקוטעות שכוללות מידע על היציאה (חבילות נתונים של TCP וחבילות נתונים לא מקוטעות של UDP) אוגיבוב של 3 טאפלים (מורכב מכתובת ה-IP של המקור, כתובת ה-IP של היעד ופרוטוקול) לחבילות UDP מפוצלות ולחבילות של כל הפרוטוקולים האחרים |
NONE1
או CLIENT_IP_PORT_PROTO
|
| 3-tuple hash (מורכב מכתובת ה-IP של המקור, כתובת ה-IP של היעד והפרוטוקול) |
CLIENT_IP_PROTO |
| גיבוב (hash) של 2 ערכים (מורכב מכתובת ה-IP של המקור ומכתובת ה-IP של היעד) |
CLIENT_IP |
| גיבוב של רכיב אחד (מורכב מכתובת ה-IP של המקור בלבד) |
CLIENT_IP_NO_DESTINATION |
1 הערך NONE של זיקה לסשן לא מציין שאין זיקה לסשן. במקום זאת, המשמעות היא שהזיקה לסשן מתבצעת באמצעות גיבוב של 5 ערכים או גיבוב של 3 ערכים של מאפייני חבילות – מבחינה פונקציונלית, זו אותה התנהגות כמו כשמוגדר CLIENT_IP_PORT_PROTO.
זיקה לסשן (session affinity) והצעד הבא של מאזן העומסים
כשמאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי משמש כצעד הבא במסלול סטטי, כתובת ה-IP של היעד לא מוגבלת לכתובת ה-IP של כלל ההעברה של מאזן העומסים. במקום זאת, כתובת ה-IP של היעד של החבילה יכולה להיות כל כתובת IP שמתאימה לטווח היעד של המסלול הסטטי.
בחירת קצה עורפי מתאים תלויה בחישוב גיבוב (hash) של מאפייני החבילה. חוץ מאפיניות (affinity) של סשן CLIENT_IP_NO_DESTINATION (hash של 1-tuple), ה-hash תלוי, בין היתר, בכתובת ה-IP של היעד של החבילה.
אם קבוצת הקצוות העורפיים המתאימים לא משתנה, מאזן העומסים בוחר את אותו קצה עורפי לכל החיבורים החדשים האפשריים שיש להם מאפייני חבילה זהים, כפי שמוגדר על ידי הזיקה לסשן. אם אתם צריכים שמכונה וירטואלית אחת בעורף תעבד את כל החבילות מלקוח, על סמך כתובת ה-IP של המקור בלבד, בלי קשר לכתובות ה-IP של היעד, אתם יכולים להשתמש בCLIENT_IP_NO_DESTINATIONזיקה לסשן (session affinity).
מדיניות מעקב אחרי חיבורים
בקטע הזה מתוארות ההגדרות במדיניות מעקב החיבורים של מאזן העומסים:
מצב מעקב אחרי חיבורים
בקטע הזה מוסבר איך מאזן העומסים יוצר רשומות בטבלת המעקב אחר החיבורים שלו. מאזני עומסי רשת פנימיים מסוג Passthrough עוקבים אחרי החיבורים בכל הפרוטוקולים שהם תומכים בהם ובכל האפשרויות של זיקה לסשן (session affinity).מצב המעקב אחרי החיבור, הפרוטוקול והזיקה לסשן קובעים את קבוצת המאפיינים של החבילה שמשמשים ליצירת ה-hash של החבילה בכל רשומה בטבלת המעקב אחרי החיבור.
מצב המעקב אחרי החיבור יכול להיות אחד מהבאים:
PER_CONNECTION. זהו מצב מעקב החיבורים המפורט ביותר, והוא מוגדר כברירת מחדל. כל חיבור מוגדר כגיבוב (hash) של 5 ערכים או של 3 ערכים של מאפייני חבילות, בהתאם לשאלה אם פרטי היציאה קיימים בחבילה. מנות לא מקוטעות שכוללות פרטי יציאה (כמו מנות TCP ומנות UDP לא מקוטעות) נרשמות ביומן באמצעות גיבוב של 5 טופלים. כל שאר החבילות עוברות מעקב באמצעות גיבובים של 3 ערכים.
PER_SESSION. מצב מעקב חיבורים פחות מפורט זה משתמש בגיבוב שזהה לגיבוב של זיקה לסשן. בהתאם לזיקה לסשן שנבחרה, מצב המעקב שלPER_SESSIONיכול להתייחס לכמה חיבורים נפרדים כאל חיבור אחד למטרות מעקב אחרי חיבורים. כך החיבור נחשב לחדש בתדירות נמוכה יותר, והוא כפוף לשלבים לבחירת קצה עורפי.
בטבלה הבאה מפורטים:
- ערכי ה-hash של החבילות שמשמשים לבחירת הקצה העורפי.
- ערכי ה-hash של החבילות שמשמשים למעקב אחרי חיבורים, על סמך מצב המעקב אחרי חיבורים, הפרוטוקול והזיקה לסשן (session affinity).
| זיקה לסשן (session affinity) | Hash של מנות לבחירה של קצה עורפי | גיבוב (hash) של מנות למעקב אחרי חיבורים | |
|---|---|---|---|
כשמשתמשים במצב מעקב PER_CONNECTION (ברירת מחדל) |
כשמשתמשים במצב מעקב PER_SESSION |
||
NONE (ברירת מחדל)או CLIENT_IP_PORT_PROTO
|
|
|
|
CLIENT_IP_PROTO |
|
|
|
CLIENT_IP |
|
|
|
CLIENT_IP_NO_DESTINATION |
|
|
|
במאמר הגדרת מדיניות למעקב אחרי חיבורים מוסבר איך משנים את מצב המעקב אחרי חיבורים.
שמירת החיבור בקצוות עורפיים לא תקינים
ההגדרה Connection persistence on unhealthy backends קובעת אם חיבורים קיימים יכולים להישאר ב-VM קודם שנבחר, אם ה-VM הקודם שנבחר הופך ללא תקין. כדי לשמור על החיבור בקצוות עורפיים לא תקינים, ה-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 הלא תקין שולח חבילת איפוס (RST) של TCP או לא מגיב לחבילות, יכול להיות שהלקוח ינסה שוב עם חיבור חדש, ויאפשר למאזן העומסים לבחור backend מתאים אחר. (חבילות TCP
SYNמטופלות כחיבורים חדשים בשלב זיהוי בק-אנדים מתאימים).
זמן קצוב לתפוגה של חוסר פעילות
רשומה בטבלת מעקב החיבורים מוסרת אחרי שהחיבור לא פעיל במשך פרק זמן מסוים. אם לא מגדירים זמן קצוב בהתאמה אישית, מאזן העומסים משתמש בערך ברירת המחדל של 600 שניות (10 דקות).בטבלה הבאה מוצגים ערכי הזמן הקצוב לתפוגה של חוסר פעילות שאפשר להגדיר, המינימלי והמקסימלי, לשילובים שונים של הגדרות של זיקה לסשן (session affinity) ומצב מעקב אחר חיבורים.
| זיקה לסשן (session affinity) | מצב מעקב אחר חיבורים | ברירת המחדל של הזמן הקצוב לתפוגה של חוסר פעילות | הזמן הקצוב המינימלי שניתן להגדיר עד לכניסה למצב "לא פעיל" | הזמן הקצוב המקסימלי לתפוגה של חוסר פעילות שניתן להגדיר |
|---|---|---|---|---|
| כל טופל חיבור | PER_CONNECTION |
600 שניות | 60 שניות | 600 שניות |
|
PER_SESSION |
600 שניות | 60 שניות | 57,600 שניות |
5-tuple (NONE, CLIENT_IP_PORT_PROTO) |
PER_SESSION |
600 שניות | 60 שניות | 600 שניות |
במאמר הגדרת מדיניות למעקב אחרי חיבורים מוסבר איך משנים את ערך הזמן הקצוב לתפוגה במצב חוסר פעילות.
זמן להשלמת תהליך (connection draining) של שירותי backend שהוסרו, הופסקו או נמחקו
התכונה "זמן להשלמת תהליך" מאפשרת להגדיר את משך הזמן המינימלי שבו החיבורים הקיימים יישמרו בטבלת מעקב החיבורים של מאזן העומסים, במקרים הבאים:
- מוציאים מופע מכונה וירטואלית (VM) מקבוצת שרתי עורפיים (backend instance) (כולל ביטול מופע בקבוצת מופעי מכונה מנוהלים)
- מכונה וירטואלית נעצרת או נמחקת (כולל פעולות אוטומטיות כמו עדכונים בהדרגה או הקטנת קבוצת מופעי מכונה מנוהלים בקצה העורפי)
- נקודת קצה מוסרת מקבוצה של נקודות קצה ברשת (NEG) בקצה העורפי
כברירת מחדל, האפשרות "זמן להשלמת תהליך" מושבתת כשמסירים, עוצרים או מוחקים את הקצוות העורפיים. מידע נוסף זמין במאמר הפעלת זמן להשלמת תהליך (connection draining).
יתירות כשל
תכונת יתירות הכשל מאפשרת לכם להשפיע על קבוצת הקצוות העורפיים המתאימים, על ידי סיווג של קבוצות שרתי עורפיים או קבוצות של נקודות קצה ברשת (NEG) של קצוות עורפיים ונקודות הקצה שלהם באופן הבא:
- קצוות עורפיים ראשיים הם מכונות וירטואליות או נקודות קצה בקבוצת מכונות או ב-NEG שהוגדרו כקבוצת קצוות עורפיים ראשית.
- קצוות עורפיים לגיבוי הם מכונות וירטואליות או נקודות קצה בקבוצת מכונות או ב-NEG שמוגדרים כקבוצת קצוות עורפיים לגיבוי.
כברירת מחדל, כשמוסיפים קבוצת מכונות או NEG לשירות לקצה העורפי, קבוצת המכונות או ה-NEG היא קבוצת קצה עורפי ראשית. אפשר להוסיף לשירות לקצה העורפי עד 50 קבוצות ראשיות של קצוות עורפיים ו-50 קבוצות של קצוות עורפיים לגיבוי.
כדי להפעיל את תכונת יתירות הכשל, צריך להגדיר את שירות הקצה העורפי של מאזן העומסים עם שני המאפיינים הבאים:
- לפחות קבוצת קצה עורפי ראשית אחת שאינה ריקה
- לפחות קבוצת עורף חלופית אחת לא ריקה
כשמפעילים את יתירות הכשל, הגורמים הבאים קובעים את קבוצת הקצוות העורפיים שעומדים בדרישות:
- מצב התקינות של כל שרת קצה עורפי
- יחס יתירות הכשל במדיניות יתירות הכשל
- ההגדרה drop traffic if backends are unhealthy במדיניות המעבר לגיבוי (failover)
מדיניות מעבר לגיבוי (Failover)
אפשר לשנות את ההגדרות הבאות במדיניות יתירות הכשל של שירות לקצה העורפי. מדיניות יתירות הכשל רלוונטית רק אם יתירות הכשל מופעלת.
- יחס מעבר לגיבוי: מספר בין
0.0ל-1.0, כולל. - Drop traffic if backends are unhealthy: ערך בוליאני שקובע את ההתנהגות של מאזן העומסים כמוצא אחרון. ההגדרה failover ratio וההגדרה drop traffic if backends are unhealthy פועלות יחד עם גורמים אחרים כדי לשלוט בקבוצת הקצוות העורפיים המתאימים.
- הפסקת החיבורים במעבר לגיבוי: ערך בוליאני שקובע אם החיבורים נשמרים בשרתי קצה עורפיים שנבחרו קודם, כשהקבוצה של שרתי קצה עורפיים שעומדים בדרישות עוברת בין שרתי קצה עורפיים ראשיים לבין שרתי קצה עורפיים לגיבוי.
יחס יתירות כשל
יחס יתירות הכשל קובע מתי קבוצת הקצוות העורפיים המתאימים עוברת בין הקצוות העורפיים הראשיים לבין הקצוות העורפיים של יתירות הכשל. היחס יכול להיות מספר בין 0.0 ל-1.0, כולל. אם לא מציינים יחס יתירות כשל, Cloud de Confiance משתמש בערך ברירת המחדל 0.0. מומלץ להגדיר את יחס יתירות הכשל למספר שמתאים לתרחיש לדוגמה שלכם, ולא להסתמך על ברירת המחדל הזו.
זמן להשלמת תהליך (connection draining) במעבר לגיבוי בעת כשל (failover)
זמן להשלמת תהליך (connection draining) במעבר לגיבוי (failover) קובע אם חיבור קיים יישמר במכונה וירטואלית או בנקודת קצה של עורף קודם שנבחרו, כשקבוצת עורפי הקוד שעומדים בדרישות עוברת בין עורף קוד ראשי לעורף קוד לגיבוי.
התכונה "זמן להשלמת תהליך (connection draining) במקרה של יתירות כשל" מופעלת כברירת מחדל. בטבלה הבאה מפורט אם החיבורים נשמרים, בהתאם לאפשרות ולפרוטוקול של זמן להשלמת תהליך (connection draining) במקרה של יתירות כשל:
| זמן להשלמת תהליך (connection draining) באפשרות של יתירות כשל | התנהגות כשקבוצת השרתים העורפיים שעומדים בדרישות עוברת בין שרתים עורפיים ראשיים לבין שרתים עורפיים למעבר לגיבוי בעת כשל |
|---|---|
| מופעל (ברירת מחדל) | כל הפרוטוקולים: החיבורים נשמרים כל עוד קיימת רשומה תואמת בטבלת מעקב החיבורים, כשקבוצת הקצוות העורפיים המתאימים עוברת בין קצוות עורפיים ראשיים לבין קצוות עורפיים של יתירות כשל. מידע נוסף זמין בשלב ניהול הרשומות בטבלת מעקב החיבורים. |
| מושבת | כל הפרוטוקולים: החיבורים לא נשמרים כשקבוצת הקצוות העורפיים המתאימים עוברת בין קצוות עורפיים ראשיים לבין קצוות עורפיים של יתירות כשל. |
השבתת ניתוק החיבורים במעבר לגיבוי שימושית בתרחישים הבאים:
החלת תיקוני אבטחה על מכונות וירטואליות בעורף האתר. לפני הפעלת התיקון, אפשר להגדיר ששרתי קצה עורפיים ראשיים תקינים ייכשלו בבדיקות התקינות, כדי ששרתי קצה עורפיים שעומדים בדרישות יוכלו לשמש כשרתי קצה עורפיים תקינים למעבר לגיבוי. אם משביתים את ניתוק החיבורים במהלך יתירות כשל, מאזן העומסים מסיר רשומות מטבלת מעקב החיבורים, מחיל את השלבים של בחירת השרת העורפי על מנות נתונים עוקבות ומעביר אותן לשרת עורפי כשיר אחר. לאחר מכן, הקצה העורפי האחר סוגר את החיבור באמצעות איפוס TCP, כדי שהמכונות הווירטואליות של הלקוח יוכלו ליצור במהירות חיבור חדש למאזן העומסים.
מכונה וירטואלית אחת בקצה העורפי לעקביות בנתונים. אם אתם צריכים לוודא שבקבוצת הקצוות העורפיים שעומדים בדרישות יש רק מכונה וירטואלית אחת או נקודת קצה אחת, השבתת הזמן להשלמת תהליך (connection draining) במקרה של יתירות כשל מפחיתה את הסיכוי לחוסר עקביות בנתונים.
מידע על השבתת ניתוק החיבורים במעבר לגיבוי זמין במאמר הגדרת מדיניות מעבר לגיבוי.
שיטות מומלצות והנחיות
כדי לבצע אופטימיזציה של מאזן עומסי רשת פנימי להעברת נתונים ללא שינוי, כדאי לפעול לפי ההנחיות התפעוליות הבאות. בקטעים הבאים מפורטות הדרישות הטכניות לניהול חבילות UDP מקוטעות, ושיטות מומלצות לבדיקת חלוקת העומס מלקוח יחיד.
טיפול בפרגמנטציה של UDP
מאזני עומסי רשת פנימיים להעברת סיגנל ללא שינוי יכולים לעבד מנות UDP מפוצלות ולא מפוצלות. אם האפליקציה משתמשת בחבילות UDP מקוטעות, חשוב לזכור את הדברים הבאים:- יכול להיות שחבילות UDP יפוצלו לפני שיגיעו לרשת VPC של Cloud de Confiance.
- Cloud de Confiance רשתות VPC מעבירות את חלקי ה-UDP כשהם מגיעים (בלי לחכות שכל החלקים יגיעו).
- ציוד רשת שאינוCloud de Confiance וציוד רשת מקומי עשויים להעביר חלקי UDP כשהם מגיעים, לעכב חבילות UDP מפוצלות עד שכל החלקים יגיעו או להשליך חבילות UDP מפוצלות. לפרטים, עיינו במסמכי התיעוד של ספק התקשורת או של ציוד הרשת.
אם אתם מצפים לחבילות UDP מקוטעות וצריכים לנתב אותן לאותם שרתים עורפיים, אתם יכולים להשתמש בפרמטרים הבאים של כלל ההעברה ושירות לקצה העורפי:
הגדרת כלל העברה: משתמשים רק בכלל העברה אחד של
UDPלכל כתובת IP של מאזן עומסים, ומגדירים את כלל ההעברה כך שיקבל תנועה בכל היציאות. כך כל החלקים מגיעים לאותו כלל העברה. למרות שבחבילות המפוצלות (חוץ מהחלק הראשון) אין יציאת יעד, הגדרת כלל ההעברה לעיבוד תנועה בכל היציאות מגדירה אותו גם לקבלת חלקי UDP שאין בהם מידע על יציאה. כדי להגדיר את כל היציאות, משתמשים ב-Google Cloud CLI כדי להגדיר את--ports=ALLאו משתמשים ב-API כדי להגדיר אתallPortsלערךTrue.הגדרת שירות לקצה העורפי: מגדירים את הזיקה לסשן של השירות לקצה העורפי לערך
CLIENT_IP(גיבוב של 2-tuple) או לערךCLIENT_IP_PROTO(גיבוב של 3-tuple), כדי שאותו קצה עורפי ייבחר לחבילות UDP שכוללות מידע על יציאות ולפרגמנטים של UDP (מלבד הפרגמנט הראשון) שאין בהם מידע על יציאות. מגדירים את מצב מעקב החיבורים של שירות לקצה העורפי לערךPER_SESSIONכדי שערכי הטבלה של מעקב החיבורים יבנו באמצעות אותם גיבובים של 2-tuple או 3-tuple.
בדיקה מלקוח יחיד
כשבודקים מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי מלקוח אחד, חשוב לזכור:
אם ה-VM של הלקוח הוא לא בקצה העורפי של מאזן העומסים: חיבורים חדשים מעובדים כמו שמתואר בשלבים בחירת קצה עורפי ומעקב אחרי חיבורים. בשלב בחירת קצה עורפי מתאים, מאזן העומסים יוצר גיבוב (hash) של מאפייני החבילה בהתאם לזיקה לסשן (session affinity).
חשוב לזכור שכל האפשרויות של הזיקה לסשן מסתמכות לפחות על כתובת ה-IP של הלקוח, ולכן יכול להיות שחיבורים מאותו לקוח יופצו לאותו קצה עורפי כשיר בתדירות גבוהה יותר מהצפוי. לכן, אי אפשר ליצור מודל מדויק של ההתפלגות הכוללת של חיבורים חדשים על ידי התחברות למאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי מלקוח אחד.
אם ה-VM של הלקוח הוא גם VM לקצה העורפי של מאזן העומסים: מאזן העומסים לא מעבד בכלל חיבורים חדשים. חבילות יוצאות עם כתובת ה-IP של היעד של כלל ההעברה של מאזן העומסים מנותבות באופן מקומי בתוך מערכת ההפעלה של הלקוח, בגלל הנוכחות של נתיב מקומי לכלל ההעברה.
המאמרים הבאים
- במאמר הגדרת יתירות כשל למאזני עומסי רשת פנימיים להעברת סיגנל ללא שינוי מוסבר איך מגדירים ובודקים מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי שמשתמש ביתירות כשל.
- במאמר הגדרת מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי מוסבר איך מגדירים ובודקים מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי.