‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

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

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

הרשאות

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

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

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

הגדרה

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

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

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

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

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

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

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

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

המסוף

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

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

הבק-אנד הראשי והבק-אנד ליתירות כשל ממוקמים בתחומים (zone) נפרדים כדי להבהיר את ההוראות ולטפל ביתירות כשל במקרה שאחד מהתחומים (zone) מושבת.

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

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

קבוצת מכונות שלישית, 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"
   }
 ]
}

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

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

המסוף

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

כניסה לדף Load balancing
בכרטיסייה Load balancers (מאזני עומסים), לוחצים על השם של מאזן עומסים קיים מסוג TCP/UDP (Internal) (פנימי) (בדוגמה הזו, 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

כדי להמיר קצה עורפי קיים למעבר לגיבוי (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)

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

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

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

המסוף

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

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

כניסה לדף Load balancing
בכרטיסייה Load balancers (מאזני עומסים), לוחצים על השם של מאזן עומסים קיים מסוג TCP/UDP (Internal) (פנימי).
לוחצים על עריכה .
מוודאים שיש לכם לפחות שרת קצה עורפי אחד למעבר אוטומטי. צריך לבחור לפחות אחד מהעורפים של מאזן העומסים באפשרות Use this instance group as a failover group for backup (שימוש בקבוצת המופעים הזו כקבוצת מעבר לגיבוי במקרה של כשל).
לוחצים על הגדרות מתקדמות.
- במדיניות מעבר לגיבוי (Failover), מגדירים את יחס המעבר לגיבוי לערך בין 0.0 ל-1.0, כולל.
- מסמנים את התיבה לצד הפעלת השמטת תעבורת נתונים אם רוצים להשמיט תעבורת נתונים כשכל מכונות ה-VM של העורף הראשי ויתירות הכשל לא תקינות.
- מסמנים את התיבה שליד הפעלת ניתוק הדרגתי של חיבורים במעבר לגיבוי אם רוצים לנתק במהירות חיבורים קיימים במהלך מעבר לגיבוי.
לוחצים על 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 load balancer to drop traffic when all primary VMs and all failover 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 כדי להפעיל את ניתוק החיבורים במהלך מעבר לגיבוי.

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

בהוראות הבאות מוסבר איך לצפות במדיניות הקיימת למעבר אוטומטי לגיבוי (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
...
}

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

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

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

הרשאות

הגדרה

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

המסוף

gcloud

API

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

המסוף

gcloud

API

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

המסוף

gcloud

API

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

המסוף

gcloud

API

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

המסוף

התחלת ההגדרה

הגדרה בסיסית

gcloud

API

בדיקה

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

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

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

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

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

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

המסוף

gcloud

API

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

המסוף

gcloud

API

הוספת בק-אנד ליתירות כשל

המסוף

gcloud

API

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

המסוף

gcloud

API

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

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

המסוף

gcloud

API

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

המסוף

gcloud

API

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

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