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

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

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

מצבי פעולה

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

ארכיטקטורה

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

אזורי

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

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

רשת משנה ל-Proxy בלבד

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

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

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

REGIONAL_MANAGED_PROXY

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

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

בנוסף:

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

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

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

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

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

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

מפרט היציאה. כל כלל העברה שבו משתמשים במאזן עומסי רשת של שרת 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. כלל ההעברה צריך גם להפנות לטווח של כתובות IPv6‏ /96 מתוך טווח כתובות ה-IPv6 הפנימיות של תת-הרשת /64. אפשר להקצות את טווח /96 באחת מהשיטות הבאות:

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

שרתי proxy יעד

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

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

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

מסלולי TLS

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    דרישות לגבי רשתות עורפיות

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

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

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

    דרישות לגבי רשת משנה של IPv6 בעורף המערכת

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

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

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

שרתי קצה וממשקי רשת

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

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

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

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

בדיקת תקינות

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

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

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

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

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

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

כללי חומת אש

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

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

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

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

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

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

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

גישת לקוח

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

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

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

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

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

כתובת IP כלל העברה שרת proxy יעד רכיבי קצה עורפי

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

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

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

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

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

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

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

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

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

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

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

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

  • שימוש בכתובת IP וביציאה גלובליות מסוג anycast כדי להפעיל כמה אפליקציות, וכך לצמצם את השימוש בכתובות IPv4.
  • תומך בפריסות עם הצפנה מקצה לקצה, שבהן האישורים יכולים להישאר בשרתי הקצה העורפיים, וכך לוודא שהתנועה אף פעם לא מפוענחת בזמן ההעברה.
  • מאפשר לאדמינים של הפלטפורמה לנהל את התשתית המרכזית, בזמן שבעלי השירותים מנהלים באופן עצמאי את המסלולים והעורפים הספציפיים שלהם.
  • ההגדרה הזו מאפשרת ניתוב לשברי מידע ספציפיים באפליקציות שהן לא 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 שלו הוא qux.bar.foo.com.*.bar.foo.com
      • אם שם המארח של SNI של הלקוח הוא qux.qux.foo.com, מאזן העומסים בוחר שירות קצה עורפי שאליו מפנה נתיב ה-TLS ששם ה-SNI שלו הוא qux.qux.foo.com.*.foo.com

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

מגבלות

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

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

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

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

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

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

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

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

  • ללא

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

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

    ערך ברירת המחדל של ההעדפה לשימוש באותו שרת (session affinity) הוא NONE.

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

    זיקה לסשן (session affinity) של כתובת ה-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, ואפשר להגדיר רק אחד מהם בכל פעם לערך שונה.

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

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

  • צריך להגדיר את שרת עורפי (backend instance) או נקודת הקצה שנבחרו כ-backend. הזיקה לסשן עלולה להיפסק באחד מהמקרים הבאים:
    • הסרתם את המכונה שנבחרה מקבוצת המכונות שלה.
    • התכונות 'התאמה אוטומטית לעומס' או 'תיקון תוכנה אוטומטי' של קבוצת מופעי מכונה מנוהלים מסירות את המכונה שנבחרה מקבוצת המופעים המנוהלים.
    • מסירים את נקודת הקצה שנבחרה מה-NEG שלה.
    • מסירים את קבוצת המכונות או את ה-NEG שמכילים את המופע או נקודת הקצה שנבחרו משירות לקצה העורפי.
  • מוודאים שנקודת הקצה או מופע ה-Backend שנבחרו תקינים. הזיקה לסשן עלולה להיפסק אם המופע או נקודת הקצה שנבחרו נכשלים בבדיקות תקינות.
לכל האפשרויות של זיקה לסשן (session affinity) יש את הדרישות הנוספות הבאות:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 החיבור מסתיים

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

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

מסמכי GKE שקשורים לנושא:

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

מידע על מכסות ומגבלות זמין במאמר מכסות ומגבלות.

מגבלות

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

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