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

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

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

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

  • אתם צריכים מאזן עומסים בשכבה 4 עם ביצועים גבוהים להעברת נתונים ישירה עבור פרוטוקולי TCP,‏ UDP,‏ ICMP,‏ ICMPv6,‏ SCTP,‏ ESP,‏ AH ו-GRE.
  • אם התנועה מועברת דרך TLS (SSL), אפשר שהתנועה של SSL תסתיים בקצה העורפי ולא במאזן העומסים. מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי לא יכול לסיים תעבורת SSL.
  • צריך להעביר את החבילות המקוריות ללא פרוקסי. לדוגמה, אם אתם צריכים לשמור את כתובת ה-IP של מקור הלקוח.
  • יש לכם הגדרה קיימת שמשתמשת במאזן עומסים מסוג pass-through, ואתם רוצים להעביר אותה ללא שינויים.

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

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

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

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

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

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

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

Google Cloud רשתות וירטואליות מנהלות את העברת התנועה ואת ההתאמה של נפח התנועה בהתאם.

פרוטוקולים, סכימה והיקף

כל מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי תומך באפשרויות הבאות:

  • שירות קצה עורפי אחד עם תוכנית לאיזון עומסים INTERNAL ופרוטוקול נתמך. מידע נוסף מופיע במאמר בנושא שירות לקצה העורפי.
  • מכונות וירטואליות בבק-אנד שצוינו כאחת מהאפשרויות הבאות:
  • תמיכה בתנועת נתונים ב-IPv4 וב-IPv6 כשמשתמשים בעורפי קצה של קבוצות מכונות. קבוצות נקודות קצה ברשת (NEGs) אזוריות עם נקודות קצה GCE_VM_IP תומכות רק בתעבורת IPv4.
  • כלל העברה אחד או יותר, שכל אחד מהם משתמש בפרוטוקול TCP, UDP או L3_DEFAULT שתואם לפרוטוקול של שירות ה-Backend.
  • כל כלל העברה עם כתובת IP ייחודית משלו או כמה כללי העברה שחולקים כתובת IP משותפת.
  • כל כלל העברה עם עד חמש יציאות או כל היציאות.
  • אם מופעלת גישה גלובלית, לקוחות בכל אזור.
  • אם הגישה הגלובלית מושבתת, לקוחות באותו אזור כמו מאזן העומסים.

מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי לא תומך באפשרויות הבאות:

גישת לקוח

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

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

בטבלה הבאה מפורטת גישת הלקוח.

הגישה הגלובלית מושבתת הגישה הגלובלית מופעלת
הלקוחות צריכים להיות באותו אזור כמו מאזן העומסים. הם גם צריכים להיות באותה רשת VPC כמו מאזן העומסים, או ברשת VPC שמחוברת לרשת ה-VPC של מאזן העומסים באמצעות VPC Network Peering. הלקוחות יכולים להיות בכל אזור. הם עדיין צריכים להיות באותה רשת VPC כמו מאזן העומסים, או ברשת VPC שמחוברת לרשת ה-VPC של מאזן העומסים באמצעות VPC Network Peering (קישור בין רשתות VPC).
לקוחות מקומיים יכולים לגשת למאזן העומסים דרך מנהרות Cloud VPN או קבצים מצורפים של VLAN. המנהרות או הקבצים המצורפים האלה צריכים להיות באותו אזור כמו מאזן העומסים. לקוחות מקומיים יכולים לגשת למאזן העומסים דרך מנהרות Cloud VPN או קבצים מצורפים של VLAN. המנהרות או הקבצים המצורפים האלה יכולים להיות בכל אזור.

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

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

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

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

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

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

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

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

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

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

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

ארכיטקטורה

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

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

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

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

מכונות וירטואליות שמשמשות כשרתים עורפיים למאזני עומסי רשת פנימיים להעברת סיגנל ללא שינוי צריכות להריץ את סביבת האורח המתאימה של Linux או Windows, או תהליכים אחרים שמספקים פונקציונליות שוות ערך. סביבת האורח הזו צריכה להיות מסוגלת ליצור קשר עם שרת המטא-נתונים (metadata.google.internal,‏ 169.254.169.254) כדי לקרוא את המטא-נתונים של המכונה, וכך ליצור מסלולים מקומיים לקבלת תעבורת נתונים שנשלחת לכתובת ה-IP הפנימית של מאזן העומסים.

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

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

מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי לא תומך באפשרויות הבאות:

כתובת IP פנימית

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

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

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

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

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

הגדרת חומת אש

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

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

כללי העברה

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

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

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

כלל ההעברה צריך להפנות לרשת משנה ספציפית באותה רשת VPC ואותו אזור שבהם נמצאים רכיבי ה-Backend של מאזן העומסים. הדרישה הזו מובילה להשלכות הבאות:

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

  • עבור תנועת IPv6, כלל ההעברה מפנה לטווח /96 של כתובות IPv6 מתוך טווח כתובות ה-IPv6 הפנימיות של תת-הרשת /64. רשת המשנה צריכה להיות רשת משנה עם תמיכה כפולה בפרוטוקולים, והערך של ipv6-access-type צריך להיות INTERNAL. אפשר להקצות את טווח כתובות ה-IPv6‏ /96 על ידי ציון כתובת IPv6 פנימית שמורה, ציון כתובת IPv6 זמנית בהתאמה אישית או מתן אפשרות ל- Google Cloudלהקצות באופן אוטומטי כתובת IPv6 זמנית.

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

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

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

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

האפשרות L3_DEFAULT מאפשרת לאזן עומסים של פרוטוקולים מסוג TCP,‏ UDP,‏ ICMP,‏ ICMPv6,‏ SCTP,‏ ESP,‏ AH ו-GRE.

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

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

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

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

התנועה שייעשה לה איזון עומסים פרוטוקול של כלל העברה פרוטוקול של שירות לקצה העורפי
‫TCP‏ (IPv4 או IPv6) TCP TCP or UNSPECIFIED
‫UDP‏ (IPv4 או IPv6) UDP UDP or UNSPECIFIED
TCP,‏ UDP,‏ ICMP,‏ ICMPv6,‏ SCTP,‏ ESP,‏ AH ו-GRE L3_DEFAULT UNSPECIFIED

כללי העברה וגישה גלובלית

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

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

כשיוצרים כלל להעברה פנימית, צריך לבחור אחת מהאפשרויות הבאות לציון יציאה:

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

כלל העברה פנימי שתומך בכל יציאות ה-TCP או בכל יציאות ה-UDP מאפשר למכונות וירטואליות בקצה העורפי להריץ כמה אפליקציות, כל אחת ביציאה משלה. התנועה שנשלחת ליציאה מסוימת מועברת לאפליקציה המתאימה, וכל האפליקציות משתמשות באותה כתובת IP.

אם אתם צריכים להעביר תנועה ביותר מחמש יציאות ספציפיות, אתם יכולים לשלב כללים לחומת אש עם כללי העברה. כשיוצרים את כלל ההעברה, מציינים את כל היציאות, ואז יוצרים כללים של allow חומת אש לתעבורת נתונים נכנסת (ingress) שמאפשרים תעבורה רק ליציאות הרצויות. מחילים את הכללים של חומת האש על המכונות הווירטואליות של ה-Backend.

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

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

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

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

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

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

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

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

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

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

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

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

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

    שירותים לקצה העורפי תומכים באפשרויות הבאות של פרוטוקול IPv6: ‏ TCP או UDP. הפרוטוקול של שירות לקצה העורפי חייב להיות תואם לפרוטוקול של כלל ההעברה.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

בדיקת תקינות

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

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

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

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

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

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

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

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

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

ארכיטקטורה של זמינות גבוהה

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

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

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

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

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

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

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

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

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

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

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

מכסות ומגבלות

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

מגבלות

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