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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

NEG באינטרנט

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

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

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

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

קודם כול צריך ליצור אזור (zone) ב-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, אפשר לעיין במסמכי התיעוד של ה-DNS הציבורי של Google. אי אפשר להשתמש בשמות שלא ניתן לפענח על ידי מערכת ה-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 שהוחזרו על סמך אלגוריתם איזון העומסים שהוגדר (round robin, בקשה מינימלית וכו'). רשימת נקודות הקצה מתעדכנת מדי פעם על סמך DNS TTL. אתם יכולים להגדיר מדיניות ניסיון חוזר כדי לחייב את Envoy לנסות להתחבר לכתובת IP אחרת אם אחת מהן נכשלת.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

קבוצות NEGs גלובליות: רשימת היתרים של כתובות 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.

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

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

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

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

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

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

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

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

יומנים

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

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

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

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

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

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

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

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

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

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

• הכותרות הן בפורמט Proper Case כשהפרוטוקול של שירות ה-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 באינטרנט כ-backends.
• כשמשנים את מאזן העומסים כדי לשנות את ה-backend מ-NEG של אינטרנט לכל סוג אחר של backend, או כדי לשנות את ה-backend מכל סוג אחר של backend ל-NEG של אינטרנט, האפליקציה מושבתת באופן זמני למשך כ-30 עד 90 שניות. לדוגמה, במהלך ההשבתה הזו, לקוחות ששולחים בקשות למאזני עומסים חיצוניים גלובליים של אפליקציות רואים שגיאות 502 עם קוד השגיאה failed_to_connect_to_backend. זו התנהגות צפויה.

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

• בקטע שער Cloud NAT מפורטות מגבלות שקשורות לשערי NAT שהוגדרו ברשתות משנה שמוגדרות רק כפרוקסי.

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

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

תמחור

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

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

למידע נוסף על התמחור של Cloud Load Balancing ועל חיובים על קבוצות אזוריות של נקודות קצה ברשת (NEG), ראו תמחור רשת: Cloud Load Balancing.

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

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

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