במסמך הזה מוסברים המושגים שצריך להבין כדי להגדיר מאזן עומסי רשת חיצוני לשרת proxy מסוג Google Cloud .
מאזן עומסי רשת חיצוני לשרת proxy הוא מאזן עומסים של שרת proxy הפוך, שמפזר את תעבורת הנתונים ב-TCP שמגיעה מהאינטרנט למכונות וירטואליות (VM) ברשתGoogle Cloud Virtual Private Cloud (VPC). כשמשתמשים במאזן עומסי רשת בשרת proxy חיצוני, תנועת הנתונים הנכנסת של TCPמסתיימת במאזן העומסים. חיבור חדש מעביר את התנועה לקצה העורפי הזמין הקרוב ביותר.
מאזני עומסי רשת חיצוניים לשרת proxy מאפשרים להשתמש בכתובת IP אחת לכל המשתמשים ברחבי העולם. מאזן העומסים מנתב באופן אוטומטי את התנועה לקצוות העורפיים שהכי קרובים למשתמש.
מאזן העומסים הזה זמין במצב אזורי, ובהמשך המאמר הוא נקרא "מאזן עומסי רשת אזורי חיצוני בשרת proxy". מאזן העומסים מיושם כשירות מנוהל שמבוסס על שרת ה-proxy של Envoy בקוד פתוח. במצב האזורי, כל הלקוחות וה-backends נמצאים באזור מסוים. כדאי להשתמש במאזן העומסים הזה אם רוצים להציג תוכן ממיקום גיאוגרפי אחד בלבד (לדוגמה, כדי לעמוד בתקנות התאימות).
ארכיטקטורה
בתרשימים הבאים מוצגים הרכיבים של מאזני עומסי רשת חיצוניים בשרת proxy.
אזורי
הדיאגרמה הזו מציגה את הרכיבים של פריסת מאזן עומסי רשת אזורי חיצוני בשרת proxy.
אלה הרכיבים של מאזני עומסי רשת חיצוניים בשרת proxy.
רשת משנה לשרתי proxy בלבד
רשת המשנה לשרתי proxy בלבד מספקת קבוצה של כתובות IP שבהן Google משתמשת כדי להריץ שרתי proxy של Envoy בשבילכם. צריך ליצור רשת משנה אחת של שרתי proxy בלבד בכל אזור של רשת VPC שבו משתמשים במאזני עומסים. הדגל --purpose של רשת המשנה הזו לשרתי proxy בלבד מוגדר ל-REGIONAL_MANAGED_PROXY. כל מאזני העומסים האזוריים מבוססי-Envoy באותו אזור ורשת VPC חולקים מאגר של שרתי proxy של Envoy מאותה רשת משנה של שרתי proxy בלבד.
מכונות וירטואליות לקצה העורפי או נקודות קצה של כל מאזני העומסים באזור וברשת VPC מקבלות חיבורים מרשת המשנה לשרתי proxy בלבד.
נקודות שחשוב לזכור:
- תת-רשתות מסוג proxy-only משמשות רק לשרתי 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 עד 65,535. כדי לתמוך בכמה יציאות עוקבות, צריך להגדיר כמה כללי העברה. אפשר להגדיר כמה כללי העברה עם אותה כתובת IP וירטואלית ויציאות שונות. לכן, אפשר להגדיר שרת proxy לכמה אפליקציות עם יציאות נפרדות בהתאמה אישית לאותה כתובת IP וירטואלית של שרת proxy ל-TCP. לפרטים נוספים, ראו מפרטי יציאות לכללי העברה.
כדי לתמוך בכמה יציאות עוקבות, צריך להגדיר כמה כללי העברה. אפשר להגדיר כמה כללי העברה עם אותה כתובת IP וירטואלית ויציאות שונות. לכן, אפשר להשתמש בשרת proxy לכמה אפליקציות עם יציאות נפרדות בהתאמה אישית לאותה כתובת IP וירטואלית של שרת proxy ל-TCP.
בטבלה הבאה מפורטות הדרישות של כללי ההעברה למאזני עומסי רשת חיצוניים בשרת proxy.
| מצב מאזן עומסים | מסלול שירות הרשת | כלל העברה, כתובת IP וסכמת איזון עומסים | ניתוב מהאינטרנט אל ממשק ה-frontend של מאזן העומסים |
|---|---|---|---|
| מאזן עומסי רשת אזורי חיצוני בשרת proxy | מסלול פרימיום |
סכמת איזון עומסים: |
בקשות שמנותבות לשרתי ה-proxy של Envoy באותו אזור שבו נמצא מאזן העומסים. |
כללי העברה ורשתות VPC
בקטע הזה מוסבר איך כללי העברה שמשמשים מאזני עומסים חיצוניים של אפליקציות משויכים לרשתות VPC.
| מצב מאזן עומסים | שיוך רשת VPC |
|---|---|
| מאזן עומסי רשת אזורי חיצוני בשרת proxy | רשת ה-VPC של כלל ההעברה היא הרשת שבה נוצרה רשת המשנה שמשמשת רק לשרתי proxy. אתם מציינים את הרשת כשאתם יוצרים את כלל ההעברה. בהתאם לשימוש בכתובת IPv4 או בטווח כתובות IPv6, תמיד יש רשת VPC מפורשת או משתמעת שמשויכת לכלל ההעברה.
|
שרתי proxy לחלוקת העומס
מאזני עומסי רשת חיצוניים לשרת proxy סוגרים את החיבורים מהלקוח ויוצרים חיבורים חדשים לקצוות העורפיים. שרת ה-Proxy לחלוקת העומס מנתב את החיבורים החדשים האלה לשירות לקצה העורפי.
כברירת מחדל, שרת ה-Proxy לחלוקת העומס לא שומר את כתובת ה-IP המקורית של הלקוח ואת פרטי היציאה. כדי לשמור את המידע הזה, אפשר להפעיל את פרוטוקול PROXY בשרת ה-proxy לחלוקת העומס.
בטבלה הבאה מפורטות הדרישות של שרת ה-Proxy לטירגוט במאזני עומסי רשת חיצוניים של שרתי Proxy.
| מצב מאזן עומסים | מסלול שירות הרשת | שרת proxy לחלוקת העומס | חומרי עזר |
|---|---|---|---|
| מאזן עומסי רשת אזורי חיצוני בשרת proxy | מסלול פרימיום ומסלול רגיל | regionTargetTcpProxies |
שרת ה-Proxy לחלוקת העומס מפנה לשירות אחד לקצה העורפי או למסלול TLS אחד או יותר. |
מסלולי TLS
משאב מסלול TLS מאפשר להגדיר איך תעבורת הנתונים מנותבת לשירותים לקצה העורפי על סמך שמות מארחים של SNI.
אם לא מפנים לנתיב TLS בשרת ה-proxy ל-TCP של מאזן העומסים, המערכת משתמשת רק בשירות ברירת המחדל היחיד לקצה העורפי, והערך של שם המארח של SNI שנשלח על ידי הלקוח או היעדרו לא רלוונטי.
נתיבי TLS זמינים רק למאזני עומסי רשת אזוריים חיצוניים בשרת proxy. הם לא נתמכים במאזני עומסי רשת קלאסיים בשרת proxy ובמאזני עומסי רשת גלובליים חיצוניים בשרת proxy.כדי לצרף הגדרת ניתוב TLS לשרת proxy לחלוקת העומס, משתמשים בפקודות gcloud network-services tls-routes.
בטבלה הבאה מפורטים ממשקי ה-API של נתיבי TLS שנדרשים למאזני עומסי רשת חיצוניים בשרת proxy:
| מצב מאזן עומסים | מסלול TLS | חומרי עזר |
|---|---|---|
| מאזן עומסי רשת אזורי חיצוני בשרת proxy | אזורי tlsRoutes |
כל מסלול TLS יכול להפנות לשירות אחד או יותר לקצה העורפי. |
שירותים לקצה העורפי
שירותים לקצה העורפי מפנים את התנועה הנכנסת לקצה עורפי אחד או יותר שמחוברים אליהם. כל קצה עורפי מורכב מקבוצת מכונות או מקבוצה של נקודות קצה ברשת, וממידע על קיבולת ההצגה של הקצה העורפי. קיבולת השירות של הקצה העורפי יכולה להתבסס על מעבד (CPU) או על בקשות לשנייה (RPS).
לכל מאזן עומסים יש לפחות משאב אחד של שירות לקצה העורפי. אם אתם משתמשים בנתיבי TLS (גרסת טרום-השקה (Preview)) כדי להגדיר ניתוב, אתם יכולים להגדיר כמה שירותים לקצה העורפי בשביל מאזן העומסים. בלי נתיבי TLS, אתם מוגבלים לשירות אחד בלבד לקצה העורפי לכל מאזן עומסים.
בשירות לקצה העורפי מצוינת בדיקת התקינות שצריך לבצע בקצוות העורפיים הזמינים.
השינויים שבוצעו בשירות לקצה העורפי לא מתבצעים באופן מיידי. יכול להיות שיחלפו כמה דקות עד שהשינויים יופצו ל-GFE. כדי להבטיח הפרעות מינימליות למשתמשים, אתם יכולים להפעיל זמן להשלמת תהליך (connection draining) בשירותים לקצה העורפי. הפרעות כאלה יכולות לקרות כש-backend מסתיים, מוסר באופן ידני או מוסר על ידי התאמה לעומס (autoscaler). במאמר הפעלת זמן להשלמת תהליך (connection draining) מוסבר איך להשתמש בזמן להשלמת תהליך כדי לצמצם את ההפרעות לשירות.
למידע נוסף על משאב השירות לקצה העורפי, קראו את הסקירה הכללית על שירותים לקצה העורפי.
בטבלה הבאה מפורטים הקצוות העורפיים השונים שנתמכים בשירות לקצה העורפי של מאזני עומסי רשת חיצוניים לשרת proxy.
| מצב מאזן עומסים | קצוות עורפיים נתמכים בשירות לקצה העורפי | ||||||
|---|---|---|---|---|---|---|---|
| קבוצות של מכונות | קבוצות NEG אזוריות | קבוצות של נקודות קצה ברשת באינטרנט | קבוצות NEG ללא שרת (serverless) | קבוצות NEG היברידיות | GKE | ||
| מאזן עומסי רשת אזורי חיצוני בשרת proxy | נקודות קצה מסוג GCE_VM_IP_PORT |
קבוצות NEG אזוריות בלבד | |||||
רשתות VPC ורכיבי Back-end
בקצוות עורפיים של מאזן עומסי רשת אזורי חיצוני בשרת proxy, חלים הכללים הבאים:
בקבוצות של מכונות, בקבוצות של נקודות קצה ברמת האזור ובקבוצות של נקודות קצה לקישוריות היברידית, כל הקצוות העורפיים צריכים להיות באותו פרויקט ובאותו אזור כמו השירות לקצה העורפי. עם זאת, מאזן עומסים יכול להפנות לקצה עורפי שמשתמש ברשת VPC אחרת באותו פרויקט כמו שירות הקצה העורפי. אפשר להגדיר את הקישוריות בין רשת ה-VPC של מאזן העומסים לבין רשת ה-VPC לקצה העורפי באמצעות קישור בין רשתות VPC שכנות (peering), מנהרות Cloud VPN או צירופים ל-VLAN של Cloud Interconnect.
הגדרת רשת לקצה העורפי
- בקבוצות NEG אזוריות ובקבוצות NEG היברידיות, אתם מציינים במפורש את רשת ה-VPC כשאתם יוצרים את קבוצת ה-NEG.
- בקבוצות מופעי מכונה מנוהלים, רשת ה-VPC מוגדרת בתבנית של הגדרות המכונה.
- בקבוצות של מכונות לא מנוהלות, רשת ה-VPC של קבוצת המכונות מוגדרת כך שתתאים לרשת ה-VPC של הממשק
nic0של המכונה הווירטואלית הראשונה שנוספה לקבוצת המכונות.
דרישות רשת לקצה העורפי
הרשת של ה-backend צריכה לעמוד באחת מדרישות הרשת הבאות:
רשת ה-VPC של ה-backend חייבת להתאים בדיוק לרשת ה-VPC של כלל ההעברה.
רשת ה-VPC של הקצה העורפי צריכה להיות מחוברת לרשת ה-VPC של כלל ההעברה באמצעות קישור בין רשתות VPC שכנות. כדי לאפשר תקשורת בין רשת המשנה שמשמשת רק לשרתי proxy ברשת ה-VPC של כלל ההעברה לבין רשתות המשנה שמשמשות את המכונות או נקודות הקצה לקצה העורפי, צריך להגדיר החלפות של נתיבים ברשת המשנה.
דרישות לגבי רשתות משנה של IPv6 בקצה העורפי
גרסת ה-IP שמשמשת לחיבור הקצה הקדמי לא תלויה בחיבור הקצה העורפי. מכיוון שתת-הרשת של שרת ה-proxy בלבד היא במצב דואלי (IPV4_IPV6), היא יכולה לתקשר עם קצוות עורפיים באמצעות IPv4 או IPv6.
אם שרתי ה-backend (backend instances) שלכם מטפלים בתעבורת נתונים ב-IPv6, אפשר להגדיר את רשת המשנה העורפית עם סוג מחסנית
IPV4_ONLYאוIPV4_IPV6(מחסנית כפולה). אם סוג המחסנית של רשת המשנה של הקצה העורפי כולל IPv6, צריך להגדיר באופן מפורש את ipv6-access-type של רשת המשנה לערךEXTERNAL.
בכל שאר סוגי הקצוות העורפיים, כל הקצוות העורפיים צריכים להיות באותו אזור ובאותה רשת VPC.
ממשקי רשת וקצוות עורפיים
אם משתמשים בקצוות עורפיים של קבוצות מכונות, החבילות תמיד נשלחות אל nic0. אם רוצים לשלוח חבילות לממשקים שהם לא nic0 (ממשקי רשת וירטואליים או ממשקי רשת דינמיים), צריך להשתמש בקצוות עורפיים של קבוצות של נקודות קצה ברשת (NEG).
אם אתם משתמשים בקצוות עורפיים של קבוצות NEG אזוריות, החבילות נשלחות לממשק הרשת שמיוצג על ידי נקודת הקצה ב-NEG. נקודות הקצה של ה-NEG צריכות להיות באותה רשת VPC כמו רשת ה-VPC שמוגדרת במפורש ב-NEG.
פרוטוקול לתקשורת עם הקצוות העורפיים
כשמגדירים שירות לקצה העורפי של מאזן עומסי רשת בשרת proxy חיצוני, מגדירים את הפרוטוקול שבו שירות הקצה העורפי משתמש כדי לתקשר עם הקצוות העורפיים. מאזן העומסים משתמש רק בפרוטוקול שציינתם, ולא מנסה לנהל משא ומתן על חיבור עם הפרוטוקול השני. מאזני עומסי רשת חיצוניים לשרת proxy תומכים רק ב-TCP לתקשורת עם הקצוות העורפיים.
כללי חומת אש
אלה כללי חומת האש שצריך להגדיר:
במאזני עומסי רשת אזוריים חיצוניים בשרת proxy, כלל חומת אש לתעבורת נתונים נכנסת (ingress) שמאפשר לתעבורת הנתונים מתת-הרשת של שרת ה-proxy בלבד להגיע לקצוות העורפיים.
כלל חומת אש נכנסת (ingress) של
allowכדי לאפשר לתעבורת הנתונים מטווח בדיקות התקינות להגיע לשרתים העורפיים. למידע נוסף על בדיקות תקינות ועל הסיבה לכך שצריך לאפשר תנועה מהן, קראו את המאמר טווחי כתובות IP לבדיקה וכללים של חומת אש.
כללי חומת האש מוטמעים ברמת המכונה הווירטואלית, ולא ברמת שרתי ה-proxy של GFE. אי אפשר להשתמש בכללי חומת אש כדי למנוע מתעבורת נתונים להגיע למאזן העומסים.
צריך להגדיר את היציאות של כללי חומת האש האלה באופן הבא:
- מאפשרים תנועה ליציאת היעד של בדיקת התקינות של כל שירות לקצה העורפי.
- בקצוות עורפיים של קבוצות מכונות: קובעים את היציאות שצריך להגדיר באמצעות המיפוי בין היציאה בעלת השם של השירות לקצה העורפי לבין מספרי היציאות שמשויכים ליציאה בעלת השם בכל קבוצת מכונות. מספרי היציאות יכולים להשתנות בין קבוצות של מכונות שמוקצות לאותו שירות לקצה העורפי.
- ל-
GCE_VM_IP_PORT NEGקצוות עורפיים של NEG אזורי: מאפשרים תנועה למספרי היציאות של נקודות הקצה.
כתובות IP של המקור
כתובת ה-IP של מקור החבילות, כפי שהיא נראית בקצוות העורפיים, היא לא כתובת ה-IP החיצונית של מאזן העומסים שלGoogle Cloud . במילים אחרות, יש שני חיבורי TCP.
במאזני עומסי רשת אזוריים חיצוניים בשרת proxy:חיבור 1, מהלקוח המקורי למאזן העומסים (רשת משנה לשרת proxy בלבד):
- כתובת ה-IP של המקור: הלקוח המקורי (או כתובת IP חיצונית אם הלקוח נמצא מאחורי שער NAT או שרת proxy להעברה).
- כתובת ה-IP של היעד: כתובת ה-IP של מאזן העומסים.
חיבור 2, ממאזן העומסים (רשת משנה של שרתי proxy בלבד) ל-VM או לנקודת הקצה לקצה העורפי:
כתובת ה-IP של המקור: כתובת IP בתת-הרשת לשרתי proxy בלבד, שמשותפת לכל מאזני העומסים מבוססי-Envoy שנפרסו באותו אזור ורשת כמו מאזן העומסים.
כתובת ה-IP של היעד: כתובת ה-IP הפנימית של ה-VM או הקונטיינר לקצה העורפי ברשת ה-VPC.
יציאות פתוחות
מאזני עומסי רשת חיצוניים לשרת proxy הם מאזני עומסים של שרת proxy הפוך. מאזן העומסים סוגר את החיבורים הנכנסים ופותח חיבורים חדשים ממאזן העומסים לקצוות העורפיים. מאזני העומסים האלה מוטמעים באמצעות שרתי proxy של Google Front End (GFE) ברחבי העולם.
ל-GFE יש כמה יציאות פתוחות כדי לתמוך בשירותים אחרים של Google שפועלים באותה ארכיטקטורה. כשמריצים סריקת יציאות, יכול להיות שיופיעו יציאות פתוחות אחרות של שירותי Google אחרים שפועלים ב-GFE.
מבחינת ביקורת, אין טעם להריץ סריקת יציאות בכתובת ה-IP של מאזן עומסים שמבוסס על GFE, מהסיבות הבאות:
בסריקת יציאות (לדוגמה, באמצעות
nmap), בדרך כלל לא מצפים לחבילת תגובה או לחבילת TCP RST כשמבצעים בדיקת TCP SYN. שרתי GFE שולחים חבילות SYN-ACK בתגובה לבדיקות SYN רק ליציאות שבהן הגדרתם כלל העברה. שרתי GFE שולחים חבילות לשרתי הקצה שלכם רק בתגובה לחבילות שנשלחות לכתובת ה-IP של מאזן העומסים וגם ליציאת היעד שהוגדרה בכלל ההעברה שלו. חבילות שנשלחות לכתובת IP או ליציאה אחרת לא נשלחות לקצוות העורפיים שלכם.כל GFE בצי של Google יכול לענות על חבילות שנשלחות לכתובת ה-IP של מאזן העומסים. עם זאת, סריקה של שילוב בין כתובת IP של מאזן עומסים לבין יציאת יעד, חוקרת רק GFE אחד לכל חיבור TCP. כתובת ה-IP של מאזן העומסים לא מוקצית למכשיר או למערכת אחת. לכן, סריקה של כתובת ה-IP של מאזן עומסים שמבוסס על GFE לא סורקת את כל ה-GFE בצי של Google.
לכן, הנה כמה דרכים יעילות יותר לבדוק את האבטחה של מכונות הקצה העורפי:
מבקר אבטחה צריך לבדוק את הגדרת כללי ההעברה של מאזן העומסים. כללי ההעברה מגדירים את יציאת היעד שבה מאזן העומסים מקבל חבילות ומעביר אותן לקצוות העורפיים. במאזני עומסים שמבוססים על GFE, כל כלל העברה חיצוני יכול להפנות רק ליציאת TCP אחת ביעד.
מבקר אבטחה צריך לבדוק את הגדרת כלל חומת האש שרלוונטית למכונות הווירטואליות לקצה העורפי. כללי חומת האש שאתם מגדירים חוסמים את תעבורת הנתונים מה-GFE למכונות הווירטואליות של ה-backend, אבל לא חוסמים את תעבורת הנתונים הנכנסת ל-GFE. לשיטות מומלצות, ראו את הקטע בנושא כללים של חומת אש.
ארכיטקטורת VPC משותף
מאזני עומסי רשת אזוריים חיצוניים לשרת proxy תומכים בפריסות שמשתמשות ברשתות VPC משותפות. בעזרת VPC משותף אתם יכולים לשמור על הפרדה ברורה בין תחומי האחריות של מנהלי הרשתות לבין אלה של מפתחי השירותים. צוותי הפיתוח יכולים להתמקד בבניית שירותים בפרויקטים של שירות, וצוותי התשתית של הרשת יכולים להקצות ולנהל את איזון העומסים. אם אתם לא מכירים את VPC משותף, כדאי לקרוא את הסקירה הכללית על VPC משותף.
| כתובת IP | כלל העברה | שרת proxy לחלוקת העומס | רכיבי קצה עורפי |
|---|---|---|---|
| צריך להגדיר כתובת IP חיצונית באותו פרויקט שבו נמצא מאזן העומסים. | כלל ההעברה החיצוני צריך להיות מוגדר באותו פרויקט שבו נמצאים שרתי ה-backend (backend instances) (פרויקט השירות). | צריך להגדיר את שרת ה-proxy ל-TCP באותו פרויקט שבו נמצאים השרתים העורפיים. |
במאזני עומסי רשת אזוריים חיצוניים בשרת proxy, המכונות הווירטואליות לקצה העורפי נמצאות בדרך כלל בפרויקט שירות. בפרויקט השירות הזה צריך להגדיר שירות לקצה העורפי ובדיקת תקינות ברמה האזורית. |
ביזור תעבורת נתונים
כשמוסיפים קבוצת שרתי עורפי (backend instance) או קבוצת נקודות קצה של רשת (NEG) לשירות לקצה העורפי, צריך לציין מצב איזון עומסים. המצב הזה מגדיר שיטה למדידת העומס בקצה העורפי והקיבולת המקסימלית.
במאזני עומסי רשת חיצוניים בשרת proxy, מצב האיזון יכול להיות CONNECTION או UTILIZATION:
- אם מצב איזון העומסים הוא
CONNECTION, העומס מתחלק לפי המספר הכולל של החיבורים שה-backend יכול לטפל בהם. - אם מצב איזון העומסים הוא
UTILIZATION, העומס מתחלק לפי השימוש במכונות בקבוצת המכונות. מצב האיזון הזה רלוונטי רק לקצוות עורפיים של קבוצות מכונות וירטואליות.
התפלגות התנועה בין הקצוות העורפיים נקבעת לפי מצב האיזון של מאזן העומסים.
מאזן עומסי רשת אזורי חיצוני בשרת proxy
במאזני עומסי רשת אזוריים חיצוניים לשרת proxy, חלוקת התנועה מבוססת על מצב איזון העומסים ועל מדיניות המיקום של איזון העומסים.
מצב האיזון קובע את המשקל ואת החלק של התנועה שצריך לשלוח לכל קצה עורפי (קבוצת מכונות או NEG). המדיניות המקומית של איזון העומסים (LocalityLbPolicy) קובעת איך מתבצע איזון העומסים בקצוות העורפיים שבקבוצה.
כששירות לקצה העורפי מקבל תנועה, הוא מפנה אותה קודם כל לקצה עורפי (קבוצת מכונות או NEG) בהתאם למצב האיזון שלו. אחרי שבוחרים בקצה עורפי, תעבורת הנתונים מופצת בין המכונות או נקודות הקצה בקבוצת הקצה העורפי הזו בהתאם למדיניות המקומית של איזון העומסים.
למידע נוסף, קראו את המאמרים הבאים:
ניתוב מבוסס-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, תעבורת הנתונים מנותבת לשירותים לקצה העורפי באופן הבא:
- מאזן העומסים מאזין לכתובת ה-IP וליציאה שמוגדרות בכלל ההעברה.
- כשלקוח יוזם חיבור TLS, מאזן העומסים מיירט את ההודעה
ClientHelloומחלץ את שם המארח של ה-SNI. ה-SNI שחולץ מושווה לשמות המארחים שמוגדרים בנתיבי ה-TLS שהוגדרו. מאזן העומסים משתמש בלוגיקה הבאה כדי לקבוע איזה שירות לקצה העורפי צריך לקבל את התנועה:
- אם הלקוח לא משתמש בפרוטוקול TLS, מאזן העומסים סוגר את החיבור.
- אם הלקוח לא שולח שם מארח של SNI בהודעת
ClientHello, מאזן העומסים סוגר את החיבור. - אם הלקוח שולח שם מארח SNI שהוא לא שם DNS תקין, מאזן העומסים סוגר את החיבור.
- אם הלקוח שולח שם מארח SNI שלא תואם לאף אחד משמות המארחים של SNI שמשויכים לנתיב TLS, מאזן העומסים סוגר את החיבור.
בכל המצבים האחרים: מאזן העומסים בוחר שירות לקצה העורפי באמצעות תהליך ההתאמה הבא:
ההתאמה מתבצעת לפי הסיומת הארוכה ביותר (הארוכה ביותר מבחינת מספר תת-הדומיינים). כדי להמחיש את שיטת ההתאמה, נניח שיש מסלול 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.
- אם שם המארח של ה-SNI של הלקוח הוא
אחרי שנמצאת התאמה, זרם הבייטים המוצפן מועבר ישירות באמצעות שרת 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 לפני שהיא נשלחת למאזן עומסים של Google Cloud . במצבים שבהם לקוחות רבים משתמשים באותה כתובת IP אפקטיבית של מקור, יכול להיות שחלק מהמכונות הווירטואליות בקצה העורפי יקבלו יותר חיבורים או בקשות מאחרות.
כשמגדירים זיקה לסשן, חשוב לזכור את הנקודות הבאות:
אל תסתמכו על זיקה לסשן למטרות אימות או אבטחה. הזיקה לסשן יכולה להשתבש בכל פעם שמספר הקצוות העורפיים התקינים שמציגים מודעות משתנה. למידע נוסף, קראו את המאמר אובדן הזיקה לסשן.
ערכי ברירת המחדל של הדגלים
--session-affinityו---subsetting-policyהםNONE, ורק אחד מהם יכול להיות מוגדר לערך אחר בכל פעם.
אובדן הזיקה לסשן (session affinity)
כל האפשרויות של זיקה לסשן מחייבות את הדברים הבאים:
- צריך להגדיר את נקודת הקצה או את השרת העורפי שנבחרו כשרת עורפי. הזיקה לסשן יכולה להשתבש אם מתרחש אחד מהאירועים הבאים:
- המכונה שנבחרה תוסר מקבוצת המכונות שלה.
- התאמה אוטומטית לעומס או תיקון תוכנה אוטומטי (autohealing) של קבוצת מופעי מכונה מנוהלים מסירים את המכונה שנבחרה מקבוצת מופעי המכונה המנוהלים שלה.
- אתם מסירים את נקודת הקצה שנבחרה מה-NEG שלה.
- מסירים משירות הקצה העורפי את קבוצת המכונות או את ה-NEG שמכילים את המכונה או את נקודת הקצה שנבחרו.
- השרת העורפי או נקודת הקצה שנבחרו חייבים להישאר תקינים. הזיקה לסשן עלולה להישבר אם המכונה או נקודת הקצה שנבחרו נכשלות בבדיקות התקינות.
- במאזני עומסי רשת חיצוניים גלובליים של שרת proxy ובמאזני עומסי רשת קלאסיים של שרת proxy, הזיקה לסשן (session affinity) יכולה להשתבש אם משתמשים בממשק קצה של Google (GFE) אחר בשכבה הראשונה לבקשות או לחיבורים הבאים אחרי השינוי בנתיב הניתוב. יכול להיות שייבחר GFE אחר בשכבה הראשונה אם נתיב הניתוב מלקוח באינטרנט ל-Google ישתנה בין בקשות או חיבורים.
קבוצת המכונות או ה-NEG שמכילים את המכונה או נקודת הקצה שנבחרו לא יכולים להיות מלאים, כפי שמוגדר בקיבולת היעד שלהם. (בקבוצות אזוריות של קבוצות מופעי מכונה מנוהלים, הרכיב האזורי של קבוצת המכונות שמכילה את המכונה שנבחרה לא יכול להיות מלא). הזיקה לסשן יכולה להשתבש כשקבוצת המכונות או ה-NEG מלאים, וקבוצות מכונות או קבוצות NEG אחרות לא מלאות. מכיוון שרמת העומס יכולה להשתנות באופן בלתי צפוי כשמשתמשים במצב האיזון
UTILIZATION, כדאי להשתמש במצב האיזוןRATEאוCONNECTIONכדי לצמצם מצבים שבהם הזיקה לסשן עלולה להשתבש.המספר הכולל של שרתי עורף (backend instance) או נקודות קצה שהוגדרו חייב להישאר קבוע. כשמתרחש לפחות אחד מהאירועים הבאים, מספר נקודות הקצה או המכונות של השרת העורפי שהוגדרו משתנה, והזיקה לסשן עלולה להשתבש:
הוספת מכונות או נקודות קצה חדשות:
- מוסיפים מכונות לקבוצת מכונות קיימת בשירות לקצה העורפי.
- התאמה אוטומטית לעומס של קבוצת מופעי מכונה מנוהלים מוסיפה מופעים לקבוצת מופעי מכונה מנוהלים בשירות לקצה העורפי.
- מוסיפים נקודות קצה ל-NEG קיים בשירות לקצה העורפי.
- מוסיפים לשירות לקצה העורפי קבוצות של מכונות או קבוצות של נקודות קצה ברשת (NEG) שאינן ריקות.
הסרה של כל מכונה או נקודת קצה, לא רק המכונה או נקודת הקצה שנבחרו:
- אתם מסירים מכונה כלשהי מקצה עורפי של קבוצת מכונות.
- התאמה אוטומטית לעומס (autoscaling) או תיקון תוכנה אוטומטי (autohealing) של קבוצת מופעי מכונה מנוהלים מסירים כל מכונה מה-backend של קבוצת מופעי מכונה מנוהלים.
- אתם מסירים נקודת קצה (endpoint) כלשהי מקצה עורפי של NEG.
- מסירים משירות הקצה העורפי את כל קבוצות המכונות או ה-NEG הקיימות שאינן ריקות.
המספר הכולל של נקודות קצה או מכונות תקינות של שרתים עורפיים חייב להישאר קבוע. כשמתרחש לפחות אחד מהאירועים הבאים, מספר נקודות הקצה או המכונות התקינות של ה-backend משתנה, והזיקה לסשן עלולה להישבר:
- כל מכונה או נקודת קצה (endpoint) שעוברת את בדיקת התקינות, ועוברת ממצב לא תקין למצב תקין.
- מופע או נקודת קצה (endpoint) כלשהם נכשלים בבדיקת התקינות, ועוברים ממצב תקין למצב לא תקין או לזמן קצוב לתפוגה.
יתירות כשל
כך פועל מעבר לגיבוי במקרה של כשל במאזני עומסי רשת חיצוניים לשרת proxy:
- אם קצה עורפי הופך ללא תקין, התנועה מופנית אוטומטית לקצוות עורפיים תקינים באותו אזור.
- אם כל ה-backends לא תקינים, מאזן העומסים מפיל את התנועה.
איזון עומסים לאפליקציות GKE
אם אתם מפתחים אפליקציות ב-Google Kubernetes Engine, אתם יכולים להשתמש בקבוצות NEG עצמאיות כדי לאזן את העומסים של התנועה ישירות לקונטיינרים. כשמשתמשים בקבוצות NEG עצמאיות, אתם צריכים ליצור את אובייקט ה-Service שיוצר את ה-NEG, ואז לשייך את ה-NEG לשירות לקצה העורפי כדי שמאזן העומסים יוכל להתחבר לפודים.
למסמכים קשורים, ראו איזון עומסים שמקורם בקונטיינר באמצעות קבוצות NEG עצמאיות ברמת האזור.
מגבלות
אי אפשר ליצור מאזן עומסי רשת אזורי חיצוני בשרת proxy במסלול הפרימיום באמצעותGoogle Cloud מסוף . במקום זאת, צריך להשתמש ב-CLI של gcloud או ב-API.
Google Cloud לא מבטיחה את משך החיים של חיבורי TCP כשמשתמשים במאזני עומסי רשת חיצוניים לשרת proxy. הלקוחות צריכים להיות עמידים בפני ניתוקים, גם בגלל בעיות רחבות יותר באינטרנט וגם בגלל הפעלות מחדש מתוזמנות באופן קבוע של שרתי ה-proxy שמנהלים את החיבורים. אם שרת ה-proxy מופעל מחדש, בשדה
proxyStatus statusביומנים של מאזן עומסי הרשת של שרת ה-proxy מוצגת הודעת סטטוס משויכת.