במסמך הזה מוסברים המושגים שצריך להכיר כדי להגדיר מאזן עומסי רשת חיצוני לשרת proxy Google Cloud .
מאזן עומסי רשת חיצוני לשרת proxy הוא מאזן עומסים של שרת proxy הפוך שמפיץ תעבורת TCP שמגיעה מהאינטרנט למכונות וירטואליות (VM) ברשתGoogle Cloud הענן הווירטואלי הפרטי (VPC). כשמשתמשים במאזן עומסי רשת בשרת proxy חיצוני, תעבורת TCP או SSLנכנסת מסתיימת במאזן העומסים. חיבור חדש מעביר את התנועה לשרת העורפי הזמין הקרוב ביותר באמצעות TCP או SSL (מומלץ). תרחישי שימוש נוספים מפורטים במאמר סקירה כללית של מאזן עומסי רשת לשרת proxy.
מאזני עומסי רשת חיצוניים לשרת proxy מאפשרים לכם להשתמש בכתובת IP אחת לכל המשתמשים ברחבי העולם. מאזן העומסים מנתב באופן אוטומטי את התנועה אל השרתים העורפיים שהכי קרובים למשתמש.
בדוגמה הזו, תעבורת SSL ממשתמשים בעיר א' ובעיר ב' מסתיימת בשכבת איזון העומסים, ונוצר חיבור נפרד לשרת העורפי שנבחר.
מצבי פעולה
אפשר להגדיר מאזן עומסי רשת חיצוני לשרת proxy באחד מהמצבים הבאים:
- מאזן עומסי רשת קלאסי בשרת proxy מיושם בממשקי קצה של Google (GFE) שמפוזרים באופן גלובלי. אפשר להגדיר את מאזן העומסים הזה לטיפול בתעבורת TCP או SSL באמצעות שרת proxy של TCP או שרת proxy של SSL, בהתאמה. במסלול פרימיום, אפשר להגדיר את מאזן העומסים הזה כשירות גלובלי לאיזון עומסים. במסלול הרגיל, מאזן העומסים הזה מוגדר כשירות אזורי לאיזון עומסים. אפשר להשתמש במאזני עומסים קלאסיים של רשת לשרת proxy גם לפרוטוקולים אחרים שמשתמשים ב-SSL, כמו WebSockets ו-IMAP over SSL.
- מאזן עומסי רשת גלובלי חיצוני בשרת proxy מיושם בGFE שמפוזרים באופן גלובלי, ותומך ביכולות מתקדמות של ניהול תעבורה. אפשר להגדיר את מאזן העומסים הזה לטיפול בתנועת TCP או SSL באמצעות שרת proxy של TCP או שרת proxy של SSL, בהתאמה. מאזן העומסים הזה מוגדר כשירות גלובלי לאיזון עומסים במסלול פרימיום. אפשר להשתמש במאזני עומסים חיצוניים גלובליים של רשתות proxy גם לפרוטוקולים אחרים שמשתמשים ב-SSL, כמו WebSockets ו-IMAP over SSL.
- מאזן עומסי רשת אזורי חיצוני בשרת proxy מיושם במערך התוכנה Envoy proxy בקוד פתוח. הוא יכול לטפל רק בתנועת TCP. מאזן העומסים הזה מוגדר כשירות אזורי לאיזון עומסים, שאפשר להשתמש בו במסלול פרימיום או במסלול רגיל.
זיהוי המצב
כדי לקבוע את המצב של מאזן העומסים, פועלים לפי השלבים הבאים.
המסוף
נכנסים לדף Load balancing במסוף Google Cloud .
בכרטיסייה Load Balancers (מאזני עומסים) מוצגים סוג מאזן העומסים, הפרוטוקול והאזור. אם האזור ריק, מאזן העומסים הוא גלובלי.
בטבלה הבאה מוסבר איך לזהות את מצב איזון העומסים.
מצב מאזן עומסים סוג מאזן העומסים סוג הגישה אזור מאזן עומסי רשת קלאסי בשרת proxy רשת (Proxy קלאסי) חיצוני מאזן עומסי רשת גלובלי חיצוני בשרת proxy רשת (Proxy) חיצוני מאזן עומסי רשת אזורי חיצוני בשרת proxy רשת (Proxy) חיצוני מציין אזור
gcloud
משתמשים בפקודה
gcloud compute forwarding-rules describe:gcloud compute forwarding-rules describe FORWARDING_RULE_NAME
בפלט פקודה, בודקים את סכמת איזון העומסים, האזור ורמת הרשת. בטבלה הבאה מוסבר איך לזהות את מצב איזון העומסים.
מצב מאזן עומסים סכמת איזון עומסים כלל העברה רמת הרשת מאזן עומסי רשת קלאסי בשרת proxy חיצוני עולמי Standard או Premium מאזן עומסי רשת גלובלי חיצוני בשרת proxy EXTERNAL_MANAGED עולמי פרימיום מאזן עומסי רשת אזורי חיצוני בשרת proxy EXTERNAL_MANAGED אזורי Standard או Premium
ארכיטקטורה
בתרשימים הבאים מוצגים הרכיבים של מאזני עומסי רשת חיצוניים בשרת proxy.
עולמי
בתרשים הזה מוצגים הרכיבים של פריסת מאזן עומסי רשת גלובלי חיצוני בשרת proxy. הארכיטקטורה הזו רלוונטית גם למאזן עומסי רשת גלובלי חיצוני בשרת proxy וגם למאזן עומסי רשת בשרת proxy בגרסה הקלאסית במסלול פרימיום.
אזורי
בתרשים הזה מוצגים הרכיבים של פריסת מאזן עומסי רשת אזורי חיצוני בשרת proxy.
הרכיבים הבאים הם חלק ממאזני עומסים חיצוניים של רשת בשרת proxy.
רשת משנה של שרת proxy בלבד
הערה: רשתות משנה לשרת proxy בלבד נדרשות רק למאזני עומסי רשת אזוריים חיצוניים בשרת proxy.תת-הרשת של שרת proxy בלבד מספקת קבוצה של כתובות IP ש-Google משתמשת בהן כדי להפעיל שרתי proxy של Envoy בשמכם. צריך ליצור רשת משנה מסוג proxy-only בכל אזור של רשת VPC שבה משתמשים במאזני עומסים. הדגל --purpose של רשת המשנה הזו שמוגדרת רק כפרוקסי מוגדר כ-REGIONAL_MANAGED_PROXY. כל מאזני העומסים האזוריים שמבוססים על Envoy באותו אזור ובאותה רשת VPC חולקים מאגר של שרתי proxy של Envoy מאותה תת-רשת של שרתי proxy בלבד.
מכונות וירטואליות בבק-אנד או נקודות קצה של כל מאזני העומסים באזור וברשת VPC מקבלות חיבורים מרשת המשנה של proxy בלבד.
נקודות שכדאי לזכור:
- תת-רשתות של פרוקסי בלבד משמשות רק לפרוקסי Envoy, ולא לשרתי הקצה העורפיים.
- כתובת ה-IP של מאזן העומסים לא נמצאת בתת-הרשת של ה-proxy בלבד. כתובת ה-IP של מאזן העומסים מוגדרת על ידי כלל ההעברה החיצוני המנוהל שלו.
כללי העברה וכתובות IP
כללי העברה מעבירים תעבורה לפי כתובת IP, יציאה ופרוטוקול להגדרת איזון עומסים שכוללת שרת proxy ליעד ושירות קצה עורפי.
ציון כתובת IP. כל כלל העברה מתייחס לכתובת IP אחת שאפשר להשתמש בה ברשומות DNS של האפליקציה. אתם יכולים להזמין כתובת IP סטטית שתוכלו להשתמש בה, או לאפשר ל-Cloud Load Balancing להקצות לכם כתובת כזו. מומלץ להזמין כתובת IP סטטית. אחרת, בכל פעם שמוחקים כלל העברה ויוצרים כלל חדש, צריך לעדכן את רשומת ה-DNS עם כתובת ה-IP הזמנית החדשה שהוקצתה.
מפרט היציאה. כללי העברה חיצוניים שמשמשים בהגדרה של מאזן העומסים הזה יכולים להפנות ליציאה אחת בלבד מתוך 1 עד 65535. אם רוצים לתמוך בכמה יציאות עוקבות, צריך להגדיר כמה כללי העברה. אפשר להגדיר כמה כללי העברה עם אותה כתובת IP וירטואלית ויציאות שונות. לכן, אפשר להשתמש בכתובת IP וירטואלית של פרוקסי TCP כדי להעביר כמה אפליקציות עם יציאות מותאמות אישית נפרדות. פרטים נוספים זמינים במאמר מפרט הפורטים לכללי העברה.
כדי לתמוך בכמה יציאות עוקבות, צריך להגדיר כמה כללי העברה. אפשר להגדיר כמה כללי העברה עם אותה כתובת IP וירטואלית ויציאות שונות. לכן, אפשר להשתמש ב-proxy לכמה אפליקציות עם יציאות מותאמות אישית נפרדות לאותה כתובת IP וירטואלית של TCP proxy.
בטבלה הבאה מפורטות הדרישות של כללי העברה למאזני עומסי רשת חיצוניים לשרת proxy.
| מצב מאזן עומסים | Network Service Tier | כלל העברה, כתובת IP וסכמת איזון עומסים | ניתוב מהאינטרנט לקצה הקדמי של מאזן העומסים |
|---|---|---|---|
| מאזן עומסי רשת קלאסי בשרת proxy | מסלול פרימיום |
סכמת איזון עומסים: |
הבקשות מנותבות ל-GFE שהכי קרובים ללקוח באינטרנט. |
| מסלול רגיל |
סכמת איזון עומסים: |
בקשות שמנותבות ל-GFE באזור של מאזן העומסים. | |
| מאזן עומסי רשת גלובלי חיצוני בשרת proxy | מסלול פרימיום |
סכמת איזון עומסים: |
הבקשות מנותבות ל-GFE שהכי קרובים ללקוח באינטרנט. |
| מאזן עומסי רשת אזורי חיצוני בשרת proxy | מסלול פרימיוםומסלול רגיל |
סכמת איזון עומסים: |
בקשות מנותבות לשרתי ה-proxy של Envoy באותו אזור שבו נמצא מאזן העומסים. |
כללי העברה ורשתות VPC
בקטע הזה מוסבר איך כללי העברה שמשמשים מאזני עומסים חיצוניים של אפליקציות משויכים לרשתות VPC.
| מצב מאזן עומסים | שיוך של רשת VPC |
|---|---|
| מאזן עומסי רשת גלובלי חיצוני בשרת proxy מאזן עומסי רשת קלאסי בשרת proxy |
אין רשת VPC משויכת. כלל ההעברה תמיד משתמש בכתובת IP שנמצאת מחוץ לרשת ה-VPC. לכן, אין רשת VPC שמשויכת לכלל ההעברה. |
| מאזן עומסי רשת אזורי חיצוני בשרת proxy | רשת ה-VPC של כלל ההעברה היא הרשת שבה נוצרה תת-הרשת של ה-proxy בלבד. כשיוצרים את כלל ההעברה, מציינים את הרשת. |
שרתי proxy יעד
מאזני עומסים חיצוניים לשרת proxy ברשת מסיימים את החיבורים מהלקוח ויוצרים חיבורים חדשים לקצה העורפי. פרוקסי היעד מעביר את החיבורים החדשים האלה לשירות הקצה העורפי.
בהתאם לסוג התעבורה שהאפליקציה צריכה לטפל בה, אפשר להגדיר מאזן עומסי רשת בשרת proxy חיצוני עם שרת proxy של TCP או שרת proxy של SSL.
- שרת proxy של TCP ביעד: מגדירים את מאזן העומסים עם שרת proxy של TCP ביעד אם מצפים לתעבורת TCP.
- שרת proxy של SSL ביעד: מגדירים את מאזן העומסים עם שרת proxy של SSL ביעד אם צפויה תנועת לקוחות מוצפנת. סוג מאזן העומסים הזה מיועד רק לתנועה שאינה HTTP(S). לתנועת HTTP(S), מומלץ להשתמש במאזן עומסים חיצוני של אפליקציות (ALB).
כברירת מחדל, פרוקסי היעד לא שומר את כתובת ה-IP המקורית של הלקוח ואת פרטי היציאה. כדי לשמור את המידע הזה, צריך להפעיל את פרוטוקול ה-PROXY ב-proxy של היעד.
בטבלה הבאה מפורטות הדרישות של שרת proxy ליעד עבור מאזני עומסי רשת חיצוניים לשרת proxy.
| מצב מאזן עומסים | Network Service Tier | שרת proxy יעד |
|---|---|---|
| מאזן עומסי רשת קלאסי בשרת proxy | מסלול פרימיום | targetTcpProxies או targetSslProxies |
| מסלול רגיל | targetTcpProxies או targetSslProxies |
|
| מאזן עומסי רשת גלובלי חיצוני בשרת proxy | מסלול פרימיום | targetTcpProxies או targetSslProxies |
| מאזן עומסי רשת אזורי חיצוני בשרת proxy | מסלול פרימיום ומסלול רגיל | regionTargetTcpProxies |
אישורי SSL
נדרשים אישורי SSL רק אם פורסים מאזן עומסי רשת גלובלי חיצוני בשרת proxy ומאזן עומסי רשת קלאסי בשרת proxy עם SSL יעד.
מאזני עומסים חיצוניים של רשתות proxy שמשתמשים בשרתי proxy של SSL לצורך טירגוט דורשים מפתחות פרטיים ואישורי SSL כחלק מהגדרת מאזן העומסים.
Google Cloud יש שתי שיטות הגדרה להקצאת מפתחות פרטיים ואישורי SSL ל-proxy יעד ל-SSL: אישורי SSL של Compute Engine ו-Certificate Manager. תיאור של כל הגדרה זמין במאמר שיטות להגדרת אישורים בסקירה הכללית על אישורי SSL.
Google Cloud יש שני סוגים של אישורים: בניהול עצמי ובניהול Google. תיאור של כל סוג מופיע במאמר סוגי אישורים בסקירה הכללית על אישורי SSL.
שירותים לקצה העורפי
שירותים לקצה העורפי מפנים תנועה נכנסת ישירות לקצה עורפי אחד או יותר שמצורפים אליהם. כל קצה עורפי מורכב מקבוצת מופעים או מקבוצת נקודות קצה ברשת, וממידע על יכולת ההצגה של הקצה העורפי. קיבולת ההגשה של הקצה העורפי יכולה להתבסס על יחידת העיבוד המרכזית (CPU) או על בקשות לשנייה (RPS).
לכל מאזן עומסים יש משאב יחיד של שירות קצה עורפי שמציין את בדיקת תקינות שתתבצע עבור הקצוות העורפיים הזמינים.
השינויים בשירות לקצה העורפי לא מתבצעים באופן מיידי. יכול להיות שיחלפו כמה דקות עד שהשינויים יופצו ל-GFE. כדי לצמצם את ההפרעות למשתמשים, אפשר להפעיל ניתוק הדרגתי של חיבורים בשירותי קצה עורפיים. הפרעות כאלה יכולות לקרות כשמערכת עורפית מסתיימת, מוסרת באופן ידני או מוסרת על ידי קנה מידה אוטומטי. מידע נוסף על שימוש ב-זמן להשלמת תהליך (connection draining) כדי לצמצם את ההפרעות בשירות זמין במאמר הפעלת זמן להשלמת תהליך (connection draining).
מידע נוסף על משאב שירות לקצה העורפי זמין במאמר סקירה כללית על שירותי Backend.
בטבלה הבאה מפורטים סוגי הקצה העורפי השונים שנתמכים בשירות הקצה העורפי של מאזני עומסי רשת חיצוניים לשרת proxy.
| מצב מאזן עומסים | בק-אנדים נתמכים בשירות לקצה העורפי | ||||||
|---|---|---|---|---|---|---|---|
| קבוצות של מכונות | קבוצות אזוריות של נקודות קצה של רשתות | Internet NEGs | קבוצות NEG ללא שרת (serverless) | קבוצות היברידיות של נקודות קצה ברשת (NEGs) | קבוצות של נקודות קצה ברשת (NEGs) של Private Service Connect | GKE | |
| מאזן עומסי רשת קלאסי בשרת proxy | שימוש ב-NEGs אזוריים עצמאיים | ||||||
| מאזן עומסי רשת גלובלי חיצוני בשרת proxy | * | GCE_VM_IP_PORT type
endpoints * |
|||||
| מאזן עומסי רשת אזורי חיצוני בשרת proxy | נקודות קצה מסוג GCE_VM_IP_PORT |
קבוצות אזוריות של נקודות קצה ברשת (NEGs) בלבד | הוספת קבוצת נקודות קצה ברשת (NEG) של Private Service Connect | ||||
* מאזני עומסי רשת גלובליים חיצוניים בשרת proxy תומכים בקבוצות של מכונות וירטואליות עם IPv4 ו-IPv6 (מערך כפול) ובקצוות עורפיים של NEG אזוריים עם נקודות קצה של GCE_VM_IP_PORT.
שרתי קצה עורפיים ורשתות VPC
בקצה העורפי של מאזן עומסי רשת גלובלי חיצוני בשרת proxy ובקצה העורפי של מאזן עומסי רשת קלאסי בשרת proxy, כל המכונות בקצה העורפי מקבוצות של מכונות וכל נקודות הקצה בקצה העורפי מקבוצות של נקודות קצה ברשת (NEG) חייבות להיות באותו פרויקט. עם זאת, קצה עורפי של קבוצת מופעים או NEG יכול להשתמש ברשת VPC אחרת באותו פרויקט. אין צורך לקשר בין רשתות ה-VPC השונות באמצעות קישור בין רשתות שכנות (peering) כי ה-GFE מתקשרים ישירות עם השרתים העורפיים ברשתות ה-VPC שלהם.
למאזן עומסי רשת אזורי חיצוני בשרת proxy, הכללים הבאים חלים:
במקרה של קבוצות מכונות, NEGs אזוריים ו-NEGs של קישוריות היברידית, כל הקצוות העורפיים צריכים להיות ממוקמים באותו פרויקט ואזור כמו השירות לקצה העורפי. עם זאת, מאזן עומסים יכול להפנות לעורף חזיתי שמשתמש ברשת VPC אחרת באותו פרויקט כמו שירות העורף החזיתי. אפשר להגדיר קישוריות בין רשת ה-VPC של מאזן העומסים לבין רשת ה-VPC של השרת העורפי באמצעות קישור בין רשתות VPC שכנות (peering), מנהרות Cloud VPN, קבצים מצורפים של Cloud Interconnect VLAN או מסגרת Network Connectivity Center.
הגדרת רשת בקצה העורפי
- כשיוצרים קבוצות אזוריות של נקודות קצה ברשת (NEGs) וקבוצות היברידיות של נקודות קצה ברשת (NEGs), צריך לציין במפורש את רשת ה-VPC.
- בקבוצות מופעי מכונה מנוהלים, רשת VPC מוגדרת בתבנית של הגדרות מכונה.
- בקבוצות של מכונות לא מנוהלות, רשת ה-VPC של קבוצת המכונות מוגדרת כך שתתאים לרשת ה-VPC של ממשק
nic0של המכונה הווירטואלית הראשונה שנוספה לקבוצת המכונות.
דרישות לגבי רשת ה-Backend
הרשת של ה-Backend חייבת לעמוד באחת מהדרישות הבאות:
רשת ה-VPC של ה-backend חייבת להיות זהה לרשת ה-VPC של כלל ההעברה.
רשת ה-VPC של ה-Backend צריכה להיות מחוברת לרשת ה-VPC של כלל ההעברה באמצעות קישור בין רשתות שכנות (VPC Network Peering). צריך להגדיר את החלפת נתיבי רשתות המשנה כדי לאפשר תקשורת בין רשת המשנה של שרת ה-proxy בלבד ברשת ה-VPC של כלל ההעברה לבין רשתות המשנה שבהן נעשה שימוש במופעי ה-backend או בנקודות הקצה.
- רשת ה-VPC של ה-backend ורשת ה-VPC של כלל ההעברה צריכות להיות רשתות VPC מסוג spoke שמצורפות לאותו מרכז NCC. מסנני הייבוא והייצוא צריכים לאפשר תקשורת בין רשת המשנה של ה-proxy בלבד ברשת ה-VPC של כלל ההעברה לבין רשתות המשנה שמשמשות את מופעי ה-backend או נקודות הקצה.
בכל שאר סוגי ה-Backend, כל ה-Backend-ים צריכים להיות ממוקמים באותה רשת VPC ובאותו אזור.
שרתי קצה עורפיים וממשקי רשת
אם משתמשים בעורפי קצה של קבוצות מופעים, החבילות תמיד מועברות אל nic0. אם רוצים לשלוח מנות לממשקי nic0 שאינם ממשקי רשת וירטואליים (vNIC) או ממשקי רשת דינמיים, צריך להשתמש במקום זאת בשרתי קצה עורפיים של NEG.
אם משתמשים בקצה עורפי של NEG אזורי, המנות נשלחות לכל ממשק רשת שמיוצג על ידי נקודת הקצה ב-NEG. נקודות הקצה של ה-NEG צריכות להיות באותה רשת VPC כמו רשת ה-VPC שמוגדרת באופן מפורש ב-NEG.
פרוטוקול לתקשורת עם השרתים העורפיים
כשמגדירים שירות לקצה העורפי למאזן עומסי רשת חיצוני של שרת proxy, מגדירים את הפרוטוקול שבו שירות לקצה העורפי משתמש כדי לתקשר עם הבק-אנדים.
- במאזני עומסי רשת קלאסיים בשרת proxy, אפשר לבחור TCP או SSL.
- במאזני עומסים גלובליים חיצוניים של רשת בשרת proxy, אפשר לבחור בין TCP לבין SSL.
- במאזני עומסים אזוריים חיצוניים של רשת לשרת proxy, אפשר להשתמש ב-TCP.
מאזן העומסים משתמש רק בפרוטוקול שאתם מציינים, ולא מנסה לנהל משא ומתן על חיבור עם הפרוטוקול השני.
כללי חומת אש
חובה להגדיר את כללי חומת האש הבאים:
במאזני עומסי רשת קלאסיים בשרת proxy, צריך כלל חומת אש של תעבורת נתונים נכנסת (ingress)
allowכדי לאפשר לתעבורה מ-GFE להגיע לשרתים העורפיים.במאזני עומסים גלובליים חיצוניים בשרת proxy, כלל חומת אש של תעבורת נתונים נכנסת (ingress)
allowכדי לאפשר לתעבורת נתונים מ-GFE להגיע לשרתים העורפיים.
במאזני עומסים אזוריים חיצוניים בשרת proxy, צריך כלל חומת אש לתעבורת נתונים נכנסת (ingress) כדי לאפשר לתעבורה מתת-הרשת של שרת proxy בלבד להגיע לשרתים העורפיים.
כלל חומת אש של תעבורת נתונים נכנסת (ingress)
allowכדי לאפשר לתעבורה מטווחים של בדיקות תקינות להגיע לשרתים העורפיים. מידע נוסף על בדיקות תקינות ולמה צריך לאפשר תנועה מהן זמין במאמר Probe IP ranges and firewall rules.
כללי חומת האש מוטמעים ברמת המכונה הווירטואלית, ולא ברמת שרתי ה-proxy של GFE. אי אפשר להשתמש בכללי חומת אש כדי למנוע מתעבורת נתונים להגיע למאזן העומסים.
היציאות של כללי חומת האש האלה צריכות להיות מוגדרות באופן הבא:
- מאפשרים תנועה ליעד של כל בדיקת תקינות של שירות קצה עורפי.
- לדוגמה, עבור קצה עורפי של קבוצת מכונות: צריך לקבוע את היציאות שיוגדרו על ידי המיפוי בין היציאה עם השם של השירות לקצה העורפי לבין מספרי היציאות שמשויכים ליציאה עם השם הזו בכל קבוצת מכונות. מספרי הפורטים יכולים להיות שונים בין קבוצות מכונות שמוקצות לאותו שירות לקצה העורפי.
- ל
GCE_VM_IP_PORT NEGעורפי NEG אזוריים: מאפשרים תנועה למספרי היציאות של נקודות הקצה.
בטבלה הבאה מפורטים טווחי כתובות ה-IP של המקור שנדרשים לכללים של חומת האש.
| מצב מאזן עומסים | טווחים של כתובות IP של בדיקות תקינות | בקשה של טווחי מקורות |
|---|---|---|
| מאזן עומסי רשת גלובלי חיצוני בשרת proxy |
לתנועת IPv6 אל השרתים העורפיים:
|
מקור התנועה של GFE תלוי בסוג ה-Backend:
|
| מאזן עומסי רשת קלאסי בשרת proxy |
|
הטווחים האלה חלים על בקשות לבדיקות תקינות (probes) ובקשות מ-GFE. |
| מאזן עומסי רשת אזורי חיצוני בשרת proxy *, † |
לתנועת IPv6 אל השרתים העורפיים:
|
הטווחים האלה חלים על בקשות לבדיקות תקינות. |
* אין צורך לאפשר תנועה מטווחים של בקשות לבדיקת תקינות (probe) של Google עבור קבוצות NEG היברידיות. עם זאת, אם אתם משתמשים בשילוב של NEGs היברידיים ואזוריים בשירות לקצה העורפי יחיד, אתם צריכים לאפשר תנועה מטווחים של בדיקות תקינות של Google עבור ה-NEGs האזוריים.
† ב-NEGs אזוריים לאינטרנט, בדיקות תקינות הן אופציונליות. תעבורת נתונים ממאזני עומסים שמשתמשים ב-NEGs של אינטרנט אזורי מגיעה מרשת המשנה של שרת ה-proxy בלבד, ואז מתבצעת תרגום NAT (באמצעות Cloud NAT) לכתובות IP של NAT שהוקצו באופן ידני או אוטומטי. התנועה הזו כוללת גם בדיקות תקינות וגם בקשות של משתמשים ממאזן העומסים אל השרתים העורפיים. פרטים נוספים זמינים במאמר בנושא קבוצות אזוריות של נקודות קצה ברשת: שימוש בשער Cloud NAT.
כתובות IP של המקור
כתובת ה-IP של המקור של המנות, כפי שהיא נראית בבק-אנד, לא זהה לGoogle Cloud כתובת ה-IP החיצונית של מאזן העומסים. במילים אחרות, יש שני חיבורי TCP.
למאזני עומסי רשת קלאסיים בשרת proxy ולמאזני עומסי רשת גלובליים חיצוניים בשרת proxy:חיבור 1, מהלקוח המקורי למאזן העומסים (GFE):
- כתובת ה-IP של המקור: הלקוח המקורי (או כתובת IP חיצונית אם הלקוח נמצא מאחורי שער NAT או שרת proxy להעברה).
- כתובת ה-IP של היעד: כתובת ה-IP של מאזן העומסים.
חיבור 2, ממאזן העומסים (GFE) אל מכונת ה-VM או נקודת הקצה של ה-Backend:
כתובת ה-IP של המקור: כתובת IP באחד מהטווחים שצוינו בכללי חומת האש.
כתובת ה-IP של היעד: כתובת ה-IP הפנימית של המכונה הווירטואלית או של הקונטיינר בעורף השרת ברשת ה-VPC.
חיבור 1, מהלקוח המקורי למאזן העומסים (רשת משנה ל-proxy בלבד):
- כתובת ה-IP של המקור: הלקוח המקורי (או כתובת IP חיצונית אם הלקוח נמצא מאחורי שער NAT או שרת proxy להעברה).
- כתובת ה-IP של היעד: כתובת ה-IP של מאזן העומסים.
חיבור 2, ממאזן העומסים (רשת משנה של פרוקסי בלבד) אל ה-VM או נקודת הקצה של הבק-אנד:
כתובת ה-IP של המקור: כתובת IP ברשת המשנה של שרת ה-proxy בלבד שמשותפת לכל מאזני העומסים שמבוססים על Envoy שנפרסו באותו אזור ובאותה רשת כמו מאזן העומסים.
כתובת ה-IP של היעד: כתובת ה-IP הפנימית של המכונה הווירטואלית או של הקונטיינר בעורף השרת ברשת ה-VPC.
יציאות פתוחות
מאזני עומסים חיצוניים של רשתות proxy הם מאזני עומסים של שרת proxy הפוך. מאזן העומסים מסיים את החיבורים הנכנסים, ואז פותח חיבורים חדשים ממאזן העומסים אל השרתים העורפיים. מאזני העומסים האלה מיושמים באמצעות שרתי proxy של ממשק הקצה של Google (GFE) ברחבי העולם.
ל-GFE יש כמה יציאות פתוחות לתמיכה בשירותים אחרים של Google שפועלים באותה ארכיטקטורה. כשמריצים סריקת יציאות, יכול להיות שיוצגו יציאות פתוחות אחרות של שירותי Google אחרים שפועלים ב-GFE.
הפעלת סריקת יציאות בכתובת ה-IP של מאזן עומסים שמבוסס על GFE לא מועילה מנקודת מבט של ביקורת, מהסיבות הבאות:
בסריקת יציאות (לדוגמה, באמצעות
nmap) בדרך כלל לא צפויה חבילת תגובה או חבילת TCP RST כשמבצעים בדיקת TCP SYN. מערכות GFE שולחות מנות SYN-ACK בתגובה לבדיקות SYN רק עבור יציאות שהגדרתם עבורן כלל העברה. GFE שולח מנות רק לשרתי הקצה העורפיים בתגובה למנות שנשלחות לכתובת ה-IP של מאזן העומסים וליציאת היעד שהוגדרה בכלל ההעברה שלו. מנות שנשלחות לכתובת IP או ליציאה אחרת לא נשלחות לשרתי הקצה העורפיים.GFE מטמיע תכונות אבטחה כמו Google Cloud Armor. עם Cloud Armor Standard, שרתי GFE מספקים הגנה בזמינות תמידית מפני מתקפות DDoS נפחיות ומבוססות פרוטוקול, ומפני הצפות SYN. ההגנה הזו זמינה גם אם לא הגדרתם את Cloud Armor באופן מפורש. תחויבו רק אם תגדירו מדיניות אבטחה או אם תירשמו לתוכנית Managed Protection Plus.
על מנות שנשלחות לכתובת ה-IP של איזון העומסים יכול לענות כל GFE בצי של Google. עם זאת, סריקה של כתובת IP של איזון עומסים ושילוב של יציאת יעד בודקת רק GFE אחד לכל חיבור TCP. כתובת ה-IP של מאזן העומסים לא מוקצית למכשיר או למערכת יחידים. לכן, סריקת כתובת ה-IP של מאזן עומסים שמבוסס על GFE לא סורקת את כל ה-GFE בצי של Google.
לכן, הנה כמה דרכים יעילות יותר לבדיקת האבטחה של מופעי ה-Backend:
בודק אבטחה צריך לבדוק את ההגדרה של כללי ההעברה בהגדרה של מאזן העומסים. כללי ההעברה מגדירים את יציאת היעד שמאזן העומסים מקבל דרכה חבילות ומעביר אותן לשרתי הקצה. במאזני עומסים שמבוססים על GFE, כל כלל העברה חיצוני יכול להפנות רק ליעד אחד של יציאת TCP.
בודק אבטחה צריך לבדוק את ההגדרות של כלל חומת האש שרלוונטי למכונות וירטואליות של ה-Backend. כללי חומת האש שהגדרתם חוסמים תעבורת נתונים מ-GFE למכונות ה-VM של ה-Backend, אבל לא חוסמים תעבורת נתונים נכנסת ל-GFE. מידע נוסף על שיטות מומלצות זמין בקטע בנושא כללים של חומת אש.
ארכיטקטורה של VPC משותף
מאזני עומסים אזוריים חיצוניים של רשתות proxy ומאזני עומסים קלאסיים של רשתות proxy תומכים בפריסות שמשתמשות ברשתות VPC משותפות. VPC משותף מאפשר לכם לשמור על הפרדה ברורה של תחומי האחריות בין אדמינים של רשתות לבין מפתחי שירותים. צוותי הפיתוח יכולים להתמקד בבניית שירותים בפרויקטים של שירותים, וצוותי התשתית של הרשת יכולים להקצות ולנהל איזון עומסים. אם אתם לא מכירים את ה-VPC המשולב, כדאי לקרוא את הסקירה הכללית על VPC משולב.
| כתובת IP | כלל העברה | שרת proxy יעד | רכיבי קצה עורפי |
|---|---|---|---|
| צריך להגדיר כתובת IP חיצונית באותו פרויקט שבו נמצא מאזן העומסים. | כלל ההעברה החיצוני צריך להיות מוגדר באותו פרויקט כמו מופעי ה-Backend (פרויקט השירות). | פרוקסי TCPאו SSL היעד חייב להיות מוגדר באותו פרויקט שבו מוגדרים מופעי הקצה העורפי. |
במאזני עומסי רשת קלאסיים בשרת proxy, צריך להגדיר שירות גלובלי לקצה העורפי באותו פרויקט שבו מוגדרות מכונות הקצה העורפי. המכונות האלה צריכות להיות בקבוצות של מכונות שמצורפות לשירות הקצה העורפי בתור קצה עורפי. בדיקות תקינות שמשויכות לשירותי קצה עורפיים צריכות להיות מוגדרות באותו פרויקט כמו שירות הקצה העורפי. במאזני עומסי רשת אזוריים חיצוניים בשרת proxy, המכונות הווירטואליות בקצה העורפי ממוקמות בדרך כלל בפרויקט שירות. צריך להגדיר בפרויקט השירות שירות לקצה העורפי אזורי ובדיקת תקינות. |
ביזור תעבורת נתונים
כשמוסיפים קבוצת מופעים או NEG לעורף העורף לשירות עורף, מציינים מצב איזון עומסים, שמגדיר שיטה למדידת עומס העורף וקיבולת היעד.
במאזני עומסים חיצוניים של רשת בשרת proxy, מצב האיזון יכול להיות CONNECTION או UTILIZATION:
- אם מצב איזון העומסים הוא
CONNECTION, העומס מתחלק על סמך המספר הכולל של החיבורים שהקצה העורפי יכול לטפל בהם. - אם מצב איזון העומסים הוא
UTILIZATION, העומס מתחלק בהתאם לניצול של המכונות בקבוצת המכונות. מצב האיזון הזה חל רק על קצה עורפי של קבוצת מכונות וירטואליות.
ההתפלגות של תעבורת הנתונים בין קצה עורפי לקצה עורפי נקבעת לפי מצב האיזון של מאזן העומסים.
מאזן עומסי רשת קלאסי בשרת proxy
במאזן עומסי רשת קלאסי בשרת proxy, מצב האיזון משמש לבחירת הקצה העורפי (קבוצת מכונות או NEG) הכי מתאים. התנועה מחולקת באופן סדר סיבובי בין המופעים או נקודות הקצה ב-Backend.
איך הקשרים מחולקים
אפשר להגדיר מאזן עומסי רשת בשרת proxy בגרסה הקלאסית כשירות גלובלי לאיזון עומסים במסלול פרימיום, וכשירות אזורי במסלול רגיל.
מצב האיזון והבחירה של היעד קובעים את הקיבולת של העורף (backend) מנקודת המבט של כל NEG אזורי, קבוצת מופעים אזורית או אזור של קבוצת מופעים אזורית.GCE_VM_IP_PORT לאחר מכן, התנועה מופצת בתוך אזור באמצעות גיבוב עקבי.
במסלול פרימיום
יכול להיות לכם רק שירות לקצה העורפי אחד, והוא יכול לכלול בק-אנדים בכמה אזורים. באיזון עומסים גלובלי, אתם פורסים את השרתים העורפיים שלכם בכמה אזורים, ומאזן העומסים מנתב את התנועה באופן אוטומטי לאזור הקרוב ביותר למשתמש. אם אזור מסוים מלא, מאזן העומסים מפנה באופן אוטומטי חיבורים חדשים לאזור אחר שיש בו קיבולת זמינה. החיבורים הקיימים של המשתמשים יישארו באזור הנוכחי.
Google מפרסמת את כתובת ה-IP של מאזן העומסים מכל נקודות הנוכחות ברחבי העולם. כל כתובת IP של מאזן עומסים היא גלובלית מסוג anycast.
אם מגדירים שירות לקצה העורפי עם בק-אנד בכמה אזורים, מערכות ממשק קצה של Google (GFE) מנסות להפנות בקשות לקבוצות בריאות של שרתים עורפיים (backend instance) או לקבוצות NEG באזור הקרוב ביותר למשתמש.
במסלול רגיל
Google מפרסמת את כתובת ה-IP של מאזן העומסים מנקודות נוכחות שמשויכות לאזור של כלל ההעברה. מאזן העומסים משתמש בכתובת IP חיצונית אזורית.
אפשר להגדיר שרתי בק-אנד רק באותו אזור שבו מוגדר כלל ההעברה. מאזן העומסים מפנה בקשות רק לשרתי בק-אנד תקינים באותו אזור.
מאזן עומסי רשת גלובלי חיצוני בשרת proxy
במאזן עומסי רשת גלובלי חיצוני בשרת proxy, חלוקת התנועה מבוססת על מצב איזון העומסים ומדיניות המיקום של איזון העומסים.
מצב האיזון קובע את המשקל ואת החלק של תעבורת הנתונים שיישלחו לכל קבוצה (קבוצת מופעים או NEG). מדיניות המיקום של איזון העומסים (LocalityLbPolicy) קובעת איך מתבצע איזון העומסים של הקצוות העורפיים בקבוצה.
כששירות קצה עורפי מקבל תנועה, הוא קודם מפנה את התנועה לקצה עורפי (קבוצת מופעים או NEG) בהתאם למצב האיזון של הקצה העורפי. אחרי שבוחרים בקצה העורפי, תעבורת הנתונים מופצת בין המופעים או נקודות הקצה בקבוצה הזו של הקצה העורפי בהתאם למדיניות המיקום של איזון העומסים.
למידע נוסף, קראו את המאמרים הבאים:
איך הקשרים מחולקים
אפשר להגדיר מאזן עומסי רשת גלובלי חיצוני בשרת proxy כשירות גלובלי לאיזון עומסים עם מסלול פרימיום
מצב האיזון והבחירה של היעד קובעים את הקיבולת של ה-NEG האזורי או של קבוצת המופעים האזורית, מנקודת המבט של כל אחד מהם.GCE_VM_IP_PORT
לאחר מכן, התנועה מופצת בתוך אזור באמצעות גיבוב עקבי.
יכול להיות לכם רק שירות לקצה העורפי אחד, ושירות לקצה העורפי יכול לכלול שרתי בק-אנד בכמה אזורים. באיזון עומסים גלובלי, אתם פורסים את השרתים העורפיים שלכם בכמה אזורים, ומאזן העומסים מנתב את התנועה באופן אוטומטי לאזור הקרוב ביותר למשתמש. אם אזור מסוים מלא, מאזן העומסים מפנה באופן אוטומטי חיבורים חדשים לאזור אחר שיש בו קיבולת זמינה. החיבורים הקיימים של המשתמשים יישארו באזור הנוכחי.
Google מפרסמת את כתובת ה-IP של מאזן העומסים מכל נקודות הנוכחות ברחבי העולם. כל כתובת IP של מאזן עומסים היא גלובלית מסוג anycast.
אם מגדירים שירות לקצה העורפי עם בק-אנד בכמה אזורים, מערכות ממשק קצה של Google (GFE) מנסות להפנות בקשות לקבוצות בריאות של שרתים עורפיים (backend instance) או לקבוצות NEG באזור הקרוב ביותר למשתמש.
מאזן עומסי רשת אזורי חיצוני בשרת proxy
במאזני עומסי רשת אזוריים חיצוניים לשרת proxy, חלוקת התעבורה מבוססת על מצב איזון העומסים ומדיניות המיקום של איזון העומסים.
מצב האיזון קובע את המשקל ואת חלקיק התנועה שצריך לשלוח לכל קצה עורפי (קבוצת מופעים או NEG). מדיניות המיקום של איזון העומסים (LocalityLbPolicy) קובעת איך מתבצע איזון העומסים של הקצוות העורפיים בקבוצה.
כששירות לקצה העורפי מקבל תנועה, הוא קודם מפנה את התנועה ל-backend (קבוצת מופעים או NEG) בהתאם למצב האיזון שלו. אחרי שבוחרים בקצה העורפי, תעבורת הנתונים מופצת בין המופעים או נקודות הקצה בקבוצה הזו של הקצה העורפי בהתאם למדיניות המיקום של איזון העומסים.
למידע נוסף, קראו את המאמרים הבאים:
זיקה לסשן (session affinity)
התכונה 'זיקה לסשן (session affinity)' מאפשרת להגדיר את שירות לקצה העורפי של מאזן העומסים כך שישלח את כל הבקשות מאותו לקוח לאותו בק-אנד, כל עוד הבק-אנד תקין ויש לו קיבולת.
מאזני עומסי רשת חיצוניים לשרת proxy מציעים את סוגי ההצמדה הבאים של סשנים:ללא
הגדרה של זיקה לסשן עם ערך של
NONEלא אומרת שאין זיקה לסשן. המשמעות היא שלא הוגדרה במפורש אפשרות של זיקה לסשן.הגיבוב תמיד מתבצע כדי לבחור שרת קצה עורפי. הגדרה של זיקה לסשן של
NONEפירושה שמאזן העומסים משתמש בגיבוב של 5 טאפלים כדי לבחור בק-אנד. הגיבוב של 5-tuple מורכב מכתובת ה-IP של המקור, יציאת המקור, הפרוטוקול, כתובת ה-IP של היעד ויציאת היעד.ערך ברירת המחדל של זיקה לסשן הוא
NONE.זיקה לכתובת IP של לקוח
זיקה לסשן לפי כתובת ה-IP של הלקוח (
CLIENT_IP) היא גיבוב של 2-tuple שנוצר מכתובות ה-IP של המקור והיעד של חבילת הנתונים. התכונה 'זיקה לכתובת IP של לקוח' מעבירה את כל הבקשות מאותה כתובת IP של לקוח לאותו קצה עורפי, כל עוד יש לאותו קצה עורפי קיבולת והוא תקין.כשמשתמשים בזיקה לכתובת IP של לקוח, חשוב לזכור את הנקודות הבאות:
- כתובת ה-IP של היעד של החבילה זהה לכתובת ה-IP של כלל ההעברה של מאזן העומסים רק אם החבילה נשלחת ישירות למאזן העומסים.
- כתובת ה-IP של המקור של חבילת הנתונים לא בהכרח תואמת לכתובת ה-IP שמשויכת ללקוח המקורי אם חבילת הנתונים מעובדת על ידי מערכת NAT או proxy ביניים לפני שהיא מועברת למאזן עומסים. Google Cloud במצבים שבהם הרבה לקוחות חולקים את אותה כתובת IP אפקטיבית של המקור, יכול להיות שחלק מהמכונות הווירטואליות של ה-Backend יקבלו יותר חיבורים או בקשות מאחרות.
כשמגדירים זיקה לסשן (session affinity), חשוב לזכור את הנקודות הבאות:
אל תסתמכו על זיקה לסשן (session affinity) למטרות אימות או אבטחה. הזיקה לסשן עלולה להיפסק בכל פעם שמספר השרתים העורפיים הפעילים והתקינים משתנה. פרטים נוספים זמינים במאמר בנושא איבוד של זיקה לסשן.
ערכי ברירת המחדל של הדגלים
--session-affinityו---subsetting-policyהםNONE, ואפשר להגדיר רק אחד מהם בכל פעם לערך שונה.
איבוד הזיקה לסשן
כל האפשרויות של זיקה לסשן (session affinity) דורשות את הדברים הבאים:
- צריך להגדיר את מופע השרת העורפי (backend instance) או נקודת הקצה שנבחרו כ-Backend. הזיקה לסשן עלולה להיפסק באחד מהמקרים הבאים:
- הסרתם את המופע שנבחר מקבוצת המופעים שלו.
- התכונות 'התאמה אוטומטית לעומס' או 'תיקון תוכנה אוטומטי' של קבוצת מופעי מכונה מנוהלים מסירות את המופע שנבחר מקבוצת המופעים המנוהלים.
- מסירים את נקודת הקצה שנבחרה מקבוצת נקודות הקצה לרשת (NEG).
- מסירים את קבוצת המכונות או את ה-NEG שמכילים את המכונה או נקודת הקצה שנבחרו משירות ה-Backend.
- מופע הקצה העורפי או נקודת הקצה שנבחרו צריכים להישאר תקינים. הזיקה לסשן עלולה להיפסק אם המופע או נקודת הקצה שנבחרו נכשלים בבדיקות התקינות.
- במאזני עומסים גלובליים חיצוניים של רשתות פרוקסי ובמאזני עומסים קלאסיים של רשתות פרוקסי, יכול להיות שהזיקה לסשן תישבר אם נעשה שימוש בממשק קצה של Google (GFE) שונה בשכבה הראשונה לבקשות או לחיבורים הבאים אחרי השינוי בנתיב הניתוב. יכול להיות שייבחר GFE אחר בשכבה הראשונה אם נתיב הניתוב מלקוח באינטרנט אל Google משתנה בין בקשות או בין חיבורים.
קבוצת המופעים או ה-NEG שמכילים את המופע או נקודת הקצה שנבחרו לא יכולים להיות מלאים, כפי שמוגדר בקיבולת היעד שלהם. (בקבוצות מנוהלות של מופעי מכונה אזוריים, הרכיב האזורי של קבוצת המופעים שמכילה את המופע שנבחר לא יכול להיות מלא). הזיקה לסשן עלולה להיפסק אם קבוצת המופעים או ה-NEG מלאים, וקבוצות מופעים או NEGs אחרים לא מלאים. כשמשתמשים במצב איזון
UTILIZATION, יכול להיות שהקיבולת תשתנה בצורה בלתי צפויה. לכן, כדי לצמצם את הסיכויים שהזיקה לסשן תישבר, מומלץ להשתמש במצב איזוןRATEאוCONNECTION.המספר הכולל של נקודות הקצה או המופעים של ה-backend שהוגדרו חייב להישאר קבוע. כשמתרחש לפחות אחד מהאירועים הבאים, המספר של מופעי הקצה העורפי או נקודות הקצה שהוגדרו משתנה, והזיקה לסשן עלולה להיפסק:
הוספת מופעים או נקודות קצה חדשים:
- מוסיפים מופעים לקבוצת מופעים קיימת בשירות הקצה העורפי.
- התאמה אוטומטית לעומס של קבוצת מופעי מכונה מנוהלים מוסיפה מופעים לשירות לקצה העורפי.
- מוסיפים נקודות קצה ל-NEG קיים בשירות לקצה העורפי.
- מוסיפים קבוצות של מופעים לא ריקים או NEGs לשירות לקצה העורפי.
הסרה של כל מופע או נקודת קצה, לא רק המופע או נקודת הקצה שנבחרו:
- מסירים מופע כלשהו מקצה עורפי של קבוצת מופעים.
- שינוי גודל אוטומטי או תיקון אוטומטי של קבוצת מופעי מכונה מנוהלים מסירים כל מופע מקצה עורפי של קבוצת מופעי מכונה מנוהלים.
- אתם מסירים נקודת קצה כלשהי מקצה עורפי של NEG.
- מסירים כל קבוצת מופעים או NEG קיימים ולא ריקים משירות הקצה העורפי.
המספר הכולל של מופעי קצה עורפיים או נקודות קצה תקינים חייב להישאר קבוע. כשמתרחש לפחות אחד מהאירועים הבאים, המספר של נקודות הקצה או המופעים של ה-backend שפועלים בצורה תקינה משתנה, והזיקה לסשן עלולה להיפסק:
- כל מופע או נקודת קצה עוברים את בדיקת התקינות, ועוברים ממצב לא תקין למצב תקין.
- כל מופע או נקודת קצה נכשלים בבדיקת התקינות שלהם, ועוברים ממצב תקין למצב לא תקין או למצב של פסק זמן.
מעבר לגיבוי (Failover)
יתירות כשל עבור מאזני עומסי רשת חיצוניים של שרת proxy פועלת באופן הבא:
- אם שרת קצה עורפי (backend) לא תקין, התעבורה מופנית אוטומטית לשרתי קצה עורפיים תקינים באותו אזור.
- אם כל שרתי הבק-אנד באזור מסוים לא תקינים, תעבורת הנתונים מופצת לשרתי בק-אנד תקינים באזורים אחרים (במצבים גלובליים וקלאסיים בלבד).
- אם כל השרתים העורפיים לא תקינים, מאזן העומסים מפסיק את התעבורה.
איזון עומסים באפליקציות GKE
אם אתם מפתחים אפליקציות ב-Google Kubernetes Engine, אתם יכולים להשתמש ב-NEGs עצמאיים כדי לבצע איזון עומסים של תעבורה ישירות לקונטיינרים. כשמשתמשים ב-NEGs עצמאיים, אתם אחראים ליצירת אובייקט Service שיוצר את ה-NEG, ואז לשיוך ה-NEG לשירות לקצה העורפי כדי שמאזן העומסים יוכל להתחבר ל-Pods.
למידע נוסף, אפשר לעיין במאמר בנושא איזון עומסים שמקורם בקונטיינר באמצעות קבוצות עצמאיות של נקודות קצה ברמת האזור.
מגבלות
במסלול הפרימיום, אי אפשר ליצור מאזן עומסי רשת אזורי חיצוני לשרת proxy באמצעותGoogle Cloud המסוף .בנוסף, רק אזורים שתומכים במסלול הרגיל זמינים למאזני העומסים האלה בGoogle Cloud מסוף .במקום זאת, צריך להשתמש ב-ה-CLI של gcloud או ב-API.
Google Cloud לא מתחייבת לגבי משך החיים של חיבורי TCP כשמשתמשים במאזני עומסי רשת חיצוניים לשרת proxy. הלקוחות צריכים להיות עמידים לניתוקים, גם בגלל בעיות באינטרנט וגם בגלל הפעלות מחדש מתוזמנות של שרתי ה-proxy שמנהלים את החיבורים.
המגבלות הבאות חלות רק על מאזני עומסי רשת בשרת proxy בגרסה הקלאסית ועל מאזני עומסי רשת בשרת proxy חיצוני גלובלי שנפרסים עם שרת proxy של SSL:
מאזני עומסים קלאסיים של רשת בשרת proxy ומאזני עומסים גלובליים חיצוניים של רשת בשרת proxy לא תומכים באימות שמבוסס על אישורי לקוח, שנקרא גם אימות TLS הדדי.
מאזני עומסים קלאסיים של רשתות בשרת proxy ומאזני עומסים גלובליים חיצוניים של רשתות בשרת proxy תומכים רק בתווים קטנים בדומיינים במאפיין של שם נפוץ (
CN) או במאפיין של שם חלופי של בעלים (subject) (SAN) באישור. אישורים עם אותיות רישיות בדומיינים מוחזרים רק אם הם מוגדרים כאישור הראשי בשרת הפרוקסי של היעד.
המאמרים הבאים
- הגדרת מאזן עומסי רשת קלאסי לשרת proxy (שרת proxy ל-TCP)
- הגדרת מאזן עומסי רשת קלאסי בשרת proxy (שרת proxy ל-SSL)
- הגדרת מאזן עומסי רשת גלובלי חיצוני מסוג Proxy (TCP Proxy)
- הגדרת מאזן עומסי רשת גלובלי חיצוני בשרת proxy (שרת proxy של SSL)
- הגדרת מאזן עומסי רשת אזורי חיצוני בשרת proxy (TCP proxy)
- רישום ביומן ומעקב במאזן עומסי רשת בשרת proxy