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

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

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

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

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

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

  • קצה עורפי של קבוצת מופעים מנוהלת ולא מנוהלת. מאזני עומסי רשת אזוריים חיצוניים להעברת סיגנל ללא שינוי שמבוססים על שירותי בק-אנד תומכים בקבוצות מופעים מנוהלות ולא מנוהלות בתור בק-אנד. קבוצות של מופעי מכונה מנוהלים מאפשרות לבצע אוטומציה של היבטים מסוימים בניהול של ה-Backend, ומספקות יכולת טובה יותר של התאמה לעומס ואמינות בהשוואה לקבוצות של מופעי מכונה לא מנוהלים.
  • שרתי קצה עורפיים של Zonal NEG. מאזני עומסים אזוריים חיצוניים של רשתות להעברת סיגנל ללא שינוי שמבוססים על שירותים לקצה העורפי תומכים בשימוש ב-NEGs אזוריים עם נקודות קצה של GCE_VM_IP. נקודות קצה של קבוצת נקודות קצה אזורית 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, שפורסGoogle Cloud מאזני עומסים בשם משתמשי GKE. הארכיטקטורה הזו זהה לארכיטקטורת איזון העומסים העצמאית שמתוארת בדף הזה, אלא שמחזור החיים שלה אוטומטי לגמרי ומנוהל על ידי GKE.

    מסמכי תיעוד קשורים של GKE:

ארכיטקטורה

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

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

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

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

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

כתובת IP

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

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

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

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

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

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

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

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

כלל העברה

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

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

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

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

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

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

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

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

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

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

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

  • אתם צריכים להגדיר יותר מכתובת IP חיצונית אחת לאותו שירות backend. לדוגמה, כלל העברה אחד לכתובת IPv4 וכלל אחר לכתובת IPv6.
  • צריך להגדיר כמה כללי העברה לאותה כתובת 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) ובאותה כתובת IP.

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

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

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

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

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

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

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

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

הכוונת תנועה

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

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

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

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

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

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

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

התנהגות של זיקה לסשן בעקבות שינויים בהפניה

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

קבוצות Zonal NEG

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

כללי חומת אש

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

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

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

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

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

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

  • האזנה (קישור) לכתובת ה-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 שאליה הוא שלח חבילת בקשה.

נתיב החזרה

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מגבלות

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

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

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

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

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

תמחור

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

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