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

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

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

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

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

ארכיטקטורה

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

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

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

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

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

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

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

כללי העברה וכתובות 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 בלבד. כשיוצרים את כלל ההעברה, מציינים את הרשת. בהתאם לכתובת IPv4 או לטווח כתובות IPv6 שבהם אתם משתמשים, תמיד יש רשת VPC מפורשת או מרומזת שמשויכת לכלל ההעברה. כתובות IPv4 חיצוניות אזוריות תמיד נמצאות מחוץ לרשתות VPC. עם זאת, כשיוצרים את כלל ההעברה, צריך לציין את רשת ה-VPC שבה נוצרה תת-הרשת של ה-proxy בלבד. לכן, לכלל ההעברה יש שיוך מפורש לרשת. טווחים של כתובות IPv6 חיצוניות אזוריות תמיד קיימים בתוך רשת VPC. כשיוצרים את כלל ההעברה, צריך לציין את רשת המשנה שממנה נלקח טווח כתובות ה-IP. תת-הרשת הזו צריכה להיות באותו אזור ובאותה רשת VPC שבה נוצרה תת-רשת של שרת proxy בלבד. לכן, יש שיוך רשת משתמע. דרישות לגבי רשתות ותת-רשתות. כדי להשתמש בתנועה מסוג IPv6, הרשתות ורשתות המשנה צריכות לעמוד בדרישות ההגדרה הבאות: רשת VPC: צריך להשתמש ברשת VPC במצב מותאם אישית שהוגדרה עם הדגל --enable-ula-internal-ipv6. תת-רשת של כלל העברה: תת-הרשת הזו צריכה להיות תת-רשת עם תמיכה כפולה (IPv4_IPv6) או IPV6_ONLY, עם הערך ipv6-access-type שמוגדר ל-EXTERNAL. אפשרויות להקצאת כתובות IPv6. כלל ההעברה חייב להפנות לטווח של כתובות IPv6 מתוך טווח כתובות ה-IPv6 החיצוניות של תת-הרשת./96/64 אפשר להקצות את טווח כתובות ה-IPv6 הזה באחת מהשיטות הבאות: /96 מציינים כתובת IPv6 חיצונית שמורה. הגדרת כתובת IPv6 זמנית מותאמת אישית. מאפשרים הקצאה אוטומטית של כתובת IPv6 זמנית. Cloud de Confiance מגבלות. כדי לציין כתובת IPv6 זמנית בהתאמה אישית, צריך להשתמש ב-Google Cloud CLI או ב-API. ב Cloud de Confiance מסוף אין תמיכה בציון כתובות IPv6 זמניות מותאמות אישית לכללי העברה.

שרתי proxy יעד

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

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

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

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

מסלולי TLS

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• במקרה של קבוצות של מכונות, 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 של רשת המשנה ל-EXTERNAL.

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

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

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

אם משתמשים בקצה עורפי של 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 או ליציאה אחרת לא נשלחות לשרתי ה-Backend.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ניתוב מבוסס-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 שנבחרו תקינים. הזיקה לסשן עלולה להיפסק אם המופע או נקודת הקצה שנבחרו נכשלים בבדיקות תקינות.
• במאזני עומסים גלובליים חיצוניים של רשתות פרוקסי ובמאזני עומסים קלאסיים של רשתות פרוקסי, זיקה להפעלת אינטרנט יכולה להיפסק אם נעשה שימוש ב-Google Front End (GFE) שונה בשכבה הראשונה לבקשות או לחיבורים הבאים אחרי השינוי בנתיב הניתוב. יכול להיות שייבחר GFE אחר בשכבה הראשונה אם נתיב הניתוב מלקוח באינטרנט אל Google משתנה בין בקשות או חיבורים.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מגבלות

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

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

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

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