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

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

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

בתנאי שהגדרתם קצה עורפי שעומד בדרישות בשני אזורים או יותר:

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

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

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

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

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

  • אתם צריכים מאזן עומסים ברמה 4 עם ביצועים גבוהים להעברת תנועה של TCP,‏ UDP,‏ ESP,‏ GRE,‏ ICMP ו-ICMPv6. מאזן העומסים יכול לטפל בתנועה של IPv4 ו-IPv6.

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

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

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

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

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

תכונות עיקריות

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

זמינות גבוהה כחלק מהתכנון

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

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

מומלץ לפרוס את השרתים העורפיים בשלושה Google Cloud אזורים לפחות כדי להבטיח עמידות להפסקות חשמל אזוריות, גם אם מותר להגדיר את כל השרתים העורפיים באזור Google Cloud אחד.

זמן אחזור ואיזון עומסים

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

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

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

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

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

ארכיטקטורה

בתרשים הבא מוצג מאזן עומסי רשת חיצוני גלובלי להעברת סיגנל ללא שינוי שמפיץ תנועה אל קצה העורף (backend) בכמה Google Cloud אזורים. כשמאזן העומסים נוצר, Google Cloud מקצה לו שתי כתובות IP חיצוניות גלובליות מסוג Anycast, שמוגשות על ידי תשתית נפרדת ומבודדת של מישור הבקרה ומישור הנתונים (שנקראות גם קבוצות זמינות, AG0 ו-AG1).

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

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

מאזן העומסים מורכב מרכיבי ההגדרה הבאים.

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

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

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

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

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

החזרה ישירה לשרת

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

ניתוב מקומי לכתובת ה-IP של מאזן העומסים

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

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

כתובות IP של חבילות בקשה וחבילות החזרה

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

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

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

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

  • האזנה (binding) לכתובות ה-IP של כלל ההעברה של מאזן העומסים או לכל כתובת IP (0.0.0.0 או ::)
  • אם הפרוטוקול של כלל ההעברה במאזן העומסים תומך ביציאות, צריך להאזין (להתחבר) ליציאה שכלולה בכלל ההעברה במאזן העומסים.

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

  • פרוטוקול TCP הוא פרוטוקול מבוסס-חיבור, ולכן מכונות וירטואליות בעורף המערכת צריכות להשיב עם חבילות שכתובות ה-IP של המקור שלהן תואמות לכתובת ה-IP של היעד של חבילת הבקשה, כדי שהלקוח יוכל לשייך את חבילות התגובה לחיבור ה-TCP המתאים.
  • פרוטוקולים UDP,‏ ESP,‏ GRE,‏ ICMP ו-ICMPv6 הם פרוטוקולים ללא חיבור. מכונות וירטואליות בעורף יכולות לשלוח חבילות תגובה שכתובות ה-IP של המקור שלהן תואמות לכתובת ה-IP של כלל ההעברה או לכל כתובת IP חיצונית שהוקצתה למכונה הווירטואלית. מבחינה מעשית, רוב הלקוחות מצפים שהתגובה תגיע מאותה כתובת IP שאליה הם שלחו חבילות.

בטבלה הבאה מפורטות כתובות ה-IP של המקור והיעד של חבילות התגובה:

סוג תעבורה מקור יעד
TCP היעד של מנת המידע ששולחת את הבקשה המקור של חבילת הבקשה
‫UDP,‏ ESP,‏ GRE,‏ ICMP ו-ICMPv6 ברוב תרחישי השימוש, היעד של חבילת הבקשה1 המקור של חבילת הבקשה

‫1 כשמכונה וירטואלית כוללת כתובת IP חיצונית או כשמשתמשים ב-Cloud NAT, אפשר גם להגדיר את כתובת ה-IP של המקור של חבילת התגובה לכתובת ה-IPv4 הפנימית הראשית של כרטיס ממשק הרשת של המכונה הווירטואלית. Google Cloud או ש-Cloud NAT משנה את כתובת ה-IP של המקור של חבילת התגובה לכתובת ה-IPv4 החיצונית של כרטיס ממשק הרשת או לכתובת IPv4 חיצונית של Cloud NAT, כדי לשלוח את חבילת התגובה לכתובת ה-IP החיצונית של הלקוח. התרחיש שבו לא משתמשים בכתובת ה-IP של כלל ההעברה כמקור הוא תרחיש מתקדם, כי הלקוח מקבל מכתובת IP חיצונית חבילת תגובה שלא תואמת לכתובת ה-IP שאליה הוא שלח חבילת בקשה.

רכיבים

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

כתובות IP

מאזן עומסי רשת גלובלי חיצוני להעברת סיגנל ללא שינוי דורש שתי כתובות IP חיצוניות גלובליות כדי לספק זמינות גבוהה. כללי ההעברה של מאזן העומסים משתמשים בכתובות האלה כדי לקבל תעבורה נכנסת, והן צריכות להיות מאותה גרסת IP –‏ IPv4 או IPv6. Google Cloud מפרסם את כתובות ה-IP של מאזן העומסים מכל נקודות הנוכחות, בכל העולם. כל כתובת IP של מאזן עומסים היא כתובת IP גלובלית מסוג anycast, שנתמכת רק במסלול פרימיום.

כל אחת משתי כתובות ה-IP צריכה להיות ממאגרים של כתובות IP חיצוניות גלובליות ששייכים לקבוצת זמינות נפרדת. כתובות ה-IP לא משויכות לתת-רשת ברשת VPC. ב-API, קבוצות הזמינות מיוצגות באמצעות השדה purpose במשאב globalAddresses:

  • ‫PASSTHROUGH_LOAD_BALANCER_AVAILABILITY_GROUP0: לכתובות של קבוצת הזמינות 0.
  • ‫PASSTHROUGH_LOAD_BALANCER_AVAILABILITY_GROUP1: לכתובות של קבוצת הזמינות 1.

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

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

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

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

  • כתובת IPv4 סטטית או זמנית ממאגר כתובות IP גלובליות בבעלות Google.
  • טווח /96 של כתובות IPv6 חיצוניות סטטיות או ארעיות ממאגר גלובלי של כתובות IP בבעלות Google.
  • כתובת IPv4 סטטית של BYOIP מקידומת ציבורית גלובלית שהוקצתה.

מאזן עומסי רשת גלובלי חיצוני להעברת סיגנל ללא שינוי תומך בהעברת כתובות IP משלכם (BYOIP) רק לכתובות IPv4. התמיכה מוגבלת ל-BYOIP API בגרסה 1. הקצאה של טווחי כתובות IPv4 חדשים יכולה להימשך עד 4 שבועות, ואין ממשקי API שמאפשרים לכם לשלוט בסטטוס הפרסום של BGP. פרטים נוספים מופיעים במאמר בנושא הגדרות של כתובות IP משלכם.

אפשר להגדיר את השדה IPAddresses של כלל העברה רק בזמן היצירה, ואי אפשר לעדכן אותו.

לא משנה מה המקור שלהן (בבעלות Google או BYOIP), כתובות ה-IP החיצוניות הגלובליות ב- Google Cloud נלקחות משלושה סוגים שונים של מאגרי כתובות IP חיצוניות גלובליות:

  • מאגרי כתובות IP שמשמשים מאזני עומסים גלובליים חיצוניים של רשת להעברת סיגנל ללא שינוי לקבוצת הזמינות AG0
  • מאגרי כתובות IP שמשמשים מאזני עומסים גלובליים חיצוניים של רשת להעברת סיגנל ללא שינוי לקבוצת הזמינות AG1
  • מאגרים של כתובות IP שמשמשים מאזני עומסים גלובליים חיצוניים שמבוססים על שרת proxy

לכן, מאזני עומסי רשת גלובליים חיצוניים להעברת סיגנל ללא שינוי לא יכולים לשתף כתובות IP עם מאזני עומסים גלובליים או אזוריים אחרים.

כללי העברה גלובליים

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

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

  • סכמת איזון העומסים מסומנת כ-EXTERNAL_PASSTHROUGH.
  • זוג כתובות ה-IP הגלובליות בשדה IPAddresses[], אחת מכל קבוצת זמינות.
  • הפרוטוקול (TCP,‏ UDP או L3_DEFAULT) והיציאות.

לכל כלל העברה גלובלי חיצוני של מאזן עומסי רשת שאתם יוצרים (שנקרא גם כלל העברה ראשי),מערכת Google Cloudיוצרת שני כללי העברה משניים לקריאה בלבד לכל ערימת איזון עומסים – AVAILABILITY_GROUP0 ו-AVAILABILITY_GROUP1. לכלל ההעברה של הצאצא יש את אותן הגדרות של פרוטוקול IP, יציאה ושירות קצה עורפי כמו לכלל ההעברה של ההורה, אבל יש לו רק אחת משתי כתובות ה-IP של כלל ההעברה של ההורה.

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

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

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

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

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

אפשר ליצור כלל העברה של IPv4 וכלל העברה של IPv6 שמפנים לאותו שירות לקצה העורפי, אבל בשירות לקצה העורפי צריך להיות הפניה ל-backends עם ממשקי רשת של מכונות וירטואליות עם תמיכה ב-dual-stack.

גרסת ה-IP של כלל ההעברה צריכה להתאים לסוג הערימה של ממשקי הרשת של מכונת ה-VM בקצה העורפי.

סוג המערך של ממשקי הרשת של מכונות וירטואליות בקצה העורפי כלל העברה
ממשק רשת של מכונה וירטואלית עם IPv4 בלבד (IPV4_ONLY) יכול להיות בק-אנד רק לכללי העברה של IPv4.
ממשק רשת של מכונה וירטואלית עם IPv6 בלבד (IPV6_ONLY) יכול להיות בק-אנד רק בכללי העברה של IPv6.
ממשק רשת של מכונה וירטואלית עם תמיכה כפולה (IPV4_IPV6) יכולים להיות שרתי בק-אנד לכללי העברה של IPv4, לכללי העברה של IPv6 או לשניהם.

פרוטוקולים של כללי העברה

מאזני עומסי רשת גלובליים חיצוניים להעברת סיגנל ללא שינוי תומכים באפשרויות הפרוטוקול הבאות לכל כלל העברה: TCP,‏ UDP ו-L3_DEFAULT.

משתמשים באפשרויות TCP ו-UDP כדי להגדיר איזון עומסים ב-TCP או ב-UDP, בהתאמה. אפשרות הפרוטוקול L3_DEFAULT מאפשרת למאזן עומסי רשת חיצוני גלובלי להעברת סיגנל ללא שינוי לאזן עומסים של תעבורת נתונים בפרוטוקולים TCP,‏ UDP,‏ ESP,‏ GRE,‏ ICMP ו-ICMPv6.

בנוסף לתמיכה בפרוטוקולים אחרים מלבד TCP ו-UDP, ‏ L3_DEFAULT מאפשרת לכלל העברה יחיד לשרת כמה פרוטוקולים. לדוגמה, שירותי IPsec בדרך כלל מטפלים בשילוב כלשהו של תנועת ESP ו-IKE ו-NAT-T שמבוססת על UDP. האפשרות L3_DEFAULT מאפשרת להגדיר כלל העברה יחיד שיעבד את כל הפרוטוקולים האלה.

אם אתם משתמשים בפרוטוקול L3_DEFAULT, אתם צריכים להגדיר את כלל ההעברה כדי לאפשר תנועה בכל היציאות. מכיוון ש-L3_DEFAULT הוא כלל catch-all, מומלץ להגדיר כללי חומת אש שמאפשרים תעבורת נתונים נכנסת (ingress) רק עבור פרוטוקולי ה-IP והיציאות שאתם צריכים.

מספר כללי העברה

אפשר להגדיר כמה כללי העברה, ויש שני סוגים של כללים כאלה:

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

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

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

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

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

  • צריך להגדיר יותר מזוג אחד של כתובות IP חיצוניות לאותו שירות לקצה העורפי. לדוגמה, כלל העברה אחד לכתובות IPv4 וכלל העברה אחר לכתובות IPv6.
  • צריך להגדיר כמה כללי העברה לאותו זוג של כתובות IP חיצוניות, אבל עם פרוטוקולים שונים או יציאות או טווחי יציאות שלא חופפים. כללי ההעברה יכולים להשתמש באותם שירותי קצה עורפי או בשירותים שונים.

הגבלות על פרוטוקולים ויציאות בכמה כללי העברה

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

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

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

    לדוגמה, אם יוצרים כלל העברה באמצעות צמד כתובות ה-IP – 136.124.69.214 ו-136.124.83.205, פרוטוקול TCP וכל היציאות, אי אפשר ליצור כלל העברה אחר באמצעות אותו צמד כתובות IP ופרוטוקול TCP.

    אתם יכולים ליצור שני כללי העברה, שניהם באמצעות צמד כתובות ה-IP והפרוטוקול TCP, אם לכל אחד מהם יש יציאות ייחודיות או טווחי יציאות לא חופפים. לדוגמה, אפשר ליצור שני כללי העברה באמצעות אותו זוג כתובות IP ופרוטוקול TCP, כאשר היציאות של כלל העברה אחד הן 80,443 והשני משתמש בטווח היציאות 81-442.

  • אפשר ליצור רק כלל העברה אחד של L3_DEFAULT לכל זוג כתובות IP.

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

  • כלל העברה יחיד של L3_DEFAULT יכול להתקיים לצד כללי העברה אחרים שמשתמשים בפרוטוקולים ספציפיים (TCP או UDP) ובאותו זוג כתובות IP.

    אם יש לכם כללי העברה ספציפיים של TCP או UDP שמצורפים לצמד כתובות IP, אתם יכולים גם לצרף כלל העברה של L3_DEFAULT לאותו צמד כתובות IP כדי שישמש כגיבוי לכל תנועה שלא תואמת לכללי ההעברה הספציפיים. חבילות שנשלחות לכתובת ה-IP של היעד עוברות עיבוד על ידי כלל העברה L3_DEFAULT רק אם כתובת ה-IP של היעד, הפרוטוקול ויציאת היעד של החבילה לא תואמים לכלל העברה ספציפי לפרוטוקול.

    כדי להמחיש את זה, נבחן שני תרחישים. כללי ההעברה בשני התרחישים משתמשים באותו צמד כתובות IP – 136.124.69.214 ו-136.124.83.205.

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

    • תרחיש 2. כלל ההעברה הראשון משתמש בפרוטוקול L3_DEFAULT. כלל ההעברה השני משתמש בפרוטוקול TCP וביציאה 8080. חבילות TCP שנשלחות ליציאה 8080 של אחת מכתובות ה-IP מעובדות על ידי כלל ההעברה השני. כל שאר החבילות, כולל חבילות TCP שנשלחות ליעדים שונים, מעובדות על ידי כלל ההעברה הראשון.

בחירת כלל העברה

‫Google Cloud בוחר כלל העברה אחד או אפס כללי העברה לעיבוד מנה (packet) נכנס באמצעות תהליך ההדרה הזה, החל מקבוצת המועמדים לכללי העברה שתואמים לכתובת ה-IP של היעד של המנה:

  • מבטלים כללי העברה שהפרוטוקול שלהם לא תואם לפרוטוקול של החבילה, למעט כללי העברה של L3_DEFAULT. כללי העברה שמשתמשים בפרוטוקול L3_DEFAULT אף פעם לא נמחקים בשלב הזה, כי L3_DEFAULT תואם לכל הפרוטוקולים. לדוגמה, אם הפרוטוקול של החבילה הוא TCP, רק כללי ההעברה שמשתמשים בפרוטוקול UDP יבוטלו.

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

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

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

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

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

שירותים לקצה עורפי גלובלי

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

השירות לקצה העורפי מגדיר את הפרמטרים הבאים לקצה העורפי:

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

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

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

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

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

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

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

תאימות של ממשק רשת של מכונה וירטואלית (VM) לכללי העברה

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

כלל העברה סוג המערך של ממשקי הרשת של מכונות וירטואליות בקצה העורפי
רק כללי העברה של IPv4 IPv4 בלבד (IPV4_ONLY) או dual-stack‏ (IPV4_IPv6)
רק כללי העברה של IPv6 IPv6 בלבד (IPV6_ONLY) או dual-stack‏ (IPV4_IPv6)
כללי העברה של IPv4 ו-IPv6 מערך כפול (IPV4_IPv6)

תאימות של ממשק הרשת של מכונות וירטואליות בעורף עם רשתות משנה של VPC

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

סוג ה-Stack של רשתות משנה ב-VPC סוג המערך של ממשק הרשת של המכונה הווירטואלית בקצה העורפי
‫IPV4_ONLY (single-stack)
רק טווחי רשתות משנה של IPv4		 IPv4 בלבד (IPV4_ONLY)
‫IPV4_IPV6 (dual-stack)
Both IPv4 and IPv6 subnet ranges		 IPv4 בלבד (IPV4_ONLY),‏ dual-stack‏ (IPV4_IPv6) ו-IPv6 בלבד (IPV6_ONLY)
‫IPV6_ONLY (single-stack)
רק טווחי רשתות משנה של IPv6		 IPv6 בלבד (IPV6_ONLY)

חשוב לזכור:

  • כתובת ה-IP שמוקצית לממשק רשת של מכונה וירטואלית מוקצית ישירות מתת-רשת ה-VPC הבסיסית.

  • לצורך קישוריות IPv6, כשממשק רשת של מכונה וירטואלית מוקצה ל רשת משנה עם IPv6 מופעל, Google Cloud מערכת מקצה לממשק הרשת של המכונה הווירטואלית /96 טווח כתובות מהחצי הראשון (/65) של טווח כתובות ה-IPv6 החיצוניות של רשת המשנה./64/64 מידע נוסף זמין במאמר בנושא מפרטים חיצוניים של IPv6.

  • אם סוג הערימה של ממשק הרשת של המכונה הווירטואלית הוא dual-stack‏ (IPV4_IPv6) או IPv6 בלבד (IPV6_ONLY), צריך להגדיר את ההגדרה --ipv6-access-type ברשת המשנה של ה-VPC לערך EXTERNAL או INTERNAL כדי לקבוע איך אפשר להגיע לכתובת IPv6 של ממשק הרשת של המכונה הווירטואלית. אם הערך של --ipv6-access-type ברשת המשנה מוגדר כ-EXTERNAL, צריך להגדיר גם את --ipv6-network-tier בממשק הרשת של המכונה הווירטואלית כ-PREMIUM. מידע נוסף זמין במאמר בנושא טווחים של רשתות משנה ב-IPv6.

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

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

כדי להפיץ תעבורה מאוזנת עומסים לממשק יעד של מאזן עומסים שאינו nic0, אי אפשר להשתמש בקצוות עורפיים של קבוצת מופעים. במקום זאת, משתמשים ב-NEGs אזוריים עם נקודות קצה GCE_VM_IP. למידע נוסף, קראו את המאמר בנושא שירותי קצה עורפי ורשתות VPC.

ממשקי קצה וממשקי רשת של Zonal NEG

רשת ה-VPC ותת-הרשת שמשויכות ל-NEG אזורי עם נקודות קצה (endpoints) מסוג GCE_VM_IP מוגדרות כשיוצרים את ה-NEG. מידע נוסף וכללים לגבי נקודות קצה זמינים במאמר GCE_VM_IP עורפי NEG אזוריים וממשקי רשת.

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

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

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

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

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

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

סוג בדיקת התקינות, הפרוטוקול והיציאה

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

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

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

מנות של בדיקת תקינות

במכונות וירטואליות לקצה העורפי של קבוצת מכונות, בדיקות תקינות שולחות מנות לnic0ממשק הרשת של כל מכונה וירטואלית לקצה העורפי. במקרה של GCE_VM_IP קצוות עורפיים של NEG אזוריים, בודקי תקינות שולחים מנות לממשק הרשת בתת-הרשת של ה-VPC של ה-NEG. למנות של בדיקת תקינות יש את המאפיינים הבאים:

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

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

כללי חומת אש

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

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

  • כדי לאשר תעבורת נתונים מכל כתובת IP באינטרנט, צריך ליצור כלל חומת אש לכניסת תעבורת נתונים עם טווח המקור 0.0.0.0/0 או ::/0. כדי לאפשר תנועה רק מטווחים מסוימים של כתובות IP, משתמשים בטווחים מגבילים יותר של מקורות.

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

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

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

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

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

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

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

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

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

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

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

‫1 כולל את כלל ההעברה, שירות לקצה העורפי, בדיקת תקינות ו-backends (קבוצות מופעים או NEGs)

מגבלות

  • אפשר לפרוס שרתי בק-אנד רק באזורים הבאים: Google Cloud

    • צפון אמריקה: us-west1, us-west4, us-east4, us-east5
    • אירופה: europe-west2, europe-west3
    • אסיה: asia-southeast1, ‏ asia-south1, ‏ asia-northeast1
    • דרום אמריקה: southamerica-east1
    • אפריקה: africa-south1
    • אוסטרליה: australia-southeast1

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

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

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

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

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

  • מאזן עומסי רשת גלובלי חיצוני להעברת סיגנל ללא שינוי תומך בהעברת כתובות IP משלכם (BYOIP) רק לכתובות IPv4. התמיכה מוגבלת ל-BYOIP API בגרסה 1. הקצאה של טווחי כתובות IPv4 חדשים יכולה להימשך עד 4 שבועות, ואין ממשקי API שמאפשרים לכם לשלוט בסטטוס הפרסום של BGP. פרטים נוספים מופיעים במאמר בנושא הגדרות של כתובות IP משלכם.

  • אי אפשר ליצור יותר מ-10 כללי העברה בפרויקט, ואי אפשר להוסיף יותר מ-25 קבוצות עורפיות לשירות לקצה העורפי. פרטים נוספים זמינים במאמר בנושא מכסות ומגבלות.

  • אי אפשר לפרוס מאזן עומסי רשת גלובלי חיצוני להעברת סיגנל ללא שינוי ב-GKE.

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

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

  • אין תמיכה במצב מעקב החיבורים PER_SESSION. יש תמיכה רק במצב מעקב אחר חיבורים PER_CONNECTION.

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

  • אין תמיכה בכללי העברה (הפניית תעבורה שמבוססת על כתובת IP של המקור).

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

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

תמחור

למידע על תמחור, אפשר לעיין במאמר תמחור רשת: Cloud Load Balancing.

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