สถานะของ Private Service Connect

1. บทนำ

Codelab นี้จะสำรวจประสิทธิภาพของ Private Service Connect (PSC) สำหรับการเฟลโอเวอร์ระดับภูมิภาคอัตโนมัติ สถานะ PSC เป็นฟีเจอร์เครือข่ายที่ช่วยปรับปรุงความยืดหยุ่นและความพร้อมใช้งานของบริการ

สถานะของ PSC ช่วยให้ผู้ผลิตบริการกำหนดนโยบายสถานะที่กำหนดเองได้ (สถานะที่กำหนดบริการว่ามีสถานะปกติหรือไม่) และเผยแพร่สัญญาณเหล่านี้ไปยังผู้ใช้บริการที่เชื่อมต่อกับบริการด้วยแบ็กเอนด์ของ PSC โดยอัตโนมัติ ฟีเจอร์นี้ออกแบบมาโดยเฉพาะเพื่อรองรับเฟลโอเวอร์ข้ามภูมิภาคโดยอัตโนมัติ หากบริการผู้ผลิตระดับภูมิภาคไม่ทำงานตามปกติ ตัวจัดสรรภาระงานของผู้บริโภคจะหยุดกำหนดเส้นทางการรับส่งข้อมูลไปยังภูมิภาคนั้นโดยอัตโนมัติ และกำหนดเส้นทางการรับส่งข้อมูลไปยังบริการที่ทำงานตามปกติในภูมิภาคอื่น

เมื่อเทียบกับวิธีการเฟลโอเวอร์ข้ามภูมิภาคก่อนหน้านี้ เช่น การตรวจหาค่าผิดปกติ การตรวจสอบสถานะ PSC จะให้สัญญาณเฟลโอเวอร์ที่แม่นยำกว่าเนื่องจากอิงตามสถานะที่รวบรวมของแบ็กเอนด์บริการของผู้ผลิต (กลุ่มอินสแตนซ์ VM หรือปลายทางเครือข่าย) โดยตรง ผู้ผลิตสามารถกำหนดตรรกะด้านสุขภาพของตนเองได้ เพื่อให้มั่นใจว่าผู้ผลิตจะได้รับการเข้าชมเฉพาะเมื่อบริการเป็นไปตามเกณฑ์ด้านสุขภาพที่จำเป็นอย่างแท้จริงเท่านั้น

สิ่งที่คุณจะได้เรียนรู้

• องค์ประกอบของสถานะของ PSC และวิธีที่องค์ประกอบเหล่านี้ทำงานร่วมกันเพื่อกำหนดสถานะของบริการของผู้ผลิต
• การใช้สถานะของ PSC สำหรับบริการของผู้ผลิตโดยใช้คำสั่ง gcloud
• การกำหนดค่าตัวจัดสรรภาระงานการเข้าถึงของผู้ใช้ PSC ข้ามภูมิภาคเพื่อใช้สัญญาณด้านสถานะจากนโยบายด้านสถานะของ PSC ของผู้ผลิต
• การทดสอบสถานการณ์ที่บริการล้มเหลวและการตรวจสอบการทำงานของการเปลี่ยนเส้นทางไปยังภูมิภาคอื่นโดยอัตโนมัติ

สิ่งที่ต้องมี

• โปรเจ็กต์ Google Cloud
• สิทธิ์ IAM ที่มอบให้กับบทบาท roles/compute.admin ที่กำหนดไว้ล่วงหน้าหรือบทบาทพื้นฐานแบบกว้าง เช่น roles/admin หรือ roles/owner แบบเดิม
• มีความคุ้นเคยกับแนวคิดด้านเครือข่ายของ Google Cloud และการใช้ Google Cloud CLI

2. แนวคิด

การเชื่อมต่อเครือข่าย PSC

โทโพโลยีเครือข่าย Codelab นี้มีเครือข่าย VPC ของผู้บริโภคและผู้ผลิตใน 2 ภูมิภาค Google Cloud ที่ใช้งานอยู่

ฝั่งผู้ใช้มีซับเน็ตระดับภูมิภาคที่มีอินสแตนซ์ VM ของไคลเอ็นต์ซึ่งใช้เพื่อเข้าถึงบริการของผู้ผลิตผ่านตัวจัดสรรภาระงานแอปพลิเคชันภายในแบบข้ามภูมิภาคที่มีแบ็กเอนด์กลุ่มปลายทางเครือข่าย PSC (NEG) มีกฎการส่งต่อตัวจัดสรรภาระงานระดับภูมิภาค 2 รายการที่มีที่อยู่ IP ระดับภูมิภาคสำหรับการรับส่งข้อมูลขาเข้าของไคลเอ็นต์ทั่วโลก (ข้ามภูมิภาค) บริการแบ็กเอนด์เป็นทรัพยากรส่วนกลางที่รองรับ NEG ในภูมิภาคต่างๆ ในสถานการณ์เฟลโอเวอร์ ระบบจะนำไคลเอ็นต์ที่เชื่อมต่อกับกฎการส่งต่อส่วนหน้าของภูมิภาคไปยังแบ็กเอนด์ส่วนกลางที่ทำงานได้

รูปที่ 1 โทโพโลยีเครือข่าย Codelab

ฝั่งผู้ผลิตมีเครือข่ายย่อยระดับภูมิภาคที่มีตัวจัดสรรภาระงานเครือข่ายแบบส่งผ่านภายในระดับภูมิภาคซึ่งแสดงบริการผ่านทรัพยากรไฟล์แนบบริการ PSC ระดับภูมิภาค บริการแบ็กเอนด์มีกลุ่มอินสแตนซ์ที่มีการจัดการ (MIG) ระดับภูมิภาค และได้รับการตรวจสอบประสิทธิภาพการทำงานโดยการตรวจสอบคำขอ http และตรวจสอบการตอบกลับ 200 (OK)

โปรดดูเอกสารล่าสุดเกี่ยวกับความเข้ากันได้ของ Private Service Connect สำหรับการกำหนดค่าผู้ผลิตเพื่อดูว่าตัวจัดสรรภาระงานใดรองรับสถานะของ PSC

ประสิทธิภาพบริการ

การตรวจสอบประสิทธิภาพการทำงานของบริการแบ็กเอนด์ของผู้ผลิต ซึ่งกำหนดค่าไว้ในระหว่างการสร้างตัวจัดสรรภาระงาน จะทำหน้าที่เป็นสัญญาณต้นทางสำหรับฟีเจอร์สถานะ PSC ทรัพยากรแหล่งข้อมูลด้านสุขภาพใช้สัญญาณดังกล่าวพร้อมกับข้อจำกัดเพิ่มเติมที่กำหนดไว้ในทรัพยากรนโยบายการรวบรวมข้อมูลด้านสุขภาพเพื่อกำหนดสถานะสุขภาพสำหรับบริการแบ็กเอนด์เดียว

โดยค่าเริ่มต้น ระบบจะถือว่าบริการมีสถานะปกติเมื่อเป็นไปตามข้อจำกัดทั้ง 2 ข้อนี้

• มีแบ็กเอนด์ที่ทำงานได้ดีอย่างน้อย x เปอร์เซ็นต์ (ค่าเริ่มต้นคือ 60)
• แบ็กเอนด์อย่างน้อย y รายการมีประสิทธิภาพดี (ค่าเริ่มต้นคือ 1)

การตรวจสอบประสิทธิภาพการทำงานแบบผสมจะอ้างอิงแหล่งที่มาของสถานะทั้งหมดสำหรับบริการแบ็กเอนด์ทั้งหมดเพื่อพิจารณาสถานะโดยรวมของบริการผู้ผลิตระดับภูมิภาคทั้งหมด ในกรณีของ Lab นี้ บริการผู้ผลิตแต่ละภูมิภาคมีแหล่งที่มาของสถานะบริการแบ็กเอนด์เพียงแหล่งเดียวที่สรุปผลเป็นการตรวจสอบประสิทธิภาพการทำงานแบบคอมโพสิต 1 รายการ

รูปที่ 2 รูปแบบทรัพยากรด้านสุขภาพของ PSC

คำจำกัดความของทรัพยากรการตรวจสอบประสิทธิภาพการทำงานแบบคอมโพสิตยังอ้างอิงถึงกฎการส่งต่อของตัวจัดสรรภาระงานของบริการผู้ผลิตด้วย แบ็กเอนด์ PSC NEG ของตัวจัดสรรภาระงานสำหรับการเข้าถึงของผู้ใช้จะเชื่อมต่อกับไฟล์แนบบริการ PSC ของผู้ผลิตและกฎการส่งต่อของตัวจัดสรรภาระงานของผู้ผลิตโดยตรรกะ ซึ่งจะเชื่อมโยงตัวจัดสรรภาระงานการเข้าถึงของผู้บริโภคกับสถานะการตรวจสอบประสิทธิภาพการทำงานแบบคอมโพสิตของบริการของผู้ผลิต จากนั้นระบบจะเผยแพร่สถานะบริการโดยรวมของบริการผู้ผลิตระดับภูมิภาคไปยังตัวจัดสรรภาระงานของผู้ใช้เพื่อเลือกแบ็กเอนด์ที่เหมาะสม

3. การตั้งค่าโปรเจ็กต์

เข้าถึงโปรเจ็กต์

Codelab นี้เขียนขึ้นเพื่อใช้โปรเจ็กต์ Google Cloud เดียว ขั้นตอนการกำหนดค่าใช้คำสั่ง gcloud และคำสั่งเชลล์ของ Linux

หมายเหตุ: ในการติดตั้งใช้งานจริง โดยปกติแล้วทรัพยากรผู้ใช้ PSC และบริการของผู้ให้บริการจะอยู่ในโปรเจ็กต์ที่แตกต่างกัน

เริ่มต้นด้วยการเข้าถึงบรรทัดคำสั่งของโปรเจ็กต์ที่อยู่ในระบบคลาวด์ของ Google โดยใช้คำสั่งต่อไปนี้

• Cloud Shell http://shell.cloud.google.com/ หรือ
• เทอร์มินัลในเครื่องที่gcloud CLI ติดตั้งแล้ว

ตั้งค่ารหัสโปรเจ็กต์

gcloud config set project YOUR_PROJECT_ID_HERE

ตั้งค่าตัวแปรสภาพแวดล้อมของ Shell

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

หมายเหตุ: ฟีเจอร์ก่อน GA อาจใช้คำสั่ง gcloud beta หากไม่ได้ติดตั้ง ให้เรียกใช้ gcloud components install beta เพื่อเปิดใช้

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

สร้างคอมโพเนนต์ไฟร์วอลล์

คุณต้องมีกฎไฟร์วอลล์เพื่ออนุญาตการรับส่งข้อมูลไปยังทรัพยากร VM (กฎไฟร์วอลล์เริ่มต้นโดยนัยคือปฏิเสธการรับส่งข้อมูลขาเข้าและอนุญาตการรับส่งข้อมูลขาออก) นโยบายเป็นวิธีที่แนะนำในการทำให้กฎไฟร์วอลล์ใช้งานได้โดยการสร้างทรัพยากรไฟร์วอลล์เครือข่าย สร้างและเพิ่มกฎลงในนโยบาย จากนั้นเชื่อมโยงนโยบายกับเครือข่าย 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 Router และเกตเวย์ 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

สร้างการกำหนดค่าการเริ่มต้น VM ด้วยเซิร์ฟเวอร์ 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

ตัวจัดสรรภาระงานของแอปพลิเคชันผู้ใช้ (อิงตามพร็อกซี) ต้องใช้ซับเน็ตเฉพาะพร็อกซี ซับเน็ตเหล่านี้มีกลุ่มที่อยู่ IP ที่ใช้โดยตัวจัดสรรภาระงานที่อิงตามพร็อกซีเป็นที่อยู่ต้นทางภายในเมื่อส่งการรับส่งข้อมูลไปยังแบ็กเอนด์

# 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)"

ยืนยัน: ตรวจสอบการเชื่อมต่อ PSC ที่ยอมรับ 2 รายการ...
.../regions/REGION_1/networkEndpointGroups/neg-foo ACCEPTED
.../regions/REGION_2/networkEndpointGroups/neg-bar ACCEPTED

# 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

ทดสอบค่าฐานของบริการ

SSH ไปยัง VM ไคลเอ็นต์ในภูมิภาค 1

gcloud compute ssh client-1 --zone=${ZONE_1}

# send request to service using hostname
curl -v www.foobar.com

# send request to load balancer forwarding rule region 1
curl 10.10.1.99

ยืนยัน: ตรวจสอบว่าการตอบกลับมาจากบริการในภูมิภาค 1...
Page served from: service-foo-{UID} in zone projects/{PROJECT_NO}/zones/{REGION_1_ZONE}

# send request to load balancer forwarding rule region 2
curl 10.10.2.99

ยืนยัน: ตรวจสอบว่าการตอบกลับมาจากบริการในภูมิภาค 1...
Page served from: service-bar-{UID} in zone projects/{PROJECT_NO}/zones/{REGION_2_ZONE}

# exit vm ssh
exit

ไม่บังคับ: ลองทำการทดสอบเดียวกันจาก VM ไคลเอ็นต์ในภูมิภาค 2: gcloud compute ssh client-2 --zone=${ZONE_2}

ประเด็นสำคัญ: ลักษณะการทำงานของตัวจัดสรรภาระงานปกติสำหรับคำขอของไคลเอ็นต์ที่เข้ากฎการส่งต่อใน region-x คือการเลือกใช้แบ็กเอนด์ใน region-x เดียวกัน หากทรัพยากรแบ็กเอนด์ทั้งหมดมีประสิทธิภาพดี ภูมิภาคที่มีเวลาในการตอบสนองต่ำที่สุดจะเป็นผู้ชนะ แบ็กเอนด์ส่วนกลางจะเฟลโอเวอร์ไปยังภูมิภาคอื่นที่มีสัญญาณสถานะที่เหมาะสม

แต่เนื่องจากทรัพยากรบริการของผู้ผลิตจริงอยู่เบื้องหลังตัวจัดสรรภาระงานของผู้ผลิตในเครือข่าย VPC ของผู้ผลิต สัญญาณสถานะเหล่านี้จึงไม่ชัดเจนสำหรับตัวจัดสรรภาระงานของผู้บริโภคก่อนหน้านี้ และด้วยเหตุนี้ฝั่งผู้บริโภคจึงไม่สามารถกำหนดการเฟลโอเวอร์ของแบ็กเอนด์ดังกล่าวได้ ซึ่ง PSC health จะแก้ปัญหานี้ด้วยการเผยแพร่ข้อมูลสถานะบริการจากฝั่งผู้ผลิตไปยังฝั่งผู้บริโภค

6. แหล่งข้อมูลด้านสุขภาพ

ผู้ผลิตจะกำหนดค่าทรัพยากรด้านสถานะของ PSC เพื่อแสดงสถานะโดยรวมของบริการระดับภูมิภาค นโยบายด้านสุขภาพอิงตามสิ่งที่ผู้ผลิตบริการกำหนดว่าเหมาะสมในการรักษาระดับการให้บริการที่ใช้งานได้ ระบบจะตั้งค่าเกณฑ์เพื่อแจ้งให้ผู้บริโภคทำการเฟลโอเวอร์เมื่อไม่เป็นไปตามเงื่อนไขที่ผู้ผลิตกำหนดอีกต่อไป

ตั้งค่าสถานะบริการ foo ในภูมิภาค 1

สร้างนโยบายการรวบรวมข้อมูลสถานะ

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

หมายเหตุ: เงื่อนไขใช้ค่าเริ่มต้น: --healthy-percent-threshold=60 และ --min-healthy-threshold=1

สร้างแหล่งข้อมูลด้านสุขภาพ

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

หมายเหตุ: แหล่งข้อมูลด้านสุขภาพกำหนดโดยทรัพยากรบริการแบ็กเอนด์และเงื่อนไขนโยบายการรวบรวมข้อมูลด้านสุขภาพ

สร้างการตรวจสอบประสิทธิภาพการทำงานแบบรวม

gcloud beta 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 beta compute health-aggregation-policies list --regions=${REGION_1}

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

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

ตั้งค่าสถานะบริการ bar ในภูมิภาค 2

สร้างนโยบายการรวบรวมข้อมูลสถานะ

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

สร้างแหล่งข้อมูลด้านสุขภาพ

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

สร้างการตรวจสอบประสิทธิภาพการทำงานแบบรวม

gcloud beta 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 beta compute health-aggregation-policies list --regions=${REGION_2}

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

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

ส่วนการกำหนดค่าก็จบลงเพียงเท่านี้... ต่อไปเป็นการทดสอบ

7. การทดสอบเฟลโอเวอร์

สถานการณ์ที่บริการ foo ภูมิภาค 1 มีประสิทธิภาพไม่ดี

สถานการณ์นี้จำลองความล้มเหลวของบริการผู้ผลิต PSC foo ในภูมิภาค 1 โดยการหยุดเว็บเซิร์ฟเวอร์ในอินสแตนซ์ VM 1 ใน 2 รายการ

ดูรายละเอียด 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}

SSH ไปยัง VM ของเซิร์ฟเวอร์และหยุดเซิร์ฟเวอร์ http

gcloud compute ssh ${FOO_FAIL_NAME} --zone=${FOO_FAIL_ZONE}

# stop apache http server to fail service
sudo systemctl stop apache2

# verify service dead
sudo systemctl status apache2 | grep Active:

# exit vm ssh
exit

ยืนยันว่าบริการระดับภูมิภาคมีประสิทธิภาพไม่ดี

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

healthState: UNHEALTHY

เอาต์พุตควรมีลักษณะคล้ายกับตัวอย่างต่อไปนี้...

backend: .../regions/<REGION_1>/instanceGroups/mig-foo
status:
  healthStatus:
  -   forwardingRule: .../regions/<REGION_1>/forwardingRules/fr-foo
    forwardingRuleIp: 172.16.1.99
    healthState: UNHEALTHY
    instance: .../zones/<ZONE_1x>/instances/<FOO_FAIL_NAME>
    ipAddress: <FOO_FAIL_IP>
    port: 80
  -   forwardingRule: .../regions/<REGION_1>/forwardingRules/fr-foo
    forwardingRuleIp: 172.16.1.99
    healthState: HEALTHY
    instance: .../zones/<ZONE_1y>/instances/<FOO_OTHER_NAME>
    ipAddress: <FOO_OTHER_IP>
    port: 80
  kind: compute#backendServiceGroupHealth

SSH ไปยัง VM ไคลเอ็นต์ในภูมิภาค 1 และทดสอบเฟลโอเวอร์

gcloud compute ssh client-1 --zone=${ZONE_1}

# send request to service using hostname
curl -v www.foobar.com

# curl to ilb vip in region 1
curl 10.10.1.99

# curl to ilb vip in region 2
curl 10.10.2.99

ยืนยัน: ตรวจสอบว่าการตอบกลับมาจากบริการในภูมิภาค 2...
Page served from: service-bar-{UID} in zone projects/{PROJECT_NO}/zones/{REGION_2_ZONE}

ความสมบูรณ์ของ PSC ได้อัปเดตตัวจัดสรรภาระงานของผู้บริโภคและสั่งให้หลีกเลี่ยงบริการแบ็กเอนด์ที่ไม่สมบูรณ์ในภูมิภาค 1 แต่ได้เปลี่ยนเส้นทางการรับส่งข้อมูลไปยังบริการที่มีประสิทธิภาพดี bar ในภูมิภาค 2 แทน

# exit client vm ssh
exit

SSH ไปยัง VM ของเซิร์ฟเวอร์และรีสตาร์ทเซิร์ฟเวอร์ http

# ssh to foo service vm
gcloud compute ssh ${FOO_FAIL_NAME} --zone=${FOO_FAIL_ZONE}

# start apache http server to return service to healthy
sudo systemctl start apache2

# verify service running
sudo systemctl status apache2 | grep Active:

# exit vm ssh
exit

เปลี่ยนนโยบายด้านสุขภาพ

ผู้ผลิตสามารถปรับนโยบายด้านสถานะบริการตามเกณฑ์ต่างๆ ได้ แหล่งข้อมูลนโยบายการรวบรวมข้อมูลด้านสุขภาพจะระบุเกณฑ์ขั้นต่ำที่จำเป็นต่อการรักษาสถานะปกติในแหล่งข้อมูลด้านสุขภาพ (บริการแบ็กเอนด์) ทั้งหมด

หมายเหตุ: การเปลี่ยนแปลงนี้แสดงให้เห็นถึงการเรียกใช้เงื่อนไขที่แตกต่างกันในนโยบายการรวบรวมข้อมูลด้านสุขภาพโดยใช้ --min-healthy-threshold

อัปเดตbarนโยบายการรวบรวมข้อมูลสถานะบริการ

gcloud beta 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 beta compute health-aggregation-policies list --regions=${REGION_2}

การเปลี่ยนแปลงนโยบายด้านสุขภาพของผู้ผลิตนี้มีผลดังนี้

1. ลดเปอร์เซ็นต์เกณฑ์ขั้นต่ำที่มีประสิทธิภาพจาก 60% เป็น 40% – ตอนนี้ความล้มเหลวของอินสแตนซ์ VM เพียงรายการเดียวจะไม่ทริกเกอร์สถานะไม่มีประสิทธิภาพตาม --healthy-percent-threshold (สถานะความล้มเหลวจะเป็น 50% และต้องมีเพียง 40% เท่านั้นจึงจะมีประสิทธิภาพ)
2. เพิ่มจำนวนแบ็กเอนด์ที่มีประสิทธิภาพขั้นต่ำจาก 1 เป็น 2 อินสแตนซ์ VM - ตอนนี้ความล้มเหลวของอินสแตนซ์ VM เดียวจะทําให้เกิดสถานะไม่มีประสิทธิภาพตาม --min-healthy-threshold (สถานะความล้มเหลวจะเป็น 1 แต่ต้องมี 2 รายการจึงจะมีประสิทธิภาพ)

สถานการณ์ที่บริการ bar ภูมิภาค 2 มีประสิทธิภาพไม่ดี

สถานการณ์นี้จำลองความล้มเหลวของบริการผู้ผลิต PSC bar ในภูมิภาค 2 โดยการหยุดเว็บเซิร์ฟเวอร์ในอินสแตนซ์ VM 1 ใน 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}

SSH ไปยัง VM ของเซิร์ฟเวอร์และหยุดเซิร์ฟเวอร์ http

gcloud compute ssh ${BAR_FAIL_NAME} --zone=${BAR_FAIL_ZONE}

# stop apache http server to fail service
sudo systemctl stop apache2

# verify service dead
sudo systemctl status apache2 | grep Active:

# exit vm ssh
exit

ยืนยันว่าบริการระดับภูมิภาคมีประสิทธิภาพไม่ดี

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

healthState: UNHEALTHY

เอาต์พุตควรมีลักษณะคล้ายกับตัวอย่างต่อไปนี้...

backend: .../regions/<REGION_2>/instanceGroups/mig-bar
status:
  healthStatus:
  -   forwardingRule: .../regions/<REGION_2>/forwardingRules/fr-bar
    forwardingRuleIp: 172.16.2.99
    healthState: UNHEALTHY
    instance: .../zones/<ZONE_2x>/instances/<BAR_FAIL_NAME>
    ipAddress: <BAR_FAIL_IP>
    port: 80
  -   forwardingRule: .../regions/<REGION_2>/forwardingRules/fr-bar
    forwardingRuleIp: 172.16.2.99
    healthState: HEALTHY
    instance: .../zones/<ZONE_2y>/instances/<BAR_OTHER_NAME>
    ipAddress: <BAR_OTHER_IP>
    port: 80
  kind: compute#backendServiceGroupHealth

SSH ไปยัง VM ไคลเอ็นต์ในภูมิภาค 2 และทดสอบเฟลโอเวอร์

gcloud compute ssh client-2 --zone=${ZONE_2}

# send request to service using hostname
curl -v www.foobar.com

# curl to ilb vip in region 1
curl 10.10.1.99

# curl to ilb vip in region 2
curl 10.10.2.99

ยืนยัน: ตรวจสอบว่าการตอบกลับมาจากบริการในภูมิภาค 1...
Page served from: service-foo-{UID} in zone projects/{PROJECT_NO}/zones/{REGION_1_ZONE}

PSC Health ได้อัปเดตตัวจัดสรรภาระงานของผู้บริโภคและสั่งให้หลีกเลี่ยงบริการแบ็กเอนด์ที่ไม่สมบูรณ์ในภูมิภาค 2 แต่ได้เปลี่ยนเส้นทางการรับส่งข้อมูลไปยังบริการที่มีประสิทธิภาพดีfooในภูมิภาค 1 แทน

ในกรณีที่ตัวจัดสรรภาระงานของผู้บริโภคเห็นว่าบริการของผู้ผลิตทั้งหมดไม่สมบูรณ์ ตัวจัดสรรภาระงานจะเฟลโอเวอร์ไปยังอินสแตนซ์ที่สมบูรณ์ไม่ได้ ลักษณะการทำงานที่คาดไว้คือตัวจัดสรรภาระงานจะกระจายการรับส่งข้อมูลไปยังแบ็กเอนด์ที่ไม่สมบูรณ์ทั้งหมด (เปิดล้มเหลว)

# exit client vm ssh
exit

ส่วนการทดสอบก็มีเพียงเท่านี้... มาถึงส่วนการทำความสะอาดข้อมูลกัน

8. ล้างข้อมูล

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

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

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

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

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

gcloud -q beta 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
#

9. บทสรุป

ยินดีด้วย คุณกำหนดค่าสถานะของ PSC และทดสอบการทำงานล้มเหลวระดับภูมิภาคอัตโนมัติเรียบร้อยแล้ว

โปรดแสดงความคิดเห็น ถามคำถาม หรือแก้ไขข้อมูลโดยใช้แบบฟอร์มความคิดเห็นนี้

ขอขอบคุณ