خدمات خصوصی سلامت را متصل کنید

۱. مقدمه

این Codelab به بررسی سلامت Private Service Connect (PSC) برای failover خودکار منطقه‌ای می‌پردازد. سلامت PSC یک ویژگی شبکه‌ای است که انعطاف‌پذیری و در دسترس بودن خدمات را بهبود می‌بخشد.

سلامت PSC به تولیدکنندگان سرویس اجازه می‌دهد تا سیاست‌های سلامت سفارشی (آنچه که یک سرویس سالم یا ناسالم را تعریف می‌کند) را تعریف کنند و به طور خودکار این سیگنال‌ها را به مصرف‌کنندگان سرویس که با backendهای PSC به سرویس متصل می‌شوند، منتشر کنند. این ویژگی به طور خاص برای پشتیبانی از failover خودکار بین منطقه‌ای طراحی شده است. اگر یک سرویس تولیدکننده منطقه‌ای ناسالم شود، متعادل‌کننده بار مصرف‌کننده به طور خودکار مسیریابی ترافیک به آن منطقه را متوقف کرده و ترافیک را به یک سرویس سالم در منطقه دیگری هدایت می‌کند.

در مقایسه با روش‌های قبلی برای failover بین منطقه‌ای، مانند تشخیص داده‌های پرت ، سلامت PSC سیگنال failover دقیق‌تری ارائه می‌دهد زیرا مستقیماً بر اساس سلامت تجمیعی backendهای سرویس تولیدکننده (گروه‌های نمونه ماشین مجازی یا نقاط انتهایی شبکه) است. تولیدکنندگان می‌توانند منطق سلامت خود را تعریف کنند و اطمینان حاصل کنند که تولیدکننده فقط زمانی ترافیک دریافت می‌کند که سرویس واقعاً معیارهای سلامت لازم را برآورده کند.

آنچه یاد می‌گیرید

  • اجزای سلامت PSC و نحوه همکاری آنها برای تعیین وضعیت سلامت یک سرویس تولیدکننده
  • پیاده‌سازی سلامت PSC برای یک سرویس تولیدکننده با استفاده از دستورات gcloud
  • پیکربندی یک متعادل‌کننده بار دسترسی مصرف‌کننده PSC بین منطقه‌ای برای استفاده از سیگنال‌های سلامت از سیاست سلامت PSC تولیدکننده
  • آزمایش سناریوهای خرابی سرویس و اعتبارسنجی failover خودکار بین منطقه‌ای

آنچه شما نیاز دارید

  • یک پروژه ابری گوگل
  • مجوزهای IAM اعطا شده به نقش از پیش تعریف شده roles/compute.admin یا یک نقش اساسی گسترده مانند roles/admin یا roles/owner
  • آشنایی با مفاهیم شبکه Google Cloud و استفاده از رابط خط فرمان Google Cloud

۲. مفاهیم

شبکه PSC

این توپولوژی شبکه Codelab شامل یک شبکه VPC مصرف‌کننده و تولیدکننده در دو منطقه فعال Google Cloud است.

سمت مصرف‌کننده دارای زیرشبکه‌های منطقه‌ای با نمونه‌های ماشین مجازی کلاینت است که برای دسترسی به سرویس تولیدکننده از طریق یک متعادل‌کننده بار برنامه داخلی فرامنطقه‌ای با گروه‌های انتهایی شبکه PSC (NEG) در بک‌اندها استفاده می‌شوند. دو قانون ارسال متعادل‌کننده بار منطقه‌ای، با آدرس‌های IP منطقه‌ای، برای ورود کلاینت جهانی (فرامنطقه‌ای) وجود دارد. سرویس بک‌اند یک منبع جهانی است که از NEGها در مناطق مختلف پشتیبانی می‌کند. در یک سناریوی failover، کلاینتی که به هر یک از قوانین ارسال فرانت‌اند منطقه‌ای متصل می‌شود، می‌تواند به یک بک‌اند جهانی سالم هدایت شود.

شکل ۱

شکل 1. توپولوژی شبکه Codelab

طرف تولیدکننده دارای زیرشبکه‌های منطقه‌ای با متعادل‌کننده‌های بار شبکه داخلی منطقه‌ای است که یک سرویس را از طریق منبع پیوست سرویس PSC منطقه‌ای در معرض نمایش قرار می‌دهد. سرویس‌های backend شامل گروه‌های نمونه مدیریت‌شده (MIG) منطقه‌ای هستند و با بررسی درخواست‌های http و اعتبارسنجی پاسخ‌های 200 (OK) سلامت آنها بررسی می‌شود.

برای مشاهده‌ی اینکه کدام متعادل‌کننده‌های بار از سلامت PSC پشتیبانی می‌کنند، به آخرین مستندات مربوط به سازگاری Private Service Connect برای پیکربندی Producer مراجعه کنید.

سلامت خدمات

بررسی سلامت سرویس backend تولیدکننده، که در طول ایجاد متعادل‌کننده بار پیکربندی شده است، به عنوان سیگنال اولیه برای ویژگی سلامت PSC عمل می‌کند. منبع منبع سلامت از آن سیگنال به همراه محدودیت‌های اضافی تعریف شده در منبع سیاست تجمیع سلامت برای تعیین وضعیت سلامت برای یک سرویس backend واحد استفاده می‌کند.

به طور پیش‌فرض، یک سرویس زمانی سالم در نظر گرفته می‌شود که هر دو محدودیت زیر برآورده شوند:

  • حداقل x درصد از backend ها سالم هستند (پیش فرض 60 )
  • حداقل تعداد y از backend ها سالم هستند (پیش فرض 1 )

بررسی سلامت ترکیبی، به تمام منابع سلامت برای تمام سرویس‌های backend ارجاع می‌دهد تا سلامت کلی کل سرویس تولیدکننده منطقه‌ای را تعیین کند. در مورد این آزمایش، هر سرویس تولیدکننده منطقه‌ای تنها یک منبع سلامت سرویس backend دارد که به یک بررسی سلامت ترکیبی منتهی می‌شود.

شکل ۲

شکل 2. مدل منابع سلامت PSC

تعریف منبع بررسی سلامت ترکیبی همچنین به قانون ارسال متعادل‌کننده بار سرویس تولیدکننده اشاره دارد. PSC NEG مربوط به backend متعادل‌کننده بار دسترسی مصرف‌کننده به طور منطقی به پیوست سرویس PSC تولیدکننده و قانون ارسال متعادل‌کننده بار تولیدکننده متصل است. این امر متعادل‌کننده بار دسترسی مصرف‌کننده را به وضعیت بررسی سلامت ترکیبی سرویس تولیدکننده مرتبط می‌کند. سپس سلامت کلی سرویس برای سرویس تولیدکننده منطقه‌ای به متعادل‌کننده بار مصرف‌کننده منتشر می‌شود تا انتخاب backend مناسب انجام شود.

۳. راه‌اندازی پروژه

به پروژه خود دسترسی پیدا کنید

این Codelab برای استفاده از یک پروژه Google Cloud واحد نوشته شده است. مراحل پیکربندی از دستورات gcloud و shell لینوکس استفاده می‌کنند.

نکته: در یک استقرار عملیاتی، منابع مصرف‌کننده PSC و خدمات تولیدکننده معمولاً در پروژه‌های مختلفی قرار دارند.

با دسترسی به خط فرمان پروژه Google Cloud خود، با استفاده از موارد زیر شروع کنید:

شناسه پروژه خود را تنظیم کنید

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

۴. خدمات تولیدکننده

ایجاد منابع مشترک

ایجاد شبکه

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

ایجاد روترهای ابری و دروازه‌های 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 در منطقه ۱

ایجاد سرویس محاسباتی

# 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 در منطقه ۲

ایجاد سرویس محاسباتی

# 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

۵. دسترسی مصرف‌کننده

منابع کلاینت را تنظیم کنید

ایجاد اجزای شبکه

# 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 را فراهم می‌کنند که توسط متعادل‌کننده‌های بار مبتنی بر پروکسی به عنوان آدرس‌های منبع داخلی هنگام ارسال ترافیک به backendها استفاده می‌شوند.

# 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

خط پایه سرویس تست

SSH به ماشین مجازی کلاینت در ناحیه ۱

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
# send request to load balancer forwarding rule region 2
curl 10.10.2.99
# exit vm ssh
exit

اختیاری: همین تست‌ها را از ماشین مجازی کلاینت در ناحیه ۲ امتحان کنید: gcloud compute ssh client-2 --zone=${ZONE_2}

نکته کلیدی: رفتار عادی متعادل‌کننده بار برای درخواست‌های کلاینت که وارد یک قانون ارسال در region-x می‌شوند، ترجیح دادن backendها در همان region-x است. اگر همه منابع backend سالم باشند، منطقه‌ای که کمترین تأخیر را دارد برنده می‌شود. backendهای سراسری با سیگنال سلامت مناسب به منطقه دیگری failover می‌شوند.

اما از آنجا که منابع سرویس تولیدکننده واقعی در شبکه VPC تولیدکننده ، پشت متعادل‌کننده بار تولیدکننده قرار دارند، این سیگنال‌های سلامت قبلاً برای متعادل‌کننده بار مصرف‌کننده مبهم بودند - و بنابراین طرف مصرف‌کننده قادر به انجام چنین تعیین‌های مربوط به failover در backend نبود. سلامت PSC با انتشار اطلاعات سلامت سرویس از طرف تولیدکننده به طرف مصرف‌کننده ، این مشکل را برطرف می‌کند.

۶. منابع بهداشتی

منابع PSC Health توسط تولیدکننده پیکربندی می‌شوند تا سلامت کلی سرویس منطقه‌ای را نشان دهند. سیاست سلامت بر اساس آنچه تولیدکننده سرویس برای حفظ سطح سرویس عملکردی مناسب تعریف می‌کند، تعیین می‌شود. آستانه‌ها برای اطلاع‌رسانی به مصرف‌کنندگان جهت Failover در زمانی که شرایط تعریف‌شده توسط تولیدکننده دیگر برآورده نمی‌شوند، تنظیم می‌شوند.

راه‌اندازی خدمات تغذیه foo در منطقه ۱

ایجاد یک سیاست تجمیع سلامت

gcloud beta compute health-aggregation-policies create foo-health-policy \
  --region=${REGION_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 را تأیید کنید

پیکربندی منابع سلامت را می‌توان با دستورات فهرست (و توصیف ) برای هر منطقه مشاهده کرد

# 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 بهداشتی در منطقه ۲

ایجاد یک سیاست تجمیع سلامت

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}

این بخش پیکربندی را به پایان می‌رساند... و به سراغ آزمایش می‌رویم.

۷. تست غلبه بر خرابی

سناریوی ناسالم خدمات foo منطقه ۱

این سناریو با متوقف کردن وب سرور روی یکی از دو نمونه ماشین مجازی، خرابی سرویس تولیدکننده PSC foo در ناحیه ۱ را شبیه‌سازی می‌کند.

دریافت جزئیات ماشین مجازی سرور

# 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 به ماشین مجازی سرور و متوقف کردن سرور 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}

خروجی باید شبیه به این باشد...

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 به ماشین مجازی کلاینت ناحیه ۱ و تست failover

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

بخش سلامت PSC، متعادل‌کننده بار مصرف‌کننده را به‌روزرسانی کرده و آن را طوری تنظیم کرده است که از سرویس backend ناسالم در منطقه ۱ جلوگیری کند. در عوض، ترافیک را به bar سرویس سالم در منطقه ۲ هدایت کرده است.

# exit client vm ssh
exit

اتصال SSH به ماشین مجازی سرور و راه‌اندازی مجدد سرور 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

تغییر سیاست سلامت

تولیدکنندگان می‌توانند سیاست‌های سلامت خدمات را بر اساس معیارهای مختلف تنظیم کنند. منبع سیاست تجمیع سلامت، حداقل آستانه‌های مورد نیاز برای حفظ وضعیت سالم در تمام منابع مختلف سلامت (خدمات بک‌اند) را مشخص می‌کند.

به‌روزرسانی سیاست تجمیع سلامت خدمات 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. حداقل درصد آستانه سالم بودن را از ۶۰٪ به ۴۰٪ کاهش می‌دهد - اکنون یک خرابی در نمونه ماشین مجازی، بر اساس --healthy-percent-threshold وضعیت ناسالم را ایجاد نمی‌کند (وضعیت خرابی ۵۰٪ خواهد بود و فقط به ۴۰٪ برای سالم بودن نیاز است)
  2. حداقل تعداد سالم بودن backendها را از ۱ به ۲ نمونه ماشین مجازی افزایش می‌دهد - اکنون یک خرابی در نمونه ماشین مجازی، بر اساس --min-healthy-threshold وضعیت ناسالم را فعال می‌کند (وضعیت خرابی ۱ خواهد بود، اما برای سالم بودن به ۲ مورد نیاز است)

سناریوی ناسالم منطقه ۲ bar سرویس

این سناریو با متوقف کردن وب سرور روی یکی از دو نمونه ماشین مجازی، خرابی bar سرویس تولیدکننده PSC در ناحیه ۲ را شبیه‌سازی می‌کند.

دریافت جزئیات ماشین مجازی سرور

# 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 به ماشین مجازی سرور و متوقف کردن سرور 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}

خروجی باید شبیه به این باشد...

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 به ماشین مجازی کلاینت ناحیه ۲ و تست failover

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

بخش سلامت PSC، متعادل‌کننده بار مصرف‌کننده را به‌روزرسانی کرده و آن را به گونه‌ای هدایت کرده است که از سرویس بک‌اند ناسالم در منطقه ۲ اجتناب کند. در عوض، ترافیک را به سرویس سالم foo در منطقه ۱ هدایت کرده است.

در شرایطی که متعادل‌کننده بار مصرف‌کننده، تمام سرویس‌های تولیدکننده را ناسالم تشخیص دهد، نمی‌تواند به یک نمونه سالم failover کند . رفتار مورد انتظار برای متعادل‌کننده بار این است که ترافیک را در تمام backendهای ناسالم توزیع کند (fail open).

# exit client vm ssh
exit

این بخش آزمایش را به پایان می‌رساند... و به سراغ پاکسازی می‌رویم.

۸. پاکسازی

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

۹. نتیجه‌گیری

تبریک! شما با موفقیت سلامت PSC را پیکربندی کردید و تست عدم موفقیت منطقه‌ای خودکار را انجام دادید!

با استفاده از این فرم بازخورد، می‌توانید هرگونه نظر، سوال یا اصلاحیه‌ای را ارائه دهید.

متشکرم!