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

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

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

הרשאות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

בדוגמה הזו נעשה שימוש ברשתות 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 , 130.211.0.0/22 ו-35.191.0.0/16). בדוגמה הזו נעשה שימוש בתג היעד allow-health-check כדי לזהות את המופעים שאליהם הכלל צריך לחול.

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

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

המסוף

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

    לדף Firewall policies

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    • Name (שם): fw-allow-production-health-check
    • רשת: production
    • עדיפות: 1000
    • כיוון התנועה: כניסה
    • פעולה בהתאמה: לאפשר
    • יעדים: תגי יעד שצוינו
    • תגי טירגוט: allow-health-check
    • מסנן מקור: טווחים של IPv4
    • טווחי IPv4 של המקור: 130.211.0.0/22 ו-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=130.211.0.0/22,35.191.0.0/16 \
    --rules=tcp

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

    gcloud compute firewall-rules create fw-allow-production-health-check \
    --network=production \
    --action=allow \
    --direction=ingress \
    --target-tags=allow-health-check \
    --source-ranges=130.211.0.0/22,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 כדי שמופעי VM שנוצרו מהתבנית יוכלו להעביר מנות ממופעים אחרים ברשתות 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

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

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

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

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

  • כלל העברה. למרות שכלל ההעברה הזה מציין יציאת TCP‏ 80, כשמאזן העומסים הוא ה-Next Hop של מסלול, תעבורת נתונים בכל יציאת TCP או UDP נשלחת אל ה-Backends של מאזן העומסים.

  • כתובת 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. ברשימה בדיקת תקינות, לוחצים על יצירת בדיקת תקינות ומזינים את הפרטים הבאים:
      • 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. Subnetwork: 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. בקטע פריט חדש של קצה עורפי, בוחרים את קבוצת המופעים third-party-instance-group ולוחצים על סיום.
    2. בקטע Health check (בדיקת תקינות), בוחרים באפשרות hc-http-80.
    3. בקטע Session affinity (זיקה לסשן), בוחרים באפשרות Client IP (כתובת IP של לקוח).
    4. לפני שממשיכים, מוודאים שלצד Backend configuration מופיע סימן אישור כחול. אם לא, צריך לבדוק את השלב הזה.
  5. לוחצים על Frontend configuration. בקטע New Frontend IP and port מבצעים את השינויים הבאים:
    1. Name (שם): fr-ilb2
    2. Subnetwork: 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. בשדה הניתוב הבא של המסלול, בוחרים באפשרות ציון כלל העברה של מאזן עומסים פנימי מסוג TCP/UDP.

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

    כדי לציין את כתובת ה-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

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

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

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

מידע נוסף זמין במאמר בנושא גיבוב סימטרי.

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

המסוף

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

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

    כניסה לדף איזון עומסים

  2. לוחצים על מאזן העומסים be-ilb ואז על עריכה.

  3. לוחצים על Frontend configuration.

  4. מעבירים את העכבר מעל כלל ההעברה ולוחצים על מחיקה כדי להסיר אותו.

  5. לוחצים על Add frontend IP and port.

  6. בקטע New Frontend IP and port, מבצעים את השינויים הבאים:

    1. Name (שם): FORWARDING_RULE_NAME
    2. Subnetwork: SUBNET_NAME
    3. בקטע כתובת IP פנימית, בוחרים באפשרות IP_ADDRESS.
    4. יציאות: PORT_NUMBER או ALL.
    5. לוחצים על סיום.
    6. לפני שממשיכים, מוודאים שלצד Frontend configuration מופיע סימן אישור כחול. אם לא, צריך לבדוק את השלב הזה.

  7. לוחצים על Review and finalize. כדאי לבדוק שוב את ההגדרות.

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

gcloud

  1. מוחקים את כללי ההעברה הקיימים.

    gcloud compute forwarding-rules delete FORWARDING_RULE_NAME \
    --region=REGION

  2. יוצרים כללי העברה חלופיים עם אותו שם.

    gcloud compute forwarding-rules create FORWARDING_RULE_NAME \
    --load-balancing-scheme=internal \
    --ports=PORT_NUMBER or `ALL` \
    --network=NETWORK_NAME \
    --subnet=SUBNET_NAME \
    --region=REGION \
    --backend-service=BACKEND_SERVICE_NAME \
    --address=IP_ADDRESS

מתי לא צריך SNAT

כפי שמוצג בדוגמה הקודמת, תרגום כתובות רשת של המקור (SNAT) לא נדרש אם כל התנאים הבאים מתקיימים:

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

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

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

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

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

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

הסרת המשאבים

  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

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