Private Service Connect здоровье

1. Введение

В этом практическом занятии рассматривается проверка работоспособности Private Service Connect (PSC) для автоматического регионального переключения при сбое. Проверка работоспособности PSC — это сетевая функция, обеспечивающая повышенную отказоустойчивость и доступность сервисов.

Функция PSC Health позволяет производителям услуг определять индивидуальные политики работоспособности (какое состояние определяет работоспособность услуги) и автоматически передавать эти сигналы потребителям услуг, подключающимся к услуге через бэкэнды PSC. Эта функция разработана специально для поддержки автоматического переключения между регионами при сбоях. Если региональная служба-производитель становится неработоспособной, балансировщик нагрузки потребителя автоматически прекращает маршрутизацию трафика в этот регион и перенаправляет трафик на работоспособную службу в другом регионе.

По сравнению с предыдущими методами межрегионального переключения при сбоях, такими как обнаружение выбросов , проверка состояния PSC обеспечивает более точный сигнал переключения при сбоях, поскольку она основана непосредственно на агрегированных данных о состоянии бэкэндов сервисов-производителей (группы экземпляров виртуальных машин или сетевые конечные точки). Производители могут определять собственную логику проверки состояния, гарантируя, что они получают трафик только тогда, когда сервис действительно соответствует необходимым критериям работоспособности.

Чему вы научитесь

• Компоненты состояния здоровья PSC и то, как они взаимодействуют, определяя состояние здоровья поставщика услуг для производителей.
• Реализация проверки работоспособности PSC для сервиса производителя с использованием команд gcloud.
• Настройка балансировщика нагрузки доступа потребителей PSC для межрегионального использования сигналов состояния из политики состояния PSC производителя.
• Тестирование сценариев сбоев в работе сервисов и проверка автоматического переключения между регионами при возникновении проблем.

Что вам нужно

• Проект Google Cloud
• Разрешения IAM, предоставленные предопределенной roles/compute.admin или широкой базовой роли, такой как roles/admin или устаревшей roles/owner
• Знание сетевых концепций Google Cloud и умение пользоваться интерфейсом командной строки Google Cloud.

2. Понятия

Сетевые технологии PSC

Данная сетевая топология Codelab включает в себя потребительскую и производственную VPC-сети в двух активных регионах Google Cloud.

На стороне потребителя используются региональные подсети с экземплярами клиентских виртуальных машин, которые обеспечивают доступ к сервису производителя через внутренний межрегиональный балансировщик нагрузки приложений с бэкэндами групп сетевых конечных точек (NEG) PSC. Для глобального (межрегионального) входящего трафика клиентов действуют два региональных правила переадресации балансировщика нагрузки с региональными IP-адресами. Бэкэнд-сервис является глобальным ресурсом, поддерживающим NEG в разных регионах. В случае отказа клиент, подключающийся к любому из региональных правил переадресации, может быть перенаправлен на работоспособный глобальный бэкэнд.

Рис. 1. Топология сети Codelab.

На стороне производителя используются региональные подсети с региональными внутренними балансировщиками нагрузки, предоставляющими доступ к сервису через региональный ресурс подключения сервиса PSC. Бэкенд-сервисы содержат региональные группы управляемых экземпляров (MIG) и проверяются на работоспособность путем анализа http запросов и подтверждения ответов 200 (OK) .

Обратитесь к последней документации по совместимости Private Service Connect для настройки Producer , чтобы узнать, какие балансировщики нагрузки поддерживают работоспособность PSC.

Служба здравоохранения

Проверка работоспособности серверной службы производителя, настроенная при создании балансировщика нагрузки, служит исходным сигналом для функции проверки работоспособности серверной службы производителя . Ресурс источника проверки работоспособности использует этот сигнал вместе с дополнительными ограничениями, определенными в ресурсе политики агрегации проверки работоспособности, для определения состояния работоспособности отдельной серверной службы.

По умолчанию сервис считается работоспособным, если выполняются оба этих условия:

• Минимум x процентов бэкэндов находятся в рабочем состоянии (по умолчанию 60 ).
• Минимальное количество работоспособных бэкэндов — y (по умолчанию 1 ).

Комплексная проверка состояния системы учитывает все источники информации о состоянии всех внутренних служб для определения общего состояния всей региональной службы производителя. В данном случае каждая региональная служба производителя имеет только один источник информации о состоянии внутренних служб, который суммируется в одну комплексную проверку состояния.

Рис. 2. Модель ресурсов здравоохранения PSC.

Определение ресурса составной проверки работоспособности также ссылается на правило пересылки балансировщика нагрузки сервиса производителя. Бэкэнд балансировщика нагрузки доступа потребителя (PSC NEG) логически связан с подключением сервиса PSC производителя и правилом пересылки балансировщика нагрузки производителя. Это связывает балансировщик нагрузки доступа потребителя с состоянием составной проверки работоспособности сервиса производителя. Общая информация о работоспособности регионального сервиса производителя затем передается балансировщику нагрузки потребителя для выбора соответствующего бэкэнда.

3. Настройка проекта

Получите доступ к своему проекту

Данный практический пример разработан для использования с одним проектом Google Cloud. В шагах по настройке используются команды gcloud и командная строка Linux.

ПРИМЕЧАНИЕ: При развертывании в производственной среде ресурсы для потребителей PSC и сервисы для производителей обычно находятся в разных проектах.

Для начала откройте командную строку вашего проекта Google Cloud, используя:

• Cloud Shell http://shell.cloud.google.com/ , или
• Локальный терминал с установленным интерфейсом командной строки gcloud

Укажите идентификатор вашего проекта.

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 beta . Если они не установлены, выполните gcloud components install beta , чтобы включить их.

4. Услуги производителя

Создание общих ресурсов

Создать сеть

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 в регионе 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...
... /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-подключение к виртуальной машине клиента в регионе 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

Дополнительно: Попробуйте выполнить те же тесты с клиентской виртуальной машины в регионе 2: gcloud compute ssh client-2 --zone=${ZONE_2}

КЛЮЧЕВОЙ МОМЕНТ: Обычно балансировщик нагрузки для клиентских запросов, поступающих по правилу переадресации в region-x отдает предпочтение бэкэндам в том же region-x . Если все ресурсы бэкэндов работоспособны, побеждает регион с наименьшей задержкой. Глобальные бэкэнды переключатся на другой регион при наличии соответствующего сигнала о работоспособности.

Однако, поскольку фактические ресурсы сервиса производителя находятся за балансировщиком нагрузки производителя в сети VPC производителя , эти сигналы о состоянии ранее были непрозрачны для балансировщика нагрузки потребителя , и поэтому сторона потребителя не могла принимать такие решения о переключении на резервный сервер. Функция PSC health решает эту проблему, передавая информацию о состоянии сервиса от стороны производителя к стороне потребителя .

6. Ресурсы здравоохранения

Ресурсы PSC Health настраиваются производителем в соответствии с общим состоянием региональной службы. Политика в отношении состояния службы основана на том, что производитель услуг определяет как приемлемое для поддержания функционирующего уровня обслуживания. Устанавливаются пороговые значения для оповещения потребителей о необходимости переключения на резервный сервер, когда определенные производителем условия перестают выполняться.

Создать 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 producer service foo в регионе 1 путем остановки веб-сервера на одном из двух экземпляров виртуальных машин.

Получить сведения о виртуальной машине сервера

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

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 к виртуальной машине клиента региона 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 Health обновила балансировщик нагрузки для потребителей и направила его таким образом, чтобы он избегал неработоспособной серверной службы в регионе 1. Вместо этого трафик перенаправляется на работоспособную серверную bar в регионе 2.

# 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

Изменить политику в области здравоохранения

Производители могут настраивать политики проверки работоспособности сервисов на основе различных критериев. Ресурс политики агрегации работоспособности определяет минимальные пороговые значения, необходимые для поддержания работоспособного состояния во всех различных источниках данных о работоспособности (бэкэнд-сервисах).

ПРИМЕЧАНИЕ: Это изменение демонстрирует возможность применения другого условия в политике агрегирования состояния здоровья с помощью --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% — теперь сбой одного экземпляра виртуальной машины не будет приводить к переходу в неработоспособное состояние на основе --healthy-percent-threshold (для состояния сбоя потребуется 50%, а для работоспособности достаточно 40%).
2. Увеличивает минимальное количество работоспособных бэкендов с 1 до 2 экземпляров виртуальных машин — теперь отказ одного экземпляра виртуальной машины будет приводить к неработоспособному состоянию на основе --min-healthy-threshold (состояние отказа будет 1, но для работоспособности необходимо 2 экземпляра).

Нездоровая ситуация в bar обслуживания 2.

Этот сценарий имитирует сбой сервиса PSC Producer Service bar в регионе 2 путем остановки веб-сервера на одном из двух экземпляров виртуальных машин.

Получить сведения о виртуальной машине сервера

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

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 к виртуальной машине клиента региона 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 и протестировали автоматическое региональное переключение при сбое!

Пожалуйста, оставляйте свои комментарии, вопросы или замечания, используя эту форму обратной связи .

Спасибо!