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

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

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

הרשאות

כדי לפעול לפי המדריך הזה, צריך ליצור מופעים ולשנות רשת בפרויקט. צריכות להיות לכם הרשאות בעלים או עריכה בפרויקט, או שצריכים להיות לכם כל תפקידי ה-IAM הבאים ב-Compute Engine:

משימה התפקיד הנדרש
יצירת רשתות, רשתות משנה ורכיבים של מאזן עומסים אדמין רשתות
הוספה והסרה של כללים לחומת האש Security Admin
יצירת מופעים Compute Instance Admin

מידע נוסף זמין במדריכים הבאים:

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

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

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

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

  • דוגמה לרשתות VPC ולרשתות משנה בהתאמה אישית
  • Google Cloud כללי חומת אש שמאפשרים חיבורים נכנסים למכונות וירטואליות (VM) של מכשירי קצה בעורף
  • מסלולים סטטיים
  • שתי מכונות וירטואליות של לקוחות לבדיקת חיבורים
  • הרכיבים הבאים של מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי:
    • מכונות וירטואליות בבק-אנד בקבוצת מופעי מכונה מנוהלים (MIG)
    • בדיקת תקינות של מכונות וירטואליות (VM) בעורף
    • שירות פנימי לקצה העורפי באזור us-west1 לניהול חלוקת החיבורים בין המכונות הווירטואליות בקצה העורפי
    • כלל העברה פנימי וכתובת IP פנימית לחלק הקדמי של מאזן העומסים

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

הטופולוגיה נראית כך:

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

בתרשים מוצגים חלק מהמשאבים שנוצרו בדוגמה:

  • מופעי אפליקציות מאחורי מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי (fr-ilb1, בדוגמה הזו). למכונות של האפליקציה יש רק כתובות IP פנימיות.
  • בכל מופע של אפליקציה מופעל הדגל can-ip-forward. בלי הדגל הזה, מכונה וירטואלית ב-Compute Engine יכולה להעביר מנה רק אם כתובת ה-IP של המקור במנה זהה לכתובת ה-IP הפנימית של המכונה, לכתובת IP מטווח של כתובות IP של כינוי או לכתובת IP של כלל העברה שמפנה למכונה. הדגל can-ip-forward משנה את ההתנהגות הזו, כך שהמכונה הווירטואלית יכולה לשדר חבילות עם כל כתובת IP של מקור.
  • מסלול סטטי עם יעד 10.50.1.0/24 והצעד הבא מוגדר לכלל ההעברה של מאזן העומסים, fr-ilb1.

בתרשים מוצג גם זרימת התנועה:

  • ברשת ה-VPC‏ testing יש נתיב סטטי לתעבורה שמיועדת לתת-הרשת 10.50.1.0/24. המסלול הזה מנתב את תעבורת הנתונים למאזן העומסים.
  • מאזן העומסים מעביר את התעבורה לאחד מהמופעים של האפליקציה על סמך זיקה לסשן (session affinity) שהוגדרה. (זיקה לסשן (session affinity) משפיעה רק על תעבורת TCP).

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

הגדרת הרשתות, האזור ורשתות המשנה

בדוגמה הזו נעשה שימוש ברשתות VPC, באזור ובתת-רשתות הבאים:

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

  • אזור: תת-הרשתות ממוקמות באזור us-west1. תת-הרשתות צריכות להיות באותו אזור כי מכונות וירטואליות הן משאבים אזוריים.

  • רשתות משנה: רשתות המשנה, testing-subnet ו-production-subnet, משתמשות בטווחים של כתובות ה-IP הראשיות 10.30.1.0/24 ו-10.50.1.0/24, בהתאמה.

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

המסוף

יוצרים את הרשת testing ואת testing-subnet:

  1. נכנסים לדף VPC networks במסוף Google Cloud .

    מעבר לרשתות VPC

  2. לוחצים על יצירת רשת VPC.

  3. מזינים שם של testing.

  4. בקטע Subnets (רשתות משנה):

    • מגדירים את מצב יצירת רשתות משנה לבהתאמה אישית.
    • בקטע New subnet (רשת משנה חדשה), מזינים את הפרטים הבאים:
      • Name (שם): testing-subnet
      • אזור: us-west1
      • טווח כתובות IP: 10.30.1.0/24
      • לוחצים על סיום.

  5. לוחצים על יצירה.

יוצרים את הרשת production ואת production-subnet:

  1. נכנסים לדף VPC networks במסוף Google Cloud .

    מעבר לרשתות VPC

  2. לוחצים על יצירת רשת VPC.

  3. מזינים שם של production.

  4. בקטע Subnets (רשתות משנה):

    • מגדירים את מצב יצירת רשתות משנה לבהתאמה אישית.
    • בקטע New subnet (רשת משנה חדשה), מזינים את הפרטים הבאים:
      • Name (שם): production-subnet
      • אזור: us-west1
      • טווח כתובות IP: 10.50.1.0/24
      • לוחצים על סיום.

  5. לוחצים על יצירה.

gcloud

  1. יוצרים את רשתות ה-VPC במצב מותאם אישית:

    gcloud compute networks create testing --subnet-mode=custom

    gcloud compute networks create production --subnet-mode=custom

  2. יוצרים רשתות משנה ברשתות testing ו-production באזור us-west1:

    gcloud compute networks subnets create testing-subnet \
    --network=testing \
    --range=10.30.1.0/24 \
    --region=us-west1

    gcloud compute networks subnets create production-subnet \
    --network=production \
    --range=10.50.1.0/24 \
    --region=us-west1

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

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

  • ‫fw-allow-testing-from-both: כלל תעבורה נכנסת, שחל על כל היעדים ברשת testing. הכלל הזה מאפשר תנועה ממקורות בטווחים של כתובות ה-IP‏ 10.30.1.0/24 ו-10.50.1.0/24. שני הטווחים האלה כוללים את כתובות ה-IP הפנימיות הראשיות של מכונות וירטואליות בשתי הרשתות.

  • ‫fw-allow-production-from-both: כלל תעבורה נכנסת, שחל על כל היעדים ברשת production. הכלל הזה מאפשר תנועה ממקורות בטווחים של כתובות ה-IP‏ 10.30.1.0/24 ו-10.50.1.0/24. שני הטווחים האלה כוללים את כתובות ה-IP הפנימיות הראשיות של מכונות וירטואליות בשתי הרשתות.

  • ‫fw-allow-testing-ssh: כלל תעבורה נכנסת שחל על המכונות הווירטואליות ברשת ה-VPC‏ testing. הכלל הזה מאפשר קישוריות SSH נכנסת ביציאת TCP‏ 22 מכל כתובת. אפשר לבחור טווח IP של מקור מגביל יותר לכלל הזה. לדוגמה, אפשר לציין את טווחי ה-IP של המערכות שמהן אתם מתכננים להפעיל סשנים של SSH. בדוגמה הזו נעשה שימוש בתג היעד allow-ssh כדי לזהות את המכונות הווירטואליות שהכלל של חומת האש חל עליהן.

  • ‫fw-allow-production-ssh: כלל תעבורה נכנסת שחל על המכונות הווירטואליות ברשת ה-VPC‏ production. הכלל הזה מאפשר קישוריות SSH נכנסת ביציאת TCP‏ 22 מכל כתובת. בדומה לכלל fw-allow-testing-ssh, אפשר לבחור לכלל הזה טווח כתובות IP של מקור שהוא מגביל יותר.

  • ‫fw-allow-health-check: כלל כניסה למכונות וירטואליות של מכשיר צד שלישי שעוברות איזון עומסים. הכלל הזה מאפשר תעבורה מGoogle Cloud טווחים של בדיקות תקינות. בדוגמה הזו נעשה שימוש בתג היעד allow-health-check כדי לזהות את המקרים שבהם צריך להחיל את הכלל.

  • ‫fw-allow-production-health-check: כלל כניסה למכונות וירטואליות של מכשיר צד שלישי שעוברות איזון עומסים. הכלל הזה מאפשר תעבורה מGoogle Cloud טווחים של בדיקות תקינות. בדוגמה הזו נעשה שימוש בתג היעד allow-health-check כדי לזהות את המקרים שבהם צריך להחיל את הכלל.

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

המסוף

  1. נכנסים לדף Firewall policies במסוף Google Cloud .

    למדיניות חומת האש

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

    • Name (שם): fw-allow-testing-from-both
    • רשת: testing
    • עדיפות: 1000
    • כיוון התנועה: נכנסת (ingress)
    • פעולה במקרה של התאמה: לאפשר
    • יעדים: כל המופעים ברשת
    • מסנן מקור: טווחים של כתובות IPv4
    • טווחים של כתובות IPv4 של המקור: 10.30.1.0/24, 10.50.1.0/24
    • פרוטוקולים ויציאות: אישור כל הפרוטוקולים והיציאות

  3. לוחצים על יצירה.

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

    • Name (שם): fw-allow-production-from-both
    • רשת: production
    • עדיפות: 1000
    • כיוון התנועה: נכנסת (ingress)
    • פעולה במקרה של התאמה: לאפשר
    • יעדים: כל המופעים ברשת
    • מסנן מקור: טווחים של כתובות IPv4
    • טווחים של כתובות IPv4 של המקור: 10.30.1.0/24, 10.50.1.0/24
    • פרוטוקולים ויציאות: אישור כל הפרוטוקולים והיציאות

  5. לוחצים על יצירה.

  6. לוחצים על Create firewall rule (יצירת כלל חומת אש) כדי ליצור את הכלל שיאפשר חיבורי SSH נכנסים בסביבת הבדיקה:

    • Name (שם): fw-allow-testing-ssh
    • רשת: testing
    • עדיפות: 1000
    • כיוון התנועה: נכנסת (ingress)
    • פעולה במקרה של התאמה: לאפשר
    • יעדים: תגי יעד שצוינו
    • תגי יעד: allow-ssh
    • מסנן מקור: טווחים של כתובות IPv4
    • טווחים של כתובות IPv4 של המקור: 0.0.0.0/0
    • פרוטוקולים ויציאות: בוחרים באפשרות פרוטוקולים ויציאות שצוינו ומקלידים: tcp:22

  7. לוחצים על יצירה.

  8. לוחצים על Create firewall rule (יצירת כלל חומת אש) כדי ליצור את הכלל שיאפשר חיבורי SSH נכנסים בסביבת הייצור:

    • Name (שם): fw-allow-production-ssh
    • רשת: production
    • עדיפות: 1000
    • כיוון התנועה: נכנסת (ingress)
    • פעולה במקרה של התאמה: לאפשר
    • יעדים: תגי יעד שצוינו
    • תגי יעד: allow-ssh
    • מסנן מקור: טווחים של כתובות IPv4
    • טווחים של כתובות IPv4 של המקור: 0.0.0.0/0
    • פרוטוקולים ויציאות: בוחרים באפשרות פרוטוקולים ויציאות שצוינו ומקלידים: tcp:22

  9. לוחצים על יצירה.

  10. לוחצים על יצירת כלל חומת אש כדי ליצור את הכלל שיאפשרGoogle Cloud בדיקות תקינות בסביבת הבדיקה:

    • Name (שם): fw-allow-health-check
    • רשת: testing
    • עדיפות: 1000
    • כיוון התנועה: נכנסת (ingress)
    • פעולה במקרה של התאמה: לאפשר
    • יעדים: תגי יעד שצוינו
    • תגי יעד: allow-health-check
    • מסנן מקור: טווחים של כתובות IPv4
    • טווחי IPv4 של המקור: 35.191.0.0/16
    • פרוטוקולים ויציאות: tcp

  11. לוחצים על יצירה.

  12. לוחצים על יצירת כלל לחומת האש כדי ליצור את הכלל שיאפשרGoogle Cloud בדיקות תקינות בסביבת הייצור:

    • Name (שם): fw-allow-production-health-check
    • רשת: production
    • עדיפות: 1000
    • כיוון התנועה: נכנסת (ingress)
    • פעולה במקרה של התאמה: לאפשר
    • יעדים: תגי יעד שצוינו
    • תגי יעד: allow-health-check
    • מסנן מקור: טווחים של כתובות IPv4
    • טווחי IPv4 של המקור: 35.191.0.0/16
    • פרוטוקולים ויציאות: tcp

  13. לוחצים על יצירה.

gcloud

  1. יוצרים את כלל חומת האש fw-allow-testing-subnet כדי לאפשר למכונות הווירטואליות לבדיקה לקבל חבילות נתונים מתת-הרשתות testing ו-production:

    gcloud compute firewall-rules create fw-allow-testing-from-both \
    --network=testing \
    --action=allow \
    --direction=ingress \
    --source-ranges=10.30.1.0/24,10.50.1.0/24 \
    --rules=all

  2. יוצרים את כלל חומת האש fw-allow-production-subnet כדי לאפשר למכונות וירטואליות של סביבת הייצור לקבל מנות נתונים מתת-הרשתות testing ו-production:

    gcloud compute firewall-rules create fw-allow-production-from-both \
    --network=production \
    --action=allow \
    --direction=ingress \
    --source-ranges=10.30.1.0/24,10.50.1.0/24 \
    --rules=all

  3. יוצרים את כלל חומת האש fw-allow-testing-ssh כדי לאפשר קישוריות SSH למכונות וירטואליות עם תג הרשת allow-ssh. אם לא מציינים את source-ranges,‏Google Cloud מפרש את הכלל כאילו הוא מתייחס לכל מקור.

    gcloud compute firewall-rules create fw-allow-testing-ssh \
    --network=testing \
    --action=allow \
    --direction=ingress \
    --target-tags=allow-ssh \
    --rules=tcp:22

  4. יוצרים את כלל חומת האש fw-allow-production-ssh כדי לאפשר קישוריות SSH למכונות וירטואליות עם תג הרשת allow-ssh.

    gcloud compute firewall-rules create fw-allow-production-ssh \
    --network=production \
    --action=allow \
    --direction=ingress \
    --target-tags=allow-ssh \
    --rules=tcp:22

  5. יוצרים את הכלל fw-allow-health-check כדי לאפשר Google Cloudבדיקות תקינות למכונות וירטואליות של מכשירי צד שלישי ברשת testing.

    gcloud compute firewall-rules create fw-allow-testing-health-check \
    --network=testing \
    --action=allow \
    --direction=ingress \
    --target-tags=allow-health-check \
    --source-ranges=35.191.0.0/16 \
    --rules=tcp

  6. יוצרים את כלל חומת האש fw-allow-production-health-check כדי לאפשר Google Cloud בדיקות תקינות של מכונות וירטואליות של מכשירי צד שלישי ברשת production.

    gcloud compute firewall-rules create fw-allow-production-health-check \
    --network=production \
    --action=allow \
    --direction=ingress \
    --target-tags=allow-health-check \
    --source-ranges=35.191.0.0/16 \
    --rules=tcp

יצירת מכשירים וירטואליים של צד שלישי

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

המסוף

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

gcloud

  1. יוצרים קובץ מקומי בשם config.sh ומזינים בו את התוכן הבא:

    #!/bin/bash
# Enable IP forwarding:
echo 1 > /proc/sys/net/ipv4/ip_forward
echo "net.ipv4.ip_forward=1" > /etc/sysctl.d/20-example.conf
# Read VM network configuration:
md_vm="http://metadata.google.internal/computeMetadata/v1/instance/"
md_net="$md_vm/network-interfaces"
nic0_gw="$(curl $md_net/0/gateway -H "Metadata-Flavor:Google" )"
nic0_mask="$(curl $md_net/0/subnetmask -H "Metadata-Flavor:Google")"
nic0_addr="$(curl $md_net/0/ip -H "Metadata-Flavor:Google")"
nic0_id="$(ip addr show | grep $nic0_addr | awk '{print $NF}')"
nic1_gw="$(curl $md_net/1/gateway -H "Metadata-Flavor:Google")"
nic1_mask="$(curl $md_net/1/subnetmask -H "Metadata-Flavor:Google")"
nic1_addr="$(curl $md_net/1/ip -H "Metadata-Flavor:Google")"
nic1_id="$(ip addr show | grep $nic1_addr | awk '{print $NF}')"
# Source based policy routing for nic1
echo "100 rt-nic1" >> /etc/iproute2/rt_tables
sudo ip rule add pri 32000 from $nic1_gw/$nic1_mask table rt-nic1
sleep 1
sudo ip route add 35.191.0.0/16 via $nic1_gw dev $nic1_id table rt-nic1
sudo ip route add 130.211.0.0/22 via $nic1_gw dev $nic1_id table rt-nic1
# Use a web server to pass the health check for this example.
# You should use a more complete test in production.
sudo apt-get update
sudo apt-get install apache2 -y
sudo a2ensite default-ssl
sudo a2enmod ssl
echo "Example web page to pass health check" | \
tee /var/www/html/index.html
sudo systemctl restart apache2

  2. יוצרים תבנית של הגדרות מכונה למכשירים וירטואליים של צד שלישי. תבנית של הגדרות מכונה חייבת לכלול את הדגל --can-ip-forward כדי שמופעי מכונות וירטואליות שנוצרו מהתבנית יוכלו להעביר מנות ממופעים אחרים ברשתות testing ו-production.

    gcloud compute instance-templates create third-party-template-multinic \
    --region=us-west1 \
    --network-interface subnet=testing-subnet,address="" \
    --network-interface subnet=production-subnet \
    --tags=allow-ssh,allow-health-check,my-network-tag \
    --image-family=debian-12 \
    --image-project=debian-cloud \
    --can-ip-forward \
    --metadata-from-file=startup-script="config.sh"

  3. יוצרים קבוצה של מופעי מכונה מנוהלים עבור מכשירים וירטואליים של צד שלישי. הפקודה הזו יוצרת קבוצה אזורית של מופעי מכונה מנוהלים, שאפשר להפעיל בה קנה מידה אוטומטי, באזור us-west1.

    gcloud compute instance-groups managed create third-party-instance-group \
    --region=us-west1 \
    --template=third-party-template-multinic \
    --size=3

יצירת משאבי איזון העומסים

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

  • בדיקת תקינות. בדוגמה הזו, בדיקת תקינות HTTP בודקת תגובת HTTP 200 (OK). מידע נוסף זמין בקטע בדיקת תקינות.

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

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

  • כתובת IP פנימית. בדוגמה הזו, כתובת ה-IP הפנימית שצוינה לכלל ההעברה היא 10.30.1.99.

המסוף

התחלת ההגדרה

  1. נכנסים לדף Load balancing במסוף Google Cloud .

    כניסה לדף Load balancing

  2. לוחצים על Create load balancer (יצירת מאזן עומסים).
  3. בקטע Type of load balancer (סוג מאזן העומסים), בוחרים באפשרות Network Load Balancer (TCP/UDP/SSL) (מאזן עומסים ברשת (TCP/UDP/SSL)) ולוחצים על Next (הבא).
  4. בקטע Proxy or passthrough (פרוקסי או העברה), בוחרים באפשרות Passthrough load balancer (מאזן עומסים להעברה) ולוחצים על Next (הבא).
  5. בקטע גלוי לכולם או פנימי, בוחרים באפשרות פנימי ולוחצים על הבא.
  6. לוחצים על Configure (הגדרה).

יצירת מאזן העומסים הראשון

  1. בשדה Load Balancer name, מזינים ilb1.
  2. ברשימה Region בוחרים באזור us-west1.
  3. ברשימה Network בוחרים באפשרות testing.
  4. לוחצים על Backend configuration ומבצעים את הפעולות הבאות:
    1. ברשימה Health check, לוחצים על Create a health check ומזינים את הפרטים הבאים:
      • Name (שם): hc-http-80
      • Protocol: HTTP
      • יציאה: 80
      • פרוטוקול שרת proxy: NONE
      • בקשה: / שימו לב: כשמשתמשים במסוף Google Cloud כדי ליצור מאזן עומסים, בדיקת התקינות היא גלובלית. אם רוצים ליצור בדיקת תקינות אזורית, משתמשים ב-gcloud או ב-API.
    2. לוחצים על יצירה.
    3. בקטע New backend (שרת קצה עורפי חדש), בוחרים את קבוצת המופעים third-party-instance-group ולוחצים על Done (סיום).
    4. ברשימה Session affinity בוחרים באפשרות Client IP.
    5. לפני שממשיכים, מוודאים שמופיע סימן וי כחול לצד Backend configuration. אם לא, כדאי לבדוק את השלב הזה.
  5. לוחצים על Frontend configuration. בקטע New Frontend IP and port מבצעים את השינויים הבאים:
    1. Name (שם): fr-ilb1
    2. תת-רשת: testing-subnet
    3. בקטע כתובת IP פנימית, בוחרים באפשרות Reserve a static internal IP address, מזינים את הפרטים הבאים ולוחצים על Reserve:
      • Name (שם): ip-ilb
      • כתובת IP סטטית: אני רוצה לבחור
      • כתובת IP מותאמת אישית: 10.30.1.99
    4. יציאות: בוחרים באפשרות יחיד ומזינים 80 בשדה מספר היציאה. חשוב לזכור שהבחירה של פרוטוקול ויציאה למאזן העומסים לא מגבילה את הפרוטוקולים והיציאות שבהם נעשה שימוש כשמאזן העומסים הוא השלב הבא במסלול.
    5. לפני שממשיכים, מוודאים שמופיע סימן וי כחול לצד Frontend configuration. אם לא, כדאי לבדוק את השלב הזה.
  6. לוחצים על Review and finalize. כדאי לבדוק שוב את ההגדרות.
  7. לוחצים על יצירה.

התחלת ההגדרה

  1. נכנסים לדף Load balancing במסוף Google Cloud .

    כניסה לדף Load balancing

  2. לוחצים על Create load balancer (יצירת מאזן עומסים).
  3. בקטע Type of load balancer (סוג מאזן העומסים), בוחרים באפשרות Network Load Balancer (TCP/UDP/SSL) (מאזן עומסים ברשת (TCP/UDP/SSL)) ולוחצים על Next (הבא).
  4. בקטע Proxy or passthrough (פרוקסי או העברה), בוחרים באפשרות Passthrough load balancer (מאזן עומסים להעברה) ולוחצים על Next (הבא).
  5. בקטע גלוי לכולם או פנימי, בוחרים באפשרות פנימי ולוחצים על הבא.
  6. לוחצים על Configure (הגדרה).

יצירת מאזן העומסים השני

  1. מגדירים את Name לערך ilb2.
  2. מגדירים את Region לערך us-west1.
  3. מגדירים את Network ל-production.
  4. לוחצים על Backend configuration ומבצעים את השינויים הבאים:
    1. בקטע New item (פריט חדש) של Backends (שרתי קצה עורפיים), בוחרים את קבוצת המופעים third-party-instance-group ולוחצים על Done (סיום).
    2. בשדה Health check (בדיקת תקינות), בוחרים באפשרות hc-http-80.
    3. בשדה Session affinity, בוחרים באפשרות Client IP.
    4. לפני שממשיכים, מוודאים שמופיע סימן וי כחול לצד Backend configuration. אם לא, כדאי לבדוק את השלב הזה.
  5. לוחצים על Frontend configuration. בקטע New Frontend IP and port מבצעים את השינויים הבאים:
    1. Name (שם): fr-ilb2
    2. תת-רשת: production-subnet
    3. בקטע כתובת IP פנימית, בוחרים באפשרות Reserve a static internal IP address, מזינים את הפרטים הבאים ולוחצים על Reserve:
      • Name (שם): ip-ilb2
      • כתובת IP סטטית: אני רוצה לבחור
      • כתובת IP מותאמת אישית: 10.50.1.99
    4. יציאות: בוחרים באפשרות יחיד ומזינים 80 בשדה מספר היציאה. חשוב לזכור שהבחירה של פרוטוקול ויציאה למאזן העומסים לא מגבילה את הפרוטוקולים והיציאות שבהם נעשה שימוש כשמאזן העומסים הוא השלב הבא במסלול.
    5. לפני שממשיכים, מוודאים שמופיע סימן וי כחול לצד Frontend configuration. אם לא, כדאי לבדוק את השלב הזה.
  6. לוחצים על Review and finalize. כדאי לבדוק שוב את ההגדרות.
  7. לוחצים על יצירה.

gcloud

  1. יוצרים בדיקת תקינות חדשה של HTTP כדי לבדוק את קישוריות ה-TCP למכונות הווירטואליות בפורט 80.

    gcloud compute health-checks create http hc-http-80 \
    --region=us-west1 \
    --port=80

  2. יוצרים שני שירותים פנימיים לקצה העורפי באזור us-west1.

    gcloud compute backend-services create ilb1 \
    --load-balancing-scheme=internal \
    --health-checks-region=us-west1 \
    --health-checks=hc-http-80 \
    --region=us-west1 \
    --network=testing \
    --session-affinity=CLIENT_IP

    gcloud compute backend-services create ilb2 \
    --load-balancing-scheme=internal \
    --health-checks-region=us-west1 \
    --health-checks=hc-http-80 \
    --region=us-west1 \
    --network=production \
    --session-affinity=CLIENT_IP

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

    gcloud compute backend-services add-backend ilb1 \
    --instance-group=third-party-instance-group \
    --instance-group-region=us-west1 \
    --region=us-west1

    gcloud compute backend-services add-backend ilb2 \
    --instance-group=third-party-instance-group \
    --instance-group-region=us-west1 \
    --region=us-west1

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

    gcloud compute forwarding-rules create fr-ilb1 \
    --load-balancing-scheme=internal \
    --ports=80 \
    --network=testing \
    --subnet=testing-subnet \
    --region=us-west1 \
    --backend-service=ilb1 \
    --address=10.30.1.99

    gcloud compute forwarding-rules create fr-ilb2 \
    --load-balancing-scheme=internal \
    --ports=80 \
    --network=production \
    --subnet=production-subnet \
    --region=us-west1 \
    --backend-service=ilb2 \
    --address=10.50.1.99

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

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

המסוף

יצירת המסלול הראשון

  1. נכנסים לדף Routes במסוף Google Cloud .

    לדף Routes

  2. לוחצים על יצירת מסלול.

  3. בשדה שם של הנתיב, מזינים ilb-nhop-dest-10-50-1.

  4. בוחרים את הרשת testing.

  5. בשדה טווח כתובות ה-IP של היעד, מזינים 10.50.1.0/24.

  6. בשדה Instance tags (תגי מופע), מזינים my-network-tag.

  7. בקטע Next hop (הצעד הבא) של המסלול, בוחרים באפשרות Specify a forwarding rule of an internal passthrough Network Load Balancer (ציון כלל העברה של מאזן עומסי רשת פנימי מסוג passthrough).

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

  8. מציינים את השם של כלל ההעברה. בוחרים את שם כלל ההעברה fr-ilb1.

  9. לוחצים על יצירה.

יצירת המסלול השני

  1. לוחצים על יצירת מסלול.
  2. בשדה שם של הנתיב, מזינים ilb-nhop-dest-10-30-1.
  3. בוחרים את הרשת testing.
  4. בשדה טווח כתובות ה-IP של היעד, מזינים 10.30.1.0/24.

  5. בקטע Next hop (הצעד הבא) של המסלול, בוחרים באפשרות Specify a forwarding rule of an internal passthrough Network Load Balancer (ציון כלל העברה של מאזן עומסי רשת פנימי מסוג passthrough).

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

  6. בשדה 'שם כלל ההעברה', בוחרים באפשרות fr-ilb2.

  7. לוחצים על יצירה.

gcloud

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

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

בדוגמה, המסלול הראשון משתמש בכתובת ה-IP‏ 10.30.1.99, והמסלול השני משתמש בשם כלל ההעברה fr-ilb12.

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

gcloud compute routes create ilb-nhop-dest-10-50-1 \
    --network=testing \
    --destination-range=10.50.1.0/24 \
    --next-hop-ilb=10.30.1.99 \
    --tags=my-network-tag

gcloud compute routes create ilb-nhop-dest-10-30-1 \
    --network=production \
    --destination-range=10.30.1.0/24 \
    --next-hop-ilb=fr-ilb2 \
    --next-hop-ilb-region=us-west1

יצירת מכונה וירטואלית testing

בדוגמה הזו נוצרת מכונה וירטואלית עם כתובת ה-IP‏ 10.30.1.100 בtesting-subnet (10.30.1.0/24) ברשת ה-VPC‏ testing.

gcloud

  1. יוצרים את testing-vm על ידי הפעלת הפקודה הבאה.

    gcloud compute instances create testing-vm \
    --zone=us-west1-a \
    --image-family=debian-12 \
    --image-project=debian-cloud \
    --tags=allow-ssh,my-network-tag \
    --subnet=testing-subnet \
    --private-network-ip 10.30.1.100 \
    --metadata=startup-script='#! /bin/bash
    sudo apt-get update
    sudo apt-get install apache2 -y
    sudo a2ensite default-ssl
    sudo a2enmod ssl
    vm_hostname="$(curl -H "Metadata-Flavor:Google" \
    http://metadata.google.internal/computeMetadata/v1/instance/name)"
    echo "Page served from: $vm_hostname" | \
    tee /var/www/html/index.html
    sudo systemctl restart apache2'

יצירת מכונה וירטואלית production

בדוגמה הזו נוצרת מכונה וירטואלית עם כתובת ה-IP‏ 10.50.1.100 בproduction-subnet (10.50.1.0/24) ברשת ה-VPC‏ production.

gcloud

‫production-vm יכול להיות בכל אזור באותו אזור כמו מאזן העומסים, והוא יכול להשתמש בכל רשת משנה באותו אזור. בדוגמה הזו, production-vm נמצא באזור us-west1-a.

  1. יוצרים את production-vm על ידי הפעלת הפקודה הבאה.

    gcloud compute instances create production-vm \
    --zone=us-west1-a \
    --image-family=debian-12 \
    --image-project=debian-cloud \
    --tags=allow-ssh \
    --subnet=production-subnet \
    --private-network-ip 10.50.1.100 \
    --metadata=startup-script='#! /bin/bash
    sudo apt-get update
    sudo apt-get install apache2 -y
    sudo a2ensite default-ssl
    sudo a2enmod ssl
    vm_hostname="$(curl -H "Metadata-Flavor:Google" \
    http://metadata.google.internal/computeMetadata/v1/instance/name)"
    echo "Page served from: $vm_hostname" | \
    tee /var/www/html/index.html
    sudo systemctl restart apache2'

בדיקת איזון עומסים בפריסה עם כמה כרטיסי NIC

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

    gcloud compute backend-services get-health ilb1 --region us-west1

    gcloud compute backend-services get-health ilb2 --region us-west1

  2. בודקים את הקישוריות מהמכונה הווירטואלית testing.

    gcloud compute ssh testing-vm --zone=us-west1-a

    curl http://10.50.1.99

    exit

  3. בודקים את הקישוריות מהמכונה הווירטואלית production.

    gcloud compute ssh production-vm --zone=us-west1-a

    curl http://10.30.1.99

    exit

הפעלה של גיבוב סימטרי

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

אם המסלולים הסטטיים או כללי ההעברה של מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי נוצרו לפני 22 ביוני 2021, צריך לבצע את הפעולות הבאות:

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

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

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

הסרת המשאבים

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

    gcloud compute backend-services remove-backend ilb1 \
    --instance-group=third-party-instance-group \
    --instance-group-region=us-west1 \
    --region=us-west1

    gcloud compute backend-services remove-backend ilb2 \
    --instance-group=third-party-instance-group \
    --instance-group-region=us-west1 \
    --region=us-west1

  2. מוחקים את המסלולים.

    gcloud compute routes delete ilb-nhop-dest-10-50-1

    gcloud compute routes delete ilb-nhop-dest-10-30-1

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

    gcloud compute forwarding-rules delete fr-ilb1 \
    --region=us-west1

    gcloud compute forwarding-rules delete fr-ilb2 \
    --region=us-west1

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

    gcloud compute backend-services delete ilb1 \
    --region=us-west1

    gcloud compute backend-services delete ilb2 \
    --region=us-west1

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

    gcloud compute health-checks delete hc-http-80 \
    --region=us-west1

    אם השתמשתם במסוף Google Cloud , בדיקת התקינות היא גלובלית. לכן, הפקודה היא:

    gcloud compute health-checks delete hc-http-80 \
     --global

  6. מוחקים את קבוצת מופעי המכונה המנוהלים.

    gcloud compute instance-groups managed delete third-party-instance-group \
    --region=us-west1

  7. מוחקים את תבניות המכונות.

    gcloud compute instance-templates delete third-party-template

    gcloud compute instance-templates delete third-party-template-multinic

  8. מוחקים את מופעי הבדיקה והייצור.

    gcloud compute instances delete testing-vm \
    --zone=us-west1-a

    gcloud compute instances delete production-vm \
    --zone=us-west1-a

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