Integridade do Private Service Connect

1. Introdução

Este codelab aborda a integridade do Private Service Connect (PSC) para failover regional automático. A integridade do PSC é um recurso de rede que oferece melhor resiliência e disponibilidade do serviço.

A integridade do PSC permite que os produtores de serviços definam políticas de integridade personalizadas (qual estado define um serviço íntegro ou não íntegro) e propaguem automaticamente esses indicadores para os consumidores de serviços que se conectam ao serviço com backends do PSC. Esse recurso foi criado especificamente para oferecer suporte ao failover automático entre regiões. Se um serviço regional do produtor ficar indisponível, o balanceador de carga do consumidor vai parar automaticamente de rotear o tráfego para essa região e o direcionará para um serviço disponível em outra região.

Em comparação com métodos anteriores de failover entre regiões, como a detecção de outliers, a integridade do PSC oferece um sinal de failover mais preciso porque se baseia diretamente na integridade agregada dos back-ends de serviço do produtor (grupos de instâncias de VM ou endpoints de rede). Os produtores podem definir a própria lógica de integridade, garantindo que o produtor só receba tráfego quando o serviço realmente atender aos critérios de integridade necessários.

Conteúdo do laboratório

• Componentes da integridade do PSC e como eles funcionam juntos para determinar o estado de integridade de um serviço de produtor
• Implementar a integridade do PSC para um serviço de produtor usando comandos gcloud
• Configuração de um balanceador de carga de acesso do consumidor do PSC entre regiões para usar os indicadores de integridade da política de integridade do produtor do PSC
• Testar cenários de falha de serviço e validar o failover automático entre regiões

O que é necessário

• um projeto do Google Cloud;
• Permissões do IAM concedidas ao papel predefinido roles/compute.admin ou a um papel básico amplo, como roles/admin ou roles/owner legado
• Familiaridade com os conceitos de rede do Google Cloud e o uso da CLI do Google Cloud

2. Conceitos

Rede do PSC

A topologia de rede deste codelab inclui uma rede VPC de consumidor e produtor em duas regiões ativas do Google Cloud.

O lado do consumidor tem sub-redes regionais com instâncias de VM cliente usadas para acessar o serviço do produtor por um balanceador de carga de aplicativo interno entre regiões com back-ends de grupo de endpoints de rede (NEG) do PSC. Há duas regras de encaminhamento de balanceador de carga regional, com endereços IP regionais, para entrada de cliente global (entre regiões). O serviço de back-end é um recurso global que oferece suporte a NEGs em diferentes regiões. Em um cenário de failover, um cliente que se conecta a qualquer regra de encaminhamento de front-end regional pode ser direcionado a um back-end global íntegro.

Fig. 1. Topologia de rede do codelab

O lado do produtor tem sub-redes regionais com balanceadores de carga de rede de passagem interna regionais que expõem um serviço por um recurso de anexo de serviço PSC regional. Os serviços de back-end contêm grupos de instâncias gerenciadas (MIGs) regionais e são verificados quanto à integridade sondando solicitações http e validando respostas 200 (OK).

Consulte a documentação mais recente sobre a compatibilidade do Private Service Connect para configuração do produtor e saiba quais balanceadores de carga oferecem suporte à integridade do PSC.

Integridade do serviço

A verificação de integridade do serviço de back-end do produtor, configurada durante a criação do balanceador de carga, serve como o sinal de origem para o recurso integridade do PSC. O recurso fonte de integridade usa esse indicador e outras restrições definidas no recurso política de agregação de integridade para determinar um estado de integridade para um único serviço de back-end.

Por padrão, um serviço é considerado íntegro quando estas duas restrições são atendidas:

• mínimo de x por cento dos back-ends estão íntegros (padrão 60)
• mínimo de y back-ends íntegros (padrão 1)

A verificação de integridade composta faz referência a todas as fontes de integridade de todos os serviços de back-end para determinar a integridade geral de todo o serviço regional do produtor. Neste laboratório, cada serviço de produtor regional tem apenas uma fonte de integridade de serviço de back-end que se acumula em uma verificação de integridade composta.

Fig 2. Modelo de recurso de integridade do PSC

A definição de recurso de verificação de integridade combinada também se refere à regra de encaminhamento do balanceador de carga do serviço do produtor. O NEG do PSC de back-end do balanceador de carga de acesso do consumidor está conectado logicamente ao anexo de serviço do PSC do produtor e à regra de encaminhamento do balanceador de carga do produtor. Isso vincula o balanceador de carga de acesso do consumidor ao estado da verificação de integridade composta do serviço do produtor. A integridade geral do serviço do produtor regional é propagada para o balanceador de carga do consumidor para fazer a seleção de back-end adequada.

3. Configurar o projeto

Acessar seu projeto

Este codelab foi escrito para usar um único projeto do Google Cloud. As etapas de configuração usam comandos do shell gcloud e do Linux.

OBSERVAÇÃO:em uma implantação de produção, os recursos do consumidor do PSC e os serviços do produtor geralmente estão em projetos diferentes.

Comece acessando a linha de comando do projeto na nuvem do Google Cloud usando:

• Cloud Shell http://shell.cloud.google.com/ ou
• Um terminal local com a CLI gcloud instalada

Definir o ID do projeto

gcloud config set project YOUR_PROJECT_ID_HERE

Definir variáveis de ambiente shell

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

Ativar serviços de API

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

OBSERVAÇÃO:os recursos pré-GA podem usar comandos gcloud beta. Se não estiver instalado, execute gcloud components install beta para ativar.

4. Serviço de produtor

Criar recursos compartilhados

Criar rede

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

Criar sub-redes

# 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

Criar componentes de firewall

As regras de firewall são necessárias para permitir o tráfego para recursos de VM. As regras de firewall padrão implícitas são para negar entrada e permitir saída. As políticas são a maneira preferida de implantar regras de firewall. Para isso, crie um recurso de política de firewall de rede, crie e adicione regras a ela e associe a política a uma rede 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

Criar Cloud Routers e gateways 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

Criar uma configuração de inicialização de VM com servidor 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

Configurar o serviço foo na região 1

Criar computação de serviço

# 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

Criar componentes do balanceador de carga de serviço

# 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

Publicar serviço do 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

Configurar o serviço bar na região 2

Criar computação de serviço

# 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

Criar componentes do balanceador de carga de serviço

# 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

Publicar serviço do 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. Acesso do consumidor

Configurar recursos do cliente

Criar componentes de rede

# 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

O balanceador de carga de aplicativo (baseado em proxy) do consumidor exige sub-redes somente proxy. Essas sub-redes fornecem um pool de endereços IP usados por balanceadores de carga baseados em proxy como endereços de origem internos ao enviar tráfego para back-ends.

# 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

Criar componentes de firewall

# 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

Criar componentes do balanceador de carga

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

VERIFIQUE:confira se há duas conexões de PSC aceitas...
.../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

Criar registros 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"

Criar recursos de computação

# 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

Valor de referência do serviço de teste

SSH para a VM cliente na região 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

VERIFIQUE:confira se a resposta vem do serviço na região 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

VERIFIQUE:confira se a resposta vem do serviço na região 1...
Page served from: service-bar-{UID} in zone projects/{PROJECT_NO}/zones/{REGION_2_ZONE}

# exit vm ssh
exit

Opcional:tente os mesmos testes na VM de cliente na região 2: gcloud compute ssh client-2 --zone=${ZONE_2}

PONTO PRINCIPAL:o comportamento normal do balanceador de carga para solicitações de clientes que entram em uma regra de encaminhamento em region-x é preferir back-ends no mesmo region-x. Se todos os recursos de back-end estiverem íntegros, a região com menor latência será escolhida. Os back-ends globais vão fazer failover para a outra região com o sinal de integridade adequado.

No entanto, como os recursos reais do serviço produtor estão atrás do balanceador de carga produtor na rede VPC produtor, esses indicadores de integridade eram opacos para o balanceador de carga consumidor. Portanto, o lado consumidor não conseguia fazer essas determinações de failover de back-end. O status de integridade do PSC resolve isso propagando informações de integridade do serviço do lado do produtor para o lado do consumidor.

6. Recursos de saúde

Os recursos de integridade do PSC são configurados pelo produtor para representar a integridade geral do serviço regional. A política de integridade se baseia no que o produtor do serviço define como adequado para manter um nível de serviço funcional. Os limites são definidos para notificar os consumidores sobre o failover quando as condições definidas pelo produtor não são mais atendidas.

Configurar a integridade do serviço foo na região 1

Criar uma política de agregação de integridade

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

OBSERVAÇÃO:as condições estão usando os valores padrão: --healthy-percent-threshold=60 e --min-healthy-threshold=1

Criar uma fonte de integridade

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

OBSERVAÇÃO:a origem de integridade é definida pelo recurso de serviço de back-end e pelas condições da política de agregação de integridade.

Criar uma verificação de integridade composta

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

OBSERVAÇÃO:a verificação de integridade composta faz referência às origens de integridade e define o destino de integridade. A vinculação de integridade de ponta a ponta entre o serviço do produtor e o acesso do consumidor está concluída.

Verificar a integridade da configuração do serviço foo

As configurações de recursos de integridade podem ser visualizadas com comandos de lista (e describe) por região.

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

Configurar a integridade do serviço bar na região 2

Criar uma política de agregação de integridade

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

Criar uma fonte de integridade

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

Criar uma verificação de integridade composta

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

Verificar a integridade da configuração do serviço 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}

Isso conclui a parte de configuração. Agora vamos para o teste.

7. Teste de failover

Cenário de serviço foo região 1 não íntegro

Este cenário simula uma falha do serviço de produtor do PSC foo na região 1 interrompendo o servidor da Web em uma das duas instâncias de VM.

Receber detalhes da VM do servidor

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

Conecte-se por SSH à VM do servidor e interrompa o servidor 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

Verificar se o serviço regional não está íntegro

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

healthState: UNHEALTHY

A saída será semelhante a esta:

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

Conecte-se por SSH à VM cliente da região 1 e teste o 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

VERIFICAR:confira se a resposta vem do serviço na região 2...
Page served from: service-bar-{UID} in zone projects/{PROJECT_NO}/zones/{REGION_2_ZONE}

A integridade do PSC atualizou o balanceador de carga do consumidor e o direcionou para evitar o serviço de back-end não íntegro na região 1. Em vez disso, ele direcionou o tráfego para o serviço íntegro bar na região 2.

# exit client vm ssh
exit

Conecte-se por SSH à VM do servidor e reinicie o servidor 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

Mudar política de integridade

Os produtores podem ajustar as políticas de integridade do serviço com base em diferentes critérios. O recurso política de agregação de integridade especifica os limites mínimos necessários para manter um status de integridade em todas as origens de integridade (serviços de back-end).

OBSERVAÇÃO:essa mudança demonstra a invocação de uma condição diferente na política de agregação de integridade usando --min-healthy-threshold.

Atualizar a política de agregação de integridade do serviço 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}

Essa mudança na política de integridade do produtor faz o seguinte:

1. Diminui a porcentagem mínima de integridade de 60% para 40%. Agora, uma única falha de instância de VM não vai acionar um estado não íntegro com base em --healthy-percent-threshold. O estado de falha será de 50% e só precisará de 40% para ser considerado íntegro.
2. Aumenta o número mínimo de back-ends íntegros de 1 para 2 instâncias de VM. Agora, uma única falha de instância de VM vai acionar um estado não íntegro com base em --min-healthy-threshold (o estado de falha será 1, mas é necessário 2 para ser íntegro).

Cenário de serviço bar região 2 não íntegro

Este cenário simula uma falha do serviço produtor do PSC bar na região 2 interrompendo o servidor da Web em uma das duas instâncias de VM.

Receber detalhes da VM do servidor

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

Conecte-se por SSH à VM do servidor e interrompa o servidor 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

Verificar se o serviço regional não está íntegro

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

healthState: UNHEALTHY

A saída será semelhante a esta:

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

Conecte-se por SSH à VM cliente da região 2 e teste o 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

VERIFIQUE:confira se a resposta vem do serviço na região 1...
Page served from: service-foo-{UID} in zone projects/{PROJECT_NO}/zones/{REGION_1_ZONE}

A integridade do PSC atualizou o balanceador de carga do consumidor e o direcionou para evitar o serviço de back-end não íntegro na região 2. Em vez disso, ele direcionou o tráfego para o serviço íntegro foo na região 1.

Em uma situação em que o balanceador de carga do consumidor considera todos os serviços do produtor como não íntegros, ele não pode fazer failover para uma instância íntegra. O comportamento esperado é que o balanceador de carga distribua o tráfego entre todos os back-ends não íntegros (abertura por falha).

# exit client vm ssh
exit

Isso conclui a parte de teste... vamos para a revisão dos dados.

8. Limpeza

# 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. Conclusão

Parabéns! Você configurou a integridade do PSC e testou o failover regional automático.

Envie comentários, dúvidas ou correções usando este formulário de feedback.

Agradecemos pela atenção!