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

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

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

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

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

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

  • בקצה העורפי של קבוצות מופעי מכונה מנוהלות ולא מנוהלות. מאזני עומסי רשת אזוריים חיצוניים להעברת סיגנל ללא שינוי שמבוססים על שירותים לקצה העורפי תומכים בקבוצות מנוהלות ולא מנוהלות של מופעים כקצה עורפי. קבוצות של מופעי מכונה מנוהלים מאפשרות לבצע אוטומציה של היבטים מסוימים בניהול של קצה העורפי, ומספקות יכולת הרחבה ואמינות טובות יותר בהשוואה לקבוצות של מופעי מכונה לא מנוהלים.
  • בקצה העורפי של Zonal NEG. מאזני עומסים אזוריים חיצוניים של רשתות להעברת סיגנל ללא שינוי שמבוססים על שירותים לקצה העורפי תומכים בשימוש ב-NEGs אזוריים עם נקודות קצה של GCE_VM_IP. נקודות קצה של Zonal NEG GCE_VM_IP מאפשרות לכם:
    • העברת חבילות לכל ממשק רשת, ולא רק ל-nic0.
    • מציבים את אותה נקודת קצה GCE_VM_IP בשתי קבוצות NEG אזוריות או יותר שמחוברות לשירותים שונים של קצה עורפי.
  • תמיכה בכמה פרוטוקולים. מאזני עומסים אזוריים חיצוניים של רשת להעברת סיגנל ללא שינוי שמבוססים על שירות קצה עורפי יכולים לבצע איזון עומסים של תנועת TCP,‏ UDP,‏ ESP,‏ GRE,‏ ICMP ו-ICMPv6.
  • תמיכה בקישוריות IPv6. מאזני עומסים אזוריים חיצוניים של רשתות להעברת סיגנל ללא שינוי שמבוססים על שירותים לקצה העורפי יכולים לטפל בתעבורת נתונים של IPv4 ו-IPv6.
  • שליטה מפורטת בחלוקת התנועה. שירות לקצה העורפי מאפשר להפיץ את תעבורת הנתונים בהתאם להגדרות של זיקה לסשן (session affinity), מדיניות מעקב אחר חיבורים והגדרות איזון עומסים משוקלל. אפשר גם להגדיר את שירות הקצה העורפי כך שיאפשר ניתוק הדרגתי של חיבורים ויקצה קצה עורפי לגיבוי למאזן העומסים. לרוב ההגדרות האלה יש ערכי ברירת מחדל שמאפשרים לכם להתחיל במהירות. מידע נוסף זמין במאמר חלוקת תנועה למאזני עומסי רשת אזוריים חיצוניים להעברת סיגנל ללא שינוי.
  • תמיכה בבדיקות תקינות אזוריות שאינן מדור קודם. מאזני עומס אזוריים חיצוניים של רשת להעברת סיגנל ללא שינוי שמבוססים על שירות קצה עורפי תומכים בבדיקות תקינות אזוריות, שיכולות להשתמש בכל פרוטוקול נתמך של בדיקת תקינות.
  • שילוב עם Google Cloud Armor. ‫Cloud Armor תומך בהגנה מתקדמת מפני מתקפות DDoS ברשתות למאזנים אזוריים חיצוניים של עומסי רשת להעברת סיגנל ללא שינוי. מידע נוסף מופיע במאמר בנושא הגדרת הגנה מתקדמת מפני מתקפות DDoS ברשת.

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

    מסמכי GKE שקשורים לנושא:

ארכיטקטורה

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

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

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

  • כתובת IP חיצונית אזורית אחת או יותר
  • כלל אחד או יותר של העברה חיצונית אזורית
  • שירות קצה עורפי חיצוני אזורי אחד
  • קצה עורפי אחד או יותר: כל קבוצות המכונות או כל הקצוות העורפיים של NEG אזורי (נקודות קצה GCE_VM_IP)
  • בדיקת תקינות שמשויכת לשירות לקצה העורפי

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

כתובת IP

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

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

  • במקרה של תנועת IPv6, כלל ההעברה מפנה לטווח /96 של כתובות IPv6 מרשת משנה עם תמיכה כפולה או מרשת משנה עם IPv6 בלבד. ברשת ה-VPC צריך להיות טווח של כתובות IPv6 חיצוניות שהוקצה לרשת המשנה. כתובות IPv6 חיצוניות זמינות רק במסלול פרימיום.

    אפשר להקצות את טווח כתובות ה-IPv6‏ /96 על ידי ציון כתובת IPv6 חיצונית שמורה, ציון כתובת IPv6 ארעית בהתאמה אישית או מתן אפשרות ל- Google Cloudלהקצות באופן אוטומטי כתובת IPv6 ארעית.

    כדי לציין כתובת IPv6 זמנית בהתאמה אישית, צריך להשתמש ב-CLI של gcloud או ב-API. במסוף Google Cloud אין תמיכה בהגדרת כתובות IPv6 זמניות מותאמות אישית לכללי העברה.

    לפרטים נוספים על תמיכה ב-IPv6, אפשר לעיין במסמכי התיעוד של VPC בנושא טווחים של רשתות משנה של IPv6 וכתובות IPv6.

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

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

כלל העברה

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

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

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

  • אם כלל ההעברה מפנה לכתובת IPv4, כלל ההעברה לא משויך לרשת משנה כלשהי. כלומר, כתובת ה-IP שלה מגיעה מחוץ לכל טווח של תת-רשתGoogle Cloud .

  • אם כלל ההעברה מפנה ל/96 טווח כתובות IPv6, טווח כתובות ה-IPv6 הזה צריך להיות מרשת משנה עם מחסנית כפולה או יחידה של IPv6 עם טווח חיצוני של רשת משנה IPv6 (כאשר --ipv6-access-type מוגדר כ-EXTERNAL)./96

    תת-הרשת שאליה מפנה כלל ההעברה יכולה להיות אותה תת-רשת שבה משתמשות מכונות הבק-אנד, או שמכונות הבק-אנד יכולות להיות ממוקמות בכל תת-רשת IPv6 עם מחסנית כפולה או עם מחסנית יחידה באותו אזור שבו נמצא כלל ההעברה. לדוגמה, לתת-הרשת שמשמשת את השרתים העורפיים יכול להיות טווח של תת-רשת פנימית של IPv6 (עם --ipv6-access-type שמוגדר ל-INTERNAL).

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

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

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

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

כללי העברה שמשתמשים בפרוטוקולים TCP או UDP יכולים להפנות לשירות backend באמצעות אותו פרוטוקול כמו כלל ההעברה, או לשירות backend שהפרוטוקול שלו הוא UNSPECIFIED. כללי העברה של L3_DEFAULT יכולים להפנות רק אל שירות קצה עורפי עם פרוטוקול UNSPECIFIED.

אם אתם משתמשים בפרוטוקול L3_DEFAULT, אתם צריכים להגדיר את כלל ההעברה כדי לאפשר תנועה בכל היציאות. כדי להגדיר את כל היציאות, צריך להגדיר את --ports=ALL באמצעות Google Cloud CLI, או להגדיר את allPorts ל-True באמצעות ה-API.

בטבלה הבאה מפורט איך להשתמש בהגדרות האלה עבור פרוטוקולים שונים.

התנועה שייעשה לה איזון עומסים פרוטוקול של כלל העברה פרוטוקול של שירות לקצה העורפי
TCP TCP TCP או UNSPECIFIED
L3_DEFAULT UNSPECIFIED
UDP UDP UDP או UNSPECIFIED
L3_DEFAULT UNSPECIFIED
ESP, ‏ GRE, ‏ ICMP/ICMPv6 (בקשת הד בלבד) L3_DEFAULT UNSPECIFIED

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

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

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

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

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

  • כלל העברה שמוגדר לכל הפורטים של פרוטוקול מסוים מונע את היצירה של כללי העברה אחרים שמשתמשים באותו פרוטוקול ובאותה כתובת IP. אפשר להגדיר כללי העברה באמצעות פרוטוקולים TCP או UDP כך שישתמשו בכל היציאות, או להגדיר אותם ליציאות ספציפיות. לדוגמה, אם יוצרים כלל העברה באמצעות כתובת ה-IP‏ 198.51.100.1, פרוטוקול TCP וכל היציאות, אי אפשר ליצור כלל העברה אחר באמצעות כתובת ה-IP‏ 198.51.100.1 ופרוטוקול TCP. אתם יכולים ליצור שני כללי העברה, שניהם באמצעות כתובת ה-IP‏ 198.51.100.1 והפרוטוקול TCP, אם לכל אחד מהם יש יציאות ייחודיות או טווחי יציאות לא חופפים. לדוגמה, אפשר ליצור שני כללי העברה באמצעות כתובת ה-IP‏ 198.51.100.1 ופרוטוקול TCP, כשביציאות של כלל העברה אחד מוגדרת היציאה 80,443, ובכלל השני מוגדר טווח היציאות 81-442.
  • אפשר ליצור רק כלל העברה אחד של L3_DEFAULT לכל כתובת IP. הסיבה לכך היא שפרוטוקול L3_DEFAULT משתמש בכל היציאות בהגדרה. בהקשר הזה, המונח 'כל היציאות' כולל פרוטוקולים ללא פרטי יציאה.

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

    כדי להמחיש את זה, נבחן שני תרחישים. כללי ההעברה בשני התרחישים משתמשים באותה כתובת IP‏ 198.51.100.1.

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

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

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

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

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

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

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

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

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

ניתוב תנועה

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

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

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

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

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

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

  • כלל העברה ראשי: כתובת IP: ‏ 198.51.100.1, פרוטוקול IP: ‏ TCP, יציאות: 80
  • כלל העברה לניתוב תנועה: כתובת IP: ‏ 198.51.100.1, פרוטוקול IP: ‏ TCP, יציאות: 80, טווחי כתובות IP של מקור: 203.0.113.0/24

אפשר לשייך כלל העברה ראשי שמפנה לשירות backend לכלל העברה להפניית תנועה שמפנה לשירות backend או למופע יעד.

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

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

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

התנהגות של זיקה לסשן במקרה של שינויים בהכוונה

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

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

שמירה על שיוך סשנים בין שינויים בהפניה

בקטע הזה מוסבר איך להימנע משיבוש של זיקה לסשן (session affinity) כשמעדכנים את טווחי כתובות ה-IP של המקור לכללי העברה של תנועה:

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

הוראות להגדרת ניהול תנועה מופיעות במאמר הגדרת ניהול תנועה.

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

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

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

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

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

    אפשר להשתמש בשירותי קצה עורפי עם פרוטוקול UNSPECIFIED בכל כלל העברה, בלי קשר לפרוטוקול של כלל ההעברה. אפשר להפנות שירותים לקצה עורפי עם פרוטוקול ספציפי (TCP או UDP) רק באמצעות כללי העברה עם אותו פרוטוקול (TCP או UDP). כללי העברה עם פרוטוקול L3_DEFAULT יכולים להפנות רק לשירותים לקצה עורפי עם פרוטוקול UNSPECIFIED.

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

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

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

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

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

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

קבוצות של מכונות

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

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

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

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

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

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

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

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

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

קבוצות אזוריות של נקודות קצה ברשת (Zonal NEGs)

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

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

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

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

בתוך קבוצת מופעים נתונה (מנוהלת או לא מנוהלת), ממשק הרשת nic0 של כל מכונה וירטואלית חברה תמיד נמצא באותה רשת VPC:

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

למכונות וירטואליות של חברים יכולים להיות ממשקי רשת נוספים (vNICs או ממשקי רשת דינמיים). כל ממשק שאינו nic0 יכול להיות ברשת ה-VPC של קבוצת המופעים (הרשת שבה נעשה שימוש בממשק nic0) או ברשת VPC אחרת.

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

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

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

בתוך NEG נתון, כל נקודת קצה GCE_VM_IP מייצגת למעשה ממשק רשת. ממשק הרשת צריך להיות ברשת המשנה שמשויכת ל-NEG. מנקודת המבט של מכונת Compute Engine, לממשק הרשת יכול להיות כל מזהה. מנקודת המבט של נקודת קצה ב-NEG, ממשק הרשת מזוהה באמצעות כתובת ה-IPv4 הפנימית הראשית שלו. מידע נוסף זמין במאמר בנושא NEGs עם נקודות קצה (endpoint) של GCE_VM_IP.

יש שתי דרכים להוסיף נקודת קצה GCE_VM_IP ל-NEG:

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

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

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

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

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

  • ממשקי הרשת של nic0 ו-nic0 צריכים להיות ברשתות VPC שונות. (רשת ה-VPC של ה-NEG לא יכולה להכיל את הממשק nic0 ואת הממשק הרצוי שאינו nic0).

שרתי קצה עורפיים עם תמיכה כפולה (IPv4 ו-IPv6)

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

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

שרתי קצה עורפיים (Backend) מסוג IPv6 בלבד

אם רוצים שמאזן העומסים ישתמש בקצה עורפי של IPv6 בלבד, צריך לשים לב לדרישות הבאות:

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

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

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

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

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

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

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

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

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

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

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

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

כללי חומת אש

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

נתיב החזרה

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מגבלות

  • אי אפשר להשתמש במסוף כדי לבצע את המשימות הבאות: Google Cloud

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

    במקום זאת, אפשר להשתמש ב-Google Cloud CLI או ב-API ל-REST.

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

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

תמחור

למידע על תמחור, אפשר לעיין במאמר בנושא תמחור רשת: איזון עומסים ב-Cloud.

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