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

Cloud de Confiance by S3NS מאזן עומסי רשת פנימי לשרת proxy הוא מאזן עומסים שמבוסס על שרת proxy, ומופעל באמצעות תוכנת שרת proxy של Envoy בקוד פתוח ומחסנית הווירטואליזציה של רשת Andromeda.

מאזן עומסי רשת פנימי של שרתי proxy הוא מאזן עומסים בשכבה 4, שמאפשר להריץ את תעבורת הנתונים של שירות ה-TCP ולהתאים אותה לעומס מאחורי כתובת IP פנימית אזורית. הכתובת הזו נגישה רק ללקוחות באותה רשת VPC או ללקוחות שמחוברים לרשת ה-VPC. מאזן העומסים מסיים קודם את חיבור ה-TCP בין הלקוח לבין מאזן העומסים בשרת proxy של Envoy. שרת ה-proxy פותח חיבור TCP שני לקצוות עורפיים שמתארחים ב- Cloud de Confiance by S3NS, בסביבות מקומיות או בסביבות ענן אחרות. לתרחישים נוספים לדוגמה, קראו את הסקירה הכללית על מאזן עומסי רשת לשרת proxy.

מצבי פעולה

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

ארכיטקטורה

בתרשים הבא מוצגים המשאבים של Cloud de Confiance שנדרשים למאזני עומסי רשת פנימיים של שרתי proxy.

אזורי

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

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

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

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

בטבלה הבאה מתוארות הדרישות של רשתות משנה proxy-only למאזני עומסי רשת פנימיים לשרת proxy:

מצב מאזן עומסים הערך של הדגל --purpose הערך של הדגל --stack-type
מאזן עומסי רשת אזורי פנימי בשרת proxy

REGIONAL_MANAGED_PROXY

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

כל מאזני העומסים האזוריים שמבוססים על Envoy באזור וברשת VPC מסוימים חולקים את אותה רשת משנה של שרתי proxy בלבד.
  • IPV4_IPV6 כדי לסיים תנועה נכנסת של IPv6 או IPv4
  • IPV4_ONLY כדי לסיים את תנועת ה-IPv4 הנכנסת

בנוסף:

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

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

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

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

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

כתובת ה-IP הפנימית שמשויכת לכלל ההעברה יכולה להגיע מתת-רשת באותה רשת ובאותו אזור של שרתי ה-backend.

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

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

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

אזורי forwardingRules

כתובת IP אזורית

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

INTERNAL_MANAGED

רשת משנה לשרתי proxy בלבד --purpose:

REGIONAL_MANAGED_PROXY

כתובת IP‏ --purpose:

SHARED_LOADBALANCER_VIP

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

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

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

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

בהתאם לשימוש בכתובת IPv4 או בטווח כתובות IPv6, תמיד יש רשת VPC מפורשת או משתמעת שמשויכת לכלל ההעברה.

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

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

    דרישות לגבי רשתות ורשתות משנה לתנועת IPv6, הרשת ורשתות המשנה צריכות לעמוד בדרישות ההגדרה הבאות:

    • רשת VPC: צריך להשתמש ברשת VPC במצב מותאם אישית, שמוגדרת עם הדגל --enable-ula-internal-ipv6.
    • רשת משנה של כלל העברה: רשת המשנה הזו חייבת להיות רשת משנה בשני פרוטוקולים (IPv4_IPv6) או IPV6_ONLY, שבה ipv6-access-type מוגדר ל-INTERNAL.

    אפשרויות להקצאת כתובות IPv6 כלל ההעברה צריך גם להפנות לטווח /96 של כתובות IPv6 מתוך טווח כתובות ה-IPv6 הפנימיות /64 של תת-הרשת. אפשר להקצות את טווח ה-/96 הזה באחת מהשיטות הבאות:

    • ציון כתובת IPv6 פנימית שמורה.
    • הגדרת כתובת IPv6 זמנית בהתאמה אישית.
    • מאפשרים ל- Cloud de Confiance להקצות באופן אוטומטי כתובת IPv6 זמנית.
    הגבלות. כדי לציין כתובת IPv6 זמנית בהתאמה אישית, צריך להשתמש ב-Google Cloud CLI או ב-API. במסוף Cloud de Confiance אי אפשר לציין כתובות IPv6 זמניות בהתאמה אישית לכללי העברה.

שרתי proxy לחלוקת העומס

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

בטבלה הבאה מפורטים ממשקי ה-API של שרתי ה-Proxy לטירגוט שנדרשים למאזני עומסי רשת פנימיים לשרתי Proxy:

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

נתיבי TLS

משאב מסלול TLS מאפשר להגדיר איך תעבורת הנתונים מנותבת לשירותים לקצה העורפי על סמך שמות מארחים של SNI.

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

כדי לצרף הגדרת ניתוב TLS לשרת proxy לחלוקת העומס, משתמשים בפקודות gcloud network-services tls-routes.

בטבלה הבאה מפורטים ממשקי ה-API של נתיבי TLS שנדרשים למאזני עומסי רשת פנימיים לשרת proxy:

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

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

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

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

בטבלה הבאה מפורטים ממשקי ה-API של שירות לקצה העורפי למאזני עומסי רשת פנימיים של שרתי proxy:

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

קצוות עורפיים נתמכים

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

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

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

אפשר לשלב קבוצות NEG אזוריות וקבוצות NEG היברידיות באותו שירות לקצה העורפי.

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

רשתות VPC ורכיבי Back-end

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

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

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

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

    הרשת של ה-backend צריכה לעמוד באחת מדרישות הרשת הבאות:

    • רשת ה-VPC של הקצה העורפי חייבת להתאים בדיוק לרשת ה-VPC של כלל ההעברה.

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

    דרישות לגבי רשתות משנה של IPv6 בקצה העורפי

    גרסת ה-IP שמשמשת לחיבור הקצה הקדמי לא תלויה בחיבור הקצה העורפי. מכיוון שרשת המשנה proxy-only היא במצב דואלי (IPV4_IPV6), היא יכולה לתקשר עם קצוות עורפיים באמצעות IPv4 או IPv6.

    אם מכונות הקצה העורפי מטפלות בתעבורת נתונים ב-IPv6, אפשר להגדיר את סוג המחסנית של רשת המשנה של הקצה העורפי כ-IPV4_ONLY או כ-IPV4_IPV6 (מחסנית כפולה). אם סוג המחסנית של רשת המשנה של הקצה העורפי כולל IPv6, צריך להגדיר באופן מפורש את ipv6-access-type של רשת המשנה לערך INTERNAL.

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

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

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

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

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

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

בדיקת תקינות

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

פרוטוקול בדיקת תקינות

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

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

מצב מאזן עומסים סוג בדיקת התקינות
מאזן עומסי רשת אזורי פנימי בשרת proxy אזורי regionHealthChecks

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

כללי חומת אש

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

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

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

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

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

יש כמה חריגים לדרישות של כללי חומת האש למאזני העומסים האלה:

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

אתם יכולים להשתמש בכללי מדיניות חומת האש של Cloud NGFW כדי לקבוע את הגישה של הלקוחות לכללי ההעברה של מאזני עומסים שמבוססים על שרת proxy של Envoy, כמו מאזני עומסי רשת אזוריים פנימיים לשרת proxy ומאזני עומסי רשת פנימיים לשרת proxy בכמה אזורים. שתי הגרסאות, Cloud NGFW Essentials ו-Cloud NGFW Standard, תומכות בתכונות האלה.

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

גישת לקוח

הלקוחות יכולים להיות באותה רשת או ברשת VPC שמחוברת באמצעות קישור בין רשתות VPC שכנות (peering).

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

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

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

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

כתובת IP כלל העברה שרת proxy לחלוקת העומס רכיבי קצה עורפי

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

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

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

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

 צריך להגדיר את שרת ה-Proxy לחלוקת העומס באותו פרויקט שבו נמצאים ה-backends. בתרחיש של VPC משותף, המכונות הווירטואליות של ה-backend נמצאות בדרך כלל בפרויקט שירות. בפרויקט השירות הזה צריך להגדיר שירות לקצה עורפי פנימי אזורי ובדיקת תקינות.

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

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

  1. חיבורים שמקורם בלקוח יחיד נשלחים לאותו אזור, כל עוד יש באזור הזה שרתים עורפיים תקינים (קבוצות של מכונות או קבוצות של נקודות קצה ברשת) זמינים ועם קיבולת, כפי שנקבע על ידי מצב האיזון. במאזני עומסי רשת פנימיים אזוריים לשרת proxy, מצב האיזון יכול להיות CONNECTION (קבוצת מכונות או קצוות עורפיים של NEG) או UTILIZATION (קצוות עורפיים של קבוצת מכונות בלבד).
  2. אם הגדרתם זיקה לסשן (session affinity), החיבורים מהלקוח נשלחים לאותו קצה עורפי.
  3. אחרי שבוחרים בקצה עורפי, התנועה מופצת בין מכונות (בקבוצת מכונות) או נקודות קצה (ב-NEG) בהתאם למדיניות של איזון עומסים. במאמרי העזרה של ה-API של שירות אזורי לקצה העורפי, בקטע של ההגדרה localityLbPolicy, מפורטים האלגוריתמים שנתמכים במדיניות איזון העומסים.

ניתוב מבוסס-SNI עם מסלולי TLS

ניתוב מבוסס-SNI מאפשר למאזני עומסי רשת עם שרת proxy ל-TCP לנתב את התנועה לשירותים ספציפיים לקצה העורפי, על סמך שם המארח של חיווי שם השרת (SNI) שסופק במהלך לחיצת היד בפרוטוקול TLS. ‫SNI הוא תוסף TLS שמאפשר ללקוח לציין את שם הדומיין שאליו הוא רוצה להגיע לפני שנוצרת המנהרה המוצפנת. שם המארח של ה-SNI מועבר בפורמט לא מוצפן בהודעת ClientHello, כדי שמאזן העומסים יוכל לבדוק את הערך הזה ולנתב את תעבורת הנתונים לשירות לקצה העורפי המתאים.

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

התכונה הזו מאפשרת כמה תרחישים לדוגמה, כמו:

  • אפשר להשתמש בכתובת IP גלובלית אחת מסוג anycast וביציאה אחת כדי להציג כמה אפליקציות, וכך לצמצם את השימוש בכתובות IPv4.
  • תמיכה בפריסות מוצפנות מקצה לקצה שבהן האישורים יכולים להישאר בקצה העורפי, כדי לוודא שהתנועה אף פעם לא תהיה לא מוצפנת בזמן ההעברה.
  • מאפשר לאדמינים של הפלטפורמה לנהל את התשתית המרכזית, בזמן שבעלי השירותים מנהלים באופן עצמאי את המסלולים וה-backend הספציפיים שלהם.
  • מאפשר ניתוב למקטעים ספציפיים של אפליקציות stateful שאינן HTTP (כמו MongoDB) על סמך ה-SNI שסופק על ידי הלקוח.

איך התנועה מתחלקת כשמשתמשים בנתיבי TLS

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

  1. מאזן העומסים מאזין לכתובת ה-IP וליציאה שמוגדרות בכלל ההעברה.
  2. כשלקוח יוזם חיבור TLS, מאזן העומסים מיירט את ההודעה ClientHello ומחלץ את שם המארח של ה-SNI.

  3. ה-SNI שחולץ מושווה לשמות המארחים שמוגדרים בנתיבי ה-TLS שהוגדרו. מאזן העומסים משתמש בלוגיקה הבאה כדי לקבוע איזה שירות לקצה העורפי צריך לקבל את התנועה:

    1. אם הלקוח לא משתמש בפרוטוקול TLS, מאזן העומסים סוגר את החיבור.
    2. אם הלקוח לא שולח שם מארח של SNI בהודעת ClientHello, מאזן העומסים סוגר את החיבור.
    3. אם הלקוח שולח שם מארח SNI שהוא לא שם DNS תקין, מאזן העומסים סוגר את החיבור.
    4. אם הלקוח שולח שם מארח SNI שלא תואם לאף אחד משמות המארחים של SNI שמשויכים לנתיב TLS, מאזן העומסים סוגר את החיבור.

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

      ההתאמה מתבצעת לפי הסיומת הארוכה ביותר (הארוכה ביותר מבחינת מספר תת-הדומיינים). כדי להמחיש את שיטת ההתאמה, נניח שיש מסלול TLS עם SNI ‏*.foo.com, מסלול TLS נוסף עם SNI ‏*.bar.foo.com ומסלול TLS שלישי עם SNI ‏baz.bar.foo.com.

      • אם שם המארח של ה-SNI של הלקוח הוא baz.bar.foo.com, מאזן העומסים בוחר שירות לקצה העורפי שאליו מפנה נתיב ה-TLS שה-SNI שלו הוא baz.bar.foo.com.
      • אם שם המארח של ה-SNI של הלקוח הוא qux.bar.foo.com, מאזן העומסים בוחר שירות לקצה העורפי שאליו מפנה נתיב ה-TLS שה-SNI שלו הוא *.bar.foo.com.
      • אם שם המארח של ה-SNI של הלקוח הוא qux.qux.foo.com, מאזן העומסים בוחר שירות לקצה העורפי שאליו מפנה נתיב ה-TLS שה-SNI שלו הוא *.foo.com.

    אחרי שנמצאת התאמה, זרם הבייטים המוצפן מועבר ישירות באמצעות שרת proxy לשירות הקצה העורפי שהוקצה, בלי לסיים את חיבור ה-TLS (ל-TLS passthrough).

מגבלות

המגבלות הבאות חלות כשמשתמשים בנתיבי TLS כדי להגדיר ניתוב מבוסס-SNI:

  • שרת proxy ל-TCP יכול להפנות לשירות אחד לקצה העורפי או לנתיב TLS אחד או יותר. אי אפשר להגדיר את שניהם.

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

    כברירת מחדל, דפדפנים כבר מאחדים חיבורי HTTP. לדוגמה, כשדפדפן פותח חיבור ל-www.example.com והשרת מציג אישור ל-*.example.com במהלך לחיצת היד בפרוטוקול TLS, הדפדפן משתמש שוב בחיבור הזה לכל הבקשות ל-*.example.com, כל עוד שם המארח מפנה לאותה כתובת IP. ההתנהגות הזו תואמת ל-RFC 7540.

    בניתוב מבוסס-SNI, אחרי שנוצר חיבור הוא מקושר באופן קבוע לקצה העורפי של היעד. נניח שיש פריסה שבה *.example.com מוגש על ידי קצה עורפי אחד של HTTPS עם אישור TLS של *.example.com, ו-my.example.com מוגש על ידי קצה עורפי אחר של HTTPS. אם נוצר קודם חיבור ל-*.example.com, בקשות ה-HTTP הבאות ל-my.example.com ימוזגו לאותו חיבור, באמצעות הקצה העורפי של HTTPS ב-*.example.com.

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

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

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

  • ללא

    הגדרה של זיקה לסשן (session affinity) כ-NONE לא אומרת שאין זיקה לסשן. זה אומר שלא הוגדרה במפורש אפשרות של זיקה לסשן.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    • הוספת מכונות או נקודות קצה חדשות:

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

    • הסרה של כל מכונה או נקודת קצה, לא רק המכונה או נקודת הקצה שנבחרו:

      • אתם מסירים מכונה כלשהי מקצה עורפי של קבוצת מכונות.
      • התאמה אוטומטית לעומס (autoscaling) או תיקון תוכנה אוטומטי (autohealing) של קבוצת מופעי מכונה מנוהלים מסירים כל מכונה מה-backend של קבוצת מופעי מכונה מנוהלים.
      • אתם מסירים נקודת קצה (endpoint) כלשהי מקצה עורפי של NEG.
      • מסירים מהשירות לקצה העורפי את כל קבוצות המכונות או ה-NEG הקיימות בקצה העורפי שאינן ריקות.

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

    • כל מכונה או נקודת קצה (endpoint) שעוברת את בדיקת התקינות, ועוברת ממצב לא תקין למצב תקין.
    • בדיקת התקינות של מכונה או נקודת קצה נכשלת, והמצב משתנה מתקין ללא תקין או לזמן קצוב לתפוגה.

יתירות כשל

אם אחד מה-backends לא תקין, התנועה מופנית אוטומטית ל-backends תקינים.

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

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

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

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

 מנתק את החיבור

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

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

מסמכי תיעוד קשורים של GKE:

מכסות ומגבלות

מכסות ומגבלות: מידע על מכסות ומגבלות.

מגבלות

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

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