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

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

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

מצבי פעולה

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

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

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

    בטבלה הבאה מפורטים ההבדלים החשובים בין מצב אזורי למצב חוצה אזורים:

    תכונה מאזן עומסי רשת פנימי אזורי בשרת proxy מאזן עומסי רשת פנימי בשרת proxy בין אזורים
    כתובת ה-IP הווירטואלית (VIP) של מאזן העומסים. מוקצה מרשת משנה באזור ספציפי Google Cloud . מוקצה מרשת משנה באזור ספציפי Google Cloud .

    כתובות VIP מכמה אזורים יכולות לחלוק את אותו שירות גלובלי של קצה עורפי.
    גישת לקוח לא נגיש באופן גלובלי כברירת מחדל.
    אפשר גם להפעיל גישה גלובלית.    		 תמיד נגיש בכל העולם. לקוחות מכל Google Cloud אזור יכולים לשלוח תעבורה למאזן העומסים.
    קצה עורפי עם איזון עומסים שרתי בק-אנד אזוריים.
    מאזן העומסים יכול להפנות תנועה רק לשרתי בק-אנד שנמצאים באותו אזור כמו שרת ה-proxy של מאזן העומסים.    		 שרתי בק-אנד גלובליים.
    מאזן העומסים יכול לשלוח תעבורה לשרתי בק-אנד בכל אזור.
    זמינות גבוהה ומעבר לגיבוי (failover) מעבר אוטומטי לגיבוי (failover) לקצוות עורפיים תקינים באותו אזור. מעבר אוטומטי לגיבוי (failover) למערכות קצה תקינות באותו אזור או באזורים שונים.

זיהוי המצב

המסוף

  1. נכנסים לדף Load balancing במסוף Google Cloud .

    כניסה לדף איזון עומסים

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

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

gcloud

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

gcloud compute forwarding-rules describe FORWARDING_RULE_NAME

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

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

ארכיטקטורה

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

אזורי

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

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

בין אזורים

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

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

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

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

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

מצב מאזן עומסים הערך של הסימון --purpose proxy-only subnet
מאזן עומסי רשת פנימי אזורי בשרת proxy

REGIONAL_MANAGED_PROXY

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

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

GLOBAL_MANAGED_PROXY

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

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

בנוסף:

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

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

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

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

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

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

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

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

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

אזורי forwardingRules

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

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

INTERNAL_MANAGED

תת-רשת ל-Proxy בלבד --purpose:

REGIONAL_MANAGED_PROXY

כתובת IP --purpose:

SHARED_LOADBALANCER_VIP

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

גלובלי globalForwardingRules

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

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

INTERNAL_MANAGED

תת-רשת ל-Proxy בלבד --purpose:

GLOBAL_MANAGED_PROXY

כתובת IP --purpose:

SHARED_LOADBALANCER_VIP

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

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

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

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

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

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

שרתי proxy יעד

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

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

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

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

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

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

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

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

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

שירות לקצה העורפי תומך בסוגי ה-Backend הבאים:

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

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

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

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

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

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

בדיקת תקינות

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

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

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

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

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

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

כללי חומת אש

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

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

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

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

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

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

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

גישת לקוח

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

זיקה לסשן (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.
  • מופע הקצה העורפי או נקודת הקצה שנבחרו צריכים להישאר תקינים. הזיקה לסשן עלולה להיפסק אם המופע או נקודת הקצה שנבחרו נכשלים בבדיקות התקינות.
כל האפשרויות של זיקה לסשן כפופות לדרישות הנוספות הבאות:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מעבר אוטומטי לגיבוי (failover) למערכות קצה תקינות באותו אזור או באזורים אחרים.

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

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

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

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

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

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

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

מגבלות

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

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