סקירה כללית של מאזן עומסי רשת חיצוני בשרת proxy

במסמך הזה מוסברים המושגים שצריך להכיר כדי להגדיר מאזן עומסי רשת חיצוני לשרת proxy‏ Cloud de Confiance .

מאזן עומסי רשת חיצוני לשרת proxy הוא מאזן עומסים של שרת proxy הפוך שמפיץ תעבורת TCP שמגיעה מהאינטרנט למכונות וירטואליות (VM) ברשתCloud de Confiance הענן הווירטואלי הפרטי (VPC). כשמשתמשים במאזן עומסי רשת בשרת proxy חיצוני, תעבורת TCPנכנסת מסתיימת במאזן העומסים. חיבור חדש מעביר את התנועה לשרת העורפי הזמין הקרוב ביותר.

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

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

ארכיטקטורה

בתרשימים הבאים מוצגים הרכיבים של מאזני עומסי רשת חיצוניים בשרת proxy.

אזורי

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

רכיבים של מאזן עומסי רשת אזורי חיצוני בשרת proxy.
רכיבים של מאזן עומסי רשת אזורי חיצוני בשרת proxy (לוחצים כדי להגדיל).

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

רשת משנה של שרת proxy בלבד

תת-הרשת של שרת proxy בלבד מספקת קבוצה של כתובות IP ש-Google משתמשת בהן כדי להפעיל שרתי proxy של Envoy בשמכם. צריך ליצור רשת משנה מסוג proxy-only בכל אזור של רשת VPC שבה משתמשים במאזני עומסים. הדגל --purpose של רשת המשנה הזו שמוגדרת רק כפרוקסי מוגדר כ-REGIONAL_MANAGED_PROXY. כל מאזני העומסים האזוריים שמבוססים על Envoy באותו אזור ובאותה רשת VPC חולקים מאגר של שרתי proxy של Envoy מאותה תת-רשת של שרתי proxy בלבד.

מכונות וירטואליות בבק-אנד או נקודות קצה של כל מאזני העומסים באזור וברשת VPC מקבלות חיבורים מרשת המשנה של proxy בלבד.

נקודות שכדאי לזכור:

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

כללי העברה וכתובות IP

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

ציון כתובת IP. כל כלל העברה מתייחס לכתובת IP אחת שאפשר להשתמש בה ברשומות DNS של האפליקציה. אתם יכולים להזמין כתובת IP סטטית שתוכלו להשתמש בה, או לאפשר ל-Cloud Load Balancing להקצות לכם כתובת כזו. מומלץ להזמין כתובת IP סטטית. אחרת, בכל פעם שמוחקים כלל העברה ויוצרים כלל חדש, צריך לעדכן את רשומת ה-DNS עם כתובת ה-IP הזמנית החדשה שהוקצתה.

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

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

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

מצב מאזן עומסים Network Service Tier כלל העברה, כתובת IP וסכמת איזון עומסים ניתוב מהאינטרנט לקצה הקדמי של מאזן העומסים
מאזן עומסי רשת אזורי חיצוני בשרת proxy מסלול פרימיום

כלל העברה חיצוני אזורי

כתובת IP חיצונית אזורית

סכמת איזון עומסים: EXTERNAL_MANAGED

בקשות מנותבות לשרתי ה-proxy של Envoy באותו אזור שבו נמצא מאזן העומסים.

כללי העברה ורשתות VPC

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

מצב מאזן עומסים שיוך של רשת VPC
מאזן עומסי רשת אזורי חיצוני בשרת proxy

רשת ה-VPC של כלל ההעברה היא הרשת שבה נוצרה תת-הרשת של ה-proxy בלבד. כשיוצרים את כלל ההעברה, מציינים את הרשת.

שרתי proxy יעד

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

כברירת מחדל, פרוקסי היעד לא שומר את כתובת ה-IP המקורית של הלקוח ואת פרטי היציאה. כדי לשמור את המידע הזה, צריך להפעיל את פרוטוקול ה-PROXY ב-proxy של היעד.

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

מצב מאזן עומסים Network Service Tier שרת proxy יעד
מאזן עומסי רשת אזורי חיצוני בשרת proxy מסלול פרימיום ומסלול רגיל regionTargetTcpProxies

שירותים לקצה העורפי

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

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

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

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

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

מצב מאזן עומסים בק-אנדים נתמכים בשירות לקצה העורפי
קבוצות של מכונות קבוצות אזוריות של נקודות קצה של רשתות Internet NEGs קבוצות NEG ללא שרת (serverless) קבוצות היברידיות של נקודות קצה ברשת (NEGs) GKE
מאזן עומסי רשת אזורי חיצוני בשרת proxy נקודות קצה מסוג GCE_VM_IP_PORT קבוצות אזוריות של נקודות קצה ברשת (NEGs) בלבד

שרתי קצה עורפיים ורשתות VPC

למאזן עומסי רשת אזורי חיצוני בשרת proxy, הכללים הבאים חלים:

  • במקרה של קבוצות מכונות, NEGs אזוריים ו-NEGs של קישוריות היברידית, כל הקצוות העורפיים צריכים להיות ממוקמים באותו פרויקט ואזור כמו השירות לקצה העורפי. עם זאת, מאזן עומסים יכול להפנות לעורף חזיתי שמשתמש ברשת VPC אחרת באותו פרויקט כמו שירות העורף החזיתי. אפשר להגדיר קישוריות בין רשת ה-VPC של מאזן העומסים לבין רשת ה-VPC של השרת העורפי באמצעות קישור בין רשתות VPC שכנות, מנהרות Cloud VPN או צירופים ל-VLAN של Cloud Interconnect.

    הגדרת רשת בקצה העורפי

    • כשיוצרים קבוצות אזוריות של נקודות קצה ברשת (NEGs) וקבוצות היברידיות של נקודות קצה ברשת (NEGs), צריך לציין במפורש את רשת ה-VPC.
    • בקבוצות מופעי מכונה מנוהלים, רשת VPC מוגדרת בתבנית של הגדרות מכונה.
    • בקבוצות של מכונות לא מנוהלות, רשת ה-VPC של קבוצת המכונות מוגדרת כך שתתאים לרשת ה-VPC של ממשק nic0 של המכונה הווירטואלית הראשונה שנוספה לקבוצת המכונות.

    דרישות לגבי רשת ה-Backend

    הרשת של ה-Backend חייבת לעמוד באחת מהדרישות הבאות:

    • רשת ה-VPC של ה-backend חייבת להיות זהה לרשת ה-VPC של כלל ההעברה.

    • רשת ה-VPC של ה-Backend צריכה להיות מחוברת לרשת ה-VPC של כלל ההעברה באמצעות קישור בין רשתות שכנות (VPC Network Peering). צריך להגדיר את החלפת נתיבי רשתות המשנה כדי לאפשר תקשורת בין רשת המשנה של שרת ה-proxy בלבד ברשת ה-VPC של כלל ההעברה לבין רשתות המשנה שבהן נעשה שימוש במופעי ה-backend או בנקודות הקצה.

  • בכל שאר סוגי ה-Backend, כל ה-Backend-ים צריכים להיות ממוקמים באותה רשת VPC ובאותו אזור.

שרתי קצה עורפיים וממשקי רשת

אם משתמשים בעורפי קצה של קבוצות מופעים, החבילות תמיד מועברות אל nic0. אם רוצים לשלוח מנות לממשקי nic0 שאינם ממשקי רשת וירטואליים (vNIC) או ממשקי רשת דינמיים, צריך להשתמש במקום זאת בשרתי קצה עורפיים של NEG.

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

פרוטוקול לתקשורת עם השרתים העורפיים

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

כללי חומת אש

חובה להגדיר את כללי חומת האש הבאים:

  • במאזני עומסים אזוריים חיצוניים בשרת proxy, צריך כלל חומת אש לתעבורת נתונים נכנסת (ingress) כדי לאפשר לתעבורה מתת-הרשת של שרת proxy בלבד להגיע לשרתים העורפיים.

  • כלל חומת אש של תעבורת נתונים נכנסת (ingress) allow כדי לאפשר לתעבורה מטווחים של בדיקות תקינות להגיע לשרתים העורפיים. מידע נוסף על בדיקות תקינות ולמה צריך לאפשר תנועה מהן זמין במאמר Probe IP ranges and firewall rules.

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

היציאות של כללי חומת האש האלה צריכות להיות מוגדרות באופן הבא:

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

כתובות IP של המקור

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

למאזני עומסים אזוריים חיצוניים של שרתי proxy:
  • חיבור 1, מהלקוח המקורי למאזן העומסים (רשת משנה ל-proxy בלבד):

    • כתובת ה-IP של המקור: הלקוח המקורי (או כתובת IP חיצונית אם הלקוח נמצא מאחורי שער NAT או שרת proxy להעברה).
    • כתובת ה-IP של היעד: כתובת ה-IP של מאזן העומסים.
  • חיבור 2, ממאזן העומסים (רשת משנה של פרוקסי בלבד) אל ה-VM או נקודת הקצה של הבק-אנד:

    • כתובת ה-IP של המקור: כתובת IP ברשת המשנה של שרת ה-proxy בלבד שמשותפת לכל מאזני העומסים שמבוססים על Envoy שנפרסו באותו אזור ובאותה רשת כמו מאזן העומסים.

    • כתובת ה-IP של היעד: כתובת ה-IP הפנימית של המכונה הווירטואלית או של הקונטיינר בעורף השרת ברשת ה-VPC.

יציאות פתוחות

מאזני עומסים חיצוניים של רשתות proxy הם מאזני עומסים של שרת proxy הפוך. מאזן העומסים מסיים את החיבורים הנכנסים, ואז פותח חיבורים חדשים ממאזן העומסים אל השרתים העורפיים. מאזני העומסים האלה מיושמים באמצעות שרתי proxy של ממשק הקצה של Google‏ (GFE) ברחבי העולם.

ל-GFE יש כמה יציאות פתוחות לתמיכה בשירותים אחרים של Google שפועלים באותה ארכיטקטורה. כשמריצים סריקת יציאות, יכול להיות שיוצגו יציאות פתוחות אחרות של שירותי Google אחרים שפועלים ב-GFE.

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

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

    ‏GFE מטמיע תכונות אבטחה כמו Google Cloud Armor. עם Cloud Armor Standard, שרתי GFE מספקים הגנה בזמינות תמידית מפני מתקפות DDoS נפחיות ומבוססות פרוטוקול, ומפני הצפות SYN. ההגנה הזו זמינה גם אם לא הגדרתם את Cloud Armor באופן מפורש. תחויבו רק אם תגדירו מדיניות אבטחה או אם תירשמו לתוכנית Managed Protection Plus.

  • על מנות שנשלחות לכתובת ה-IP של איזון העומסים יכול לענות כל GFE בצי של Google. עם זאת, סריקה של כתובת IP של איזון עומסים ושילוב של יציאת יעד בודקת רק GFE אחד לכל חיבור TCP. כתובת ה-IP של מאזן העומסים לא מוקצית למכשיר או למערכת יחידים. לכן, סריקת כתובת ה-IP של מאזן עומסים שמבוסס על GFE לא סורקת את כל ה-GFE בצי של Google.

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

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

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

ארכיטקטורה של VPC משותף

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

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

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

ביזור תעבורת נתונים

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

במאזני עומסים חיצוניים של רשת בשרת proxy, מצב האיזון יכול להיות CONNECTION או UTILIZATION:

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

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

מאזן עומסי רשת אזורי חיצוני בשרת proxy

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

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

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

למידע נוסף, קראו את המאמרים הבאים:

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

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

מאזני עומסי רשת חיצוניים לשרת proxy מציעים את סוגי ההצמדה הבאים של סשנים:
  • ללא

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

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

    ערך ברירת המחדל של זיקה לסשן הוא NONE.

  • זיקה לכתובת IP של לקוח

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

    כשמשתמשים בזיקה לכתובת IP של לקוח, חשוב לזכור את הנקודות הבאות:

    • כתובת ה-IP של היעד של החבילה זהה לכתובת ה-IP של כלל ההעברה של מאזן העומסים רק אם החבילה נשלחת ישירות למאזן העומסים.
    • כתובת ה-IP של המקור של חבילת הנתונים לא בהכרח תואמת לכתובת ה-IP שמשויכת ללקוח המקורי אם חבילת הנתונים מעובדת על ידי מערכת NAT או proxy ביניים לפני שהיא מועברת למאזן עומסים. Cloud de Confiance במצבים שבהם הרבה לקוחות חולקים את אותה כתובת IP אפקטיבית של המקור, יכול להיות שחלק מהמכונות הווירטואליות של ה-Backend יקבלו יותר חיבורים או בקשות מאחרות.

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

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

  • ערכי ברירת המחדל של הדגלים --session-affinity ו---subsetting-policy הם NONE, ואפשר להגדיר רק אחד מהם בכל פעם לערך שונה.

איבוד הזיקה לסשן

כל האפשרויות של זיקה לסשן (session affinity) דורשות את הדברים הבאים:

  • צריך להגדיר את מופע השרת העורפי (backend instance) או נקודת הקצה שנבחרו כ-Backend. הזיקה לסשן עלולה להיפסק באחד מהמקרים הבאים:
    • הסרתם את המופע שנבחר מקבוצת המופעים שלו.
    • התכונות 'התאמה אוטומטית לעומס' או 'תיקון תוכנה אוטומטי' של קבוצת מופעי מכונה מנוהלים מסירות את המופע שנבחר מקבוצת המופעים המנוהלים.
    • מסירים את נקודת הקצה שנבחרה מקבוצת נקודות הקצה לרשת (NEG).
    • מסירים את קבוצת המכונות או את ה-NEG שמכילים את המכונה או נקודת הקצה שנבחרו משירות ה-Backend.
  • מופע הקצה העורפי או נקודת הקצה שנבחרו צריכים להישאר תקינים. הזיקה לסשן עלולה להיפסק אם המופע או נקודת הקצה שנבחרו נכשלים בבדיקות התקינות.
  • במאזני עומסים גלובליים חיצוניים של רשתות פרוקסי ובמאזני עומסים קלאסיים של רשתות פרוקסי, יכול להיות שהזיקה לסשן תישבר אם נעשה שימוש בממשק קצה של Google‏ (GFE) שונה בשכבה הראשונה לבקשות או לחיבורים הבאים אחרי השינוי בנתיב הניתוב. יכול להיות שייבחר GFE אחר בשכבה הראשונה אם נתיב הניתוב מלקוח באינטרנט אל Google משתנה בין בקשות או בין חיבורים.
כל האפשרויות של זיקה לסשן כפופות לדרישות הנוספות הבאות:
  • קבוצת המופעים או ה-NEG שמכילים את המופע או נקודת הקצה שנבחרו לא יכולים להיות מלאים, כפי שמוגדר בקיבולת היעד שלהם. (בקבוצות מנוהלות של מופעי מכונה אזוריים, הרכיב האזורי של קבוצת המופעים שמכילה את המופע שנבחר לא יכול להיות מלא). הזיקה לסשן עלולה להיפסק אם קבוצת המופעים או ה-NEG מלאים, וקבוצות מופעים או NEGs אחרים לא מלאים. כשמשתמשים במצב איזון UTILIZATION, יכול להיות שהקיבולת תשתנה בצורה בלתי צפויה. לכן, כדי לצמצם את הסיכויים שהזיקה לסשן תישבר, מומלץ להשתמש במצב איזון RATE או CONNECTION.

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

    • הוספת מופעים או נקודות קצה חדשים:

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

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

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

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

יתירות כשל עבור מאזני עומסי רשת חיצוניים של שרת proxy פועלת באופן הבא:

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

איזון עומסים באפליקציות GKE

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

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

מגבלות

  • במסלול הפרימיום, אי אפשר ליצור מאזן עומסי רשת אזורי חיצוני לשרת proxy באמצעותCloud de Confiance המסוף .במקום זאת, צריך להשתמש ב-ה-CLI של gcloud או ב-API.

  • ‫Cloud de Confiance לא מתחייבת לגבי משך החיים של חיבורי TCP כשמשתמשים במאזני עומסי רשת חיצוניים לשרת proxy. הלקוחות צריכים להיות עמידים לניתוקים, גם בגלל בעיות באינטרנט וגם בגלל הפעלות מחדש מתוזמנות של שרתי ה-proxy שמנהלים את החיבורים.

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