סקירה כללית על קבוצות של נקודות קצה ברשת האינטרנט

‫Cloud Load Balancing תומך בהעברת תעבורה לשרתי קצה עורפיים חיצוניים מחוץ ל- Google Cloud. כדי להגדיר קצה עורפי חיצוני למאזן עומסים, משתמשים במשאב שנקרא קבוצה של נקודות קצה ברשת (NEG) באינטרנט.

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

  • משתמשים בתשתית Google Edge כדי לסיים את החיבורים של המשתמשים.
  • מפנים את החיבורים אל ה-Backend החיצוני.
  • העברת תנועה לנקודת הקצה הציבורית שלכם ברשת הפרטית של Google, מה שמשפר את המהימנות ויכול להפחית את זמן האחזור בין הלקוח לשרת.
  • באמצעות מאזני עומסים גלובליים, אפשר להשתמש ב-Cloud CDN (רשת להעברת תוכן) כדי לשמור במטמון תוכן עבור הקצה העורפי החיצוני.

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

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

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

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

הסברים על המונחים

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

  • קצה עורפי חיצוני: קצה עורפי שנמצא מחוץ ל- Google Cloud וניתן להגיע אליו דרך האינטרנט. נקודת הקצה ב-NEG באינטרנט.
  • מקור בהתאמה אישית: זהה לקצה עורפי חיצוני. ב-CDN, המונח origin הוא מונח מקובל בתעשייה לציון שרת עורפי שמציג תוכן אינטרנט.
  • קבוצת נקודות קצה ברשת (NEG) באינטרנט: משאב ה-API שמשמש לציון קצה עורפי חיצוני. Google Cloud
  • נקודת קצה חיצונית: זהה לקצה עורפי חיצוני.

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

רכיבים של מאזן עומסים

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

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

חיצונית גלובלית

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

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

חיצוני אזורי

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

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

פנימי אזורי

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

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

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

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

אפשר להשתמש ב-NEGs באינטרנט רק במסלול שירותי הרשת Premium.

הגדרות הקצה הקדמי

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

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

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

NEG באינטרנט

קבוצת נקודות קצה ברשת האינטרנט היא משאב שמשמש להגדרת בק-אנד חיצוני למאזן העומסים. יש שני סוגים של NEGs באינטרנט: NEG גלובלי באינטרנט ו-NEG אזורי באינטרנט. ההבדלים ביניהם הם בהיקף (גלובלי לעומת אזורי) ובהתנהגות. אפשר להגיע לשרת העורפי החיצוני שאליו מפנה קבוצת נקודות קצה ברשת (NEG) גלובלית באינטרנט רק דרך האינטרנט, ולא דרך Cloud VPN או Cloud Interconnect. אם ה-backend החיצוני מפנה אל Google API או אל שירות של Google, צריך להיות אפשר להגיע אל השירות דרך יציאת TCP מספר 80 או 443 באמצעות הפרוטוקול HTTP, HTTPS או HTTP/2.

יש שתי דרכים להגדיר את נקודת הקצה החיצונית שאליה מתייחס ה-NEG: INTERNET_FQDN_PORT או INTERNET_IP_PORT. אם בוחרים בפורמט INTERNET_IP_PORT, אפשר להשתמש רק בכתובת IP שאפשר לנתב באינטרנט הציבורי. אם בוחרים בפורמט INTERNET_FQDN_PORT, אפשר לפתור את ה-FQDN לכתובת IP שאפשר לנתב באינטרנט הציבורי או לכתובת IP פרטית, בהתאם להיקף נקודת הקצה: אזורי או גלובלי.

קבוצות NEGs גלובליות באינטרנט מבוססות על טכנולוגיות של ממשק הקצה של Google‏ (GFE). הם משתמשים בקבוצה קבועה של כתובות IP קבועות לתעבורת נתונים יוצאת (egress) לכל הלקוחות. הם תומכים רק בנקודת קצה אחת לכל NEG וב-NEG אחד לאינטרנט לכל שירות קצה עורפי.

בטבלה הבאה מוסבר איך מאזני עומסים שונים תומכים ב-NEGs גלובליים באינטרנט.

מאזני עומסים סוג נקודת הקצה הגדרה של נקודת קצה היקף בדיקות תקינות אימות אישור השרת
  • מאזן עומסים גלובלי חיצוני של אפליקציות (ALB)
  • מאזן עומסים קלאסי של אפליקציות (ALB)

INTERNET_FQDN_PORT

שם דומיין שמוגדר במלואו וניתן לפתרון באופן ציבורי, ויציאה אופציונלית. לדוגמה, backend.example.com:443†.

שם הדומיין צריך להיות ניתן לתרגום על ידי תשתית ה-DNS הציבורי של Google.

מותר להשתמש רק בנקודת קצה אחת לכל NEG.

 עולמי לא נתמך תמיד מאומתים מול אישורי CA ציבוריים.

INTERNET_IP_PORT

כתובת IP שאפשר לנתב באופן ציבורי ויציאה אופציונלית. לדוגמה, 8.8.8.8:4431.

כתובת ה-IP לא יכולה להיות כתובת RFC 1918.

מותר להשתמש רק בנקודת קצה אחת לכל NEG.

 לא אומת.

‫† אם לא מציינים יציאה כשמוסיפים את נקודת הקצה, נעשה שימוש ביציאת ברירת המחדל של ה-NEG. אם לא ציינתם יציאה שמוגדרת כברירת מחדל ל-NEG, נעשה שימוש ביציאה המוכרת של פרוטוקול ה-Backend (80 ל-HTTP ו-443 ל-HTTPS ול-HTTP/2).

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

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

בטבלה הבאה מוסבר איך מאזני עומסים שונים תומכים ב-NEGs אזוריים באינטרנט.

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

INTERNET_FQDN_PORT

שם דומיין שמוגדר במלואו שאפשר לפתור אותו באופן ציבורי או פרטי, ויציאה אופציונלית. לדוגמה, backend.example.com:443*.

תהליך רזולוציית שם הדומיין מתבצע לפי תהליך סדר רזולוציית השמות ב-Cloud DNS.

אפשר להוסיף עד 256 נקודות קצה לכל NEG.

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

INTERNET_IP_PORT

רק כתובת IP שאפשר לנתב באופן ציבורי ויציאה אופציונלית. לדוגמה, 8.8.8.8:4432.

כתובת ה-IP לא יכולה להיות כתובת RFC 1918.

אפשר להוסיף עד 256 נקודות קצה לכל NEG.

 לא אומת. מגדירים TLS מאומת בשרת העורפי כדי לבצע אימות אישורים.

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

פענוח DNS לנקודות קצה אזוריות של INTERNET_FQDN_PORT

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

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

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

המרת כתובת IP לנקודות קצה גלובליות של INTERNET_FQDN_PORT

כשנקודת קצה INTERNET_FQDN_PORT מפנה לרשומת DNS שמחזירה כמה כתובות IP, כתובת ה-IP מתפרשת באופן הבא:

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

  • מאזן העומסים מנסה להתחבר לכתובת ה-IP הראשונה בתגובת ה-DNS. אם אי אפשר להגיע לכתובת ה-IP הזו, מאזן העומסים מחזיר תגובת HTTP 502 (Bad Gateway). זה נכון גם אם יש כתובות IP אחרות בתגובת ה-DNS.

למידע נוסף על טווחי כתובות ה-IP והמיקומים שבהם נעשה שימוש בתשתית של פותר ה-DNS של Google, אפשר לעיין במסמכי התיעוד של Google Public DNS. אי אפשר להשתמש בשמות שלא ניתן לפענח באמצעות מערכת ה-DNS הציבורית כבקצה עורפי חיצוני.

המרת כתובת IP לנקודות קצה אזוריות INTERNET_FQDN_PORT

‫NEGs אזוריים באינטרנט תומכים בפענוח של שמות דומיינים באמצעות Cloud DNS ו-Google Public DNS.

  • כדי ליצור פענוח DNS ציבורי, Cloud DNS מעביר תעבורה לשרתי ה-DNS הציבוריים של Google.
  • ב-Cloud DNS, שם הדומיין צריך להיות אחד מהבאים:
    • מתארח ב-Cloud DNS
    • אפשר לפענח אותם באמצעות העברת DNS מ-Cloud DNS לשרת DNS מקומי
    • אפשר לפתור את הבעיה באמצעות קישור בין רשתות שכנות (peering) של DNS אם אתם מפנים לתחום DNS פרטי ברשת VPC אחרת.

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

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

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

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

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

  • מספר ה-NEG לכל שירות קצה עורפי

    • הגדרות שליליות גלובליות. אפשר להוסיף רק קצה עורפי אחד של NEG באינטרנט לשירות קצה עורפי.

  • מספר נקודות הקצה לכל NEG

    • הגדרות שליליות גלובליות. אפשר להוסיף רק נקודת קצה אחת ל-NEG באינטרנט.

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

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

  • בדיקות תקינות

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

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

  • הפרוטוקול של השירות לקצה העורפי חייב להיות אחד מהערכים HTTP, HTTPS או HTTP2.

    מומלץ מאוד להשתמש ב-HTTPS או ב-HTTP/2 כפרוטוקול כשמגדירים שירות לקצה העורפי עם NEG באינטרנט, כדי שהתקשורת בין מאזן העומסים לבק-אנד תהיה מוצפנת ומאומתת כשהיא עוברת באינטרנט הציבורי.

  • אימות של אישור השרת

    אימות אישור השרת תלוי בסוג נקודת הקצה (INTERNET_FQDN_PORT או INTERNET_IP_PORT) ובהיקף נקודת הקצה: אזורית או גלובלית.

    • הגדרות שליליות גלובליות. מאזן העומסים מאמת את אישור השרת של INTERNET_FQDN_PORT.

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

      • האישור נחתם על ידי רשויות אישורים (CA) מוכרות.
      • האישור בתוקף.
      • החתימה באישור תקפה.
      • ה-FQDN שהוגדר תואם לאחד מ-Subject Alternative Names‏ (SAN) באישור.

      אם יוצרים את העורף החיצוני באמצעות נקודת קצה INTERNET_IP_PORT, לא מתבצע אימות של אישור ה-SSL של השרת.

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

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

  • טיפול בתוסף SSL Server Name Indication (SNI)‎

    תוסף SSL Server Name Indication ‏ (SNI) נתמך רק בנקודות קצה של INTERNET_FQDN_PORT. ה-FQDN שהוגדר נשלח ל-SNI ב-client hello במהלך לחיצת היד של SSL בין מאזן העומסים לבין נקודת הקצה החיצונית. ה-SNI לא נשלח כשמשתמשים בנקודת קצה INTERNET_IP_PORT כי אי אפשר להשתמש בכתובות IP מילוליות בשדה HostName של מטען ייעודי (payload) של SNI.

בדיקות תקינות

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

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

    אם לא ניתן להגיע אל השרת העורפי החיצוני או אם לא ניתן לפתור את שם המארח (FQDN) שהוגדר, מאזן העומסים מחזיר תגובת HTTP 502 (Bad Gateway) ללקוחות שלו.

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

    בדיקות תקינות מבוזרות של Envoy נוצרות באמצעות אותם תהליכים של מסוףGoogle Cloud ,‏ ה-CLI של gcloud ו-API כמו בדיקות תקינות מרכזיות. לא נדרשת הגדרה נוספת.

    נקודות חשובות:

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

    • מישור הנתונים של Envoy מטפל בבדיקות תקינות, ולכן אי אפשר להשתמש במסוףGoogle Cloud , ב-API או ב-CLI של gcloud כדי לבדוק את סטטוס התקינות של נקודות הקצה החיצוניות האלה. ב-NEGs היברידיים עם מאזני עומסים מבוססי Envoy, במסוף מוצג סטטוס בדיקת התקינות כ- Google Cloud N/A. זה תקין.

    • כל שרת Envoy proxy שמוקצה לרשת המשנה proxy-only באזור ברשת ה-VPC מתחיל בדיקות תקינות באופן עצמאי. לכן, יכול להיות שתראו עלייה בתעבורת הנתונים ברשת בגלל בדיקות תקינות. הגידול תלוי במספר שרתי ה-proxy של Envoy שהוקצו לרשת ה-VPC באזור, בכמות התנועה שמתקבלת על ידי שרתי ה-proxy האלה ובמספר נקודות הקצה שכל שרת proxy של Envoy צריך לבדוק את תקינותן. בתרחיש הגרוע ביותר, התנועה ברשת בגלל בדיקות תקינות גדלה בקצב ריבועי (O(n^2)).

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

הפעלת העורף החיצוני כדי לקבל בקשות

מגדירים את הקצה העורפי החיצוני כך שיאפשר תעבורת נתונים מ- Google Cloud.

ההליך הזה משתנה בהתאם להיקף של קבוצת ה-NEG: גלובלי או אזורי.

קבוצות NEG גלובליות: רשימת היתרים של כתובות IP ליציאה של Google

אם אתם משתמשים ב-NEG גלובלי באינטרנט, אתם צריכים להוסיף לרשימת ההיתרים את טווחי כתובות ה-IP שבהם Google משתמשת כדי לשלוח בקשות לשרתי קצה עורפיים חיצוניים. כדי לחפש את כתובות ה-IP שצריך להוסיף לרשימת ההיתרים, שולחים שאילתה לרשומת ה-DNS TXT באמצעות כלי כמו _cloud-eoips.googleusercontent.com או nslookup.dig

דוגמה מופיעה במאמר איך מאפשרים לשרת קצה עורפי חיצוני לקבל תנועה מ-Google Cloud.

קבוצות אזוריות של נקודות קצה ברשת (NEGs): שימוש בשער Cloud NAT

אם משתמשים ב-NEG אזורי לאינטרנט, קודם מגדירים שער Cloud NAT כדי להקצות קבוצה של טווחי כתובות IP שממנה אמור להגיע תעבורת Google Cloud .

נקודת הקצה של השער צריכה להיות מסוג ENDPOINT_TYPE_MANAGED_PROXY_LB.

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

  • כתובות IP שהוקצו באופן אוטומטי

    אם בסביבת ה-Backend החיצונית שלכם לא נדרשת הוספה של כתובות IP ספציפיות שיכולות לשלוח תנועה ל-Backend החיצוני לרשימת ההיתרים, אתם יכולים להשתמש בכתובות IP שמוקצות באופן אוטומטי. Google Cloud

  • כתובות IP שהוקצו באופן ידני

    משתמשים בכתובות IP שהוקצו באופן ידני רק אם בסביבת ה-Backend החיצונית צריך להוסיף כתובות IP ספציפיות לרשימת ההיתרים. Google Cloud כל Envoy שמוקצה לרשת המשנה של ה-proxy צורך כתובת IP שלמה, לכן חשוב לוודא שמאגר כתובות ה-IP השמורות גדול מספיק כדי להכיל את כל ה-Envoys.

    אם נתקלים בבעיות קישוריות בהיקף גדול, כדאי לבדוק אם הגעתם למגבלות של Cloud NAT. כברירת מחדל, אתם מוגבלים ל-50 כתובות IP של NAT שהוקצו באופן ידני לכל שער.

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

ההגדרה הזו של Cloud NAT חלה על כל רשת המשנה של proxy בלבד. תעבורת האינטרנט שמשויכת לכל מאזני העומסים האזוריים שמבוססים על Envoy באזור חולקת את אותו שער NAT.

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

שערי NAT שמוגדרים ברשתות משנה של שרת proxy בלבד לא תומכים ברישום ביומן ובמעקב. כלומר, הדגלים --enable-logging ו---log-filter לא נתמכים.

אימות בקשות לשרת קצה עורפי חיצוני

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

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

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

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

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

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

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

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

      במאזני העומסים האלה שמבוססים על Envoy, ‏ Host ו-authority הן מילות מפתח מיוחדות ששמורות על ידי Google Cloud. אי אפשר לשנות את הכותרות האלה במאזני העומסים האלה. במקום זאת, מומלץ ליצור כותרות מותאמות אישית אחרות (לדוגמה, MyHost) כדי לא להפריע לשמות הכותרות השמורים.

  • מפעילים את IAP ומוודאים ש-JWT החתום בכותרת הבקשה חתום על ידי Google, ושהתביעה aud (קהל) מכילה את מספר הפרויקט שבו מוגדר מאזן העומסים.

    שימו לב לנקודות הבאות:

    • אי אפשר להשתמש ב-IAP עם Cloud CDN.
    • אין תמיכה ב-IAP במאזני עומסי רשת לשרת proxy (פנימיים וחיצוניים).
  • הפעלת אימות מקור פרטי, שנותן למאזן עומסים חיצוני של אפליקציות גישה לטווח ארוך לקטגוריה פרטית של Amazon Simple Storage Service‏ (Amazon S3) או למאגרי אובייקטים תואמים אחרים. ‫Cloud CDN (ולכן, אימות מקור פרטי) לא נתמך במאזני עומסים חיצוניים אזוריים של אפליקציות ובמאזני עומסים פנימיים אזוריים של אפליקציות.

יומנים

בקשות שמועברות דרך שרת proxy לקצה עורפי חיצוני נרשמות ביומן של Cloud Logging באותו אופן שבו נרשמות בקשות לקצה עורפי אחר.

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

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

עיבוד כותרות באמצעות קצה עורפי חיצוני

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

מאזני עומסים גלובליים חיצוניים של אפליקציות (ALB) ומאזני עומסים קלאסיים של אפליקציות (ALB)

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

  • חלק מהכותרות אוחדו. אם יש כמה מופעים של אותו מפתח כותרת (לדוגמה, Via), מאזן העומסים משלב את הערכים שלהם לרשימה אחת של ערכים מופרדים בפסיקים עבור מפתח כותרת יחיד. רק כותרות שהערכים שלהן יכולים להיות מיוצגים כרשימה מופרדת בפסיקים מאוחדות. כותרות אחרות, כמו Set-Cookie, אף פעם לא מאוחדות.

  • הכותרות הן באותיות רישיות כשפרוטוקול שירות ה-Backend הוא HTTP או HTTPS:

    • האות הראשונה של מפתח הכותרת וכל אות שאחרי מקף (-) הן אותיות רישיות, כדי לשמור על תאימות ללקוחות HTTP/1.1. לדוגמה, user-agent השתנה ל-User-Agent, ו-content-encoding השתנה ל-Content-Encoding.

    • כותרות מסוימות, כמו Accept-CH (client hints), מומרות כך שיתאימו לייצוג סטנדרטי של אותיות מעורבות.

  • חלק מהכותרות מתווספות, או שערכים מצורפים אליהן. מאזני עומסים חיצוניים של אפליקציות (ALB) תמיד מוסיפים או משנים כותרות מסוימות כמו Via ו-X-Forwarded-For.

מאזני עומסים חיצוניים אזוריים של אפליקציות (ALB) ומאזני עומסים פנימיים אזוריים של אפליקציות (ALB)

אין עיבוד מיוחד של כותרות במאזני עומסים מבוססי Envoy שמשתמשים ב-NEGs באינטרנט. כדי להבין איך Envoy מעבד כותרות בדרך כלל, אפשר לעיין במאמר בנושא שינוי כותרות HTTP.

מגבלות

  • בקטע שירות קצה עורפי מפורטות מגבלות שקשורות להגדרת NEGs באינטרנט כקצה עורפי.
  • כשמשנים מאזן עומסים כדי לשנות את ה-backend מ-NEG באינטרנט לכל סוג אחר של backend, או כדי לשנות את ה-backend מכל סוג אחר של backend ל-NEG באינטרנט, האפליקציה חווה השבתה זמנית של כ-30 עד 90 שניות. לדוגמה, במהלך ההשבתה הזו, לקוחות ששולחים בקשות למאזני עומסים חיצוניים גלובליים של אפליקציות רואים שגיאות 502 עם קוד השגיאה failed_to_connect_to_backend. זו התנהגות צפויה.
  • התכונות המתקדמות הבאות לניהול תעבורה לא נתמכות עם קצה עורפי של global internet NEG:
    • בקשה לשקף את המסך
    • מדיניות ניסיון חוזר
    • מדיניות תנועה (כולל מדיניות מקומית של איזון עומסים, זיקה לסשן וזיהוי חריגות)
  • בקטע שער Cloud NAT מפורטות המגבלות שקשורות לשערי NAT שהוגדרו ברשתות משנה שמוגדרות רק כפרוקסי.

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

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

תמחור

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

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

מידע נוסף זמין במאמר תמחור של Cloud Load Balancing.

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