Cloud Load Balancing תומך בהעברת תעבורה לשרתי קצה עורפיים חיצוניים מחוץ ל- Cloud de Confiance by S3NS. כדי להגדיר קצה עורפי חיצוני למאזן עומסים, משתמשים במשאב שנקרא קבוצה של נקודות קצה (endpoint) ברשת האינטרנט (NEG).
אפשר להשתמש בסוג הפריסה הזה כשרוצים להציג תוכן משרת קצה עורפי חיצוני, אבל רוצים שמאזן העומסים יהיה חזית האתר. Cloud de Confiance כך תוכלו:
- שימוש בתשתית Google Edge לסיום החיבורים של המשתמשים.
- מפנים את החיבורים אל ה-Backend החיצוני.
- העברת תנועה לנקודת הקצה הציבורית שלכם ברשת הפרטית של Google, מה שמשפר את המהימנות ויכול להפחית את זמן האחזור בין הלקוח לשרת.
בקטעים הבאים מוסבר איך משתמשים בקצה עורפי חיצוני עם Cloud Load Balancing. אם אתם רוצים להשתמש בקצה עורפי חיצוני עם Cloud Service Mesh, תוכלו לעיין במאמר Cloud Service Mesh עם קבוצות של נקודות קצה ברשת האינטרנט.
הסברים על המונחים
לפעמים משתמשים במונחים הבאים לסירוגין כי יש להם משמעות זהה או דומה:
- קצה עורפי חיצוני: קצה עורפי שנמצא מחוץ ל- Cloud de Confiance by S3NS ואפשר להגיע אליו דרך האינטרנט. נקודת הקצה ב-NEG באינטרנט.
- קבוצת נקודות קצה ברשת (NEG) באינטרנט: משאב ה-API שמשמש לציון קצה עורפי חיצוני. Cloud de Confiance by S3NS
- נקודת קצה חיצונית: זהה לעורף חיצוני.
במסמך הזה אנחנו משתמשים במונח קצה עורפי חיצוני, אלא אם אנחנו מתייחסים למשאב ה-API של קבוצת נקודות קצה ברשת האינטרנט (NEG).
רכיבים של מאזן עומסים
בקטע הזה מתוארת ארכיטקטורת איזון העומסים והמשאבים שנדרשים להגדרת מאזן עומסים עם קצה עורפי חיצוני. מאזן העומסים דורש הגדרה מיוחדת רק לשירות הקצה העורפי. הגדרת ה-frontend זהה להגדרות של כל מאזן עומסים אחר.
באיורים הבאים מוצגים המשאבים של Cloud de Confiance שנדרשים להגדרת מאזן עומסים עם קצה עורפי חיצוני.
חיצוני אזורי
באיור הזה מוצגים Cloud de Confiance המשאבים שנדרשים להגדרת מאזן עומסים אזורי חיצוני של אפליקציות עם קצה עורפי חיצוני.
באיור הזה מוצגים Cloud de Confiance המשאבים שנדרשים להגדרה של מאזן עומסי רשת אזורי חיצוני בשרת proxy עם קצה עורפי חיצוני.
פנימי אזורי
באיור הזה מוצגים Cloud de Confiance המשאבים שנדרשים להגדרת מאזן עומסים פנימי אזורי של אפליקציות עם בק-אנד חיצוני.
באיור הזה מוצגים Cloud de Confiance המשאבים שנדרשים להגדרת מאזן עומסי רשת אזורי פנימי בשרת proxy עם קצה עורפי חיצוני.
אפשר להשתמש ב-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) מבוססות על שרתי proxy מנוהלים של Envoy. לכל NEG יכולים להיות כמה נקודות קצה, ושירות לקצה העורפי יכול לכלול כמה NEGs באינטרנט.
לתעבורת נתונים יוצאת, אתם יכולים להגדיר שערים של Cloud NAT כדי להגדיר את כתובות ה-IP של המקור. אפשר גם לנתב תנועה באמצעות נתיבים שנלמדו ברשת ה-VPC. למרות ש-Cloud NAT לא נדרש לשיטת הניתוב הזו, הוא נתמך.
בטבלה הבאה מוסבר איך מאזני עומסים שונים תומכים ב-NEGs אזוריים באינטרנט.
| מאזני עומסים | סוג נקודת הקצה | הגדרת נקודת קצה | היקף | בדיקות תקינות | אימות אישור השרת |
|---|---|---|---|---|---|
|
|
שם דומיין שמוגדר במלואו שאפשר לפתור אותו באופן ציבורי או פרטי, ויציאה אופציונלית. לדוגמה,
צריך להיות אפשר לפתור את שם הדומיין באמצעות Cloud DNS. אפשר להוסיף עד 256 נקודות קצה לכל NEG. |
אזורי | בדיקות תקינות מבוזרות של Envoy | לא אומת. מגדירים TLS מאומת בשרת העורפי כדי לבצע אימות אישורים. |
|
רק כתובת IP שאפשר לנתב באופן ציבורי ויציאה אופציונלית. לדוגמה,
כתובת ה-IP לא יכולה להיות כתובת RFC 1918. אפשר להוסיף עד 256 נקודות קצה לכל NEG. |
לא אומת. מגדירים TLS מאומת בשרת העורפי כדי לבצע אימות אישורים. |
* כשמשתמשים ב-NEGs אזוריים באינטרנט, צריך לציין יציאה. אפשר לציין יציאת ברירת מחדל כשיוצרים את קבוצת נקודות הקצה ברשת, או לציין יציאה בכל פעם שמוסיפים נקודת קצה לקבוצה, או לעשות את שתי הפעולות. אם לא מציינים יציאה כשמוסיפים נקודת קצה, המערכת משתמשת ביציאה שמוגדרת כברירת המחדל של ה-NEG.
פענוח 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
קבוצות אזוריות של נקודות קצה ברשת תומכות ברזולוציה של שמות דומיינים באמצעות Cloud DNS.
אם שרת ה-DNS מחזיר כמה כתובות IP, Envoy מבצע איזון עומסים של התעבורה בין כתובות ה-IP שהוחזרו על סמך אלגוריתם איזון העומסים שהוגדר (round robin, בקשה מינימלית וכו'). רשימת נקודות הקצה מתעדכנת מדי פעם על סמך DNS TTL. אתם יכולים להגדיר מדיניות ניסיון חוזר כדי לחייב את Envoy לנסות להתחבר לכתובת IP אחרת אם אחת מהן נכשלת.
שירות לקצה העורפי
שירותים לקצה העורפי מספקים למאזן העומסים פרטי הגדרה. מאזני עומסים משתמשים במידע בשירות קצה עורפי כדי להפנות תעבורה נכנסת לקצה עורפי מצורף אחד או יותר.
כדי להגדיר מאזן עומסים עם קצה עורפי חיצוני, צריך להגדיר את שירות הקצה העורפי עם קצה עורפי מסוג NEG באינטרנט. כשמוסיפים NEG לאינטרנט לשירות backend, צריך להתייחס לשיקולים הבאים, בהתאם להיקף של ה-NEG:
שירות לקצה העורפי לא יכול להשתמש גם בסוגי בק-אנד אחרים (כמו NEGs אזוריים או קבוצות מכונות) כ-backends.
מספר ה-NEG לכל שירות קצה עורפי
- קבוצות NEG אזוריות. אפשר להוסיף עד 50 קבוצות NEG לאינטרנט לאותו שירות backend.
מספר נקודות הקצה לכל NEG
- קבוצות NEG אזוריות. אפשר להוסיף עד 256 נקודות קצה לכל NEG לאותו שירות backend.
קבוצות אזוריות של נקודות קצה ברשת לא תומכות במצבי איזון עומסים, כמו קצב, חיבור או ניצול. כל נקודות הקצה של כל קבוצות ה-NEG שמצורפות לשירות backend מאוגדות לקבוצה אחת. איזון העומסים של התעבורה בין נקודות הקצה האלה מתבצע באמצעות אלגוריתמים של איזון עומסים ב-Envoy. במאמר Regional backend service API documentation (מאמרי העזרה בנושא API של שירות קצה עורפי אזורי) מופיע מידע על אלגוריתמים של מדיניות איזון עומסים שנתמכים ב-
localityLbPolicy.בדיקות תקינות
- קבוצות 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.
בדיקות תקינות
ההגדרה של בדיקת תקינות משתנה בהתאם לסוג מאזן העומסים:
מאזן עומסים חיצוני אזורי של אפליקציות (ALB), מאזן עומסים פנימי אזורי של אפליקציות (ALB), מאזן עומסי רשת אזורי חיצוני בשרת proxy ומאזן עומסי רשת אזורי פנימי בשרת proxy. בדיקות תקינות הן אופציונליות. במאזני העומסים האלה, בדיקות תקינות מקורן ברשת המשנה של ה-proxy בלבד, ואז הן עוברות תרגום NAT (באמצעות Cloud NAT) לכתובות IP שהוקצו מראש או לכתובות IP של NAT שהוקצו באופן אוטומטי. פרטים נוספים זמינים במאמר בנושא NEGs אזוריים: שימוש בשער Cloud NAT.
בדיקות תקינות מבוזרות של Envoy נוצרות באמצעות אותם תהליכים של מסוףCloud de Confiance , ה-CLI של gcloud ו-API כמו בדיקות תקינות מרכזיות. לא נדרשת הגדרה נוספת.
נקודות חשובות:
- אין תמיכה בבדיקות תקינות של gRPC.
- אין תמיכה בבדיקות תקינות עם פרוטוקול PROXY גרסה 1 מופעל.
מישור הנתונים של Envoy מטפל בבדיקות תקינות, ולכן אי אפשר להשתמש בCloud de Confiance מסוף, ב-API או ב-CLI של gcloud כדי לבדוק את סטטוס התקינות של נקודות הקצה החיצוניות האלה. ב-NEGs היברידיים עם מאזני עומסים מבוססי Envoy, במסוף מוצג סטטוס בדיקת התקינות כ- Cloud de Confiance
N/A. זה תקין.כל שרת Envoy proxy שמוקצה לרשת המשנה proxy-only באזור ברשת ה-VPC מתחיל בדיקות תקינות באופן עצמאי. לכן, יכול להיות שתראו עלייה בתעבורת הנתונים ברשת בגלל בדיקות תקינות. העלייה תלויה במספר שרתי ה-proxy של Envoy שהוקצו לרשת ה-VPC באזור, בכמות התנועה שמתקבלת בשרתי ה-proxy האלה ובמספר נקודות הקצה שכל שרת proxy של Envoy צריך לבצע בדיקת תקינות לגביהן. בתרחיש הגרוע ביותר, תנועת הרשת בגלל בדיקות תקינות גדלה בקצב ריבועי
(O(n^2)).יומני בדיקות התקינות של בדיקות תקינות מבוזרות של Envoy לא כוללים מצבי תקינות מפורטים. פרטים על מה שמתועד ביומן מופיעים במאמר בנושא תיעוד ביומן של בדיקת תקינות. כדי לפתור בעיות בקישוריות משרתי proxy של Envoy לנקודות הקצה של NEG, כדאי גם לבדוק את היומנים של מאזן העומסים הרלוונטי.
הפעלת העורף החיצוני כדי לקבל בקשות
מגדירים את הקצה העורפי החיצוני כך שיאפשר תעבורת נתונים מ- Cloud de Confiance.
NEGs אזוריים: שימוש בשער Cloud NAT
אם אתם משתמשים ב-NEG אזורי לאינטרנט, קודם צריך להגדיר שער Cloud NAT כדי להקצות קבוצה של טווחי כתובות IP שממנה אמורה להגיע תנועת נתונים. Cloud de Confiance
נקודת הקצה של השער צריכה להיות מסוג ENDPOINT_TYPE_MANAGED_PROXY_LB.
אפשר להגדיר את שער Cloud NAT כך שיקצה באופן אוטומטי כתובות IP חיצוניות על סמך הביקוש, או שישתמש בקבוצה של כתובות IP חיצוניות שהוזמנו מראש באופן ידני.
כתובות IP שהוקצו באופן אוטומטי
אם בסביבת ה-Backend החיצונית שלכם לא נדרש להוסיף לרשימת ההיתרים כתובות IP ספציפיות שיכולות לשלוח תנועה אל ה-Backend החיצוני, אתם יכולים להשתמש בכתובות IP שמוקצות באופן אוטומטי. Cloud de Confiance
כתובות IP שהוקצו באופן ידני
משתמשים בכתובות IP שהוקצו באופן ידני רק אם בסביבת ה-Backend החיצונית צריך להוסיף כתובות IP ספציפיות לרשימת ההיתרים. Cloud de Confiance מכיוון שכל Envoy שמוקצה לרשת המשנה של ה-proxy צורך כתובת IP שלמה, צריך לוודא שמאגר כתובות ה-IP השמורות גדול מספיק כדי להכיל את כל ה-Envoys.
אם נתקלים בבעיות קישוריות בהיקף גדול, כדאי לבדוק אם הגעתם למגבלות של Cloud NAT. כברירת מחדל, אתם מוגבלים ל-50 כתובות IP של NAT שהוקצו באופן ידני לכל שער.
יש תמיכה בהקצאה דינמית של יציאות ל-NEGs אזוריים באינטרנט. כתובות IP יכולות להיות משותפות על ידי שרתי proxy, ולכן נעשה בהן שימוש מלא.
ההגדרה הזו של Cloud NAT חלה על כל רשת המשנה של proxy בלבד. תעבורת האינטרנט שמשויכת לכל מאזני העומסים האזוריים שמבוססים על Envoy באזור חולקת את אותו שער NAT.
שערי NAT שהוגדרו ברשתות משנה שמוגדרות רק כפרוקסי לא תומכים ברישום ביומן ובמעקב. כלומר, הדגלים --enable-logging ו---log-filter לא נתמכים.
אימות בקשות לשרת קצה עורפי חיצוני
הקטע הזה רלוונטי רק למאזני עומסים של אפליקציות.
כדי לאמת בקשות שנשלחות לשרת העורפי החיצוני שלכם, אתם יכולים לבצע אחת מהפעולות הבאות:
מגדירים כותרת מותאמת אישית כדי לציין שהבקשה הגיעה מ Cloud de Confiance מאזן עומסים באמצעות כותרת בקשה מותאמת אישית. לדוגמה, אפשר להשתמש ב-16 או יותר בייטים אקראיים קריפטוגרפיים כמפתח משותף.
ההטמעה של טרנספורמציות מותאמות אישית של כותרות תלויה בסוג מאזן העומסים שבו אתם משתמשים:
מאזן עומסים חיצוני אזורי של אפליקציות (ALB) ומאזן עומסים פנימי אזורי של אפליקציות (ALB). אפשר להגדיר שינויים בהתאמה אישית של כותרות רק במיפוי כתובות ה-URL.
במאזני העומסים האלה שמבוססים על Envoy,
Hostו-authorityהן מילות מפתח מיוחדות ששמורות על ידי Cloud de Confiance. אי אפשר לשנות את הכותרות האלה במאזני העומסים האלה. במקום זאת, מומלץ ליצור כותרות מותאמות אישית אחרות (לדוגמה,MyHost) כדי לא להפריע לשמות הכותרות השמורים.
מפעילים את IAP ומוודאים ש-JWT החתום בכותרת הבקשה חתום על ידי Google, ושהתביעה
aud(קהל) מכילה את מספר הפרויקט שבו מוגדר מאזן העומסים.
יומנים
בקשות שמועברות דרך פרוקסי לקצה עורפי חיצוני נרשמות ביומן של Cloud Logging באותו אופן שבו נרשמות בקשות לקצה עורפי אחר.
למידע נוסף, קראו את המאמרים הבאים:
- רישום נתונים ביומן של מאזן עומסים חיצוני אזורי של אפליקציות (ALB)
- רישום נתונים ביומן של מאזן עומסים פנימי אזורי של אפליקציות (ALB)
- רישום נתונים ביומן של מאזן עומסי רשת לשרת proxy
מגבלות
- בקטע בנושא שירות לקצה העורפי מפורטות מגבלות שקשורות להגדרת NEGs באינטרנט כ-backends.
- כשמשנים את מאזן העומסים כדי לשנות את ה-backend מ-NEG של אינטרנט לכל סוג אחר של backend, או כדי לשנות את ה-backend מכל סוג אחר של backend ל-NEG של אינטרנט, האפליקציה מושבתת באופן זמני למשך כ-30 עד 90 שניות.
- בקטע שער Cloud NAT מפורטות מגבלות שקשורות לשערי NAT שהוגדרו ברשתות משנה שמוגדרות רק כפרוקסי.
מכסות ומגבלות
מידע על מכסות ומגבלות זמין בטבלת המכסות של קצה עורפי של NEG ובטבלת המכסות של נקודות קצה לכל NEG.
תמחור
מידע על תעריפי תעבורת נתונים יוצאת (egress) באינטרנט לנקודות קצה של קבוצות NEG באינטרנט זמין במאמר בנושא תמחור של מסלול פרימיום.
אם הגדרתם שער Cloud NAT למיפוי של תת-רשת של שרת proxy בלבד של מאזן עומסים אזורי מבוסס Envoy, כדאי לעיין במאמר תמחור של רשתות: Cloud NAT.
למידע נוסף על התמחור של Cloud Load Balancing ועל חיובים על קבוצות אזוריות של נקודות קצה ברשת (NEG), ראו תמחור רשת: Cloud Load Balancing.