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

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

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

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

ארכיטקטורה

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

קבוצות NEGs אזוריות תומכות במכונות וירטואליות עם 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

שירות לקצה העורפי לא משויך לאף רשת VPC; עם זאת, כל קבוצת מופעים של שרת עורפי (backend instance) או NEG אזורי משויכת לרשת VPC, כמו שצוין קודם. כל עוד כל השרתים העורפיים ממוקמים באותו אזור ובאותו פרויקט, וכל עוד כל השרתים העורפיים הם מאותו סוג (קבוצות של מכונות וירטואליות או קבוצות אזוריות של שרתים עורפיים), מאזן העומסים והשרתים העורפיים שלו יכולים להיות באותן רשתות 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 בלבד בקבוצות מופעים מנוהלות ולא מנוהלות. אין תמיכה בסוגים אחרים של קצה עורפי.
  • צריך להגדיר את השרתים העורפיים ברשתות משנה עם תמיכה כפולה או ברשתות משנה עם IPv6 בלבד שנמצאות באותו אזור כמו כלל העברת הנתונים של מאזן העומסים ב-IPv6. במקרה של שרתים עורפיים, אפשר להשתמש ברשת משנה עם הערך ipv6-access-type שמוגדר ל-INTERNAL או ל-EXTERNAL. אם הערך של ipv6-access-type ברשת המשנה של ה-backend מוגדר ל-INTERNAL, צריך להשתמש ברשת משנה אחרת עם IPv6 בלבד שבה הערך של ipv6-access-type מוגדר ל-EXTERNAL עבור כלל ההעברה החיצוני של מאזן העומסים.
  • צריך להגדיר את השרתים העורפיים כך שיתמכו רק ב-IPv6, ולהגדיר את המכונה הווירטואלית stack-type לערך IPV6_ONLY. אם הערך של ipv6-access-type ברשת המשנה של ה-backend מוגדר כ-EXTERNAL, צריך להגדיר גם את --ipv6-network-tier כ-PREMIUM. הוראות מפורטות זמינות במאמר יצירת תבנית של הגדרות מכונה עם כתובות IPv6.

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

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

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

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

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

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

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

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

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

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

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

כללי חומת אש

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

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

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

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

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

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

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

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

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

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

תמחור

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

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