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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

קבוצות אזוריות של נקודות קצה של רשתות

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

ממשקי רשת ושרתי קצה אזוריים של NEG

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

נתיב החזרה

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

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

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

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

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

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

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

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

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

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

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

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

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

שירות הלקצה העורפי האזורי צריך להיות מוגדר באותו פרויקט ובאותו אזור שבהם נמצאים ה-Backends (קבוצת מופעים או NEG אזורי).

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

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

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

מגבלות

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

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

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

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

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

תמחור

למידע על מחירים אפשר לעיין במאמר תמחור.

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