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

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

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

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

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

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

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

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

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

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

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

גישת לקוח

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מאזני עומסי רשת פנימיים להעברת סיגנל ללא שינוי תומכים ברשתות משנה מסוג IPv4 בלבד, dual-stack ו-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 (או לקצה עורפי עם תמיכה כפולה), וכלל אחד לתנועה של IPv6 שמפנה רק לקצה עורפי עם תמיכה כפולה. אפשר להגדיר כלל העברה של 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, and GRE L3_DEFAULT UNSPECIFIED

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    • לכל מכונה וירטואלית בעורף צריך להיות ממשק שאינו nic0 ברשת ה-VPC של שירות העורף וגם ממשק רשת שאינו nic0, שצריך להיות ברשת ששונה מהרשת שבה נעשה שימוש בממשק nic0 (כלומר, שונה מרשת ה-VPC של קבוצת המופעים).

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

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

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

בדיקת תקינות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מגבלות

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