תקינות משולבת של Private Service Connect

1. מבוא

ב-Codelab הזה נסביר על Composite Health ל-Private Service Connect ‏ (PSC) למעבר אוטומטי ליתירות כשל אזורית. התכונה 'מצב תקינות משולב' ל-PSC היא תכונת רשת שמשפרת את עמידות השירות והזמינות שלו.

‫Composite Health מאפשרת ליצרני שירותים להגדיר מדיניות בריאות מותאמת אישית (מה המצב שמגדיר שירות בריא או לא בריא) ולהפיץ את האותות האלה באופן אוטומטי לצרכני שירותים שמתחברים לשירות באמצעות קצה עורפי של PSC. התכונה הזו מיועדת במיוחד לתמיכה במעבר אוטומטי ליתירות כשל באזור אחר. אם שירות אזורי של ספק לא תקין, מאזן העומסים של הצרכן מפסיק אוטומטית את ניתוב התנועה לאזור הזה ומפנה את התנועה לשירות תקין באזור אחר.

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

מה לומדים

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

מה צריך

  • פרויקט ב-Google Cloud
  • הרשאות IAM שניתנו לתפקיד המוגדר מראש roles/compute.admin או לתפקיד בסיסי רחב כמו roles/admin או roles/owner מדור קודם
  • היכרות עם מושגי הרשת של Google Cloud ועם השימוש ב-Google Cloud CLI

2. מושגים

רשתות PSC

טופולוגיית הרשת של שיעור ה-Codelab הזה כוללת רשת VPC של צרכן ורשת VPC של יצרן בשני אזורים פעילים של Google Cloud.

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

figure1

איור 1. טופולוגיה של רשת Codelab

בצד של היצרן יש רשתות משנה אזוריות עם מאזני עומסים אזוריים פנימיים מסוג passthrough שחושפים שירות באמצעות משאב אזורי של PSC service attachment. השירותים לקצה העורפי מכילים קבוצות אזוריות של מופעים מנוהלים (MIG) ועוברים בדיקת תקינות באמצעות בדיקה של בקשות http ואימות של תגובות 200 (OK).

כדי לראות אילו מאזני עומסים תומכים בבדיקת תקינות מורכבת עבור PSC, אפשר לעיין בתיעוד העדכני בנושא תאימות של Private Service Connect להגדרת שירות מנוהל.

Service health

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

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

  • מינימום x אחוזים מהשרתים העורפיים תקינים (ברירת המחדל היא 60)
  • מספר המינימלי של שרתי קצה עורפיים תקינים (ברירת המחדל היא 1)y

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

figure2

איור 2. מודל משאבים של Composite Health ל-PSC

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

3. הגדרת הפרויקט

גישה לפרויקט

בשיעור Codelab הזה נשתמש בפרויקט אחד ב-Google Cloud. בשלבי ההגדרה נעשה שימוש בפקודות gcloud ובפקודות של מעטפת Linux.

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

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

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

gcloud config set project YOUR_PROJECT_ID_HERE

הגדרת סביבת מעטפת

export PROJECT_ID=$(gcloud config list --format="value(core.project)")
export REGION_1="us-west1"
export ZONE_1="us-west1-c"
export REGION_2="us-east1"
export ZONE_2="us-east1-c"
echo ${PROJECT_ID}
echo ${REGION_1}
echo ${ZONE_1}
echo ${REGION_2}
echo ${ZONE_2}

הפעלת שירותי API

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

4. שירות Producer

יצירת משאבים משותפים

יצירת רשת

gcloud compute networks create vnet-producer --subnet-mode=custom

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

# create subnet for service workload in region 1
gcloud compute networks subnets create subnet-foo \
  --network=vnet-producer \
  --region=${REGION_1} \
  --range=172.16.1.0/24 \
  --enable-private-ip-google-access

# create subnet for psc nat in region 1
gcloud compute networks subnets create subnet-foo-pscnat \
  --network=vnet-producer \
  --region=${REGION_1} \
  --range=192.168.1.0/29 \
  --purpose=PRIVATE_SERVICE_CONNECT

# create subnet for service workload in region 2
gcloud compute networks subnets create subnet-bar \
  --network=vnet-producer \
  --region=${REGION_2} \
  --range=172.16.2.0/24 \
  --enable-private-ip-google-access

# create subnet for psc nat in region 2
gcloud compute networks subnets create subnet-bar-pscnat \
  --network=vnet-producer \
  --region=${REGION_2} \
  --range=192.168.2.0/29 \
  --purpose=PRIVATE_SERVICE_CONNECT

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

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

# create fw policy
gcloud compute network-firewall-policies create fw-policy-producer --global

# create fw policy rules
gcloud compute network-firewall-policies rules create 1001 \
  --description="allow iap for ssh" \
  --firewall-policy=fw-policy-producer \
  --global-firewall-policy \
  --action=allow \
  --direction=INGRESS \
  --layer4-configs=tcp:22  \
  --src-ip-ranges=35.235.240.0/20

gcloud compute network-firewall-policies rules create 1002 \
  --description="allow health checks" \
  --firewall-policy=fw-policy-producer \
  --global-firewall-policy \
  --action=allow \
  --direction=INGRESS \
  --layer4-configs=tcp,udp,icmp  \
  --src-ip-ranges=130.211.0.0/22,35.191.0.0/16

gcloud compute network-firewall-policies rules create 1003 \
  --description="allow psc nat clients" \
  --firewall-policy=fw-policy-producer \
  --global-firewall-policy \
  --action=allow \
  --direction=INGRESS \
  --layer4-configs=tcp:80  \
  --src-ip-ranges=192.168.1.0/29,192.168.2.0/29

# associate fw policy to vnet
gcloud compute network-firewall-policies associations create \
  --firewall-policy=fw-policy-producer \
  --network=vnet-producer \
  --name=fw-policy-association-producer \
  --global-firewall-policy

יצירה של Cloud Routers ושערי NAT

# create routers for nat in each region
gcloud compute routers create cr-nat-foo \
  --network=vnet-producer \
  --asn=16550 \
  --region=${REGION_1}

gcloud compute routers create cr-nat-bar \
  --network=vnet-producer \
  --asn=16550 \
  --region=${REGION_2}

# create nat gateways in each region
gcloud compute routers nats create natgw-foo \
  --router=cr-nat-foo \
  --region=${REGION_1} \
  --auto-allocate-nat-external-ips \
  --nat-all-subnet-ip-ranges

gcloud compute routers nats create natgw-bar \
  --router=cr-nat-bar \
  --region=${REGION_2} \
  --auto-allocate-nat-external-ips \
  --nat-all-subnet-ip-ranges

יצירת הגדרת הפעלה של מכונה וירטואלית עם שרת HTTP

cat > vm-server-startup.sh << 'EOF'
#! /bin/bash
apt-get update
apt-get install apache2 -y
vm_hostname="$(curl -H "Metadata-Flavor:Google" \
http://169.254.169.254/computeMetadata/v1/instance/name)"
vm_zone="$(curl -H "Metadata-Flavor:Google" \
http://169.254.169.254/computeMetadata/v1/instance/zone)"
echo "Page served from: $vm_hostname in zone $vm_zone" | \
tee /var/www/html/index.html
systemctl restart apache2
EOF

הגדרת שירות foo באזור 1

יצירת חשבון שירות לחישוב

# create managed instance group template
gcloud compute instance-templates create mig-template-foo \
  --machine-type=e2-micro \
  --network=vnet-producer \
  --region=${REGION_1} \
  --subnet=subnet-foo \
  --no-address \
  --shielded-secure-boot \
  --metadata-from-file=startup-script=vm-server-startup.sh

# create regional managed instance group
gcloud compute instance-groups managed create mig-foo \
  --region=${REGION_1} \
  --size=2 \
  --template=mig-template-foo \
  --base-instance-name=service-foo

יצירת רכיבים של מאזן עומסים של שירות

# create lb health check
gcloud compute health-checks create http hc-foo-http \
  --region=${REGION_1} \
  --port=80 \
  --enable-logging

# create backend service
gcloud compute backend-services create ilb-foo \
  --load-balancing-scheme=INTERNAL \
  --protocol=tcp \
  --region=${REGION_1} \
  --health-checks=hc-foo-http \
  --health-checks-region=${REGION_1}

# add managed instance group to backend service
gcloud compute backend-services add-backend ilb-foo \
  --instance-group=mig-foo \
  --instance-group-region=${REGION_1} \
  --region=${REGION_1}

# create forwarding rule
gcloud compute forwarding-rules create fr-foo \
  --region=${REGION_1} \
  --load-balancing-scheme=INTERNAL \
  --network=vnet-producer \
  --subnet=subnet-foo \
  --address=172.16.1.99 \
  --ip-protocol=TCP \
  --ports=80 \
  --backend-service=ilb-foo \
  --backend-service-region=${REGION_1} \
  --allow-global-access

פרסום שירות PSC

# create psc service attachment
gcloud compute service-attachments create psc-sa-foo \
  --region=${REGION_1} \
  --target-service=projects/${PROJECT_ID}/regions/${REGION_1}/forwardingRules/fr-foo \
  --connection-preference=ACCEPT_AUTOMATIC \
  --nat-subnets=subnet-foo-pscnat

הגדרת שירות bar באזור 2

יצירת חשבון שירות לחישוב

# create managed instance group template
gcloud compute instance-templates create mig-template-bar \
  --machine-type=e2-micro \
  --network=vnet-producer \
  --region=${REGION_2} \
  --subnet=subnet-bar \
  --no-address \
  --shielded-secure-boot \
  --metadata-from-file=startup-script=vm-server-startup.sh

# create regional managed instance group
gcloud compute instance-groups managed create mig-bar \
  --region=${REGION_2} \
  --size=2 \
  --template=mig-template-bar \
  --base-instance-name=service-bar

יצירת רכיבים של מאזן עומסים של שירות

# create lb health check
gcloud compute health-checks create http hc-bar-http \
  --region=${REGION_2} \
  --port=80 \
  --enable-logging

# create backend service
gcloud compute backend-services create ilb-bar \
  --load-balancing-scheme=INTERNAL \
  --protocol=tcp \
  --region=${REGION_2} \
  --health-checks=hc-bar-http \
  --health-checks-region=${REGION_2}

# add managed instance group to backend service
gcloud compute backend-services add-backend ilb-bar \
  --instance-group=mig-bar \
  --instance-group-region=${REGION_2} \
  --region=${REGION_2}

# create forwarding rule
gcloud compute forwarding-rules create fr-bar \
  --region=${REGION_2} \
  --load-balancing-scheme=INTERNAL \
  --network=vnet-producer \
  --subnet=subnet-bar \
  --address=172.16.2.99 \
  --ip-protocol=TCP \
  --ports=80 \
  --backend-service=ilb-bar \
  --backend-service-region=${REGION_2} \
  --allow-global-access

פרסום שירות PSC

# create psc service attachment
gcloud compute service-attachments create psc-sa-bar \
  --region=${REGION_2} \
  --target-service=projects/${PROJECT_ID}/regions/${REGION_2}/forwardingRules/fr-bar \
  --connection-preference=ACCEPT_AUTOMATIC \
  --nat-subnets=subnet-bar-pscnat

5. גישה לצרכנים

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

יצירת רכיבי רשת

# create vpc network
gcloud compute networks create vnet-consumer --subnet-mode=custom

# create client subnet in each region
gcloud compute networks subnets create subnet-client-1 \
  --network=vnet-consumer \
  --region=${REGION_1} \
  --range=10.10.1.0/24 \
  --enable-private-ip-google-access

gcloud compute networks subnets create subnet-client-2 \
  --network=vnet-consumer \
  --region=${REGION_2} \
  --range=10.10.2.0/24 \
  --enable-private-ip-google-access

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

# create proxy subnet in each region
gcloud compute networks subnets create subnet-proxy-1 \
  --purpose=GLOBAL_MANAGED_PROXY \
  --role=ACTIVE \
  --network=vnet-consumer \
  --region=${REGION_1} \
  --range=10.10.128.0/23

gcloud compute networks subnets create subnet-proxy-2 \
  --purpose=GLOBAL_MANAGED_PROXY \
  --role=ACTIVE \
  --network=vnet-consumer \
  --region=${REGION_2} \
  --range=10.10.130.0/23

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

# create fw policy
gcloud compute network-firewall-policies create fw-policy-consumer --global

# create fw policy rules
gcloud compute network-firewall-policies rules create 1001 \
  --description="allow iap for ssh" \
  --firewall-policy=fw-policy-consumer \
  --global-firewall-policy \
  --action=allow \
  --direction=INGRESS \
  --layer4-configs=tcp:22  \
  --src-ip-ranges=35.235.240.0/20

# associate fw policy to vnet
gcloud compute network-firewall-policies associations create \
  --firewall-policy=fw-policy-consumer \
  --network=vnet-consumer \
  --name=fw-policy-association-consumer \
  --global-firewall-policy

יצירת רכיבים של מאזן עומסים

# create psc network endpoint group per region
gcloud compute network-endpoint-groups create neg-foo \
  --network-endpoint-type=private-service-connect \
  --psc-target-service=projects/${PROJECT_ID}/regions/${REGION_1}/serviceAttachments/psc-sa-foo \
  --region=${REGION_1} \
  --network=vnet-consumer \
  --subnet=subnet-client-1

gcloud compute network-endpoint-groups create neg-bar \
  --network-endpoint-type=private-service-connect \
  --psc-target-service=projects/${PROJECT_ID}/regions/${REGION_2}/serviceAttachments/psc-sa-bar \
  --region=${REGION_2} \
  --network=vnet-consumer \
  --subnet=subnet-client-2

# verify psc connections
gcloud compute network-endpoint-groups list --format="value(selfLink, pscData.pscConnectionStatus)"

# create global backend service
gcloud compute backend-services create bes-foobar \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --protocol=HTTP \
  --global

# add negs to backend service
gcloud compute backend-services add-backend bes-foobar \
  --network-endpoint-group=neg-foo \
  --network-endpoint-group-region=${REGION_1} \
  --global

gcloud compute backend-services add-backend bes-foobar \
  --network-endpoint-group=neg-bar \
  --network-endpoint-group-region=${REGION_2} \
  --global

# create global url map
gcloud compute url-maps create ilb-foobar \
  --default-service=bes-foobar \
  --global

# create global target proxy
gcloud compute target-http-proxies create proxy-foobar \
  --url-map=ilb-foobar \
  --global

# create global forwarding rule for region 1
gcloud compute forwarding-rules create fr-foobar-1 \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --network=vnet-consumer \
  --subnet=subnet-client-1 \
  --subnet-region=${REGION_1} \
  --address=10.10.1.99 \
  --ports=80 \
  --target-http-proxy=proxy-foobar \
  --global

# create global forwarding rule for region 2
gcloud compute forwarding-rules create fr-foobar-2 \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --network=vnet-consumer \
  --subnet=subnet-client-2 \
  --subnet-region=${REGION_2} \
  --address=10.10.2.99 \
  --ports=80 \
  --target-http-proxy=proxy-foobar \
  --global

יצירת רשומות DNS

# create dns zone
gcloud dns managed-zones create zone-foobar \
  --description="private zone for foobar" \
  --dns-name=foobar.com \
  --networks=vnet-consumer \
  --visibility=private

# create geo dns record
gcloud dns record-sets create www.foobar.com \
  --zone=zone-foobar \
  --type=A \
  --ttl=300 \
  --routing-policy-type=GEO \
  --routing-policy-item="location=${REGION_1},rrdatas=10.10.1.99" \
  --routing-policy-item="location=${REGION_2},rrdatas=10.10.2.99"

יצירת משאבי מחשוב

# create client vm in region 1
gcloud compute instances create client-1 \
  --machine-type=e2-micro \
  --zone=${ZONE_1} \
  --subnet=subnet-client-1 \
  --no-address \
  --shielded-secure-boot

# create client vm in region 2
gcloud compute instances create client-2 \
  --machine-type=e2-micro \
  --zone=${ZONE_2} \
  --subnet=subnet-client-2 \
  --no-address \
  --shielded-secure-boot

בדיקת בסיס השירות

ממכונה וירטואלית של לקוח באזור 1

# send request from vm to service using hostname
gcloud compute ssh client-1 --zone=${ZONE_1} --command='
  curl -s -v www.foobar.com'

# send request from vm to load balancer forwarding rule region 1
gcloud compute ssh client-1 --zone=${ZONE_1} --command='
  curl -s 10.10.1.99'

# send request from vm to load balancer forwarding rule region 2
gcloud compute ssh client-1 --zone=${ZONE_1} --command='
  curl -s 10.10.2.99'

אופציונלי: מנסים את אותן בדיקות ממכונת הלקוח הווירטואלית באזור 2: gcloud compute ssh client-2 --zone=${ZONE_2}

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

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

6. משאבים בנושא בריאות

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

הגדרת תקינות השירות foo באזור 1

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

gcloud compute health-aggregation-policies create foo-health-policy \
  --region=${REGION_1} \
  --healthy-percent-threshold=60 \
  --min-healthy-threshold=1

יצירת מקור נתונים בנושא בריאות

gcloud compute health-sources create foo-health-source \
  --region=${REGION_1} \
  --source-type=BACKEND_SERVICE \
  --sources=ilb-foo \
  --health-aggregation-policy=foo-health-policy

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

gcloud compute composite-health-checks create foo-health-composite \
  --region=${REGION_1} \
  --health-sources=foo-health-source \
  --health-destination=projects/${PROJECT_ID}/regions/${REGION_1}/forwardingRules/fr-foo

אימות ההגדרה של fooהתקינות של השירות

אפשר לראות את ההגדרות של משאבי בריאות באמצעות פקודות list (ו-describe) לכל אזור

# show health aggregation policies
gcloud compute health-aggregation-policies list --regions=${REGION_1}

# show health sources
gcloud compute health-sources list --regions=${REGION_1}

# show composite health checks
gcloud compute composite-health-checks list --regions=${REGION_1}

הגדרת תקינות השירות bar באזור 2

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

gcloud compute health-aggregation-policies create bar-health-policy \
  --region=${REGION_2} \
  --healthy-percent-threshold=60 \
  --min-healthy-threshold=1

יצירת מקור נתונים בנושא בריאות

gcloud compute health-sources create bar-health-source \
  --region=${REGION_2} \
  --source-type=BACKEND_SERVICE \
  --sources=ilb-bar \
  --health-aggregation-policy=bar-health-policy

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

gcloud compute composite-health-checks create bar-health-composite \
  --region=${REGION_2} \
  --health-sources=bar-health-source \
  --health-destination=projects/${PROJECT_ID}/regions/${REGION_2}/forwardingRules/fr-bar

אימות ההגדרה של barהתקינות של השירות

# show health aggregation policies
gcloud compute health-aggregation-policies list --regions=${REGION_2}

# show health sources
gcloud compute health-sources list --regions=${REGION_2}

# show composite health checks
gcloud compute composite-health-checks list --regions=${REGION_2}

כאן מסתיים החלק של ההגדרה… ועכשיו עוברים לבדיקה.

7. בדיקות מעבר לגיבוי (Failover)

תרחיש של שירות foo באזור 1 לא תקין

בתרחיש הזה, נדמה כשל בשירות היצרן של PSC ‏foo באזור 1 על ידי עצירת שרת האינטרנט באחת משתי מכונות וירטואליות.

קבלת פרטים על מכונת VM של שרת

# set env var for a foo service vm name
export FOO_FAIL_NAME=$(gcloud compute instance-groups managed list-instances mig-foo \
  --limit=1 \
  --region=${REGION_1} \
  --format="value(name)")
echo ${FOO_FAIL_NAME}

# set env var for a foo service zone
export FOO_FAIL_ZONE=$(gcloud compute instance-groups managed list-instances mig-foo \
  --limit=1 \
  --region=${REGION_1} \
  --format="value(ZONE)")
echo ${FOO_FAIL_ZONE}

עצירה של שרת אזור 1 http

# stop apache http server to fail service
gcloud compute ssh ${FOO_FAIL_NAME} --zone=${FOO_FAIL_ZONE} --command='
  sudo systemctl stop apache2'

# verify service dead
gcloud compute ssh ${FOO_FAIL_NAME} --zone=${FOO_FAIL_ZONE} --command='
  sudo systemctl status apache2 | grep Active:'

אימות של שירות אזורי לא תקין

# check health state of backend service
gcloud compute backend-services get-health ilb-foo --region=${REGION_1}

הפלט שאתם מקבלים אמור להיראות כך:

backend: .../regions/us-west1/instanceGroups/mig-foo
status:
  healthStatus:
  -   forwardingRule: .../regions/us-west1/forwardingRules/fr-foo
    forwardingRuleIp: 172.16.1.99
    healthState: UNHEALTHY
    instance: .../zones/us-west1-a/instances/service-foo-<UID_1>
    ipAddress: 172.16.1.2
    port: 80
  -   forwardingRule: .../regions/us-west1/forwardingRules/fr-foo
    forwardingRuleIp: 172.16.1.99
    healthState: HEALTHY
    instance: .../zones/us-west1-b/instances/service-foo-<UID_2>
    ipAddress: 172.16.1.3
    port: 80
  kind: compute#backendServiceGroupHealth

# check health state of health source
gcloud compute health-sources get-health foo-health-source --region=${REGION_1}

הפלט שאתם מקבלים אמור להיראות כך:

healthState: UNHEALTHY
kind: compute#healthSourceHealth
sources:
- backends:
  - endpointCount: 1
    group: .../zones/us-west1-a/instanceGroups/mig-foo
    healthyEndpointCount: 0
  - endpointCount: 0
    group: .../zones/us-west1-c/instanceGroups/mig-foo
    healthyEndpointCount: 0
  - endpointCount: 1
    group: .../zones/us-west1-b/instanceGroups/mig-foo
    healthyEndpointCount: 1
  forwardingRule: .../regions/us-west1/forwardingRules/fr-foo
  source: .../regions/us-west1/backendServices/ilb-foo

בדיקה של מעבר אוטומטי לגיבוי (failover) של לקוח באזור 1

# send request to service using hostname
gcloud compute ssh client-1 --zone=${ZONE_1} --command='
  curl -s -v www.foobar.com'

# curl to ilb vip in region 1
gcloud compute ssh client-1 --zone=${ZONE_1} --command='
  curl -s 10.10.1.99'

# curl to ilb vip in region 2
gcloud compute ssh client-1 --zone=${ZONE_1} --command='
  curl -s 10.10.2.99'

התקינות המשולבת ב-PSC עודכנה במאזן העומסים של הצרכן והוא הופנה להימנע משירות לקצה העורפי הלא תקין באזור 1. במקום זאת, התעבורה מופנית לשירות bar שפועל בצורה תקינה באזור 2.

הפעלה מחדש של שרת http באזור 1

# start apache http server to return service to healthy
gcloud compute ssh ${FOO_FAIL_NAME} --zone=${FOO_FAIL_ZONE} --command='
  sudo systemctl start apache2'

# verify service running
gcloud compute ssh ${FOO_FAIL_NAME} --zone=${FOO_FAIL_ZONE} --command='
  sudo systemctl status apache2 | grep Active:'

# check health state of health source
gcloud compute health-sources get-health foo-health-source --region=${REGION_1}

הפלט שמתקבל אמור לכלול סטטוס HEALTHY שדומה לזה...

healthState: HEALTHY
kind: compute#healthSourceHealth
sources:
- backends:
  - endpointCount: 1
    group: .../zones/us-west1-a/instanceGroups/mig-foo
    healthyEndpointCount: 1
  - endpointCount: 0
    group: .../zones/us-west1-c/instanceGroups/mig-foo
    healthyEndpointCount: 0
  - endpointCount: 1
    group: .../zones/us-west1-b/instanceGroups/mig-foo
    healthyEndpointCount: 1
  forwardingRule: .../regions/us-west1/forwardingRules/fr-foo
  source: .../regions/us-west1/backendServices/ilb-foo

שינוי מדיניות הבריאות

מפיקים יכולים לשנות את מדיניות תקינות השירות על סמך קריטריונים שונים. במאמר בנושא מדיניות צבירת נתונים על תקינות מפורטים ערכי הסף המינימליים שצריך לעמוד בהם כדי לשמור על סטטוס תקין בכל מקורות הנתונים על תקינות (שירותי קצה עורפי).

עדכון המדיניות של bar Service Health

gcloud compute health-aggregation-policies update bar-health-policy \
  --region=${REGION_2} \
  --description="min 40% threshold" \
  --healthy-percent-threshold=40 \
  --min-healthy-threshold=2

# verify new policy is applied
gcloud compute health-aggregation-policies list --regions=${REGION_2}

השינוי במדיניות הבריאות של היוצר מאפשר:

  1. הפחתה של אחוז הסף המינימלי של מצב תקין מ-60% ל-40% – עכשיו כישלון של מכונת VM אחת לא יפעיל מצב לא תקין על סמך --healthy-percent-threshold (מצב הכישלון יהיה 50% וצריך רק 40% כדי להיות תקין)
  2. הגדלת המספר המינימלי של קצוות עורפיים תקינים מ-1 ל-2 מכונות וירטואליות – עכשיו כשל במכונה וירטואלית אחת יפעיל מצב לא תקין על סמך --min-healthy-threshold (מצב הכשל יהיה 1, אבל צריך 2 כדי להיות תקין)

תרחיש של שירות bar באזור 2 עם בעיה

בתרחיש הזה, נדמה כשל בשירות היצרן של PSC ‏bar באזור 2 על ידי עצירת שרת האינטרנט באחת משתי מכונות וירטואליות.

קבלת פרטים על מכונת VM של שרת

# set env var for a bar service vm name
export BAR_FAIL_NAME=$(gcloud compute instance-groups managed list-instances mig-bar \
  --limit=1 \
  --region=${REGION_2} \
  --format="value(name)")
echo ${BAR_FAIL_NAME}

# set env var for a bar service zone
export BAR_FAIL_ZONE=$(gcloud compute instance-groups managed list-instances mig-bar \
  --limit=1 \
  --region=${REGION_2} \
  --format="value(ZONE)")
echo ${BAR_FAIL_ZONE}

עצירת השרת באזור 2 http

# stop apache http server to fail service
gcloud compute ssh ${BAR_FAIL_NAME} --zone=${BAR_FAIL_ZONE} --command='
  sudo systemctl stop apache2'

# verify service dead
gcloud compute ssh ${BAR_FAIL_NAME} --zone=${BAR_FAIL_ZONE} --command='
  sudo systemctl status apache2 | grep Active:'

אימות של שירות אזורי לא תקין

# check health state of backend service
gcloud compute backend-services get-health ilb-bar --region=${REGION_2}

הפלט שאתם מקבלים אמור להיראות כך:

backend: .../regions/us-east1/instanceGroups/mig-bar
status:
  healthStatus:
  -   forwardingRule: .../regions/us-east1/forwardingRules/fr-bar
    forwardingRuleIp: 172.16.2.99
    healthState: UNHEALTHY
    instance: .../zones/us-east1-b/instances/service-bar-<UID_1>
    ipAddress: 172.16.2.3
    port: 80
  -   forwardingRule: .../regions/us-east1/forwardingRules/fr-bar
    forwardingRuleIp: 172.16.2.99
    healthState: HEALTHY
    instance: .../zones/us-east1-d/instances/service-foo-<UID_2>
    ipAddress: 172.16.2.2
    port: 80
  kind: compute#backendServiceGroupHealth

# check health state of health source
gcloud compute health-sources get-health bar-health-source --region=${REGION_2}

הפלט שאתם מקבלים אמור להיראות כך:

healthState: UNHEALTHY
kind: compute#healthSourceHealth
sources:
- backends:
  - endpointCount: 1
    group: .../zones/us-east1-b/instanceGroups/mig-bar
    healthyEndpointCount: 0
  - endpointCount: 1
    group: .../zones/us-east1-d/instanceGroups/mig-bar
    healthyEndpointCount: 1
  - endpointCount: 0
    group: .../zones/us-east1-c/instanceGroups/mig-bar
    healthyEndpointCount: 0
  forwardingRule: .../regions/us-west1/forwardingRules/fr-bar
  source: .../regions/us-west1/backendServices/ilb-bar

בדיקת מעבר לגיבוי (failover) של לקוח באזור 2

# send request to service using hostname
gcloud compute ssh client-2 --zone=${ZONE_2} --command='
  curl -s -v www.foobar.com'

# curl to ilb vip in region 1
gcloud compute ssh client-2 --zone=${ZONE_2} --command='
  curl -s 10.10.1.99'

# curl to ilb vip in region 2
gcloud compute ssh client-2 --zone=${ZONE_2} --command='
  curl -s 10.10.2.99'

התקינות המשולבת ב-PSC עודכנה במאזן העומסים של הצרכן, והוא הונחה להימנע משירות לקצה העורפי הלא תקין באזור 2. במקום זאת, התעבורה מופנית לשירות foo תקין באזור 1.

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

כאן מסתיים החלק של הבדיקה… ועכשיו עוברים למעקב.

8. מעקב אחר מצב הבריאות

שינויים במצב התקינות נרשמים ביומן כברירת מחדל. בפרויקטים של יצרנים אפשר לראות יומנים של מקורות בריאות ובדיקות תקינות מורכבות. פרויקטים מסוג צרכן יכולים לראות יומנים של קבוצות נקודות קצה ברשת (NEG) מסוג PSC שמחוברות לשירותים שפורסמו באמצעות Composite Health.

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

משאב במעקב

הצגה

שם יומן הביקורת

מקורות מידע בנושא בריאות ובדיקות משולבות

תצוגת המפיק

.../logs/compute.googleapis.com%2Fcompositehealth

קבוצות של נקודות קצה ברשת (NEGs) של Private Service Connect

תצוגת צרכן

.../logs/compute.googleapis.com%2Fservicehealthchecks

יומני הפקה

ביומני השירות המנוהל מוצג סיכום של תקינות השירותים הפנימיים של השירות המנוהל:

  • ‫HealthSource: תקינות של שירותים ספציפיים בקצה העורפי (לדוגמה, סטטוס המכונות הווירטואליות של mig-bar ו-mig-foo)
  • ‫CompositeHealthCheck: מצב השירות המצטבר באזור שפורסם, שמופה ליעד של כלל ההעברה של הספק (למשל, fr-bar או fr-foo)
# query logs for producer
gcloud logging read \
  'logName="projects/'${PROJECT_ID}'/logs/compute.googleapis.com%2Fcompositehealth"' \
  --project=${PROJECT_ID} \
  --limit=10 \
  --format='table(
    timestamp.date(format="%I:%M:%S %p", tz=LOCAL):label=TIME,
    resource.type.basename():label=TYPE,
    resource.labels.location:label=REGION,
    jsonPayload.healthState:label=STATE,
    jsonPayload.sources[0].backends[].group.basename().join(","):label=BACKENDS,
    jsonPayload.sources[0].backends[].healthyEndpointCount.join(","):label=HEALTHY,
    jsonPayload.sources[0].backends[].endpointCount.join(","):label=TOTAL,
    jsonPayload.healthDestination.basename():label=DESTINATION
  )'

יומני צרכנים

בקטעי היומן של הצרכן מוצג סטטוס התקינות שהועבר של משאבי הצרכן:

  • ‫NetworkEndpointGroup: מצב תקינות שהועבר של ה-PSC NEG שמחובר לשירות שפורסם (למשל, neg-bar ו-neg-foo)

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

# query logs for consumer
gcloud logging read \
  "logName=projects/${PROJECT_ID}/logs/compute.googleapis.com%2Fservicehealthchecks
  AND resource.type=\"compute.googleapis.com/NetworkEndpointGroupV2\"" \
  --project="${PROJECT_ID}" \
  --freshness=30m \
  --limit=10 \
  --format="table(
    timestamp.date(format='%I:%M:%S %p', tz=LOCAL):label=TIME,
    resource.labels.location:label=REGION,
    jsonPayload.serviceHealthCheckResult.healthState:label=STATE,
    jsonPayload.serviceHealthCheckResult.previousHealthState:label=PREV_STATE,
    resource.labels.network_endpoint_group_id:label=NEG_ID
  )"

כאן מסתיים החלק של המעקב... ועכשיו עוברים לניקוי.

9. הסרת המשאבים 

# delete health resources
gcloud -q compute composite-health-checks delete foo-health-composite --region=${REGION_1}

gcloud -q compute health-sources delete foo-health-source --region=${REGION_1}

gcloud -q compute health-aggregation-policies delete foo-health-policy --region=${REGION_1}

gcloud -q compute composite-health-checks delete bar-health-composite --region=${REGION_2}

gcloud -q compute health-sources delete bar-health-source --region=${REGION_2}

gcloud -q compute health-aggregation-policies delete bar-health-policy --region=${REGION_2}

# delete consumer compute and load balancer resources
gcloud -q compute instances delete client-2 --zone=${ZONE_2}

gcloud -q compute instances delete client-1 --zone=${ZONE_1}

gcloud -q dns record-sets delete www.foobar.com --type=A --zone=zone-foobar

gcloud -q dns managed-zones delete zone-foobar

gcloud -q compute forwarding-rules delete fr-foobar-2 --global

gcloud -q compute forwarding-rules delete fr-foobar-1 --global

gcloud -q compute target-http-proxies delete proxy-foobar --global

gcloud -q compute url-maps delete ilb-foobar --global

gcloud -q compute backend-services delete bes-foobar --global



# delete consumer network resources
gcloud -q compute network-endpoint-groups delete neg-bar --region=${REGION_2}

gcloud -q compute network-endpoint-groups delete neg-foo --region=${REGION_1}

gcloud -q compute networks subnets delete subnet-proxy-2 --region=${REGION_2}

gcloud -q compute networks subnets delete subnet-proxy-1 --region=${REGION_1}

gcloud -q compute networks subnets delete subnet-client-2 --region=${REGION_2}

gcloud -q compute networks subnets delete subnet-client-1 --region=${REGION_1}

gcloud -q compute network-firewall-policies associations delete \
  --firewall-policy=fw-policy-consumer \
  --name=fw-policy-association-consumer \
  --global-firewall-policy

gcloud -q compute network-firewall-policies delete fw-policy-consumer --global

gcloud -q compute networks delete vnet-consumer

# delete producer load balancer resources
gcloud -q compute service-attachments delete psc-sa-bar --region=${REGION_2}

gcloud -q compute service-attachments delete psc-sa-foo --region=${REGION_1}

gcloud -q compute forwarding-rules delete fr-bar --region=${REGION_2}

gcloud -q compute forwarding-rules delete fr-foo --region=${REGION_1}

gcloud -q compute backend-services delete ilb-bar --region=${REGION_2}

gcloud -q compute backend-services delete ilb-foo --region=${REGION_1}

gcloud -q compute health-checks delete hc-bar-http --region=${REGION_2}

gcloud -q compute health-checks delete hc-foo-http --region=${REGION_1}

# delete producer compute resources
gcloud -q compute instance-groups managed delete mig-bar --region=${REGION_2}

gcloud -q compute instance-groups managed delete mig-foo --region=${REGION_1}

gcloud -q compute instance-templates delete mig-template-bar --global

gcloud -q compute instance-templates delete mig-template-foo --global

# delete producer network resources
gcloud -q compute networks subnets delete subnet-bar-pscnat --region=${REGION_2}

gcloud -q compute networks subnets delete subnet-foo-pscnat --region=${REGION_1}

gcloud -q compute networks subnets delete subnet-bar --region=${REGION_2}

gcloud -q compute networks subnets delete subnet-foo --region=${REGION_1}

gcloud -q compute routers delete cr-nat-bar --region=${REGION_2}

gcloud -q compute routers delete cr-nat-foo --region=${REGION_1}

gcloud -q compute network-firewall-policies associations delete \
  --firewall-policy=fw-policy-producer \
  --name=fw-policy-association-producer \
  --global-firewall-policy

gcloud -q compute network-firewall-policies delete fw-policy-producer --global

gcloud -q compute networks delete vnet-producer

# delete shell variables and script file
unset FOO_FAIL_NAME FOO_FAIL_ZONE BAR_FAIL_NAME BAR_FAIL_ZONE

unset PROJECT_ID REGION_1 ZONE_1 REGION_2 ZONE_2

rm vm-server-startup.sh
#

10. סיכום

מעולה! הגדרתם בהצלחה את המצב המשולב של PSC ובדקתם יתירות כשל אוטומטית אזורית!

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

תודה!