Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

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

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

הרשאות

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

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

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

הגדרה

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

רשת VPC לדוגמה עם רשתות משנה מותאמות אישית
כללי חומת אש שמאפשרים חיבורים נכנסים למכונות וירטואליות של שרתים עורפיים
מכונות וירטואליות של קצה עורפי:
- שרת קצה עורפי ראשי אחד בקבוצת מופעים לא מנוהלת באזור us-west1-a
- שרת קצה עורפי אחד למעבר אוטומטי לגיבוי בקבוצת מופעים לא מנוהלת באזור us-west1-c
מכונה וירטואלית אחת של לקוח לבדיקת חיבורים ולמעקב אחר התנהגות מעבר הגיבוי האוטומטי
הרכיבים הבאים של מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי:
- בדיקת תקינות של שירות הקצה העורפי
- שירות פנימי לקצה העורפי באזור us-west1 לניהול חלוקת החיבורים בין המכונות הווירטואליות בקצה העורפי
- כלל העברה פנימי וכתובת IP פנימית לחלק הקדמי של מאזן העומסים

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

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

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

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

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

רשת: הרשת היא רשת VPC במצב מותאם אישית בשם lb-network.
אזור: האזור הוא us-west1.
רשת משנה: ברשת המשנה, lb-subnet, נעשה שימוש בטווח כתובות ה-IP‏ 10.1.2.0/24.

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

המסוף

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

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

gcloud

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

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

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

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

המסוף

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

לדף Firewall policies
לוחצים על יצירת כלל לחומת אש ומזינים את הפרטים הבאים כדי ליצור את הכלל שיאפשר תעבורת נתונים ברשת המשנה:
- Name (שם): fw-allow-lb-subnet
- רשת: lb-network
- עדיפות: 1000
- כיוון התנועה: כניסה
- פעולה במקרה של התאמה: לאפשר
- יעדים: כל המופעים ברשת
- מסנן מקור: טווחים של כתובות IPv4
- טווחי IPv4 של המקור: 10.1.2.0/24
- Protocols and ports (פרוטוקולים ויציאות): Allow all (אישור הכול)
לוחצים על יצירה.
לוחצים שוב על Create firewall rule (יצירת כלל חומת אש) כדי ליצור את הכלל שיאפשר חיבורי SSH נכנסים:
- Name (שם): fw-allow-ssh
- רשת: lb-network
- עדיפות: 1000
- כיוון התנועה: כניסה
- פעולה במקרה של התאמה: לאפשר
- יעדים: תגי יעד שצוינו
- תגי טירגוט: allow-ssh
- מסנן מקור: טווחים של כתובות IPv4
- טווחי IPv4 של המקור: 0.0.0.0/0
- פרוטוקולים ויציאות: בוחרים באפשרות פרוטוקולים ויציאות שצוינו ואז מקלידים: tcp:22
לוחצים על יצירה.
לוחצים על יצירת כלל לחומת האש בפעם השלישית כדי ליצור את הכלל שיאפשרGoogle Cloud בדיקות תקינות:
- Name (שם): fw-allow-health-check
- רשת: lb-network
- עדיפות: 1000
- כיוון התנועה: כניסה
- פעולה במקרה של התאמה: לאפשר
- יעדים: תגי יעד שצוינו
- תגי טירגוט: allow-health-check
- מסנן מקור: טווחים של כתובות IPv4
- טווחים של כתובות IPv4 של המקור: 35.191.0.0/16
- Protocols and ports (פרוטוקולים ויציאות): Allow all (אישור הכול)
לוחצים על יצירה.

gcloud

יוצרים את כלל חומת האש 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

יוצרים את כלל חומת האש 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
```

יוצרים את הכלל 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=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": [HEALTH_CHECK_RANGES],
 "targetTags": [
   "allow-health-check"
 ],
 "allowed": [
   {
     "IPProtocol": "tcp"
   },
   {
     "IPProtocol": "udp"
   },
   {
     "IPProtocol": "icmp"
   }
 ],
 "direction": "INGRESS",
 "logConfig": {
   "enable": false
 },
 "disabled": false
}

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

‫PROJECT_ID: מזהה הפרויקט
‫HEALTH_CHECK_RANGES: רשימה מופרדת בפסיקים של Google Cloud טווחים של בדיקות תקינות, בפורמט של מחרוזות עם מרכאות (לדוגמה, "192.0.2.0/24",‏ "198.51.100.0/24")

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

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

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

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

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

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

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

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

המסוף

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

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

כניסה לדף VM instances
חוזרים על השלבים הבאים כדי ליצור ארבע מכונות וירטואליות, באמצעות השילובים הבאים של שם ואזור.
- שם: vm-a1, אזור: us-west1-a
- שם: vm-a2, אזור: us-west1-a
- שם: vm-c1, אזור: us-west1-c
- שם: vm-c2, אזור: us-west1-c
לוחצים על Create instance.
מגדירים את השם כמו שמוסבר בשלב 2.
בשדה Region, בוחרים us-west1, ובשדה Zone בוחרים אזור כמו שמוסבר בשלב 2.
בקטע Boot disk מוודאים שהתמונה שנבחרה היא Debian GNU/Linux 12 (bookworm)‎. אם צריך, לוחצים על בחירה כדי לשנות את התמונה.
לוחצים על אפשרויות מתקדמות.
לוחצים על Networking ומגדירים את השדות הבאים:
1. בשדה Network tags (תגי רשת), מזינים את הערכים allow-health-check ו-allow-ssh.
2. בקטע Network interfaces (ממשקי רשת), בוחרים באפשרויות הבאות:
  - רשת: lb-network
  - ‫Subnet (רשת משנה): lb-subnet

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

#! /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

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

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

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

כניסה לדף Instance groups
חוזרים על השלבים הבאים כדי ליצור שתי קבוצות של מכונות וירטואליות לא מנוהלות, שבכל אחת מהן יש שתי מכונות וירטואליות, באמצעות השילובים האלה.
- קבוצת מופעים: ig-a, אזור: us-west1-a, מכונות וירטואליות: vm-a1 ו-vm-a2
- קבוצת מופעים: ig-c, אזור: us-west1-c, מכונות וירטואליות: vm-c1 ו-vm-c2
לוחצים על יצירת קבוצת מופעים.
לוחצים על New unmanaged instance group (קבוצת מופעים חדשה לא מנוהלת).
מגדירים את השם כמו שמוסבר בשלב 2.
בקטע Location, בוחרים באפשרות us-west1 בשדה Region, ואז בוחרים Zone כמו שמוסבר בשלב 2.
בשדה רשת, מזינים lb-network.
בשדה Subnetwork (רשת משנה), מזינים lb-subnet.
בקטע VM instances, מוסיפים את המכונות הווירטואליות כמו שמוסבר בשלב 2.
לוחצים על יצירה.

gcloud

מריצים את הפקודה הבאה ארבע פעמים כדי ליצור ארבע מכונות וירטואליות, ומשתמשים בארבעת השילובים האלה עבור 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'

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

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

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

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

המסוף

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

כניסה לדף VM instances
לוחצים על Create instance.
מגדירים את Name לערך vm-client.
מגדירים את Zone לערך us-west1-a.
לוחצים על אפשרויות מתקדמות.
לוחצים על Networking ומגדירים את השדות הבאים:
1. בשדה Network tags (תגי רשת), מזינים allow-ssh.
2. בקטע Network interfaces (ממשקי רשת), בוחרים באפשרויות הבאות:
  - רשת: lb-network
  - ‫Subnet (רשת משנה): lb-subnet
לוחצים על יצירה.

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
}

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

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

בדיקת תקינות: בדוגמה הזו נעשה שימוש בבדיקת תקינות של HTTP שפשוט בודקת אם יש תגובה של HTTP 200 (OK). מידע נוסף מופיע בקטע בנושא בדיקות תקינות בסקירה הכללית של מאזן עומסים פנימי מסוג passthrough.
שירות בק-אנד: מכיוון שהדוגמה מעבירה תנועת HTTP דרך מאזן העומסים, ההגדרה מציינת TCP ולא UDP. כדי להמחיש את המעבר לגיבוי, שירות הקצה העורפי הזה כולל יחס מעבר לגיבוי של 0.75.
כלל העברה: בדוגמה הזו נוצר כלל העברה פנימי יחיד.
כתובת IP פנימית: בדוגמה הזו, אנחנו מציינים כתובת IP פנימית, 10.1.2.99, כשאנחנו יוצרים את כלל ההעברה.

המסוף

התחלת ההגדרה

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

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

הגדרה בסיסית

מגדירים את Name לערך be-ilb.
מגדירים את Region לערך us-west1.
מגדירים את Network לערך lb-network.
לוחצים על Backend configuration ומבצעים את השינויים הבאים:
1. בקטע Backends (קצה עורפי), בקטע New item (פריט חדש), בוחרים את קבוצת המכונות 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 מופיע סימן אישור כחול. אם לא, צריך לבדוק את השלב הזה.
לוחצים על Frontend configuration. בקטע New Frontend IP and port מבצעים את השינויים הבאים:
1. Name (שם): fr-ilb
2. Subnetwork: ilb-subnet
3. בקטע Internal IP, בוחרים באפשרות Reserve a static internal IP address, מזינים את הפרטים הבאים ולוחצים על Reserve:
  - Name (שם): ip-ilb
  - כתובת IP סטטית: אני רוצה לבחור
  - כתובת IP מותאמת אישית: 10.1.2.99
4. יציאות: בוחרים באפשרות יחיד ומזינים 80 בשדה מספר היציאה.
5. לפני שממשיכים, מוודאים שלצד Frontend configuration מופיע סימן אישור כחול. אם לא, צריך לבדוק את השלב הזה.
לוחצים על Review and finalize. כדאי לבדוק שוב את ההגדרות.
לוחצים על יצירה.

gcloud

יוצרים בדיקת תקינות חדשה של HTTP כדי לבדוק את קישוריות ה-TCP למכונות הווירטואליות בפורט 80.
```
gcloud compute health-checks create http hc-http-80 \
    --region=us-west1 \
    --port=80
```

יוצרים את שירות הקצה העורפי לתנועת 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מתחברים למכונה הווירטואלית vm-a1.
```
gcloud compute ssh vm-a1 --zone=us-west1-a
```
מפסיקים את שרת האינטרנט של Apache. אחרי עשר שניות, Google Cloud המערכת מחשיבה את המכונה הווירטואלית הזו כלא תקינה. (בבדיקת התקינות hc-http-80 שיצרתם בהגדרה נעשה שימוש במרווח ברירת המחדל של חמש שניות בין הבדיקות ובסף ברירת המחדל של שתי בדיקות רצופות שנכשלו).
```
sudo apachectl stop
```
פועלים לפי ההוראות לבדיקת הלקוח. חוזרים על השלב השני כמה פעמים. ההתנהגות הצפויה היא שחיבורים חדשים יתחלקו בין שתי מכונות וירטואליות תקינות למעבר לגיבוי, vm-c1 ו-vm-c2. זה קורה כי רק מכונה וירטואלית ראשית אחת, vm-a2, תקינה, והיחס בין מכונות וירטואליות ראשיות תקינות לבין סך המכונות הווירטואליות הראשיות הוא 0.5 – פחות מסף המעבר לגיבוי של 0.75. כל מכונה וירטואלית למעבר אוטומטי משרתת תגובה בערך מחצית מהזמן כל עוד הזיקה לסשן מוגדרת ל-NONE.

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

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

מתחברים למכונה הווירטואלית vm-a1.
```
gcloud compute ssh vm-a1 --zone=us-west1-a
```
מפעילים את שרת האינטרנט של Apache וממתינים 10 שניות.
```
sudo apachectl start
```
פועלים לפי ההוראות לבדיקת הלקוח. חוזרים על השלב השני כמה פעמים. ההתנהגות הצפויה היא שהתנועה תטופל על ידי שתי המכונות הווירטואליות הראשיות, vm-a1 ו-vm-a2. אם שתי המכונות הווירטואליות הראשיות תקינות, היחס בין המכונות הווירטואליות הראשיות התקינות לבין סך המכונות הווירטואליות הראשיות הוא 1.0, שהוא גדול מסף המעבר לגיבוי (0.75). לכן, הקצה העורפי שעומד בדרישות של מאזן העומסים כולל את כל המכונות הווירטואליות הראשיות התקינות.

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

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

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

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

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

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

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

המסוף

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

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

כניסה לדף VM instances
חוזרים על השלבים הבאים כדי ליצור ארבע מכונות וירטואליות, באמצעות השילובים הבאים של שם ואזור.
- שם: vm-b1, אזור: us-west1-a
- שם: vm-b2, אזור: us-west1-a
- שם: vm-d1, אזור: us-west1-c
- שם: vm-d2, אזור: us-west1-c
לוחצים על Create instance.
מגדירים את השם כמו שמוסבר בשלב 2.
בשדה Region, בוחרים us-west1, ובשדה Zone בוחרים אזור כמו שמוסבר בשלב 2.
בקטע Boot disk מוודאים שהתמונה שנבחרה היא Debian GNU/Linux 12 (bookworm)‎. אם צריך, לוחצים על בחירה כדי לשנות את התמונה.
לוחצים על אפשרויות מתקדמות ומבצעים את השינויים הבאים:
- לוחצים על Networking ומוסיפים את Network tags הבאים: allow-ssh ו-allow-health-check
- לוחצים על לחצן העריכה בקטע Network interfaces, מבצעים את השינויים הבאים ולוחצים על Done:
  - רשת: lb-network
  - ‫Subnet (רשת משנה): lb-subnet
  - כתובת IP פנימית ראשית: זמנית (אוטומטית)
  - כתובת IP חיצונית: זמנית
- לוחצים על ניהול. בשדה 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
```
לוחצים על יצירה.

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

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

כניסה לדף Instance groups
חוזרים על השלבים הבאים כדי ליצור שתי קבוצות של מכונות וירטואליות לא מנוהלות, כל אחת עם שתי מכונות וירטואליות, באמצעות השילובים האלה.
- קבוצת מופעים: ig-b, אזור: us-west1-a, מכונות וירטואליות: vm-b1 ו-vm-b2
- קבוצת מופעים: ig-d, אזור: us-west1-c, מכונות וירטואליות: vm-d1 ו-vm-d2
לוחצים על יצירת קבוצת מופעים.
לוחצים על New unmanaged instance group (קבוצת מופעים חדשה לא מנוהלת).
מגדירים את השם כמו שמוסבר בשלב 2.
בקטע Location, בוחרים באפשרות us-west1 בשדה Region, ואז בוחרים Zone כמו שמוסבר בשלב 2.
בשדה רשת, מזינים lb-network.
בשדה Subnetwork (רשת משנה), מזינים lb-subnet.
בקטע VM instances, מוסיפים את המכונות הווירטואליות כמו שמוסבר בשלב 2.
לוחצים על יצירה.

gcloud

‫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'

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

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

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

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.

המסוף

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

כניסה לדף Load balancing
בכרטיסייה Load balancers, לוחצים על השם של מאזן עומסים פנימי קיים מסוג TCP או UDP (בדוגמה הזו, be-ilb).
לוחצים על עריכה .
בקטע Backend configuration, לוחצים על Add backend ובוחרים קבוצת מופעים לא מנוהלת (בדוגמה הזו, ig-d).
מוודאים שהתיבה Use this instance group as a failover group for backup (שימוש בקבוצת המופעים הזו כקבוצת מעבר לגיבוי במקרה של כשל) לא מסומנת.
לוחצים על 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) ברשת, כבק-אנד למעבר לגיבוי (failover). בדוגמה להגדרה, התהליך הזה מראה איך להוסיף את קבוצת המופעים ig-b כקצה עורפי למעבר אוטומטי לגיבוי למאזן העומסים be-ilb.

המסוף

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

כניסה לדף Load balancing
בכרטיסייה מאזני עומסים, לוחצים על השם של מאזן עומסים קיים מסוג TCP/UDP (פנימי) (בדוגמה הזו, be-ilb).
לוחצים על עריכה .
בקטע Backend configuration, לוחצים על Add backend ובוחרים קבוצת מופעים לא מנוהלת (בדוגמה הזו, ig-b).
מסמנים את התיבה Use this instance group as a failover group for backup (שימוש בקבוצת המכונות הזו כקבוצת מעבר לגיבוי במקרה של כשל).
לוחצים על 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.

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

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

המסוף

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

כניסה לדף Load balancing
בכרטיסייה Load balancers (מאזני עומסים), לוחצים על השם של מאזן עומסים קיים מסוג TCP/UDP (Internal) (פנימי).
לוחצים על עריכה .
בקטע Backend configuration, לוחצים על השם של אחת מקבוצות המופעים של ה-Backend. לאחר מכן:
- כדי להגדיר את קבוצת המכונות כקצה עורפי למעבר לגיבוי במקרה של כשל, מסמנים את התיבה Use this instance group as a failover group for backup (שימוש בקבוצת המכונות הזו כקבוצת מעבר לגיבוי במקרה של כשל).
- כדי להגדיר את קבוצת המופעים כקצה עורפי ראשי, מבטלים את הסימון של התיבה Use this instance group as a failover group for backup (שימוש בקבוצת המופעים הזו כקבוצת מעבר לגיבוי).
לוחצים על 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 הבאה:

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) בשביל שירות backend של מאזן עומסים פנימי מסוג passthrough Network Load Balancer. מידע נוסף על הפרמטרים של מדיניות מעבר לגיבוי זמין במאמר בנושא מעבר לגיבוי.

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

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

המסוף

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

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

כניסה לדף Load balancing
בכרטיסייה מאזני עומסים, לוחצים על השם של מאזן עומסים קיים מסוג TCP/UDP (פנימי).
לוחצים על עריכה .
מוודאים שיש לכם לפחות שרת קצה עורפי אחד למעבר אוטומטי. צריך לבחור לפחות אחד מהעורפים של מאזן העומסים באפשרות Use this instance group as a failover group for backup.
לוחצים על הגדרות מתקדמות.
- במדיניות מעבר לגיבוי (Failover), מגדירים את יחס המעבר לגיבוי לערך בין 0.0 ל-1.0, כולל.
- מסמנים את התיבה לצד הפעלת השמטת תנועה אם רוצים להשמיט תנועה כשכל מכונות ה-VM של העורף הראשי והגיבוי לא תקינות.
- מסמנים את התיבה שליד הפעלת ניתוק הדרגתי של חיבורים במעבר לגיבוי אם רוצים לנתק במהירות חיבורים קיימים במהלך מעבר לגיבוי.
לוחצים על Review and finalize ואז על Update.

gcloud

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

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 מורה למאזן העומסים להפסיק את התנועה כשכל המכונות הווירטואליות הראשיות וכל המכונות הווירטואליות של הגיבוי האוטומטי לא תקינות. אם רוצים לפזר את התנועה בין כל המכונות הווירטואליות הראשיות כשכל המכונות הווירטואליות בעורף לא תקינות, צריך לשנות את הערך ל---no-drop-traffic-if-unhealthy.
‫--no-connection-drain-on-failover מורה למאזן העומסים לסיים במהירות חיבורי TCP קיימים במהלך מעבר לשירות גיבוי. משתמשים ב---connection-drain-on-failover כדי להפעיל את התכונה 'זמן להשלמת תהליך' במהלך מעבר לגיבוי בעת כשל.

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 כדי להפעיל את ניתוק החיבורים במהלך מעבר לגיבוי.

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

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

המסוף

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

gcloud

כדי להציג את ההגדרות של מדיניות המעבר לגיבוי באמצעות gcloud CLI, משתמשים בפקודה הבאה. הגדרות לא מוגדרות במדיניות מעבר לגיבוי (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
...
}

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

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

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

הרשאות

הגדרה

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

המסוף

gcloud

API

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

המסוף

gcloud

API

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

המסוף

gcloud

API

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

המסוף

gcloud

API

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

המסוף

התחלת ההגדרה

הגדרה בסיסית

gcloud

API

בדיקה

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

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

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

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

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

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

המסוף

gcloud

API

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

המסוף

gcloud

API

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

המסוף

gcloud

API

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

המסוף

gcloud

API

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

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

המסוף

gcloud

API

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

המסוף

gcloud

API

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

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