Configurar a verificação de integridade ativa para failover regional com PSC

Esta página se aplica à Apigee, mas não à Apigee híbrida.

Confira a documentação da Apigee Edge.

Neste documento, explicamos como configurar a Apigee para definir a verificação de integridade ativa nos casos em que você quer usar o Private Service Connect (PSC) para o roteamento de rede no sentido norte (tráfego de clientes para a Apigee). A verificação de integridade ativa é útil para evitar a perda de tráfego de rede em caso de falha regional.

Informações gerais

Se você quer usar o PSC para o roteamento de rede no sentido norte da Apigee, siga as instruções neste documento para configurar a verificação de integridade ativa. No momento, o PSC não é compatível com o monitoramento ativo da verificação de integridade. A fim de contornar essa limitação do PSC, modifique a configuração de instalação da Apigee para usar um grupo de instâncias gerenciadas (MIG), que fornece o recurso de verificação de integridade ativa.

É possível usar a detecção de outlier para o monitoramento de integridade. No entanto, durante falhas regionais, você pode perder periodicamente uma certa quantidade de tráfego, porque a detecção de outlier usa o tráfego em tempo real como indicador. A detecção de outlier redireciona periodicamente parte do tráfego em tempo real para a verificação da integridade da região com falha.

A Figura 1 mostra a arquitetura proposta. Um endpoint de serviço se conecta ao anexo de serviço na instância da Apigee e um MIG envia o tráfego via proxy para esse endpoint. Ative o monitoramento de verificação de integridade no MIG.

Figura 1. Arquitetura da Apigee para a verificação de integridade ativa sem peering de VPC.

Abordagem de verificação de integridade baseada em MIG

Pré-requisitos

É possível aplicar a técnica descrita neste documento às instalações da Apigee que usam ou não peering de VPC. No entanto, no caso de uma instalação com peering de VPC, a técnica de verificação de integridade ativa descrita aqui só se aplica ao usar o PSC para a configuração de roteamento.

Antes de executar as etapas nesta seção:

• Para instalações sem peering de VPC:
  1. Conclua as etapas de provisionamento da Apigee de 1 a 6 para instalações baseadas em assinatura ou instalações com pagamento por utilização. No momento, a única opção é executar essas etapas usando a interface de linha de comando.
  2. Pule a "Etapa 7: configurar o roteamento" e siga as etapas abaixo.
• Para instalações com peering de VPC que usam o PSC para roteamento:
  1. Conclua as etapas de provisionamento de 1 a 7 da Apigee para instalações baseadas em assinatura ou instalações com pagamento por utilização. No momento, a única opção é executar essas etapas usando a interface de linha de comando.
  2. Pule a "Etapa 8: configurar o roteamento" e siga as etapas abaixo.

1. Configurar um endpoint de serviço do PSC para o anexo de serviço da Apigee

Nesta etapa, você cria um endpoint de serviço do PSC que aponta para o anexo de serviço na instância da Apigee:

1. Consiga o anexo de serviço da instância Apigee criada anteriormente:

   curl -i -X GET -H "Authorization: Bearer $AUTH" \
     "https://apigee.googleapis.com/v1/organizations/$PROJECT_ID/instances"

   No exemplo de saída a seguir, o valor serviceAttachment é mostrado em negrito:

   {
     "instances": [
       {
         "name": "us-west1",
         "location": "us-west1",
         "host": "10.82.192.2",
         "port": "443",
         "createdAt": "1645731488019",
         "lastModifiedAt": "1646504754219",
         "diskEncryptionKeyName": "projects/my-project/locations/us-west1/keyRings/us-west1/cryptoKeys/dek",
         "state": "ACTIVE",
         "peeringCidrRange": "SLASH_22",
         "runtimeVersion": "1-7-0-20220228-190814",
         "ipRange": "10.82.192.0/22,10.82.196.0/28",
         "consumerAcceptList": [
           "875609189304"
         ],
         "serviceAttachment": "projects/bfac74a67a320c43a12p-tp/regions/us-west1/serviceAttachments/apigee-us-west1-crw1"
       }
     ]
   }

   Observação: o ID do projeto que você usou para criar a organização da Apigee sempre aparece na lista consumerAcceptList. No exemplo de saída mostrado acima, ele é o único projeto da lista.
2. Crie um endpoint de serviço do PSC que aponte para o anexo de serviço que você recebeu do corpo de resposta da instância na etapa anterior, conforme explicado em Criar um endpoint do Private Service Connect.

2. Configurar um MIG que aponte para o endpoint de serviço

Nesta etapa, você cria um MIG que envia o tráfego via proxy para o endpoint de serviço. Em seguida, é possível ativar a verificação de integridade ativa no MIG.

Permissões exigidas para a tarefa

É possível conceder ao provisionador da Apigee um papel predefinido que inclua as permissões necessárias para realizar essa tarefa ou conceder permissões mais refinadas a fim de fornecer o privilégio mínimo necessário. Consulte Papéis predefinidos e Permissões de roteamento de acesso.

Observação: os MIGs não são globais, são regionais. Portanto, no caso multirregional, é preciso criar um MIG para cada região e adicioná-los ao serviço de back-end do balanceador de carga global.

2A. Ativar o Acesso privado do Google para uma sub-rede da rede VPC

Para ativar o Acesso privado do Google para uma sub-rede de sua rede VPC, siga as etapas indicadas em Como ativar o Acesso privado do Google.

Observação: se você estiver fazendo uma configuração multirregional, realize essa etapa uma vez para cada região.

2B. Defina as variáveis de ambiente

Multirregião: uma configuração multirregional requer um MIG separado para cada região.

Nas instruções desta seção, usamos variáveis de ambiente para fazer referência às strings usadas várias vezes. Recomendamos que você defina essas variáveis antes de continuar:

MIG_NAME=YOUR_MIG_NAME  # A name you provide for the MIG
VPC_NAME=default       # If you are using a shared VPC, use the shared VPC name
VPC_SUBNET=default     # Private Google Access must be enabled for this subnet
REGION=RUNTIME_REGION        # The same region as your Apigee runtime instance
SERVICE_ENDPOINT_IP=YOUR_SERVICE_ENDPOINT_IP.  ## The endpoint IP of the service endpoint you just created

Você usará essas variáveis várias vezes durante os processos restantes. Se você quiser configurar várias regiões, crie variáveis com valores específicos para cada região.

2C. Criar um grupo gerenciado de instâncias

Multirregião: uma configuração multirregional requer um MIG separado para cada região. Se você estiver configurando várias regiões, repita as Etapas 2b e 2c em cada região, substituindo as variáveis correspondentes para cada uma delas.

Nesta etapa, você cria e configura um grupo gerenciado de instâncias (MIG, na sigla em inglês).

1. Crie um modelo de instância executando o seguinte comando:

   gcloud compute instance-templates create $MIG_NAME \
   --project $PROJECT_ID \
   --region $REGION \
   --network $VPC_NAME \
   --subnet $VPC_SUBNET \
   --tags=https-server,apigee-mig-proxy,gke-apigee-proxy \
   --machine-type e2-medium --image-family debian-12 \
   --image-project debian-cloud --boot-disk-size 20GB \
   --no-address \
   --metadata ENDPOINT=$SERVICE_ENDPOINT_IP,startup-script-url=gs://apigee-5g-saas/apigee-envoy-proxy-release/latest/conf/startup-script.sh

   Como você vê neste comando, as máquinas são do tipo e2-medium. Elas executam o Debian 12 e têm 20 GB de disco. O script startup-script.sh configura o MIG para rotear o tráfego de entrada do balanceador de carga para a instância da Apigee.

2. Crie um grupo gerenciado de instâncias executando o seguinte comando:

   gcloud compute instance-groups managed create $MIG_NAME \
   --project $PROJECT_ID --base-instance-name apigee-mig \
   --size 2 --template $MIG_NAME --region $REGION

3. Configure o escalonamento automático para o grupo executando o seguinte comando:
   Observação: um MIG regional com instâncias e2-medium oferece suporte para, no máximo, 6 Gbps. Se isso não for suficiente para suas necessidades de capacidade de processamento, considere aumentar o tamanho da VM e/ou o número de réplicas.

   gcloud compute instance-groups managed set-autoscaling $MIG_NAME \
   --project $PROJECT_ID --region $REGION --max-num-replicas 3 \
   --target-cpu-utilization 0.75 --cool-down-period 90

4. Defina uma porta nomeada executando o seguinte comando:

   gcloud compute instance-groups managed set-named-ports $MIG_NAME \
   --project $PROJECT_ID --region $REGION --named-ports https:443

3. Configurar o balanceador de carga com o monitoramento de verificação de integridade

Nas etapas a seguir, você configura um balanceador de carga com o monitoramento de verificação de integridade.

3A. Criar um certificado SSL e uma chave para o balanceador de carga

Você só precisa criar as credenciais uma vez, seja a instalação feita em uma única região ou em várias. Em uma etapa futura, você associará essas credenciais ao proxy HTTPS de destino do balanceador de carga.

É possível criar as credenciais com:

• Seu próprio certificado de uma autoridade certificadora
• Um certificado SSL gerenciado pelo Google
• Um certificado autoassinado (não recomendado para produção).

Saiba mais sobre como criar e usar certificados SSL com o balanceador de carga do Google Cloud em Certificados SSL e Visão geral dos certificados SSL.

No exemplo a seguir, criamos um certificado SSL gerenciado pelo Google:

1. Crie estas variáveis de ambiente:

   CERTIFICATE_NAME=YOUR_CERT_NAME
   DOMAIN_HOSTNAME=YOUR_DOMAIN_HOSTNAME 

   Defina DOMAIN_HOSTNAME como um nome de host de domínio válido que você registrou. Em uma etapa futura, você receberá o endereço IP do balanceador de carga e atualizará o registro A do domínio para apontar para esse endereço. Por exemplo, um nome de host de domínio pode ter esta aparência: foo.example.com.

2. Execute o comando gcloud compute ssl-certificates create:

   gcloud compute ssl-certificates create $CERTIFICATE_NAME \
   --domains=$DOMAIN_HOSTNAME \
   --project $PROJECT_ID \
   --global

   O provisionamento do certificado pode levar até uma hora. Para ver o status do provisionamento, execute este comando:

   gcloud compute ssl-certificates describe $CERTIFICATE_NAME \
   --global \
   --format="get(name,managed.status, managed.Status)"

   Observação: é possível criar vários registros de DNS A para os nomes de host do grupo do ambiente que apontam para o mesmo endereço IP do balanceador de carga.

3B. Criar verificação de integridade

1. criar uma verificação de integridade:

   gcloud compute health-checks create https HEALTH_CHECK_NAME \
   --project $PROJECT_ID --port 443 --global \
   --request-path /healthz/ingress

   Use essa verificação de integridade para garantir a execução do serviço de back-end. Para configurar verificações de integridade mais avançadas em um proxy específico, consulte Como executar verificações de integridade.

   Observação: se você receber o seguinte erro ao tentar criar uma verificação de integridade:

   ERROR: unrecognized arguments: --global,

   Tente atualizar gcloud usando o comando gcloud components update.

2. Crie um serviço de back-end:

   gcloud compute backend-services create PROXY_BACKEND_NAME \
   --project $PROJECT_ID \
   --protocol HTTPS \
   --health-checks HEALTH_CHECK_NAME \
   --port-name https \
   --timeout 302s \
   --connection-draining-timeout 300s \
   --global

   Observação: conforme documentado na referência de propriedades do Endpoint da Apigee, a entrada da Apigee (balanceador de carga interno) tem um tempo limite padrão de 300 segundos. Definir o tempo limite do backend-services do balanceador de carga para 302 segundos permitirá que esse comando seja totalmente concluído na Apigee no caso de transações de longa duração. Definir esse valor para algo menor, como 60 segundos, pode fazer com que o balanceador de carga atinja o tempo limite antes que a solicitação seja concluída, o que resultaria em 502 respostas.
3. Adicione o MIG ao serviço de back-end com o seguinte comando:
   Multirregião: para uma configuração multirregional, é preciso criar um MIG separado para cada região e repetir esta etapa a fim de adicionar cada MIG ao serviço de back-end. Certifique-se de substituir as variáveis REGION e MIG_NAME apropriadas para cada região.

   gcloud compute backend-services add-backend PROXY_BACKEND_NAME \
   --project $PROJECT_ID --instance-group $MIG_NAME \
   --instance-group-region $REGION \
   --balancing-mode UTILIZATION --max-utilization 0.8 --global

4. Crie um mapa de URL de balanceamento de carga com o seguinte comando:

   gcloud compute url-maps create MIG_PROXY_MAP_NAME \
   --project $PROJECT_ID --default-service PROXY_BACKEND_NAME

5. Crie um proxy HTTPS de destino de balanceamento de carga com o seguinte comando:

   gcloud compute target-https-proxies create MIG_HTTPS_PROXY_NAME \
   --project $PROJECT_ID --url-map MIG_PROXY_MAP_NAME \
   --ssl-certificates $CERTIFICATE_NAME

3C. Criar um endereço IP reservado e regras de firewall

Atribua um endereço IP ao balanceador de carga e crie regras que permitam que o balanceador de carga acesse o MIG. Essa etapa só precisa ser feita uma vez, seja na instalação em uma região ou em várias.

1. Reserve um endereço IP para o balanceador de carga:

   gcloud compute addresses create ADDRESSES_NAME \
   --project $PROJECT_ID \
   --ip-version=IPV4 \
   --global

2. Crie uma regra de encaminhamento global com o seguinte comando:

   gcloud compute forwarding-rules create FORWARDING_RULE_NAME \
   --project $PROJECT_ID --address ADDRESSES_NAME --global \
   --target-https-proxy MIG_HTTPS_PROXY_NAME --ports 443

3. Consiga um endereço IP reservado executando o seguinte comando:

   gcloud compute addresses describe ADDRESSES_NAME \
   --project $PROJECT_ID --format="get(address)" --global

4. Etapa importante: acesse o site, o host DNS ou o ISP em que seus registros DNS são gerenciados e verifique se o registro DNS do domínio é resolvido para o endereço IP do balanceador de carga do Google Cloud. Esse endereço é o valor do IP retornado na última etapa. Saiba mais em Atualizar os registros DNS A e AAAA a fim de apontar para o endereço IP do balanceador de carga.
5. Crie uma regra de firewall que permita que o balanceador de carga acesse o MIG usando o seguinte comando:

   gcloud compute firewall-rules create FIREWALL_RULE_NAME \
   --description "Allow incoming from GLB on TCP port 443 to Apigee Proxy" \
   --project $PROJECT_ID --network $VPC_NAME --allow=tcp:443 \
   --source-ranges=130.211.0.0/22,35.191.0.0/16 --target-tags=gke-apigee-proxy

   Observe que os intervalos de endereços IP 130.211.0.0/22 e 35.191.0.0/16 são os intervalos de endereços IP de origem do Google Load Balancing. Essa regra de firewall permite que o Google Cloud Load Balancing faça solicitações de verificação de integridade ao MIG.

O provisionamento da Apigee foi concluído. Acesse Implantar um proxy de amostra.