יתירות כשל במספר אזורים באמצעות מדיניות הניתוב של Cloud DNS ובדיקות התקינות למאזן העומסים הפנימי של TCP/UDP

1. מבוא

העדכון האחרון: 22 בספטמבר 2022

מהי מדיניות ניתוב DNS

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

‫Cloud DNS תומך במדיניות הניתוב הבאה:

• מדיניות ניתוב סדר סיבובי משוקלל
• מדיניות ניתוב לפי מיקום גיאוגרפי
• מדיניות ניתוב עם גבול וירטואלי
• מדיניות ניתוב במעבר לגיבוי (failover)

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

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

מדיניות ניתוב למקרה של כשל

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

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

בדיקות תקינות

מדיניות הניתוב של DNS תהיה תלויה בבדיקות תקינות מאוחדות(UHC) של איזון עומסים פנימי מקורי. מאזן עומסים פנימי נחשב תקין אם 20% (או יותר) מהקצה העורפי תקינים. בדיקות תקינות של מאזני עומסים פנימיים מסוג TCP/UDP ומאזני עומסים פנימיים מסוג HTTP(S) מספקות מידע שונה. במאזן עומסים פנימי מסוג HTTP(S),‏ UHC מספק את סטטוס תקינות כל שרתי ה-proxy של Envoy, אבל במאזן עומסים פנימי מסוג TCP/UDP, ‏ Cloud DNS מקבל אותות תקינות ישירות ממופעי הקצה העורפי הנפרדים. פרטים על בדיקות תקינות זמינים כאן .

מה תפַתחו

ב-Codelab הזה תבנו אתר שפועל בשני אזורים ותקשרו אליו מדיניות ניתוב DNS למעבר אוטומטי לגיבוי. ההגדרה תכלול:

משאבים פעילים –

• מאזן עומסים פנימי ברמה 4 באזור REGION_1
• מכונה וירטואלית שבה פועל שרת אינטרנט של Apache באזור REGION_1

גיבוי משאבים –

• מאזן עומסים פנימי ברמה 4 באזור REGION_2
• מכונה וירטואלית שמריצה שרת אינטרנט של Apache באזור REGION_2

ההגדרה היא כמו שמוצג בהמשך –

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

מה תלמדו

• איך יוצרים מדיניות ניתוב למעבר לגיבוי
• הפעלת מעבר לגיבוי (failover) של DNS
• איך לפזר תעבורת נתונים אל קבוצת הגיבוי

מה תצטרכו

• ידע בסיסי ב-DNS
• ידע בסיסי ב-Google Compute Engine
• ידע בסיסי במאזן עומסים פנימי ברמה 4

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

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

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

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

הערה: אם אתם משתמשים בחשבון Gmail, אתם יכולים להשאיר את מיקום ברירת המחדל כפי שהוא, ללא ארגון. אם אתם משתמשים בחשבון Google Workspace, אתם צריכים לבחור מיקום שמתאים לארגון שלכם.

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

הפעלת Cloud Shell

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

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

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

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

3. גרסת Google Cloud SDK

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

בדיקת גרסת ה-SDK

משתמשים בפקודה gcloud version כדי לבדוק את גרסת ה-SDK. מריצים את הפקודות הבאות ב-Cloud Shell

Command

gcloud version | grep "Google Cloud SDK"

פלט לדוגמה

Google Cloud SDK 401.0.0

השלבים הבאים

זהירות: בוחרים באפשרות 1 או 2 בהתאם לפלט של הפקודה gcloud version

1. אם גרסת ה-SDK היא 401.0.0 ואילך, אפשר לדלג לסעיף הבא.
2. אם גרסת ה-SDK נמוכה מ-401.0.0, מריצים את הפקודה שמופיעה בהמשך כדי לעדכן את ה-SDK.

פקודה אופציונלית

sudo apt-get update && sudo apt-get install google-cloud-sdk

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

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

הגדרת מזהה פרויקט

ב-Cloud Shell, מוודאים שמזהה הפרויקט מוגדר. אם שורת הפקודה של Cloud Shell נראית כמו הפלט שבהמשך ואתם לא מתכננים לשנות את מזהה הפרויקט, אתם יכולים לדלג לשלב הבא (הגדרת משתני סביבה).

USER@cloudshell:~ (PROJECT_ID)$

אם עדיין רוצים לשנות את מזהה הפרויקט, משתמשים בפקודה שמופיעה בהמשך. שורת הפקודה ב-Cloud Shell תשתנה מ-(PROJECT_ID) ל-(YOUR-PROJECT-ID)

פקודה אופציונלית

gcloud config set project [YOUR-PROJECT-ID]

פלט לדוגמה

Updated property [core/project].
USER@cloudshell:~ (YOUR-PROJECT-ID)$

הגדרת משתני הסביבה

הגדרת משתני הסביבה

נשתמש בפקודה export כדי להגדיר את משתני הסביבה. מריצים את הפקודות הבאות ב-Cloud Shell

פקודות

export REGION_1=us-west1

export REGION_1_ZONE=us-west1-a

export REGION_2=us-east4

export REGION_2_ZONE=us-east4-a

הערה: בשיעור ה-Lab הזה אנחנו משתמשים באזורים us-west1 ו-us-east4. יכול להיות שקיבולת החישוב תהיה מוגבלת באזור מסוים. אם מופיעות שגיאות שקשורות לקיבולת בזמן יצירת מכונות וירטואליות, צריך להשתמש באזור או באזור זמינות אחרים. כאן אפשר לעיין ברשימה של אזורים ותחומים (zones) שזמינים.

אימות

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

פקודות

echo $REGION_1

echo $REGION_1_ZONE

echo $REGION_2

echo $REGION_2_ZONE

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

משתמשים בפקודה gcloud services enable כדי להפעיל את ממשקי ה-API של Compute ו-DNS. מריצים את הפקודות הבאות ב-Cloud Shell

הפעלת Compute API

Command

gcloud services enable compute.googleapis.com

הפעלת DNS API

Command

gcloud services enable dns.googleapis.com

אימות

אחרי שהפעלתם את השירותים, תוכלו להשתמש בפקודה gcloud services list כדי לראות את רשימת כל ממשקי ה-API המופעלים.

Command

gcloud services list | grep -E 'compute|dns'

פלט לדוגמה

NAME: compute.googleapis.com
NAME: dns.googleapis.com

5. יצירת רשת VPC, רשתות משנה וכללים לחומת אש

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

יצירת רשת VPC

משתמשים בפקודה gcloud compute networks create כדי ליצור את רשת ה-VPC. אנחנו מגדירים את מצב רשת המשנה כ'מותאם אישית' כי בשלב הבא ניצור רשתות משנה משלנו. מריצים את הפקודות הבאות ב-Cloud Shell.

Command

gcloud compute networks create my-vpc --subnet-mode custom

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

משתמשים בפקודה gcloud compute networks subnets create כדי ליצור שתי רשתות משנה, אחת ב-REGION_1 ואחת ב-REGION_2. מריצים את הפקודות הבאות ב-Cloud Shell

רשת המשנה של REGION_1

Command

gcloud compute networks subnets create ${REGION_1}-subnet \
--network my-vpc \
--range 10.1.0.0/24 \
--region $REGION_1

רשת המשנה של REGION_2

Command

gcloud compute networks subnets create ${REGION_2}-subnet \
--network my-vpc \
--range 10.2.0.0/24 \
--region $REGION_2

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

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

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

משתמשים בפקודה gcloud compute firewall-rules create כדי ליצור את הכללים בחומת האש. מריצים את הפקודות הבאות ב-Cloud Shell

Allow Traffic on Port 80

Command

gcloud compute firewall-rules create allow-http-lb-hc \
--allow tcp:80 --network my-vpc \
--source-ranges 10.1.0.0/24,10.2.0.0/24,35.191.0.0/16,130.211.0.0/22 \
--target-tags=allow-http

אישור תעבורת SSH במכונה הווירטואלית של הלקוח

Command

gcloud compute firewall-rules create allow-ssh \
--allow tcp:22 --network my-vpc \
--source-ranges 0.0.0.0/0 \
--target-tags=allow-ssh

6. יצירת Cloud NAT

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

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

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

יצירת Cloud Routers

משתמשים בפקודה gcloud compute routers create כדי ליצור Cloud Routers באזורים us-west1 ו-us-east4. מריצים את הפקודות הבאות ב-Cloud Shell.

‫Region_1 Cloud Router

פקודות

gcloud compute routers create "${REGION_1}-cloudrouter" \
--region $REGION_1 --network=my-vpc --asn=65501

‫Region_2 Cloud Router

פקודות

gcloud compute routers create "${REGION_2}-cloudrouter" \
--region $REGION_2 --network=my-vpc --asn=65501

יצירת שערים של NAT

משתמשים בפקודה gcloud compute routers nat create כדי ליצור את שער ה-NAT באזורים us-west1 ו-us-east4. מריצים את הפקודות הבאות ב-Cloud Shell.

‫Region_1 NAT Gateway

פקודות

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

Region_2 NAT Gateway

פקודות

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

7. יצירת מכונות וירטואליות ב-Compute Engine

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

הערה: בשיעור ה-Lab הזה אנחנו משתמשים באזורים us-west1 ו-us-east4. יכול להיות שקיבולת החישוב תהיה מוגבלת באזור מסוים. אם מופיעות שגיאות שקשורות לקיבולת בזמן יצירת מכונות וירטואליות, צריך להשתמש באזור או באזור זמינות אחרים. כאן אפשר לעיין ברשימה של אזורים ותחומים (zones) שזמינים.

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

משתמשים בפקודה gcloud compute instances create כדי ליצור את שרתי האינטרנט. צריך ליצור שני שרתי אינטרנט, אחד ב-REGION_1 ואחד ב-REGION_2. אנחנו משתמשים בסקריפטים להפעלה כדי להתקין ולהגדיר את Apache בשרתי האינטרנט.

שרת אינטרנט של אזור 1

מריצים את הפקודה הבאה ב-Cloud Shell

Command

gcloud compute instances create "${REGION_1}-instance" \
--image-family=debian-11 --image-project=debian-cloud \
--zone=$REGION_1_ZONE \
--network-interface=network=my-vpc,subnet=${REGION_1}-subnet,no-address \
--tags=allow-http \
--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://169.254.169.254/computeMetadata/v1/instance/name)"
    echo "Page served from: $vm_hostname" | \
    tee /var/www/html/index.html
    systemctl restart apache2'

שרת אינטרנט של אזור 2

מריצים את הפקודה הבאה ב-Cloud Shell

Command

gcloud compute instances create "${REGION_2}-instance" \
--image-family=debian-11 --image-project=debian-cloud \
--zone=$REGION_2_ZONE \
--network-interface=network=my-vpc,subnet=${REGION_2}-subnet,no-address \
--tags=allow-http \
--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://169.254.169.254/computeMetadata/v1/instance/name)"
    echo "Page served from: $vm_hostname" | \
    tee /var/www/html/index.html
    systemctl restart apache2'

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

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

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

משתמשים בפקודה gcloud compute instance-groups unmanaged create כדי ליצור שתי קבוצות של מופעים לא מנוהלים, אחת לשרת האינטרנט us-west1 ואחת לשרת האינטרנט us-east4.

קבוצת מופעים באזור 1

פקודות

gcloud compute instance-groups unmanaged create \
"${REGION_1}-instance-group" --zone=$REGION_1_ZONE

קבוצת מופעים Region_2

פקודות

gcloud compute instance-groups unmanaged create \
"${REGION_2}-instance-group" --zone=$REGION_2_ZONE

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

משתמשים בפקודה gcloud compute instance-groups unmanaged add-instances כדי להוסיף את המכונות לקבוצות המכונות שיצרנו. הוספת שרת האינטרנט REGION_1 לקבוצת המופעים REGION_1 ושרת האינטרנט REGION_2 לקבוצת המופעים REGION_2

קבוצת מופעים באזור 1

פקודות

gcloud compute instance-groups unmanaged add-instances \
"${REGION_1}-instance-group" --instances $REGION_1-instance \
--zone=$REGION_1_ZONE

קבוצת מופעים Region_2

פקודות

gcloud compute instance-groups unmanaged add-instances \
"${REGION_2}-instance-group" --instances $REGION_2-instance \
--zone=$REGION_2_ZONE

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

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

Command

gcloud compute instances create client-instance --image-family=debian-11 \
--image-project=debian-cloud \
--zone=$REGION_1_ZONE \
--network-interface=network=my-vpc,subnet=${REGION_1}-subnet,no-address \
--tags=allow-ssh \
--metadata=startup-script='#! /bin/bash
    apt-get update
    apt-get install dnsutils -y'

8. יצירת מאזני עומסים פנימיים ברמה 4

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

יצירת בדיקת תקינות

משתמשים בפקודה gcloud compute health-checks create כדי ליצור את בדיקת תקינות. אנחנו יוצרים בדיקת תקינות בסיסית של http ויציאת היעד היא יציאה 80. מריצים את הפקודות הבאות ב-Cloud Shell

Command

gcloud compute health-checks create http http-hc --port 80

הגדרת שירותי קצה עורפי

משתמשים בפקודה gcloud compute backend-services create כדי ליצור את שירות לקצה העורפי. אחרי שיוצרים את שירותי ה-Backend, מוסיפים את קבוצות המופעים הלא מנוהלות לשירותי ה-Backend באמצעות הפקודה gcloud compute backend-services add-backend. מריצים את הפקודות הבאות ב-Cloud Shell.

יצירת שירות לקצה העורפי

פקודות

gcloud compute backend-services create $REGION_1-backend-service \
--load-balancing-scheme=INTERNAL --protocol=TCP \
--health-checks=http-hc --region=$REGION_1

gcloud compute backend-services create $REGION_2-backend-service \
--load-balancing-scheme=INTERNAL --protocol=TCP \
--health-checks=http-hc --region=$REGION_2

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

Command

gcloud compute backend-services add-backend $REGION_1-backend-service \
--instance-group=$REGION_1-instance-group \
--region=$REGION_1 \
--instance-group-zone=$REGION_1_ZONE

gcloud compute backend-services add-backend $REGION_2-backend-service \
--instance-group=$REGION_2-instance-group \
--region=$REGION_2 \
--instance-group-zone=$REGION_2_ZONE

איך יוצרים כללי העברה

משתמשים בפקודה gcloud compute forwarding-rules create כדי ליצור את כללי ההעברה בשני האזורים. מריצים את הפקודות הבאות ב-Cloud Shell

כלל העברה של REGION_1

פקודות

gcloud compute forwarding-rules create $REGION_1-ilb \
    --region=$REGION_1 \
    --load-balancing-scheme=internal \
    --network=my-vpc \
    --subnet=$REGION_1-subnet \
    --ip-protocol=TCP \
    --ports=80 \
    --backend-service=$REGION_1-backend-service \
    --backend-service-region=$REGION_1 \
    --allow-global-access

כלל העברה של REGION_2

gcloud compute forwarding-rules create $REGION_2-ilb \
    --region=$REGION_2 \
    --load-balancing-scheme=internal \
    --network=my-vpc \
    --subnet=$REGION_2-subnet \
    --ip-protocol=TCP \
    --ports=80 \
    --backend-service=$REGION_2-backend-service \
    --backend-service-region=$REGION_2 \
    --allow-global-access

9. הגדרת DNS

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

יצירת תחום DNS פרטי

משתמשים בפקודה gcloud dns managed-zones create כדי ליצור אזור פרטי לדומיין example.com. נשתמש באזור הזה כדי ליצור קבוצת רשומות של משאבים עם מדיניות ניתוב למעבר לגיבוי (failover). מריצים את הפקודה הבאה ב-Cloud Shell

פקודות

gcloud dns managed-zones create example-com \
--dns-name example.com. --description="My private zone" \
--visibility=private --networks my-vpc 

יצירת רשומת DNS עם מדיניות ניתוב למעבר לגיבוי (failover)

משתמשים בפקודה gcloud dns record-sets create כדי ליצור רשומת DNS עם מדיניות ניתוב לגיבוי. יעד ראשי הוא מאזן העומסים ב-REGION_1. ‫Cloud DNS תומך רק ביעדי גיבוי מבוססי-מיקום גיאוגרפי. קבוצת הגיבוי היא מדיניות מיקום גיאוגרפי עם איזון עומסים מסוג REGION_2 כיעד גם עבור REGION_1 וגם עבור REGION_2. מריצים את הפקודות הבאות ב-Cloud Shell

Command

gcloud dns record-sets create failover.example.com --ttl 5 --type A \
--routing-policy-type=FAILOVER \
--routing-policy-primary-data=$REGION_1-ilb \
--routing-policy-backup-data="${REGION_1}=${REGION_2}-ilb;${REGION_2}=${REGION_2}-ilb" \
--routing-policy-backup-data-type=GEO \
--zone=example-com \
--enable-health-checking

פלט לדוגמה

NAME: failover.example.com.
TYPE: A
TTL: 5
DATA: Primary: "10.1.0.4, 80, tcp, https://www.googleapis.com/compute/v1/projects/my-clouddns-codelab/global/networks/my-vpc, my-clouddns-codelab, us-west1, regionalL4ilb" Backup: us-west1: "10.2.0.3, 80, tcp, https://www.googleapis.com/compute/v1/projects/my-clouddns-codelab/global/networks/my-vpc, my-clouddns-codelab, us-east4, regionalL4ilb";us-east4: "10.2.0.3, 80, tcp, https://www.googleapis.com/compute/v1/projects/my-clouddns-codelab/global/networks/my-vpc, my-clouddns-codelab, us-east4, regionalL4ilb"

10. בדיקת פענוח DNS

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

Command

gcloud compute forwarding-rules list --filter="name:($REGION_1-ilb $REGION_2-ilb)"

פלט לדוגמה

בדוגמה הזו, ל-us-west1-ilb יש כתובת IP של 10.1.0.4 ול-us-east4-ilb יש כתובת IP של 10.2.0.3

NAME: us-west1-ilb
REGION: us-west1
IP_ADDRESS: 10.1.0.4
IP_PROTOCOL: TCP
TARGET: us-west1/backendServices/us-west1-backend-service

NAME: us-east4-ilb
REGION: us-east4
IP_ADDRESS: 10.2.0.3
IP_PROTOCOL: TCP
TARGET: us-east4/backendServices/us-east4-backend-service

עכשיו נתחבר למופע הלקוח ונבדוק את פענוח ה-DNS. במסוף האינטרנטי, מנווטים אל Compute Engine | VM Instances (מכונות וירטואליות)

לוחצים על לחצן ה-SSH כדי להתחבר למופע הלקוח מהמסוף.

עכשיו, כשנכנסתם למכונה הווירטואלית של הלקוח, משתמשים בפקודה dig כדי לפתור את שם הדומיין failover.example.com.

הלולאה מוגדרת להרצת הפקודה עשר פעמים עם טיימר שינה של 6 שניות.

Command

for i in {1..10}; do echo $i; dig failover.example.com +short; sleep 6; done

מאחר שערך ה-TTL ברשומת ה-DNS מוגדר ל-5 שניות, נוסף טיימר שינה של 6 שניות. הטיימר לשינה יוודא שתקבלו תגובת DNS לא שמורה במטמון לכל בקשת DNS. הביצוע של הפקודה הזו יימשך כדקה.

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

11. בדיקת מעבר לשירות גיבוי (failover)

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

הסרת תג הרשת

משתמשים בפקודה gcloud compute instances remove-tags כדי להסיר את תג הרשת מהמכונה הווירטואלית. מריצים את הפקודה הבאה ב-Cloud Shell

Command

gcloud compute instances remove-tags $REGION_1-instance \
--zone=$REGION_1_ZONE --tags=allow-http

בדיקת התקינות תיכשל תוך 10 שניות. מריצים שוב את בדיקת פענוח ה-DNS.

פענוח DNS

מריצים את הפקודה הבאה ממופע הלקוח

Command

for i in {1..10}; do echo $i; dig failover.example.com +short; sleep 6; done

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

12. בדיקת טפטוף תנועה

כברירת מחדל, מדיניות המעבר לגיבוי מחזירה את כתובת ה-IP של נקודת הקצה הראשית לכל בקשות ה-DNS, ומחזירה את כתובות ה-IP של הגיבוי רק אם הבדיקות של תקינות נקודת הקצה הראשית נכשלות. ב-Cloud DNS, המשתמשים יכולים להגדיר את ההגדרה Trickle Ratio (יחס טפטוף), שמאפשרת ל-Cloud DNS לשלוח חלק מהתנועה ליעדי הגיבוי, גם כשהיעדים הראשיים תקינים. היחס צריך להיות ערך בין 0 ל-1. ערך ברירת המחדל הוא 0

כדי לבדוק את זה, נוסיף את תג הרשת בחזרה לשרת האינטרנט REGION_1.

הוספת תג רשת

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

Command

gcloud compute instances add-tags $REGION_1-instance \
--zone $REGION_1_ZONE --tags allow-http

בדיקות התקינות יעברו תוך 10 שניות

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

מריצים את הפקודה הבאה ממופע הלקוח

Command

dig +short failover.example.com

עדכון רשומת ה-DNS

עכשיו נשנה את רשומת ה-DNS של failover.example.com כדי להעביר 30% מהתנועה לסט הגיבוי גם כשהמקור תקין. מריצים את הפקודה הבאה ב-Cloud Shell

Command

gcloud dns record-sets update failover.example.com --ttl 30 --type A \
--routing-policy-type=FAILOVER \
--routing-policy-primary-data=$REGION_1-ilb \
--routing-policy-backup-data="${REGION_1}=${REGION_2}-ilb;${REGION_2}=${REGION_2}-ilb" \
--routing-policy-backup-data-type=GEO \
--zone=example-com --enable-health-checking \
--backup-data-trickle-ratio=0.3

פענוח DNS

מריצים את הפקודה הבאה ממכונת ה-VM של הלקוח. אפשר לראות שרשומת ה-DNS‏ failover.example.com תתפרש ככתובת ה-IP של מאזן העומסים הראשי בערך ב-70% מהמקרים, וככתובת ה-IP של מאזן העומסים לגיבוי בערך ב-30% מהמקרים.

for i in {1..10}; do echo $i; dig failover.example.com +short; sleep 6; done

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

כדי למחוק את המשאבים שבהם השתמשתם בשיעור ה-Lab הזה, מריצים את הפקודות הבאות מ-Cloud Shell.

gcloud dns record-sets delete failover.example.com --type=A \
--zone=example-com --quiet

gcloud dns managed-zones delete example-com --quiet

gcloud compute forwarding-rules delete $REGION_1-ilb \
--region=$REGION_1 --quiet

gcloud compute forwarding-rules delete $REGION_2-ilb \
--region=$REGION_2 --quiet

gcloud compute backend-services delete $REGION_1-backend-service \
--region=$REGION_1 --quiet

gcloud compute backend-services delete $REGION_2-backend-service \
--region=$REGION_2 --quiet

gcloud compute health-checks delete http-hc --quiet

gcloud compute instances delete client-instance --zone=$REGION_1_ZONE --quiet

gcloud compute instance-groups unmanaged delete $REGION_1-instance-group \
--zone=$REGION_1_ZONE --quiet

gcloud compute instance-groups unmanaged delete $REGION_2-instance-group \
--zone=$REGION_2_ZONE --quiet

gcloud compute instances delete $REGION_1-instance \
--zone=$REGION_1_ZONE --quiet

gcloud compute instances delete $REGION_2-instance \
--zone=$REGION_2_ZONE --quiet

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

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

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

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

gcloud compute firewall-rules delete allow-ssh allow-http-lb-hc --quiet

gcloud compute networks subnets delete $REGION_1-subnet \
--region=$REGION_1 --quiet

gcloud compute networks subnets delete $REGION_2-subnet \
--region=$REGION_2 --quiet

gcloud compute networks delete my-vpc --quiet

14. מזל טוב

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

מה נכלל

• איך מגדירים מדיניות ניתוב למעבר אוטומטי לגיבוי ב-Cloud DNS
• בדיקת מעבר אוטומטי לגיבוי (failover) של DNS
• איך לפזר תעבורת נתונים לסט גיבוי

מה השלב הבא?

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

מידע נוסף

https://cloud.google.com/dns/docs/zones/manage-routing-policies