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

במדריך הזה מוסבר באמצעות דוגמה איך להגדיר יתירות כשל (failover) עבור מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי (passthrough). Google Cloud לפני שממשיכים במדריך הזה, כדאי להכיר את המושגים הבאים:

הרשאות

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

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

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

הגדרה

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

  1. רשת VPC לדוגמה עם רשתות משנה מותאמות אישית
  2. כללי חומת אש שמאפשרים חיבורים נכנסים למכונות וירטואליות עורפיות
  3. מכונות וירטואליות לקצה העורפי:
    • קצה עורפי ראשי אחד בקבוצת מופעים לא מנוהלת באזור us-west1-a
    • שרת backend אחד למעבר אוטומטי לגיבוי בקבוצת מופעים לא מנוהלת באזור us-west1-c
  4. מכונה וירטואלית אחת של לקוח לבדיקת חיבורים ולמעקב אחרי התנהגות המעבר לגיבוי (failover)
  5. הרכיבים הבאים של מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי:
    • בדיקת תקינות של שירות הקצה העורפי
    • שירות פנימי לקצה העורפי באזור us-west1 לניהול חלוקת החיבורים בין המכונות הווירטואליות בקצה העורפי
    • כלל העברה פנימי וכתובת IP פנימית לקצה הקדמי של מאזן העומסים

הארכיטקטורה של הדוגמה הזו נראית כך:

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

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

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

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

  • רשת: הרשת היא רשת VPC במצב מותאם אישית בשם lb-network.

  • אזור: האזור הוא us-west1.

  • רשת משנה: רשת המשנה, lb-subnet, משתמשת בטווח כתובות ה-IP‏ 10.1.2.0/24.

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

המסוף

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

    מעבר לרשתות VPC

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

  3. מזינים שם של lb-network.

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

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

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

gcloud

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

    gcloud compute networks create lb-network --subnet-mode=custom

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

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

API

שולחים בקשת POST אל ה-method‏ networks.insert.

‫POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks

{
 "routingConfig": {
   "routingMode": "REGIONAL"
 },
 "name": "lb-network",
 "autoCreateSubnetworks": false
}

שולחים בקשת POST אל ה-method‏ subnetworks.insert. מחליפים את PROJECT_ID במזהה הפרויקט ב- Google Cloud .

‫POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/subnetworks

{
 "name": "lb-subnet",
 "network": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network",
 "ipCidrRange": "10.1.2.0/24",
 "privateIpGoogleAccess": false
}

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

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

  • ‫fw-allow-lb-subnet: כלל כניסה (ingress) שחל על כל היעדים ברשת ה-VPC, ומאפשר תעבורה ממקורות בטווח 10.1.2.0/24. הכלל הזה מאפשר תעבורה נכנסת מכל מקור בתוך lb-subnet למופעים (מכונות וירטואליות) שמתבצע בהם איזון עומסים.

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

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

בלי כללי חומת האש האלה, הכלל default deny ingress חוסם תנועה נכנסת למופעי ה-Backend.

המסוף

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

    לדף Firewall policies

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

    • Name (שם): fw-allow-lb-subnet
    • רשת: lb-network
    • עדיפות: 1000
    • כיוון התנועה: כניסה
    • פעולה בהתאמה: לאפשר
    • יעדים: כל המופעים ברשת
    • מסנן מקור: טווחים של IPv4
    • טווחים של כתובות IPv4 של המקור: 10.1.2.0/24
    • Protocols and ports: Allow all

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

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

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

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

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

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

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

gcloud

  1. יוצרים את כלל חומת האש fw-allow-lb-subnet כדי לאפשר תקשורת מתוך תת-הרשת:

    gcloud compute firewall-rules create fw-allow-lb-subnet \
    --network=lb-network \
    --action=allow \
    --direction=ingress \
    --source-ranges=10.1.2.0/24 \
    --rules=tcp,udp,icmp

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

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

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

    gcloud compute firewall-rules create fw-allow-health-check \
    --network=lb-network \
    --action=allow \
    --direction=ingress \
    --target-tags=allow-health-check \
    --source-ranges=130.211.0.0/22,35.191.0.0/16 \
    --rules=tcp,udp,icmp

API

כדי ליצור את הכלל לחומת האש fw-allow-lb-subnet, שולחים בקשת POST אל ה-method‏ firewalls.insert. מחליפים את PROJECT_ID במזהה הפרויקט ב- Google Cloud .

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls

{
 "name": "fw-allow-lb-subnet",
 "network": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network",
 "priority": 1000,
 "sourceRanges": [
   "10.1.2.0/24"
 ],
 "allowed": [
   {
     "IPProtocol": "tcp"
   },
   {
     "IPProtocol": "udp"
   },
   {
     "IPProtocol": "icmp"
   }
 ],
 "direction": "INGRESS",
 "logConfig": {
   "enable": false
 },
 "disabled": false
}

כדי ליצור את הכלל לחומת האש fw-allow-ssh, שולחים בקשת POST אל ה-method‏ firewalls.insert. מחליפים את PROJECT_ID במזהה הפרויקט ב- Google Cloud .

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls

{
 "name": "fw-allow-ssh",
      "network": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network",
 "priority": 1000,
 "sourceRanges": [
   "0.0.0.0/0"
 ],
 "targetTags": [
   "allow-ssh"
 ],
 "allowed": [
  {
    "IPProtocol": "tcp",
    "ports": [
      "22"
    ]
  }
 ],
"direction": "INGRESS",
"logConfig": {
  "enable": false
},
"disabled": false
}

כדי ליצור את הכלל לחומת האש fw-allow-health-check, שולחים בקשת POST אל ה-method‏ firewalls.insert. מחליפים את PROJECT_ID במזהה הפרויקט ב- Google Cloud .

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls

{
 "name": "fw-allow-health-check",
 "network": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network",
 "priority": 1000,
 "sourceRanges": [
   "130.211.0.0/22",
   "35.191.0.0/16"
 ],
 "targetTags": [
   "allow-health-check"
 ],
 "allowed": [
   {
     "IPProtocol": "tcp"
   },
   {
     "IPProtocol": "udp"
   },
   {
     "IPProtocol": "icmp"
   }
 ],
 "direction": "INGRESS",
 "logConfig": {
   "enable": false
 },
 "disabled": false
}

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

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

  • קבוצת המכונות ig-a באזור us-west1-a היא קצה עורפי ראשי עם שתי מכונות וירטואליות:
    • vm-a1
    • vm-a2
  • קבוצת המופעים ig-c ב-us-west1-c היא קצה עורפי ליתירות כשל עם שני VM-ים:
    • vm-c1
    • vm-c2

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

כל מכונה וירטואלית ראשית ומכונה וירטואלית ליתירות כשל מוגדרות להפעלת שרת אינטרנט של Apache ביציאות TCP‏ 80 ו-443. לכל מכונה וירטואלית מוקצית כתובת IP פנימית ב-lb-subnet לגישת לקוח, וכתובת IP חיצונית (ציבורית) זמנית לגישת SSH. מידע על הסרת כתובות IP חיצוניות זמין במאמר בנושא הסרת כתובות IP חיצוניות ממכונות וירטואליות של קצה עורפי.

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

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

כדי לפשט את ההוראות, כל המכונות הווירטואליות הראשיות ומכונות הגיבוי מריצות Debian GNU/Linux 12.

המסוף

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

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

    כניסה לדף VM instances

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

    • שם: vm-a1, אזור: us-west1-a
    • שם: vm-a2, אזור: us-west1-a
    • שם: vm-c1, אזור: us-west1-c
    • שם: vm-c2, אזור: us-west1-c

  3. לוחצים על Create instance.

  4. מגדירים את השם כמו שמופיע בשלב 2.

  5. בקטע Region, בוחרים באפשרות us-west1, ובקטע Zone בוחרים באזור כמו שמוסבר בשלב 2.

  6. בקטע Boot disk מוודאים שהתמונה שנבחרה היא Debian GNU/Linux 12 (bookworm)‎. אם צריך, לוחצים על בחירה כדי לשנות את התמונה.

  7. לוחצים על אפשרויות מתקדמות.

  8. לוחצים על Networking ומגדירים את השדות הבאים:

    1. בשדה Network tags (תגי רשת), מזינים את הערכים allow-health-check ו-allow-ssh.
    2. בקטע Network interfaces (ממשקי רשת), בוחרים באפשרויות הבאות:
      • רשת: lb-network
      • Subnet: lb-subnet

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

    #! /bin/bash
apt-get update
apt-get install apache2 -y
a2ensite default-ssl
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
systemctl restart apache2

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

יצירת קבוצות של מכונות וירטואליות

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

    כניסה לדף Instance groups

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

    • קבוצת מופעים: ig-a, אזור: us-west1-a, מכונות וירטואליות: vm-a1 ו-vm-a2
    • קבוצת מופעים: ig-c, אזור: us-west1-c, מכונות וירטואליות: vm-c1 ו-vm-c2

  3. לוחצים על יצירת קבוצת מופעים.

  4. לוחצים על קבוצת מופעים חדשה לא מנוהלת.

  5. מגדירים את השם כמו שמוסבר בשלב 2.

  6. בקטע Location, בוחרים us-west1 בשדה Region, ואז בוחרים Zone כמו שמוסבר בשלב 2.

  7. בשדה רשת, מזינים lb-network.

  8. בשדה Subnetwork (רשת משנה), מזינים lb-subnet.

  9. בקטע VM instances, מוסיפים את המכונות הווירטואליות כמו שמוסבר בשלב 2.

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

gcloud

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

    • ‫VM_NAME מתוך vm-a1 ו-ZONE מתוך us-west1-a
    • ‫VM_NAME מתוך vm-a2 ו-ZONE מתוך us-west1-a
    • ‫VM_NAME מתוך vm-c1 ו-ZONE מתוך us-west1-c
    • ‫VM_NAME מתוך vm-c2 ו-ZONE מתוך us-west1-c
    gcloud compute instances create VM_NAME \
    --zone=ZONE \
    --image-family=debian-12 \
    --image-project=debian-cloud \
    --tags=allow-ssh,allow-health-check \
    --subnet=lb-subnet \
    --metadata=startup-script='#! /bin/bash
      apt-get update
      apt-get install apache2 -y
      a2ensite default-ssl
      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
      systemctl restart apache2'

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

    gcloud compute instance-groups unmanaged create ig-a \
    --zone=us-west1-a
gcloud compute instance-groups unmanaged create ig-c \
    --zone=us-west1-c

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

    gcloud compute instance-groups unmanaged add-instances ig-a \
    --zone=us-west1-a \
    --instances=vm-a1,vm-a2
gcloud compute instance-groups unmanaged add-instances ig-c \
    --zone=us-west1-c \
    --instances=vm-c1,vm-c2

API

שולחים ארבע בקשות POST ל-method‏ instances.insert כדי ליצור ארבע מכונות וירטואליות (VM) של קצה עורפי.

למכונות הווירטואליות, משתמשים בשמות ובאזורים הבאים:

  • ‫VM_NAME מתוך vm-a1 ו-ZONE מתוך us-west1-a
  • ‫VM_NAME מתוך vm-a2 ו-ZONE מתוך us-west1-a
  • ‫VM_NAME מתוך vm-c1 ו-ZONE מתוך us-west1-c
  • ‫VM_NAME מתוך vm-c2 ו-ZONE מתוך us-west1-c

מחליפים את מה שכתוב בשדות הבאים:

  • ‫PROJECT_ID: מזהה הפרויקט
  • ‫ZONE: האזור של המכונה

  • ‫DEBIAN_IMAGE_NAME: השם של תמונת Debian עבור המכונה. אפשר לקבל את DEBIAN_IMAGE_NAME הנוכחי על ידי הרצת הפקודה הבאה של gcloud:

    gcloud compute images list \
 --filter="family=debian-12"

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instances

{
 "name": "VM_NAME",
 "tags": {
   "items": [
     "allow-health-check",
     "allow-ssh"
   ]
 },
 "machineType": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/machineTypes/e2-standard-2",
 "canIpForward": false,
 "networkInterfaces": [
   {
     "network": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network",
     "subnetwork": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/subnetworks/lb-subnet",
     "accessConfigs": [
       {
         "type": "ONE_TO_ONE_NAT",
         "name": "external-nat",
         "networkTier": "PREMIUM"
       }
     ]
   }
 ],
 "disks": [
   {
     "type": "PERSISTENT",
     "boot": true,
     "mode": "READ_WRITE",
     "autoDelete": true,
     "deviceName": "VM_NAME",
     "initializeParams": {
       "sourceImage": "projects/debian-cloud/global/images/DEBIAN_IMAGE_NAME",
       "diskType": "projects/PROJECT_ID/zones/ZONE/diskTypes/pd-standard",
       "diskSizeGb": "10"
     }
   }
 ],
 "metadata": {
   "items": [
     {
       "key": "startup-script",
       "value": "#! /bin/bash\napt-get update\napt-get install apache2 -y\na2ensite default-ssl\na2enmod ssl\nvm_hostname=\"$(curl -H \"Metadata-Flavor:Google\" \\\nhttp://metadata.google.internal/computeMetadata/v1/instance/name)\"\necho \"Page served from: $vm_hostname\" | \\\ntee /var/www/html/index.html\nsystemctl restart apache2"
     }
   ]
 },
 "scheduling": {
   "preemptible": false
 },
 "deletionProtection": false
}

כדי ליצור שתי קבוצות של מופעי מכונה, שולחים בקשת POST אל ה-method‏ instanceGroups.insert. מחליפים את PROJECT_ID במזהה הפרויקט ב- Google Cloud .

‫POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-a/instanceGroups

{
 "name": "ig-a",
 "network": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network",
 "subnetwork": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/subnetworks/lb-subnet"
}

‫POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-c/instanceGroups

{
 "name": "ig-c",
 "network": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network",
 "subnetwork": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/subnetworks/lb-subnet"
}

כדי להוסיף מכונות לכל קבוצת מכונות, שולחים בקשת POST אל ה-method‏ instanceGroups.addInstances. מחליפים את PROJECT_ID במזהה הפרויקט ב- Google Cloud .

‫POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-a/instanceGroups/ig-a/addInstances

{
 "instances": [
   {
     "instance": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-a/instances/vm-a1",
     "instance": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-a/instances/vm-a2"
   }
 ]
}

‫POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-c/instanceGroups/ig-c/addInstances

{
 "instances": [
   {
     "instance": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-c/instances/vm-c1",
     "instance": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-c/instances/vm-c2"
   }
 ]
}

יצירת מכונת VM של לקוח

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

המסוף

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

    כניסה לדף VM instances

  2. לוחצים על Create instance.

  3. מגדירים את Name לערך vm-client.

  4. מגדירים את Zone לערך us-west1-a.

  5. לוחצים על אפשרויות מתקדמות.

  6. לוחצים על Networking ומגדירים את השדות הבאים:

    1. בשדה Network tags (תגי רשת), מזינים allow-ssh.
    2. בקטע Network interfaces (ממשקי רשת), בוחרים באפשרויות הבאות:
      • רשת: lb-network
      • Subnet: lb-subnet

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

gcloud

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

gcloud compute instances create vm-client \
    --zone=us-west1-a \
    --image-family=debian-12 \
    --image-project=debian-cloud \
    --tags=allow-ssh \
    --subnet=lb-subnet

API

שולחים בקשת POST אל ה-method‏ instances.insert.

מחליפים את מה שכתוב בשדות הבאים:

  • ‫PROJECT_ID: מזהה הפרויקט

  • ‫DEBIAN_IMAGE_NAME: השם של תמונת Debian עבור המכונה. אפשר לקבל את DEBIAN_IMAGE_NAME הנוכחי על ידי הרצת הפקודה הבאה של gcloud:

    gcloud compute images list \
 --filter="family=debian-12"

‫POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-a/instances

{
 "name": "vm-client",
 "tags": {
   "items": [
     "allow-ssh"
   ]
 },
 "machineType": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-a/machineTypes/e2-standard-2",
 "canIpForward": false,
 "networkInterfaces": [
   {
     "network": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network",
     "subnetwork": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/subnetworks/lb-subnet",
     "accessConfigs": [
       {
         "type": "ONE_TO_ONE_NAT",
         "name": "external-nat",
         "networkTier": "PREMIUM"
       }
     ]
   }
 ],
 "disks": [
   {
     "type": "PERSISTENT",
     "boot": true,
     "mode": "READ_WRITE",
     "autoDelete": true,
     "deviceName": "vm-client",
     "initializeParams": {
       "sourceImage": "projects/debian-cloud/global/images/DEBIAN_IMAGE_NAME",
       "diskType": "projects/PROJECT_ID/zones/us-west1-a/diskTypes/pd-standard",
       "diskSizeGb": "10"
     }
   }
 ],
 "scheduling": {
   "preemptible": false
 },
 "deletionProtection": false
}

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

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

  • בדיקת תקינות: בדוגמה הזו נעשה שימוש בבדיקת תקינות של HTTP שפשוט בודקת אם יש תגובת HTTP 200 (OK). מידע נוסף מופיע בקטע בנושא בדיקות תקינות בסקירה הכללית של מאזן עומסי רשת פנימי מסוג passthrough.

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

  • כלל העברה: בדוגמה הזו נוצר כלל העברה פנימי יחיד.

  • כתובת IP פנימית: בדוגמה הזו, אנחנו מציינים כתובת IP פנימית, 10.1.2.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. מגדירים את Name לערך be-ilb.
  2. מגדירים את Region לערך us-west1.
  3. מגדירים את Network לערך lb-network.
  4. לוחצים על Backend configuration ומבצעים את השינויים הבאים:
    1. בקטע New item (פריט חדש) של Backends (שרתי קצה עורפי), בוחרים את קבוצת המכונות ig-a. מוודאים שהתיבה Use this instance group as a failover group for backup (שימוש בקבוצת המכונות הזו כקבוצת מעבר לגיבוי במקרה של כשל) לא מסומנת. לוחצים על סיום.
    2. לוחצים על הוספת קצה עורפי. בקטע New item שמופיע, בוחרים את קבוצת המופעים ig-c. מסמנים את התיבה Use this instance group as a failover group for backup (שימוש בקבוצת המכונות הזו כקבוצת מעבר לגיבוי). לוחצים על סיום.
    3. בקטע בדיקת תקינות, בוחרים באפשרות יצירת בדיקת תקינות נוספת, מזינים את הפרטים הבאים ולוחצים על שמירה והמשך:
      • Name (שם): hc-http-80
      • פרוטוקול: HTTP
      • יציאה: 80
      • פרוטוקול פרוקסי: NONE
      • נתיב הבקשה: / שימו לב: כשמשתמשים במסוף Google Cloud כדי ליצור מאזן עומסים, בדיקת התקינות היא גלובלית. אם רוצים ליצור בדיקת תקינות אזורית, משתמשים ב-gcloud או ב-API.
    4. לוחצים על הגדרות מתקדמות. בקטע Failover policy (מדיניות מעבר לגיבוי), מגדירים את האפשרויות הבאות:
      • יחס מעבר לגיבוי: 0.75
      • מסמנים את התיבה Enable connection draining on failover (הפעלת ניתוק הדרגתי של חיבורים במעבר לגיבוי).
    5. לפני שממשיכים, מוודאים שלצד Backend configuration מופיע סימן אישור כחול. אם לא, צריך לבדוק את השלב הזה.
  5. לוחצים על Frontend configuration. בקטע New Frontend IP and port מבצעים את השינויים הבאים:
    1. Name (שם): fr-ilb
    2. Subnetwork: ilb-subnet
    3. בקטע כתובת IP פנימית, בוחרים באפשרות Reserve a static internal IP address, מזינים את הפרטים הבאים ולוחצים על Reserve:
      • Name (שם): ip-ilb
      • כתובת IP סטטית: אני רוצה לבחור
      • כתובת IP מותאמת אישית: 10.1.2.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. יוצרים את שירות הקצה העורפי לתנועת HTTP:

    gcloud compute backend-services create be-ilb \
    --load-balancing-scheme=internal \
    --protocol=tcp \
    --region=us-west1 \
    --health-checks=hc-http-80 \
    --health-checks-region=us-west1 \
    --failover-ratio 0.75

  3. מוסיפים את העורף הראשי לשירות לקצה העורפי:

    gcloud compute backend-services add-backend be-ilb \
    --region=us-west1 \
    --instance-group=ig-a \
    --instance-group-zone=us-west1-a

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

    gcloud compute backend-services add-backend be-ilb \
    --region=us-west1 \
    --instance-group=ig-c \
    --instance-group-zone=us-west1-c \
    --failover

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

    gcloud compute forwarding-rules create fr-ilb \
    --region=us-west1 \
    --load-balancing-scheme=internal \
    --network=lb-network \
    --subnet=lb-subnet \
    --address=10.1.2.99 \
    --ip-protocol=TCP \
    --ports=80 \
    --backend-service=be-ilb \
    --backend-service-region=us-west1

API

כדי ליצור בדיקת תקינות, שולחים בקשת POST אל ה-method‏ regionHealthChecks.insert. מחליפים את PROJECT_ID במזהה הפרויקט.

‫POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/regionHealthChecks

{
"name": "hc-http-80",
"type": "HTTP",
"httpHealthCheck": {
  "port": 80
}
}

כדי ליצור את השירות לקצה עורפי אזורי, שולחים בקשת POST אל ה-method‏ regionBackendServices.insert. מחליפים את PROJECT_ID במזהה הפרויקט.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/backendServices

{
"name": "be-ilb",
"backends": [
  {
    "group": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-a/instanceGroups/ig-a",
    "balancingMode": "CONNECTION"
  },
  {
    "group": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-c/instanceGroups/ig-c",
    "balancingMode": "CONNECTION"
    "failover": true
  }
],
"failoverPolicy": {
  "failoverRatio": 0.75
},
"healthChecks": [
  "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/healthChecks/hc-http-80"
],
"loadBalancingScheme": "INTERNAL"
}

כדי ליצור את כלל ההעברה, שולחים בקשת POST אל ה-method‏ forwardingRules.insert. מחליפים את PROJECT_ID במזהה הפרויקט.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/forwardingRules

{
"name": "fr-ilb",
"IPAddress": "10.1.2.99",
"IPProtocol": "TCP",
"ports": [
  "80", "8008", "8080", "8088"
],
"loadBalancingScheme": "INTERNAL",
"subnetwork": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/subnetworks/lb-subnet",
"network": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network",
"backendService": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/backendServices/be-ilb",
"networkTier": "PREMIUM"
}

בדיקה

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

תהליך בדיקה של לקוח

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

  1. מתחברים למופע ה-VM של הלקוח.

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

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

    curl http://10.1.2.99

  3. שימו לב לטקסט שמוחזר על ידי הפקודה curl. השם של מכונת ה-VM של ה-Backend שמייצרת את התגובה מוצג בטקסט הזה. לדוגמה: Page served from: vm-a1

בדיקת המצב ההתחלתי

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

  • שתי המכונות הווירטואליות הראשיות, vm-a1 ו-vm-a2
  • שתי מכונות ה-VM למעבר לגיבוי, vm-c1 ו-vm-c2

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

בדיקת מעבר לשירות גיבוי

הבדיקה הזו מדמה כשל של vm-a1 כדי שתוכלו לראות את התנהגות המעבר לגיבוי.

  1. מתחברים למכונה הווירטואלית vm-a1.

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

  2. עוצרים את שרת האינטרנט של Apache. אחרי עשר שניות, Google Cloud המערכת מחשיבה את המכונה הווירטואלית הזו כלא תקינה. (בבדיקת התקינות hc-http-80 שיצרתם בהגדרה נעשה שימוש במרווח ברירת המחדל של חמש שניות בין הבדיקות ובסף ברירת המחדל של שתי בדיקות רצופות שנכשלו).

    sudo apachectl stop

  3. פועלים לפי ההליך לבדיקת הלקוח. חוזרים על השלב השני כמה פעמים. ההתנהגות הצפויה היא שחיבורים חדשים יתחלקו בין שתי מכונות וירטואליות תקינות ליתירות כשל, vm-c1 ו-vm-c2. זה קורה כי רק מכונה וירטואלית ראשית אחת, vm-a2, תקינה, והיחס בין מכונות וירטואליות ראשיות תקינות לבין סך המכונות הווירטואליות הראשיות הוא 0.5 – פחות מסף המעבר לגיבוי של 0.75. כל מכונה וירטואלית ליתירות כשל מספקת תגובה בערך מחצית מהזמן כל עוד הזיקה לסשן (session affinity) מוגדרת ל-NONE.

בדיקת מעבר חזרה

בבדיקה הזו מתבצעת סימולציה של חזרה למצב תקין על ידי הפעלה מחדש של שרת Apache בכתובת vm-a1.

  1. מתחברים למכונה הווירטואלית vm-a1.

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

  2. מפעילים את שרת האינטרנט של Apache וממתינים 10 שניות.

    sudo apachectl start

  3. פועלים לפי ההליך לבדיקת הלקוח. חוזרים על השלב השני כמה פעמים. ההתנהגות הצפויה היא שהתנועה תגיע משני המכונות הווירטואליות הראשיות, vm-a1 ו-vm-a2. אם שתי המכונות הווירטואליות הראשיות תקינות, היחס בין המכונות הווירטואליות הראשיות התקינות לבין סך כל המכונות הווירטואליות הראשיות הוא 1.0, שהוא גדול מסף המעבר לגיבוי (failover) של 0.75, ולכן הקצוות העורפיים שעומדים בדרישות של מאזן העומסים כוללים את כל המכונות הווירטואליות הראשיות התקינות.

הוספת עוד מכונות וירטואליות בבק-אנד

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

  • קבוצת מכונות שלישית, ig-d ב-us-west1-c, משמשת כקצה עורפי ראשי עם שתי מכונות וירטואליות:
    • vm-d1
    • vm-d2
  • קבוצת מכונות רביעית, ig-b ב-us-west1-a, משמשת כקצה עורפי למעבר לגיבוי עם שתי מכונות וירטואליות:
    • vm-b1
    • vm-b2

הארכיטקטורה ששונתה בדוגמה הזו נראית כך:

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

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

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

המסוף

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

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

    כניסה לדף VM instances

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

    • שם: vm-b1, אזור: us-west1-a
    • שם: vm-b2, אזור: us-west1-a
    • שם: vm-d1, אזור: us-west1-c
    • שם: vm-d2, אזור: us-west1-c

  3. לוחצים על Create instance.

  4. מגדירים את השם כמו שמופיע בשלב 2.

  5. בקטע Region, בוחרים באפשרות us-west1, ובקטע Zone בוחרים באזור כמו שמוסבר בשלב 2.

  6. בקטע Boot disk מוודאים שהתמונה שנבחרה היא Debian GNU/Linux 12 (bookworm)‎. אם צריך, לוחצים על בחירה כדי לשנות את התמונה.

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

    • לוחצים על Networking ומוסיפים את Network tags (תגי רשת) הבאים: allow-ssh ו-allow-health-check
    • לוחצים על לחצן העריכה בקטע Network interfaces, מבצעים את השינויים הבאים ולוחצים על Done:
      • רשת: lb-network
      • Subnet: lb-subnet
      • כתובת IP פנימית ראשית: זמנית (אוטומטית)
      • כתובת IP חיצונית: זמנית

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

      #! /bin/bash
apt-get update
apt-get install apache2 -y
a2ensite default-ssl
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
systemctl restart apache2

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

יצירת קבוצות של מכונות וירטואליות

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

    כניסה לדף Instance groups

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

    • קבוצת מופעים: ig-b, אזור: us-west1-a, מכונות וירטואליות: vm-b1 ו-vm-b2
    • קבוצת מופעים: ig-d, אזור: us-west1-c, מכונות וירטואליות: vm-d1 ו-vm-d2

  3. לוחצים על יצירת קבוצת מופעים.

  4. לוחצים על קבוצת מופעים חדשה לא מנוהלת.

  5. מגדירים את השם כמו שמוסבר בשלב 2.

  6. בקטע Location, בוחרים us-west1 בשדה Region, ואז בוחרים Zone כמו שמוסבר בשלב 2.

  7. בשדה רשת, מזינים lb-network.

  8. בשדה Subnetwork (רשת משנה), מזינים lb-subnet.

  9. בקטע VM instances, מוסיפים את המכונות הווירטואליות כמו שמוסבר בשלב 2.

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

gcloud

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

    • ‫VM_NAME מתוך vm-b1 ו-ZONE מתוך us-west1-a
    • ‫VM_NAME מתוך vm-b2 ו-ZONE מתוך us-west1-a
    • ‫VM_NAME מתוך vm-d1 ו-ZONE מתוך us-west1-c
    • ‫VM_NAME מתוך vm-d2 ו-ZONE מתוך us-west1-c
    gcloud compute instances create VM_NAME \
    --zone=ZONE \
    --image-family=debian-12 \
    --image-project=debian-cloud \
    --tags=allow-ssh,allow-health-check \
    --subnet=lb-subnet \
    --metadata=startup-script='#! /bin/bash
      apt-get update
      apt-get install apache2 -y
      a2ensite default-ssl
      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
      systemctl restart apache2'

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

    gcloud compute instance-groups unmanaged create ig-b \
    --zone=us-west1-a
gcloud compute instance-groups unmanaged create ig-d \
    --zone=us-west1-c

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

    gcloud compute instance-groups unmanaged add-instances ig-b \
    --zone=us-west1-a \
    --instances=vm-b1,vm-b2
gcloud compute instance-groups unmanaged add-instances ig-d \
    --zone=us-west1-c \
    --instances=vm-d1,vm-d2

API

שולחים ארבע בקשות POST ל-method‏ instances.insert כדי ליצור ארבע מכונות וירטואליות (VM) של קצה עורפי.

למכונות הווירטואליות, משתמשים בשמות ובאזורים הבאים:

  • ‫VM_NAME מתוך vm-b1 ו-ZONE מתוך us-west1-a
  • ‫VM_NAME מתוך vm-b2 ו-ZONE מתוך us-west1-a
  • ‫VM_NAME מתוך vm-d1 ו-ZONE מתוך us-west1-c
  • ‫VM_NAME מתוך vm-d2 ו-ZONE מתוך us-west1-c

מחליפים את מה שכתוב בשדות הבאים:

  • ‫PROJECT_ID: מזהה הפרויקט

  • ‫DEBIAN_IMAGE_NAME: השם של תמונת Debian עבור המכונה. אפשר לקבל את DEBIAN_IMAGE_NAME הנוכחי על ידי הרצת הפקודה הבאה של gcloud:

    gcloud compute images list \
 --filter="family=debian-12"

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instances

{
 "name": "VM_NAME",
 "tags": {
   "items": [
     "allow-health-check",
     "allow-ssh"
   ]
 },
 "machineType": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/machineTypes/e2-standard-2",
 "canIpForward": false,
 "networkInterfaces": [
   {
     "network": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network",
     "subnetwork": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/subnetworks/lb-subnet",
     "accessConfigs": [
       {
         "type": "ONE_TO_ONE_NAT",
         "name": "external-nat",
         "networkTier": "PREMIUM"
       }
     ]
   }
 ],
 "disks": [
   {
     "type": "PERSISTENT",
     "boot": true,
     "mode": "READ_WRITE",
     "autoDelete": true,
     "deviceName": "VM_NAME",
     "initializeParams": {
       "sourceImage": "projects/debian-cloud/global/images/DEBIAN_IMAGE_NAME",
       "diskType": "projects/PROJECT_ID/zones/ZONE/diskTypes/pd-standard",
       "diskSizeGb": "10"
     }
   }
 ],
 "metadata": {
   "items": [
     {
       "key": "startup-script",
       "value": "#! /bin/bash\napt-get update\napt-get install apache2 -y\na2ensite default-ssl\na2enmod ssl\nvm_hostname=\"$(curl -H \"Metadata-Flavor:Google\" \\\nhttp://metadata.google.internal/computeMetadata/v1/instance/name)\"\necho \"Page served from: $vm_hostname\" | \\\ntee /var/www/html/index.html\nsystemctl restart apache2"
     }
   ]
 },
 "scheduling": {
   "preemptible": false
 },
 "deletionProtection": false
}

כדי ליצור שתי קבוצות של מופעי מכונה, שולחים בקשת POST אל ה-method‏ instanceGroups.insert. מחליפים את PROJECT_ID במזהה הפרויקט.

‫POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-a/instanceGroups

{
 "name": "ig-b",
 "network": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network",
 "subnetwork": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/subnetworks/lb-subnet"
}

‫POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-c/instanceGroups

{
 "name": "ig-d",
 "network": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network",
 "subnetwork": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/subnetworks/lb-subnet"
}

כדי להוסיף מכונות לכל קבוצת מכונות, שולחים בקשת POST אל ה-method‏ instanceGroups.addInstances. מחליפים את PROJECT_ID במזהה הפרויקט.

‫POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-a/instanceGroups/ig-b/addInstances

{
 "instances": [
   {
     "instance": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-a/instances/vm-b1",
     "instance": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-a/instances/vm-b2"
   }
 ]
}

‫POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-c/instanceGroups/ig-d/addInstances

{
 "instances": [
   {
     "instance": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-c/instances/vm-d1",
     "instance": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-c/instances/vm-d2"
   }
 ]
}

הוספת קצה עורפי ראשי

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

המסוף

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

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

  2. בכרטיסייה Load balancers (מאזני עומסים), לוחצים על השם של מאזן עומסים פנימי קיים מסוג TCP או UDP (בדוגמה הזו, be-ilb).

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

  4. בקטע Backend configuration, לוחצים על Add backend ובוחרים קבוצת מופעים לא מנוהלת (בדוגמה הזו, ig-d).

  5. מוודאים שהתיבה Use this instance group as a failover group for backup (שימוש בקבוצת המכונות הזו כקבוצת מעבר לגיבוי) לא מסומנת.

  6. לוחצים על Done (סיום) ואז על Update (עדכון).

gcloud

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

gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
   --instance-group INSTANCE_GROUP_NAME \
   --instance-group-zone INSTANCE_GROUP_ZONE \
   --region REGION

מחליפים את מה שכתוב בשדות הבאים:

  • ‫BACKEND_SERVICE_NAME: השם של שירות הקצה העורפי של מאזן העומסים. בדוגמה הזו, משתמשים ב-be-ilb.
  • ‫INSTANCE_GROUP_NAME: השם של קבוצת המכונות שרוצים להוסיף כקצה עורפי ראשי. בדוגמה הזו, משתמשים ב-ig-d.
  • ‫INSTANCE_GROUP_ZONE: האזור שבו מוגדרת קבוצת המכונות. בדוגמה הזו, משתמשים ב-us-west1-c.
  • ‫REGION: האזור של מאזן העומסים. בדוגמה הזו, משתמשים ב-us-west1.

API

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

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_NAME

{
  "backends":
  [
    {
      "balancingMode": "connection",
      "failover": false,
      "group": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/INSTANCE_GROUP_ZONE/instanceGroups/INSTANCE_GROUP_NAME"
    }
  ]
}

מחליפים את מה שכתוב בשדות הבאים:

  • ‫PROJECT_ID: מזהה הפרויקט
  • ‫REGION: האזור של מאזן העומסים. בדוגמה, משתמשים ב-us-west1.
  • ‫BACKEND_SERVICE_NAME: השם של שירות הקצה העורפי של מאזן העומסים. בדוגמה הזו, משתמשים ב-be-ilb.
  • ‫INSTANCE_GROUP_NAME: השם של קבוצת המכונות שרוצים להוסיף כקצה עורפי ראשי. בדוגמה הזו, משתמשים ב-ig-d.
  • ‫INSTANCE_GROUP_ZONE: האזור שבו מוגדרת קבוצת המכונות. בדוגמה הזו, משתמשים ב-us-west1-c.

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

אפשר להשתמש בהליך הזה כתבנית להוספת קבוצת מופעים לא מנוהלת לשירות לקצה העורפי קיים של מאזן עומסי רשת פנימי מסוג passthrough כבק-אנד ליתירות כשל. בדוגמה להגדרה, התהליך הזה מראה איך להוסיף את קבוצת המופעים ig-b כבק-אנד ליתירות כשל למאזן העומסים (LB) be-ilb.

המסוף

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

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

  2. בכרטיסייה מאזני עומסים, לוחצים על השם של מאזן עומסים קיים מסוג TCP/UDP (פנימי) (בדוגמה הזו, be-ilb).

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

  4. בקטע Backend configuration, לוחצים על Add backend ובוחרים קבוצת מופעים לא מנוהלת (בדוגמה הזו, ig-b).

  5. מסמנים את התיבה Use this instance group as a failover group for backup (שימוש בקבוצת המכונות הזו כקבוצת מעבר לגיבוי).

  6. לוחצים על Done (סיום) ואז על Update (עדכון).

gcloud

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

gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
   --instance-group INSTANCE_GROUP_NAME \
   --instance-group-zone INSTANCE_GROUP_ZONE \
   --region REGION \
   --failover

מחליפים את מה שכתוב בשדות הבאים:

  • ‫BACKEND_SERVICE_NAME: השם של שירות הקצה העורפי של מאזן העומסים. בדוגמה הזו, משתמשים ב-be-ilb.
  • ‫INSTANCE_GROUP_NAME: השם של קבוצת המכונות שרוצים להוסיף כקצה עורפי ראשי. בדוגמה הזו, משתמשים ב-ig-b.
  • ‫INSTANCE_GROUP_ZONE: האזור שבו מוגדרת קבוצת המכונות. בדוגמה הזו, משתמשים ב-us-west1-a.
  • ‫REGION הוא האזור של מאזן העומסים. בדוגמה הזו, משתמשים ב-us-west1.

API

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

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_NAME

{
  "backends":
  [
    {
      "balancingMode": "connection",
      "failover": true,
      "group": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/INSTANCE_GROUP_ZONE/instanceGroups/INSTANCE_GROUP_NAME"
    }
  ]
}

מחליפים את מה שכתוב בשדות הבאים:

  • ‫PROJECT_ID: מזהה הפרויקט
  • ‫BACKEND_SERVICE_NAME: השם של שירות הקצה העורפי של מאזן העומסים. בדוגמה הזו, משתמשים ב-be-ilb.
  • ‫INSTANCE_GROUP_NAME: השם של קבוצת המכונות שרוצים להוסיף כקצה עורפי ראשי. בדוגמה הזו, משתמשים ב-ig-b.
  • ‫INSTANCE_GROUP_ZONE: האזור שבו מוגדרת קבוצת המכונות. בדוגמה הזו, משתמשים ב-us-west1-a.
  • ‫REGION: האזור של מאזן העומסים. בדוגמה הזו, משתמשים ב-us-west1.

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

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

המסוף

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

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

  2. בכרטיסייה Load balancers, לוחצים על השם של מאזן עומסים קיים מסוג TCP/UDP (Internal).

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

  4. בקטע Backend configuration, לוחצים על השם של אחת מקבוצות המופעים של ה-Backend. לאחר מכן:

    • כדי להגדיר את קבוצת המכונות כקצה עורפי למעבר לגיבוי במקרה של כשל, מסמנים את התיבה Use this instance group as a failover group for backup (שימוש בקבוצת המכונות הזו כקבוצת מעבר לגיבוי במקרה של כשל).
    • כדי להגדיר את קבוצת המופעים כקצה עורפי ראשי, מבטלים את הסימון של התיבה Use this instance group as a failover group for backup (שימוש בקבוצת המופעים הזו כקבוצת מעבר לגיבוי).

  5. לוחצים על Done (סיום) ואז על Update (עדכון).

gcloud

משתמשים בפקודה gcloud הבאה כדי להמיר בק-אנד ראשי קיים לבק-אנד יתירות כשל:

gcloud compute backend-services update-backend BACKEND_SERVICE_NAME \
   --instance-group INSTANCE_GROUP_NAME \
   --instance-group-zone INSTANCE_GROUP_ZONE \
   --region REGION \
   --failover

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

gcloud compute backend-services update-backend BACKEND_SERVICE_NAME \
   --instance-group INSTANCE_GROUP_NAME \
   --instance-group-zone INSTANCE_GROUP_ZONE \
   --region REGION \
   --no-failover

מחליפים את מה שכתוב בשדות הבאים:

  • ‫BACKEND_SERVICE_NAME: השם של השירות לקצה העורפי של מאזן העומסים
  • ‫INSTANCE_GROUP_NAME: השם של קבוצת המופעים שרוצים להוסיף כקצה עורפי ראשי
  • ‫INSTANCE_GROUP_ZONE: האזור שבו מוגדרת קבוצת המופעים
  • ‫REGION: האזור של מאזן העומסים

API

כדי להמיר בק-אנד ראשי לבק-אנד יתירות כשל, או להיפך, משתמשים בשיטה regionBackendServices.patch.

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

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_NAME

{
  "backends":
  [
    {
      "failover": true,
      "group": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/INSTANCE_GROUP_ZONE/instanceGroups/INSTANCE_GROUP_NAME"
    }
  ]
}

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

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_NAME

{
  "backends":
  [
    {
      "failover": false,
      "group": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/INSTANCE_GROUP_ZONE/instanceGroups/INSTANCE_GROUP_NAME"
    }
  ],
}

מחליפים את מה שכתוב בשדות הבאים:

  • ‫PROJECT_ID: מזהה הפרויקט
  • ‫BACKEND_SERVICE_NAME: השם של השירות לקצה העורפי של מאזן העומסים
  • ‫INSTANCE_GROUP_NAME: השם של קבוצת המופעים שרוצים להוסיף כקצה עורפי ראשי
  • ‫INSTANCE_GROUP_ZONE: האזור שבו מוגדרת קבוצת המופעים
  • ‫REGION: האזור של מאזן העומסים

הגדרת מדיניות מעבר לגיבוי (failover)

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

הגדרת מדיניות יתירות כשל

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

המסוף

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

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

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

  2. בכרטיסייה מאזני עומסים, לוחצים על השם של מאזן עומסים קיים מסוג TCP/UDP (פנימי).

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

  4. מוודאים שיש לפחות שרת קצה עורפי אחד למעבר אוטומטי לגיבוי. צריך לבחור לפחות אחד מהעורפים של מאזן העומסים באפשרות Use this instance group as a failover group for backup (שימוש בקבוצת המופעים הזו כקבוצת מעבר לגיבוי במקרה של כשל).

  5. לוחצים על הגדרות מתקדמות.

    • בקטע Failover Policy (מדיניות מעבר לגיבוי), מגדירים את Failover ratio (יחס מעבר לגיבוי) לערך בין 0.0 ל-1.0, כולל.
    • מסמנים את התיבה לצד הפעלת השמטת תנועה אם רוצים להשמיט תנועה כשכל מכונות ה-VM של העורף הראשי והגיבוי לא תקינות.
    • מסמנים את התיבה שליד הפעלת זמן להשלמת תהליך (connection draining) ביתירות כשל אם רוצים לנתק במהירות חיבורים קיימים במהלך יתירות כשל.

  6. לוחצים על Review and finalize ואז על Update.

gcloud

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

gcloud compute backend-services update BACKEND_SERVICE_NAME \
   --region REGION \
   --failover-ratio FAILOVER_RATIO \
   --drop-traffic-if-unhealthy \
   --no-connection-drain-on-failover

מחליפים את מה שכתוב בשדות הבאים:

  • ‫BACKEND_SERVICE_NAME: השם של שירות הקצה העורפי של מאזן העומסים. בדוגמה הזו, משתמשים ב-be-ilb.
  • ‫REGION: האזור של מאזן העומסים. בדוגמה הזו, משתמשים ב-us-west1.
  • FAILOVER_RATIO: יחס המעבר לגיבוי. הערכים האפשריים הם בין 0.0 ל-1.0, כולל. בדוגמה הזו, משתמשים ב-0.75.
  • ‫--drop-traffic-if-unhealthy instructs the מאזן עומסים (LB) to drop traffic when all primary VMs and all יתירות כשל VMs are unhealthy. אם רוצים לפזר את התנועה בין כל המכונות הווירטואליות הראשיות כשכל המכונות הווירטואליות בעורף לא תקינות, צריך לשנות את הערך ל---no-drop-traffic-if-unhealthy.
  • ‫--no-connection-drain-on-failover מורה למאזן העומסים לסיים במהירות חיבורי TCP קיימים במהלך יתירות כשל. משתמשים ב---connection-drain-on-failover כדי להפעיל את התכונה 'זמן להשלמת תהליך (connection draining)' במהלך יתירות כשל.

API

משתמשים ב-method‏ regionBackendServices.patch כדי להגדיר את מדיניות יתירות הכשל.

PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_NAME

{
  "failoverPolicy":
  {
    "failoverRatio": FAILOVER_RATIO,
    "dropTrafficIfUnhealthy": [true|false],
    "disableConnectionDrainOnFailover": [true|false]
  }
}

מחליפים את מה שכתוב בשדות הבאים:

  • ‫PROJECT_ID: מזהה הפרויקט
  • ‫REGION: האזור של מאזן העומסים
  • ‫BACKEND_SERVICE_NAME: השם של השירות לקצה העורפי של מאזן העומסים
  • FAILOVER_RATIO: יחס המעבר לגיבוי. הערכים האפשריים הם בין 0.0 ל-1.0, כולל.
  • הגדרה של dropTrafficIfUnhealthy לערך true מורה למאזן העומסים להפסיק את התעבורה כשכל המכונות הווירטואליות הראשיות וכל המכונות הווירטואליות של יתירות כשל לא תקינות. מגדירים את הערך הזה ל-false אם רוצים לפזר את התעבורה בין כל המכונות הווירטואליות הראשיות כשכל המכונות הווירטואליות של הקצה העורפי לא תקינות.
  • ההגדרה disableConnectionDrainOnFailover ל-true מורה למאזן העומסים לסיים במהירות חיבורי TCP קיימים בזמן יתירות כשל. מגדירים את הערך הזה ל-false כדי להפעיל את זמן להשלמת תהליך (connection draining) במהלך יתירות כשל.

צפייה במדיניות מעבר לגיבוי

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

המסוף

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

gcloud

כדי להציג את ההגדרות של מדיניות המעבר לגיבוי באמצעות ה-CLI של gcloud, משתמשים בפקודה הבאה. הגדרות לא מוגדרות במדיניות מעבר לגיבוי (failover) משתמשות בערכי ברירת המחדל של מדיניות המעבר לגיבוי.

gcloud compute backend-services describe BACKEND_SERVICE_NAME \
   --region REGION \
   --format="get(failoverPolicy)"

מחליפים את מה שכתוב בשדות הבאים:

  • ‫BACKEND_SERVICE_NAME: השם של השירות לקצה העורפי של מאזן העומסים
  • ‫REGION: האזור של מאזן העומסים

API

משתמשים בשיטה regionBackendServices.get כדי לראות את מדיניות יתירות הכשל.

התשובה לבקשת ה-API מציגה את מדיניות היתירות כשל. דוגמה מוצגת בהמשך.

GET https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_NAME

מחליפים את מה שכתוב בשדות הבאים:

  • ‫PROJECT_ID: מזהה הפרויקט
  • ‫REGION: האזור של מאזן העומסים
  • ‫BACKEND_SERVICE_NAME: השם של השירות לקצה העורפי של מאזן העומסים
{
...
"failoverPolicy": {
  "disableConnectionDrainOnFailover": false,
  "dropTrafficIfUnhealthy": false,
  "failoverRatio": 0.75
...
}

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