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

1. מבוא

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

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

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

Cloud DNS תומך בכללי מדיניות הניתוב הבאים:

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

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

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

המדיניות בנושא ניתוב כשלים

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

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

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

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

מה תפַתחו

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

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

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

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

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

ההגדרה מוצגת כך:

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

מה תלמדו

• איך ליצור מדיניות בנושא ניתוב מסוג יתירות כשל
• הפעלת יתירות כשל של DNS
• איך להערים על התנועה אל קבוצת הגיבוי

מה צריך להכין

• ידע בסיסי ב-DNS
• ידע בסיסי ב-Google Compute Engine
• ידע בסיסי במאזן עומסים פנימי (L4)

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

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

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

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

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

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

הפעלת Cloud Shell

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

במסוף 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

פקודה

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 הנדרשים מופעלים.

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

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

אימות

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

פקודה

gcloud services enable compute.googleapis.com

הפעלת ה-DNS API

פקודה

gcloud services enable dns.googleapis.com

אימות

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

פקודה

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.

פקודה

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

יצירת רשתות משנה

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

REGION_1 רשת משנה

פקודה

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

REGION_2 רשת משנה

פקודה

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

התרת תנועה ביציאה 80

פקודה

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 ב-VM של הלקוח

פקודה

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

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

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

REGION_1 שרת אינטרנט

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

פקודה

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'

REGION_2 שרת אינטרנט

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

פקודה

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'

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

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

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

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

Region_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

Region_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

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

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

פקודה

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. יצירת מאזני עומסים פנימיים של L4

כדי ליצור את ה-L4 ILB, אנחנו צריכים ליצור בדיקת תקינות, שירות לקצה העורפי וכלל העברה.

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

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

פקודה

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

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

משתמשים בפקודה gcloud compute backend-services create כדי ליצור את השירות לקצה העורפי. אחרי שתיצרו את השירותים לקצה העורפי, נוסיף את קבוצות המכונות הלא מנוהלות לשירותים לקצה העורפי באמצעות הפקודה 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

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

פקודה

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

פקודות

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

יצירה של רשומת DNS עם מדיניות לניתוב יתירות כשל

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

פקודה

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.

פקודה

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

דוגמה לפלט

בדוגמה הזו, כתובת ה-IP של us-west1-ilb היא 10.1.0.4 וכתובת ה-IP של us-east4-ilb היא 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

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

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

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

פקודה

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. בדיקת יתירות כשל

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

הסרת תג הרשת

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

פקודה

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

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

רזולוציית DNS

מהמכונה של הלקוח, מריצים את הפקודה הבאה

פקודה

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

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

12. בדיקת תרמיות תנועה

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

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

הוספת תג רשת

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

פקודה

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

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

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

מהמכונה של הלקוח, מריצים את הפקודה הבאה

פקודה

dig +short failover.example.com

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

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

פקודה

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 הזה, מריצים את הפקודות הבאות מ-CloudShell

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. מזל טוב

מזל טוב, פרסת ובדקת בהצלחה את מדיניות הניתוב של Cloud DNS,

אילו נושאים דיברנו?

• איך להגדיר מדיניות בנושא ניתוב יתירות כשל של Cloud DNS
• בדיקת יתירות כשל של DNS
• איך להערים על התנועה לקבוצת גיבוי

מה השלב הבא?

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

מידע נוסף

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