Alta disponibilidade para balanceadores de carga de aplicativo externos regionais

Esta página descreve como configurar uma implantação altamente disponível com balanceadores de carga de aplicativo externos regionais. Para ter alta disponibilidade, implante vários balanceadores de carga de aplicativo externos regionais individuais nas regiões que melhor oferecem suporte ao do tráfego do aplicativo. Isso funciona porque os balanceadores de carga de aplicativo externos regionais em diferentes regiões não são apenas isolados entre si, mas também são isolados de qualquer balanceador de carga de aplicativo externo global ou infraestrutura de balanceador de carga de aplicativo clássico em execução na mesma região.

Usar uma política de roteamento de geolocalização do Cloud DNS para rotear o tráfego para dois ou mais balanceadores de carga em regiões diferentes. A política encaminha o tráfego para a região disponível mais próxima com base na origem da solicitação do cliente. Também é recomendado usar verificações de integridade para que o Google Cloud possa detectar as interrupções regionais e rotear o tráfego apenas para os balanceadores de carga íntegros.

Este é um exemplo de configuração que mostra dois balanceadores de carga de aplicativo externos regionais em duas diferentes regiões.

Alta disponibilidade com dois balanceadores de carga de aplicativo externos regionais. — Alta disponibilidade com dois balanceadores de carga de aplicativo externos regionais (clique para ampliar).

As seções a seguir descrevem um fluxo de trabalho típico com os diferentes componentes envolvidos nessa configuração.

Usar verificações de integridade para detectar falhas regionais

O Google Cloud usa a verificação de integridade para detectar se os balanceadores de carga de rede estão íntegros. Configure essas verificações de integridade para enviar sondagens de três regiões de origem. Essas três regiões de origem precisam ser das regiões de onde seus clientes acessam a carga balanceadores de carga HTTP(S) externos. Por exemplo, se você tiver um balanceador de carga de aplicativo externo regional com a maioria do tráfego do cliente originário da América do Norte e da Europa, poderá ter sondas originárias de duas ou mais regiões na América do Norte e sondagens originárias de duas ou mais regiões na Europa.

Observações adicionais:
- É preciso especificar exatamente três regiões de origem ao criar a verificação de integridade. Somente as verificações de integridade globais podem especificar regiões de origem.
- As verificações de integridade HTTP, HTTPS e TCP são compatíveis.
- Na verdade, as sondagens de verificação de integridade têm origem em um ponto de presença (PoP) na Internet a uma pequena distância da região de origem configurada do Google Cloud.
Encaminhar o tráfego para balanceadores de carga íntegros

O Google Cloud usa uma política de roteamento de geolocalização do Cloud DNS para direcionar o tráfego aos balanceadores de carga. Quando todos os balanceadores de carga estão íntegros, o Cloud DNS encaminha o tráfego para o balanceador de carga que está geograficamente mais próximo da origem da solicitação do cliente.

Quando um balanceador de carga em uma região específica começa a falhar nas verificações de integridade, o tráfego é roteado para balanceadores de carga íntegros disponíveis em outras regiões.
Failback para usar todos os balanceadores de carga

O failback é automático quando as verificações de integridade começam a ser aprovadas novamente. Não há tempo de inatividade esperado durante o failback porque todos os balanceadores de carga disponíveis estão disponibilizando tráfego.

Configurar o balanceamento de carga entre regiões

Execute as etapas a seguir para configurar uma implantação entre regiões que facilita a alta disponibilidade:

Crie balanceadores de carga de aplicativo externos regionais nas regiões que você determinar como as melhores para o tráfego do seu aplicativo. Cada um desses balanceadores de carga precisa ter a mesma configuração de gerenciamento de tráfego e segurança.
Crie a verificação de integridade e a política de roteamento de DNS para direcionar o tráfego para os balanceadores de carga com base na localização do cliente e para rotear o tráfego para longe de um balanceador de carga não íntegro em caso de interrupção.

Criar balanceadores de carga em várias regiões

Observe as seguintes considerações ao configurar seus balanceadores de carga redundantes adicionais:

Configure todos os balanceadores de carga de aplicativo externos regionais com recursos semelhantes para que o tráfego seja processado de forma consistente, independentemente de qual balanceador de carga atende à solicitação. Por exemplo, verifique se você está usando o mesmo tipo de certificado SSL, as mesmas políticas do Google Cloud Armor e as mesmas configurações de gerenciamento de tráfego para todos os balanceadores de carga de aplicativo externos regionais.

Recomendamos o uso de um framework de automação, como o Terraform, para ajudar a alcançar e manter a consistência nas configurações do balanceador de carga nas diferentes implantações regionais.
Recomendamos que você configure balanceadores de carga de aplicativo externos regionais em cada região que você determinar que suportará melhor o tráfego para seu aplicativo.
Os balanceadores de carga de aplicativo externos regionais dão suporte aos níveis de serviço de rede Premium e Standard. Recomendamos que você configure balanceadores de carga de aplicativo externos regionais no nível Premium para garantir baixa latência.

Para saber como configurar um balanceador de carga de aplicativo externo regional, consulte Configurar um balanceador de carga de aplicativo externo regional com back-ends de grupos de instâncias de VM.

Configurar o Cloud DNS e as verificações de integridade

Esta seção descreve como usar o Cloud DNS e as verificações de integridade do Google Cloud para configurar seu ambiente de Cloud Load Balancing para detectar falhas e rotear o tráfego para balanceadores de carga em outras regiões.

Use as etapas a seguir para configurar a verificação de integridade e as políticas de roteamento necessárias:

Crie uma verificação de integridade para o endereço IP da regra de encaminhamento do balanceador de carga primário.
```
gcloud beta compute health-checks create http HEALTH_CHECK_NAME \
    --global \
    --source-regions=SOURCE_REGION_1,SOURCE_REGION_2,SOURCE_REGION_3 \
    --use-serving-port \
    --check-interval=HEALTH_CHECK_INTERVAL \
    --healthy-threshold=HEALTHY_THRESHOLD \
    --unhealthy-threshold=UNHEALTHY_THRESHOLD \
    --request-path=REQUEST_PATH
```
Substitua:
- HEALTH_CHECK_NAME: o nome da verificação de integridade.
- SOURCE_REGION: as três regiões do Google Cloud em que as verificações de integridade são enviadas. Você deve especificar exatamente três regiões de origem.
- HEALTH_CHECK_INTERVAL: o tempo em segundos desde o início de uma sondagem emitida por uma sonda até o início da próxima sondagem emitida pela mesma sonda. O valor mínimo aceito é de 30 segundos. Para valores recomendados, consulte Práticas recomendadas.
- HEALTHY_THRESHOLD e UNHEALTHY_THRESHOLD: especificam o número sequencial de sondagens que precisam ser bem-sucedidas ou não para que a instância VM seja considerada íntegra ou não. Se omitidos, o Google Cloud usará um limite padrão de 2.
- REQUEST_PATH: o caminho do URL para o qual o Google Cloud envia solicitações de sondagem de verificação de integridade. Se for omitido, o Google Cloud enviará solicitações de sondagem para o caminho raiz, /. Se os endpoints que estão sendo verificados forem particulares, o que não é comum para endereços IP de regras de encaminhamento externas, defina esse caminho como /afhealthz.
No Cloud DNS, crie um conjunto de registros e aplique uma política de roteamento de geolocalização a ele.
```
gcloud beta dns record-sets create DNS_RECORD_SET_NAME \
    --ttl=TIME_TO_LIVE \
    --type=RECORD_TYPE \
    --zone="MANAGED_ZONE_NAME" \
    --routing-policy-type="GEO" \
    --routing-policy-data="FORWARDING_RULE_NAME_A@REGION_A;FORWARDING_RULE_NAME_B@REGION_B[,;FORWARDING_RULE_NAME_C@REGION_C]" \
    --health-check=HEALTH_CHECK_NAME
```
Substitua:
- DNS_RECORD_SET_NAME: o DNS ou nome de domínio do conjunto de registros a ser adicionado. Por exemplo, test.example.com.
- TIME_TO_LIVE: o time to live (TTL), em segundos, para fins de registro. Para ver os valores recomendados, consulte Considerações sobre o DNS.
- RECORD_TYPE: o tipo de registro. Por exemplo, A.
- MANAGED_ZONE_NAME: o nome da zona gerenciada com os conjuntos de registros que você quer gerenciar. Por exemplo, my-zone-name
- FORWARDING_RULE_NAME: os nomes das regras de encaminhamento para o balanceador de carga em cada REGION
- REGION: as regiões em que cada balanceador de carga é implantado

Práticas recomendadas

Confira algumas práticas recomendadas ao configurar o registro do Cloud DNS e as verificações de integridade:

O tempo que leva para o tráfego ser roteado de balanceadores de carga não íntegros para íntegros (ou seja, a duração da interrupção) depende do valor de TTL do DNS, do intervalo de verificação de integridade e do parâmetro limite não íntegro da verificação de integridade.

Com o Cloud DNS do Google, o limite máximo desse período pode ser calculado usando a seguinte fórmula:
```
Duration of outage = DNS TTL + Health Check Interval * Unhealthy Threshold
```
Recomendamos configurar o TTL do DNS como 30 a 60 segundos. TTLs mais altos levam a tempos de inatividade mais longos porque os clientes na Internet continuam acessando os balanceadores de carga não saudáveis, mesmo depois que o DNS falhar para outras regiões.
Configure os parâmetros de limite íntegro e não íntegro nas verificações de integridade para evitar o redirecionamento abrupto e desnecessário do tráfego devido a erros temporários. Limites mais altos aumentam o tempo necessário para o tráfego mudar para balanceadores de carga em outras regiões.