Cloud Load Balancing תומך בהעברת תעבורה לשרתי קצה עורפיים חיצוניים מחוץ ל- Cloud de Confiance by S3NS. כדי להגדיר קצה עורפי חיצוני למאזן עומסים, משתמשים במשאב שנקרא קבוצה של נקודות קצה ברשת (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).
רכיבים של מאזן עומסים
בקטע הזה מתוארים הארכיטקטורה של איזון העומסים והמשאבים שנדרשים להגדרת מאזן עומסים עם קצה עורפי חיצוני. מאזן העומסים דורש הגדרה מיוחדת רק לשירות הקצה העורפי. הגדרת הקצה הקדמי זהה לכל מאזן עומסים אחר.
באיורים הבאים מוצגים המשאבים שנדרשים להגדרת מאזן עומסים עם קצה עורפי חיצוני. 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 באינטרנט
קבוצת נקודות קצה ברשת האינטרנט היא משאב שמשמש להגדרת בק-אנד חיצוני למאזן העומסים. יש שני סוגים של 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) מבוססות על שרתי 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. עם זאת, אם אתם מבצעים רזולוציה של שמות דומיין פרטיים מלאים, תצטרכו להגדיר את 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
ממשקי רשת אזוריים (NEGs) תומכים ברזולוציית שמות דומיינים באמצעות Cloud DNS.
אם שרת ה-DNS מחזיר כמה כתובות IP, Envoy מבצע איזון עומסים של התעבורה בין כתובות ה-IP שהוחזרו על סמך אלגוריתם איזון העומסים שהוגדר (סדר סיבובי, בקשה מינימלית וכו'). רשימת נקודות הקצה מתעדכנת מדי פעם על סמך ערך ה-TTL של ה-DNS. אתם יכולים להגדיר מדיניות ניסיון חוזר כדי לחייב את Envoy לנסות להתחבר לכתובת IP אחרת אם אחת מהן נכשלת.
שירות לקצה העורפי
שירותים לקצה העורפי מספקים למאזן העומסים פרטי הגדרה. מאזני עומסים משתמשים במידע בשירות קצה עורפי כדי להפנות תעבורה נכנסת לקצה עורפי אחד או יותר שמצורפים אליו.
כדי להגדיר מאזן עומסים עם קצה עורפי חיצוני, צריך להגדיר את שירות הקצה העורפי עם קצה עורפי של NEG באינטרנט. כשמוסיפים NEG לאינטרנט לשירות backend, חשוב לשים לב לשיקולים הבאים, בהתאם להיקף של ה-NEG:
שירות לקצה העורפי לא יכול להשתמש גם בסוגי בק-אנד אחרים (כמו NEGs אזוריים או קבוצות מופעים) כבק-אנדים.
מספר ה-NEG לכל שירות קצה עורפי
- קבוצות אזוריות של נקודות קצה של רשתות. אפשר להוסיף עד 50 קבוצות NEG לאינטרנט לאותו שירות backend.
מספר נקודות הקצה לכל NEG
- קבוצות אזוריות של נקודות קצה של רשתות. אפשר להוסיף עד 256 נקודות קצה לכל NEG לאותו שירות backend.
קבוצות אזוריות של נקודות קצה ברשת לא תומכות במצבי איזון עומסים, כמו קצב, חיבור או ניצול. כל נקודות הקצה של כל קבוצות ה-NEG שמצורפות לשירות קצה עורפי מאוגדות לקבוצה אחת. איזון העומסים של תעבורת הנתונים בין נקודות הקצה האלה מתבצע באמצעות אלגוריתמים של איזון עומסים ב-Envoy. במאמר regional backend service API documentation (מאמרי העזרה בנושא API של שירות קצה עורפי אזורי) מופיעים האלגוריתמים הנתמכים של מדיניות איזון העומסים.
localityLbPolicyבדיקות תקינות
- קבוצות אזוריות של נקודות קצה של רשתות. מאזן העומסים משתמש בבדיקות תקינות מבוזרות של Envoy.
סכמת איזון העומסים של שירות הבק-אנד צריכה להיות זהה לסכמה שנדרשת על ידי מאזן העומסים שאתם פורסים. לרשימה המלאה של שירותי 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), מאזן עומסי רשת אזורי חיצוני בשרת proxy ומאזן עומסי רשת אזורי פנימי בשרת proxy. בדיקות תקינות הן אופציונליות. במאזני העומסים האלה, בדיקות תקינות מקורן ברשת המשנה של ה-proxy בלבד, ואז הן עוברות תרגום NAT (באמצעות Cloud NAT) לכתובות IP שהוקצו מראש או לכתובות IP של NAT שהוקצו באופן אוטומטי. פרטים נוספים זמינים במאמר בנושא קבוצות אזוריות של נקודות קצה ברשת: שימוש בשער 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.
השימוש ב-Cloud NAT כרוך בחיובים על תעבורת משתמשים ועל תעבורת בדיקות תקינות. פרטים על אופן התמחור של אינטרנט אזורי NEG מופיעים במאמר תמחור של אינטרנט אזורי NEG.
שערי NAT שמוגדרים ברשתות משנה של שרת proxy בלבד לא תומכים ברישום ביומן ובמעקב. כלומר, הדגלים --enable-logging ו---log-filter לא נתמכים.
אימות בקשות לשרת קצה עורפי חיצוני
הקטע הזה רלוונטי רק למאזני עומסים של אפליקציות.
כדי לאמת בקשות שנשלחות אל ה-Backend החיצוני שלכם, אתם יכולים לבצע אחת מהפעולות הבאות:
מגדירים כותרת מותאמת אישית כדי לציין שהבקשה הגיעה ממאזן עומסים Cloud de Confiance באמצעות כותרת בקשה מותאמת אישית. לדוגמה, אפשר להשתמש ב-16 או יותר בייטים אקראיים קריפטוגרפיים כמפתח משותף.
ההטמעה של טרנספורמציות מותאמות אישית של כותרות תלויה בסוג מאזן העומסים שבו אתם משתמשים:
מאזן עומסים חיצוני אזורי של אפליקציות (ALB) ומאזן עומסים פנימי אזורי של אפליקציות (ALB). אפשר להגדיר המרות של כותרות מותאמות אישית רק במיפוי כתובות ה-URL.
במאזני העומסים האלה שמבוססים על Envoy,
Hostו-authorityהן מילות מפתח מיוחדות ששמורות על ידי Cloud de Confiance. אי אפשר לשנות את הכותרות האלה במאזני העומסים האלה. במקום זאת, מומלץ ליצור כותרות מותאמות אישית אחרות (לדוגמה,MyHost) כדי לא להפריע לשמות הכותרות השמורים.
מפעילים את IAP ומוודאים ש-JWT החתום בכותרת הבקשה חתום על ידי Google, ושהתביעה
aud(קהל) מכילה את מספר הפרויקט שבו מוגדר מאזן העומסים.
יומנים
בקשות שמועברות דרך שרת proxy לקצה עורפי חיצוני נרשמות ביומן של Cloud Logging באותו אופן שבו נרשמות בקשות לקצה עורפי אחר.
למידע נוסף, קראו את המאמרים הבאים:
- רישום ביומן של מאזן עומסים חיצוני אזורי של אפליקציות (ALB)
- רישום ביומן של מאזן עומסים פנימי אזורי של אפליקציות
- רישום ביומן של מאזן עומסי רשת לשרת proxy
מגבלות
- בקטע שירות קצה עורפי מפורטות מגבלות שקשורות להגדרת NEGs באינטרנט כקצה עורפי.
- כשמשנים מאזן עומסים כדי לשנות את ה-backend מ-NEG באינטרנט לכל סוג אחר של backend, או כדי לשנות את ה-backend מכל סוג אחר של backend ל-NEG באינטרנט, האפליקציה חווה השבתה זמנית של כ-30 עד 90 שניות.
- בקטע שער Cloud NAT מפורטות המגבלות שקשורות לשערי NAT שהוגדרו ברשתות משנה שמוגדרות רק כפרוקסי.
מכסות ומגבלות
מידע על מכסות ומגבלות זמין בטבלת המכסות של קצה עורפי של NEG ובטבלת המכסות של נקודות קצה לכל NEG.
תמחור
תעבורת נתונים יוצאת (egress) לנקודות קצה חיצוניות של NEG באינטרנט מחויבת לפי תעריפי תעבורת נתונים יוצאת (egress) באינטרנט של מסלול פרימיום לרשתות. המיקום של הלקוח הוא המיקום של המקור, והמיקום של נקודת הקצה הציבורית הוא המיקום של היעד.
אם הגדרתם שער Cloud NAT למיפוי של תת-רשת של שרת proxy בלבד של מאזן עומסים אזורי מבוסס Envoy, תחויבו על השימוש ב-Cloud NAT. שערי Cloud NAT שהוקצו למאזני עומסים מחויבים לפי שעה, כמו רשת עם יותר מ-32 מכונות וירטואליות. לפרטים, ראו תמחור של Cloud NAT.
מידע נוסף זמין במאמר תמחור של Cloud Load Balancing.