Комплексное медицинское страхование для частных медицинских учреждений

1. Введение

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

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

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

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

• Компоненты комплексного состояния здоровья и то, как они взаимодействуют, определяя состояние здоровья производителя услуг.
• Реализация комплексного мониторинга состояния для PSC в сервисе производителя с использованием команд gcloud.
• Настройка балансировщика нагрузки доступа потребителей 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 , чтобы узнать, какие балансировщики нагрузки поддерживают Composite Health для 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

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

Базовый уровень сервиса тестирования

С клиентской виртуальной машины в регионе 1

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

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

ПРОВЕРКА: Ответ проверки получен от службы в регионе 1...
Page served from: service-foo-{ UID } in zone projects/{ PROJECT_NO }/zones/{ REGION_1_ZONE }

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

ПРОВЕРКА: Ответ проверки получен от службы в регионе 1...
Page served from: service-bar-{ UID } in zone projects/{ PROJECT_NO }/zones/{ REGION_2_ZONE }

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

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

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

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

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

Создать foo санитарно-гигиенического обслуживания в регионе 1.

Разработайте политику агрегирования данных о состоянии здоровья.

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

ПРИМЕЧАНИЕ: Для условий используются значения по умолчанию: --healthy-percent-threshold=60 и --min-healthy-threshold=1

Создайте источник информации о здоровье.

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

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

Создайте комплексную проверку состояния здоровья.

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

ПРИМЕЧАНИЕ: Комплексная проверка состояния здоровья содержит ссылки на источники информации о здоровье и определяет конечный пункт назначения ... и теперь сквозная связь между услугами производителя и доступом потребителя к информации о здоровье завершена!

Проверьте конфигурацию работоспособности сервиса foo .

Настройки медицинских ресурсов можно просмотреть с помощью команд list (и describe ) для каждого региона.

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

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

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

Настройте bar работоспособности сервиса в регионе 2.

Разработайте политику агрегирования данных о состоянии здоровья.

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

Создайте источник информации о здоровье.

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

Создайте комплексную проверку состояния здоровья.

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

Проверьте конфигурацию работоспособности bar обслуживания.

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

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

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

На этом завершается этап настройки... переходим к тестированию.

7. Тестирование отказоустойчивости

Нездоровый сценарий в регионе обслуживания 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}

Остановить http сервер региона 1

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

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

Проверьте, неисправно ли работает региональное электроснабжение.

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

healthState: UNHEALTHY

Результат должен выглядеть примерно так...

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

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

Результат должен выглядеть примерно так...

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

Тестирование резервирования клиента в регионе 1

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

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

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

ПРОВЕРКА: Ответ проверки получен от службы в регионе 2...
Page served from: service-bar-{ UID } in zone projects/{ PROJECT_NO }/zones/{ REGION_2_ZONE }

Система Composite Health for PSC обновила балансировщик нагрузки для потребителей и направила его трафик на обход неработоспособной серверной службы в регионе 1. Вместо этого трафик теперь направляется на работоспособную серверную bar в регионе 2.

Перезапустите http сервер региона 1.

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

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

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

Теперь в выходных данных должно отображаться состояние HEALTHY , аналогичное этому...

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

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

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

ПРИМЕЧАНИЕ: Это изменение демонстрирует возможность применения другого условия в политике агрегирования состояния здоровья с помощью --min-healthy-threshold

Обновить политику сбора данных о состоянии здоровья персонала bar

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

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

Данное изменение политики в области охраны здоровья производителей позволяет достичь следующих результатов:

1. Снижен минимальный пороговый процент работоспособности с 60% до 40% — теперь сбой одного экземпляра виртуальной машины не будет приводить к переходу в неработоспособное состояние на основе --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}

Остановить http сервер региона 2

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

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

Проверьте, неисправно ли работает региональное электроснабжение.

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

healthState: UNHEALTHY

Результат должен выглядеть примерно так...

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

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

Результат должен выглядеть примерно так...

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

Тестирование резервирования клиента в регионе 2

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

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

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

ПРОВЕРКА: Ответ проверки получен от службы в регионе 1...
Page served from: service-foo-{ UID } in zone projects/{ PROJECT_NO }/zones/{ REGION_1_ZONE }

В Composite Health for PSC обновили балансировщик нагрузки для потребителей и направили его трафик на обход проблемного бэкэнд-сервиса в регионе 2. Вместо этого трафик теперь направляется на работоспособный сервис foo в регионе 1.

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

На этом завершается этап тестирования... переходим к мониторингу.

8. Следите за состоянием здоровья.

Изменения состояния здоровья регистрируются по умолчанию. Проекты- производители могут просматривать журналы для источников состояния здоровья и сводных проверок состояния здоровья. Проекты- потребители могут просматривать журналы для PSC NEG, подключенных к опубликованным сервисам с использованием сводной проверки состояния здоровья.

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

Контролируемый ресурс	Вид	Имя журнала
Источники информации о здоровье и комплексные проверки	Мнение производителя	.../logs/compute.googleapis.com%2Fcompositehealth
Частные сервисные соединения NEG	Мнение потребителя	.../logs/compute.googleapis.com%2Fservicehealthchecks

Журналы производителя

В журналах производителя отображается сводная информация о состоянии внутренних служб производителя:

• HealthSource : состояние отдельных серверных служб (например, статус виртуальных машин mig-bar и mig-foo ).
• CompositeHealthCheck : совокупный региональный показатель состояния опубликованной службы, сопоставленный с целевым адресом правила пересылки производителя (например, fr-bar или fr-foo ).

# query logs for producer
gcloud logging read \
  'logName="projects/'${PROJECT_ID}'/logs/compute.googleapis.com%2Fcompositehealth"' \
  --project=${PROJECT_ID} \
  --limit=10 \
  --format='table(
    timestamp.date(format="%I:%M:%S %p", tz=LOCAL):label=TIME,
    resource.type.basename():label=TYPE,
    resource.labels.location:label=REGION,
    jsonPayload.healthState:label=STATE,
    jsonPayload.sources[0].backends[].group.basename().join(","):label=BACKENDS,
    jsonPayload.sources[0].backends[].healthyEndpointCount.join(","):label=HEALTHY,
    jsonPayload.sources[0].backends[].endpointCount.join(","):label=TOTAL,
    jsonPayload.healthDestination.basename():label=DESTINATION
  )'

Журналы потребителей

Журналы активности потребителей показывают распространяемое состояние работоспособности ресурсов потребителей:

• NetworkEndpointGroup : распространяемое состояние работоспособности PSC NEG, подключенного к опубликованной службе (например, neg-bar и neg-foo ).

ПРИМЕЧАНИЕ: Поскольку потребительские NEG находятся в том же проекте и сети VPC, что и ресурсы производителя, дублирующиеся события регистрации потребительских NEG не отображаются (это идентичные переходы состояний на стороне производителя).

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

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

На этом завершается этап мониторинга... переходим к очистке.

9. Уборка

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

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

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

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

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

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

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

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

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

gcloud -q dns managed-zones delete zone-foobar

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

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

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

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

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

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

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

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

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

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

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

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

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

gcloud -q compute networks delete vnet-consumer

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

gcloud -q compute networks delete vnet-producer

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

unset PROJECT_ID REGION_1 ZONE_1 REGION_2 ZONE_2

rm vm-server-startup.sh
#

10. Заключение

Поздравляем! Вы успешно настроили Composite Health для PSC и протестировали автоматическое региональное переключение при сбое!

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

Спасибо!