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

מעבר לגיבוי בענן (failover) בין אזורים עבור נקודות קצה חיצוניות אזוריות באמצעות בדיקות תקינות של Cloud DNS

1. מבוא

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

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

מה תלמדו

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

מה תצטרכו

ידע בסיסי ב-DNS.
ידע בסיסי ב-Google Compute Engine.
ידע בסיסי ב-Application Load Balancer.
פרויקט ב-Google Cloud עם הרשאות בעלים
דומיין ציבורי שבבעלותכם, שתוכלו ליצור עבורו תחום ציבורי ב-Cloud DNS.
בפרויקט Google Cloud, לא נאכפים כרגע כללי המדיניות הארגונית הבאים: מכונות וירטואליות מוגנות וקבוצות של נקודות קצה ברשת האינטרנט.

2. טופולוגיית Codelab

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

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

3. הגדרה ודרישות

הגדרת סביבה בקצב אישי

נכנסים ל-מסוף Google Cloud ויוצרים פרויקט חדש או משתמשים בפרויקט קיים. אם עדיין אין לכם חשבון Gmail או Google Workspace, אתם צריכים ליצור חשבון.

שם הפרויקט הוא השם המוצג למשתתפים בפרויקט. זו מחרוזת תווים שלא נמצאת בשימוש ב-Google APIs. תמיד אפשר לעדכן את המיקום.
מזהה הפרויקט הוא ייחודי לכל הפרויקטים ב-Google Cloud ואי אפשר לשנות אותו אחרי שהוא מוגדר. מסוף Cloud יוצר באופן אוטומטי מחרוזת ייחודית, ובדרך כלל לא צריך לדעת מה היא. ברוב ה-Codelabs, תצטרכו להפנות למזהה הפרויקט (בדרך כלל מסומן כ-PROJECT_ID). אם אתם לא אוהבים את המזהה שנוצר, אתם יכולים ליצור מזהה אקראי אחר. אפשר גם לנסות שם משתמש משלכם ולבדוק אם הוא זמין. אי אפשר לשנות את ההגדרה הזו אחרי השלב הזה, והיא נשארת לאורך הפרויקט.
לידיעתכם, יש ערך שלישי, מספר פרויקט, שחלק מממשקי ה-API משתמשים בו. מידע נוסף על שלושת הערכים האלה מופיע במאמרי העזרה.

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

מפעילים את Cloud Shell

אפשר להפעיל את Google Cloud מרחוק מהמחשב הנייד, אבל ב-Codelab הזה נשתמש ב-Google Cloud Shell, סביבת שורת פקודה שפועלת בענן.

ב-מסוף Google Cloud, לוחצים על סמל Cloud Shell בסרגל הכלים שבפינה הימנית העליונה:

הפעלת Cloud Shell

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

צילום מסך של טרמינל Google Cloud Shell שבו מוצג שהסביבה מחוברת

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

4. לפני שמתחילים

הפעלת ממשקי ה-API

ב-Cloud Shell, מוודאים שהפרויקט מוגדר ומגדירים משתנים.

gcloud auth login
gcloud config list project
gcloud config set project [YOUR-PROJECT-ID]
export projectid=[YOUR-PROJECT-ID]

# Define variables for regions and the domain
export REGION_A=us-central1
export REGION_B=us-west1
export DNS_ZONE=dnscodelab-zone
Export DNS_DOMAIN=gcp.<yourpublicdomain>.com
echo $projectid
echo $REGION_A
echo $REGION_B
echo $DNS_ZONE
echo $DNS_DOMAIN

הפעלת כל השירותים הנדרשים

gcloud services enable compute.googleapis.com 
gcloud services enable dns.googleapis.com

5. יצירת תשתית של Cloud Load Balancing

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

רשת VPC

מ-Cloud Shell

gcloud compute networks create external-lb-vpc --subnet-mode=custom

יוצרים שתי רשתות משנה ב-REGION_A (Primary) וב-REGION_B (Backup) לאירוח שרתי האינטרנט של העורף

יצירת תת-רשתות

מ-Cloud Shell

gcloud compute networks subnets create subnet-a --network=external-lb-vpc --region=$REGION_A --range=10.10.1.0/24

gcloud compute networks subnets create subnet-b --network=external-lb-vpc --region=$REGION_B --range=10.20.1.0/24

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

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

מ-Cloud Shell

gcloud compute networks subnets create proxy-only-subnet-a \
--purpose=REGIONAL_MANAGED_PROXY \
--role=ACTIVE \
--region=$REGION_A \
--network=external-lb-vpc \
--range=10.129.0.0/23

gcloud compute networks subnets create proxy-only-subnet-b \
--purpose=REGIONAL_MANAGED_PROXY \
--role=ACTIVE \
--region=$REGION_B \
--network=external-lb-vpc \
--range=10.130.0.0/23

יצירת כללים לחומת אש ברשת

fw-allow-health-check. כלל תעבורת נתונים נכנסת (ingress) שחל על המופעים שמתבצע איזון העומסים שלהם, ומאפשר את כל תעבורת ה-TCP ממערכות בדיקת תקינות ב-Google Cloud (בטווחים ‎130.211.0.0/22 ו-‎35.191.0.0/16). בדוגמה הזו, תג היעד load-balanced-backend משמש לזיהוי המכונות הווירטואליות שכלל חומת האש חל עליהן.

fw-allow-proxies. כלל תעבורת נתונים נכנסת (ingress) שרלוונטי למופעים שעובר עליהם איזון עומסים, שמאפשר תעבורת TCP ביציאות 80 משרתי ה-proxy המנוהלים של מאזן העומסים החיצוני האזורי של אפליקציות. בדוגמה הזו, תג היעד load-balanced-backend משמש לזיהוי המכונות הווירטואליות שכלל חומת האש חל עליהן.

מ-Cloud Shell

gcloud compute firewall-rules create fw-allow-health-check \
    --network=external-lb-vpc \
    --action=allow \
    --direction=ingress \
    --source-ranges=130.211.0.0/22,35.191.0.0/16 \
    --target-tags=load-balanced-backend \
    --rules=tcp
gcloud compute firewall-rules create fw-allow-proxies \
  --network=external-lb-vpc \
  --action=allow \
  --direction=ingress \
  --source-ranges=10.129.0.0/23,10.130.0.0/23 \
  --target-tags=load-balanced-backend \
  --rules=tcp:80

כדי לאפשר ל-IAP להתחבר למכונות הווירטואליות, צריך ליצור כלל חומת אש ש:

רלוונטי לכל מכונות ה-VM שרוצים לגשת אליהן באמצעות IAP.
מאפשר תעבורת נתונים נכנסת (ingress) מטווח כתובות ה-IP‏ ‎35.235.240.0/20. הטווח הזה מכיל את כל כתובות ה-IP שמשמשות את IAP להעברת TCP.

מ-Cloud Shell

gcloud compute firewall-rules create allow-ssh \
    --allow tcp:22 --network external-lb-vpc \
    --source-ranges 35.235.240.0/20  \
    --description "SSH with IAP" \
    --target-tags=allow-ssh

6. יצירה של Cloud NAT ו-Cloud Routers

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

מכונות וירטואליות של שרת האינטרנט יצטרכו להוריד ולהתקין שרת אינטרנט של Apache.
המכונה הווירטואלית של הלקוח תצטרך להוריד ולהתקין את חבילת dnsutils שבה נשתמש לבדיקה.

כל שער Cloud NAT משויך לרשת VPC אחת, לאזור אחד ול-Cloud Router אחד. לכן, לפני שיוצרים את שער ה-NAT, צריך ליצור Cloud Routers בכל אזור.

יצירת Cloud Routers

מ-Cloud Shell

gcloud compute routers create "$REGION_A-cloudrouter" \
--region $REGION_A --network=external-lb-vpc --asn=65501

gcloud compute routers create "$REGION_B-cloudrouter" \
--region $REGION_B --network=external-lb-vpc --asn=65501

יצירת שערי NAT

מ-Cloud Shell

gcloud compute routers nats create "$REGION_A-nat-gw" \
--router="$REGION_A-cloudrouter" \
--router-region=$REGION_A \
--nat-all-subnet-ip-ranges --auto-allocate-nat-external-ips

gcloud compute routers nats create "$REGION_B-nat-gw" \
--router="$REGION_B-cloudrouter" \
--router-region=$REGION_B \
--nat-all-subnet-ip-ranges --auto-allocate-nat-external-ips

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

יוצרים מכונה וירטואלית בכל אזור ומתקינים שרת אינטרנט (למשל Apache):

מ-Cloud Shell

# Primary (Region A)
gcloud compute instances create vm-a \
--zone=$REGION_A-a \
--image-family=debian-12 --image-project=debian-cloud \
--subnet=subnet-a \
--no-address \
--tags=load-balanced-backend,allow-ssh \
--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" - $REGION_A Primary Backend |\
tee /var/www/html/index.html
systemctl restart apache2'


# Backup (Region B)
gcloud compute instances create vm-b \
--zone=$REGION_B-a \
--image-family=debian-12 --image-project=debian-cloud \
--subnet=subnet-b \
--no-address \
--tags=load-balanced-backend,allow-ssh \
--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" - $REGION_B Backup Backend |\
tee /var/www/html/index.html
systemctl restart apache2'

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

מ-Cloud Shell

# Primary (Region A)
gcloud compute instance-groups unmanaged create ig-a --zone=$REGION_A-a

gcloud compute instance-groups unmanaged add-instances ig-a --zone=$REGION_A-a --instances=vm-a

# Backup (Region B)
gcloud compute instance-groups unmanaged create ig-b --zone=$REGION_B-a

gcloud compute instance-groups unmanaged add-instances ig-b --zone=$REGION_B-a --instances=vm-b

7. הגדרת מאזני עומסים חיצוניים אזוריים של אפליקציות (ALB)

תגדירו מאזן עומסים חיצוני אזורי של אפליקציות (ALB) מלא באזור REGION_A (הראשי) ובאזור REGION_B (הגיבוי).

יצירת בדיקות תקינות ושירותי קצה עורפי

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

יוצרים בדיקת תקינות של HTTP (שמשמשת את מאזני העומסים לבדיקת התקינות של המופע):

ב-Cloud Shell

gcloud compute health-checks create http http-lb-hc-primary-region \
--port 80 \
--region=$REGION_A

gcloud compute health-checks create http http-lb-hc-backup-region \
--port 80 \
--region=$REGION_B

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

ב-Cloud Shell

# Primary (Region A)
gcloud compute backend-services create be-svc-a \
--load-balancing-scheme=EXTERNAL_MANAGED \
--protocol=HTTP \
--port-name=http \
--health-checks=http-lb-hc-primary-region \
--health-checks-region=$REGION_A \
--region=$REGION_A

gcloud compute backend-services add-backend be-svc-a \
--instance-group=ig-a \
--instance-group-zone=$REGION_A-a \
--region=$REGION_A

# Backup (Region B)
gcloud compute backend-services create be-svc-b \
--load-balancing-scheme=EXTERNAL_MANAGED \
--protocol=HTTP \
--port-name=http \
--health-checks=http-lb-hc-backup-region \
--health-checks-region=$REGION_B \
--region=$REGION_B

gcloud compute backend-services add-backend be-svc-b --instance-group=ig-b --instance-group-zone=$REGION_B-a --region=$REGION_B

יצירת רכיבי Frontend

יוצרים מיפויי כתובות URL ושרתי proxy של HTTP ביעד בשני האזורים:

ב-Cloud Shell

#Primary (Region A)
gcloud compute url-maps create url-map-a \
--default-service=be-svc-a \
--region=$REGION_A
gcloud compute target-http-proxies create http-proxy-a \
--url-map=url-map-a \
--url-map-region=$REGION_A \
--region=$REGION_A
#Backup (Region B)
gcloud compute url-maps create url-map-b \
--default-service=be-svc-b \
--region=$REGION_B

gcloud compute target-http-proxies create http-proxy-b \
--url-map=url-map-b \
--url-map-region=$REGION_B \
--region=$REGION_B

שמירת כתובות IP סטטיות (חיצוניות) לכללי ההעברה:

ב-Cloud Shell

# Primary IP (Region A)
gcloud compute addresses create rxlb-ip-a --region=$REGION_A

# Backup IP (Region B)
gcloud compute addresses create rxlb-ip-b --region=$REGION_B

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

ב-Cloud Shell

# Primary (Region A)
gcloud compute forwarding-rules create http-fwd-rule-a \
--load-balancing-scheme=EXTERNAL_MANAGED \
--network=external-lb-vpc \
--region=$REGION_A \
--target-http-proxy-region=$REGION_A \
--address=rxlb-ip-a \
--target-http-proxy=http-proxy-a \
--ports=80

# Backup (Region B)
gcloud compute forwarding-rules create http-fwd-rule-b \
--load-balancing-scheme=EXTERNAL_MANAGED \
--network=external-lb-vpc \
--region=$REGION_B \
--target-http-proxy-region=$REGION_B \
--address=rxlb-ip-b \
--target-http-proxy=http-proxy-b \
--ports=80

הגדרת Cloud DNS למעבר לשירות גיבוי (Failover)

יצירת בדיקת תקינות של Cloud DNS לנקודות קצה חיצוניות

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

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

ב-Cloud Shell

PRIMARY_IP=$(gcloud compute addresses describe rxlb-ip-a --region=$REGION_A --format='get(address)')

BACKUP_IP=$(gcloud compute addresses describe rxlb-ip-b --region=$REGION_B --format='get(address)')

יוצרים את בדיקת התקינות הגלובלית של ה-DNS (נדרשים שלושה אזורי מקור):

ב-Cloud Shell

gcloud beta compute health-checks create http dns-failover-health-check \
    --global \
    --source-regions=$REGION_A,$REGION_B,europe-west1 \
    --request-path=/ \
    --check-interval=30s \
    --port=80 \
    --enable-logging

יוצרים אזור ציבורי מנוהל ומדיניות ניתוב למעבר לגיבוי (failover).

יצירת תחום ציבורי מנוהל (שימוש בדומיין DNS שבבעלותכם):

ב-Cloud Shell

gcloud dns managed-zones create codelab-publiczone --dns-name=$DNS_DOMAIN --description="Codelab DNS Failover Zone"

יוצרים את רשומת ה-A באמצעות מדיניות ניתוב למעבר אוטומטי לגיבוי. המדיניות הזו מצביעה על כתובת ה-IP הראשית ומשתמשת בבדיקת התקינות כדי לקבוע מתי לבצע מעבר לגיבוי לכתובת ה-IP של הגיבוי.

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

gcloud beta dns record-sets create codelab.gcp.axiszulu.com. \
--type=A \
--ttl=5 \
--zone=codelab-publiczone \
--routing_policy_type=FAILOVER \
--routing-policy-primary-data=$PRIMARY_IP \
--routing-policy-backup-data-type=GEO \
--routing-policy-backup-item=location=$REGION_B,external_endpoints=$BACKUP_IP \
--health-check=dns-failover-health-check

8. בדיקת מעבר לשירות גיבוי אזורי

אימות ראשוני: משתמשים בכלי (כמו dig או דפדפן אינטרנט) כדי לשלוח שאילתה לדומיין. היא אמורה להפנות אל כתובת ה-IP הראשית ($PRIMARY_IP) ולהחזיר את הדף 'אזור א' – קצה עורפי ראשי'.

dig codelab.gcp.axiszulu.com

OUTPUT
; <<>> DiG 9.18.39-0ubuntu0.24.04.2-Ubuntu <<>> codelab.gcp.axiszulu.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16096
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;codelab.gcp.axiszulu.com.      IN      A

;; ANSWER SECTION:
codelab.gcp.axiszulu.com. 5     IN      A   <PRIMARY_IP>

פלט מהדפדפן

הדמיית מעבר לגיבוי: מתחברים למכונה הווירטואלית הראשית (vm-a) ומכבים את Apache כדי להדמות הפסקת פעולה:

ב-Cloud Shell

gcloud compute ssh vm-a --zone=$REGION_A-a --command="sudo systemctl stop apache2"

אימות הסטטוס 'לא תקין': מחכים 2-3 דקות עד שבדיקת התקינות של ה-DNS תסמן את נקודת הקצה הראשית כלא תקינה.

# check health status
gcloud compute backend-services get-health be-svc-a --region=${REGION_A}

Output:
backend: https://www.googleapis.com/compute/v1/projects/precise-airship-466617-c3/zones/us-central1-a/instanceGroups/ig-a
status:
  healthStatus:
  - healthState: UNHEALTHY
    instance: https://www.googleapis.com/compute/v1/projects/precise-airship-466617-c3/zones/us-central1-a/instances/vm-a
    ipAddress: 10.10.1.2
    port: 80
  kind: compute#backendServiceGroupHealth

אימות המעבר לגיבוי: שולחים שוב שאילתה לדומיין. הכתובת אמורה עכשיו להפנות אל כתובת ה-IP של הגיבוי ($BACKUP_IP) ולהחזיר את הדף 'אזור ב' – גיבוי של השרת העורפי'.

dig codelab.gcp.axiszulu.com

OUTPUT
; <<>> DiG 9.18.39-0ubuntu0.24.04.2-Ubuntu <<>> codelab.gcp.axiszulu.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16096
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;codelab.gcp.axiszulu.com.      IN      A

;; ANSWER SECTION:
codelab.gcp.axiszulu.com. 5     IN      A   <BACKUP_IP>

פלט מהדפדפן

הדמיית חזרה לגיבוי (אופציונלי): מתחברים באמצעות SSH ומפעילים את Apache במכונת ה-VM הראשית, וממתינים עד שבדיקת התקינות של DNS תסמן את נקודת הקצה הראשית כנקודת קצה תקינה. תנועת הגולשים אמורה לחזור אוטומטית לכתובת ה-IP הראשית.
אופציונלי: כדי לנתח את הרישום ביומן של בדיקת תקינות ב-Cloud DNS, מריצים את הפקודה הבאה ב-Cloud Shell

gcloud logging read "logName=projects/${projectid}/logs/compute.googleapis.com%2Fhealthchecks" \
--limit=10 \
--project=${projectid} \
--freshness=1d \
--format="table(timestamp:label=TIME, \
jsonPayload.healthCheckProbeResult.ipAddress:label=BACKEND_IP, \
jsonPayload.healthCheckProbeResult.previousDetailedHealthState:label=PREVIOUS_STATE, \
jsonPayload.healthCheckProbeResult.detailedHealthState:label=CURRENT_STATE, \
jsonPayload.healthCheckProbeResult.probeResultText:label=RESULT_TEXT)"

9. שלבי הניקוי

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

מ-Cloud Shell

# Delete VMs
gcloud compute instances delete vm-a --zone=$REGION_A-a --quiet
gcloud compute instances delete vm-b --zone=$REGION_B-a --quiet
# Delete Load Balancer Components (Primary)
gcloud compute forwarding-rules delete http-fwd-rule-a --region=$REGION_A --quiet
gcloud compute target-http-proxies delete http-proxy-a --region=$REGION_A --quiet
gcloud compute url-maps delete url-map-a --region=$REGION_A --quiet
gcloud compute backend-services delete be-svc-a --region=$REGION_A --quiet
gcloud compute addresses delete rxlb-ip-a --region=$REGION_A --quiet
# Delete Load Balancer Components (Backup)
gcloud compute forwarding-rules delete http-fwd-rule-b --region=$REGION_B --quiet
gcloud compute target-http-proxies delete http-proxy-b --region=$REGION_B --quiet
gcloud compute url-maps delete url-map-b --region=$REGION_B --quiet
gcloud compute backend-services delete be-svc-b --region=$REGION_B --quiet
gcloud compute addresses delete rxlb-ip-b --region=$REGION_B --quiet
# Delete Instance Groups and LB Health Checks
gcloud compute instance-groups unmanaged delete ig-a --zone=$REGION_A-a --quiet
gcloud compute instance-groups unmanaged delete ig-b --zone=$REGION_B-a --quiet
gcloud compute health-checks delete http-lb-hc-primary-region --region=$REGION_A --quiet
gcloud compute health-checks delete http-lb-hc-backup-region --region=$REGION_B --quiet

# Delete Cloud DNS Records Zone and DNS Heath Checks
gcloud dns record-sets delete $DNS_DOMAIN --type=A --zone=codelab-publiczone --quiet
gcloud dns managed-zones delete codelab-publiczone --quiet

gcloud compute health-checks delete dns-failover-health-check --global --quiet

# Delete Cloud NAT and Cloud Routers
gcloud compute routers nats delete $REGION_A-nat-gw \
--router=$REGION_A-cloudrouter --region=$REGION_A --quiet

gcloud compute routers nats delete $REGION_B-nat-gw \
--router=$REGION_B-cloudrouter --region=$REGION_B --quiet

gcloud compute routers delete $REGION_A-cloudrouter \
--region=$REGION_A --quiet

gcloud compute routers delete $REGION_B-cloudrouter \
--region=$REGION_B --quiet


# Delete Subnets and Firewall Rules
gcloud compute firewall-rules delete fw-allow-health-check --quiet
gcloud compute firewall-rules delete fw-allow-proxies --quiet
gcloud compute firewall-rules delete allow-ssh --quiet
gcloud compute networks subnets delete subnet-a \
--region=$REGION_A --quiet

gcloud compute networks subnets delete subnet-b \
--region=$REGION_B --quiet
gcloud compute networks subnets delete proxy-only-subnet-a \
--region=$REGION_A --quiet

gcloud compute networks subnets delete proxy-only-subnet-b \
--region=$REGION_B --quiet

gcloud compute networks delete external-lb-vpc --quiet

10. מעולה!

כל הכבוד, סיימתם את ה-Codelab.

הצלחתם להגדיר ולאמת יתירות כשל פעילה-סבילה במספר אזורים באמצעות בדיקות תקינות של Cloud DNS ומאזן עומסים חיצוני אזורי של אפליקציות (ALB)

מעבר לגיבוי בענן (failover) בין אזורים עבור נקודות קצה חיצוניות אזוריות באמצעות בדיקות תקינות של Cloud DNS

1. מבוא

מה תלמדו

מה תצטרכו

2. טופולוגיית Codelab

3. הגדרה ודרישות

הגדרת סביבה בקצב אישי

מפעילים את Cloud Shell

4. לפני שמתחילים

הפעלת ממשקי ה-API

5. יצירת תשתית של Cloud Load Balancing

רשת VPC

יצירת תת-רשתות

יצירת כללים לחומת אש ברשת

6. יצירה של Cloud NAT ו-Cloud Routers

יצירת Cloud Routers

יצירת שערי NAT

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

7. הגדרת מאזני עומסים חיצוניים אזוריים של אפליקציות (ALB)

יצירת בדיקות תקינות ושירותי קצה עורפי

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

יצירת רכיבי Frontend

הגדרת Cloud DNS למעבר לשירות גיבוי (Failover)

יצירת בדיקת תקינות של Cloud DNS לנקודות קצה חיצוניות

יוצרים אזור ציבורי מנוהל ומדיניות ניתוב למעבר לגיבוי (failover).

8. בדיקת מעבר לשירות גיבוי אזורי

9. שלבי הניקוי

10. מעולה!

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