Esta página descreve como configurar uma implementação de alta disponibilidade com equilibradores de carga de aplicações externos regionais. Para alcançar uma elevada disponibilidade, implemente vários balanceadores de carga de aplicações externos regionais individuais em regiões que melhor suportem o tráfego da sua aplicação. Isto funciona porque os balanceadores de carga de aplicações externos regionais em diferentes regiões não só estão isolados uns dos outros, como também estão isolados de qualquer balanceador de carga de aplicações externo global ou infraestrutura de balanceador de carga de aplicações clássico em execução na mesma região.
Use uma política de encaminhamento de geolocalização do Cloud DNS para encaminhar 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 do pedido do cliente. Também recomendamos que use verificações de estado para que o Google Cloud possa detetar quaisquer interrupções regionais e encaminhar o tráfego apenas para os equilibradores de carga em bom estado. Google Cloud
Segue-se um exemplo de configuração que mostra dois equilibradores de carga de aplicações externos regionais em duas regiões diferentes.
As secções seguintes descrevem um fluxo de trabalho típico com os diferentes componentes envolvidos nesta configuração.
Use verificações de funcionamento para detetar falhas regionais
Google Cloud usa verificações de funcionamento para detetar se os seus balanceadores de carga estão em bom estado. Configura estas verificações de funcionamento para enviar sondas de três regiões de origem. Estas três regiões de origem têm de ser representativas das regiões a partir das quais os seus clientes acedem aos equilibradores de carga. Por exemplo, se tiver um Application Load Balancer externo regional com a maioria do tráfego de clientes proveniente da América do Norte e da Europa, pode ter sondagens provenientes de duas ou mais regiões na América do Norte e sondagens provenientes de duas ou mais regiões na Europa.
Notas adicionais:
- Tem de especificar exatamente três regiões de origem quando criar a verificação de estado. Apenas as verificações de saúde globais podem especificar regiões de origem.
- As verificações de funcionamento de HTTP, HTTPS e TCP são suportadas.
- As sondas de verificação de estado têm origem num ponto de presença (PoP) na Internet a uma pequena distância da região de origem configurada Google Cloud.
Encaminhe o tráfego para balanceadores de carga em bom estado
Google Cloud usa uma política de encaminhamento por geolocalização do Cloud DNS para direcionar o tráfego para os balanceadores de carga. Quando todos os balanceadores de carga estão em bom estado, o Cloud DNS encaminha o tráfego para o balanceador de carga geograficamente mais próximo da origem do pedido do cliente.
Quando um balanceador de carga numa região específica começa a falhar nas verificações de estado, o tráfego é encaminhado para balanceadores de carga disponíveis e em bom estado noutras regiões.
Recorra à utilização de todos os balanceadores de carga
A reversão é automática quando as verificações de estado voltam a ser aprovadas. Não é esperado nenhum tempo de inatividade durante o retorno porque todos os balanceadores de carga disponíveis estão a publicar tráfego.
Configure o balanceamento de carga entre regiões
Execute os seguintes passos para configurar uma implementação em várias regiões que facilita a elevada disponibilidade:
- Crie balanceadores de carga de aplicações externos regionais nas regiões que determinar que melhor suportam o tráfego para a sua aplicação. Cada um destes equilibradores de carga tem de ter a mesma configuração de gestão de tráfego e de segurança.
- Crie a verificação de estado e a política de encaminhamento de DNS para direcionar o tráfego para os equilibradores de carga com base na localização do cliente e para encaminhar o tráfego para longe de um equilibrador de carga não saudável em caso de indisponibilidade.
Crie balanceadores de carga em várias regiões
Tenha em atenção as seguintes considerações ao configurar os equilibradores de carga redundantes adicionais:
Configure todos os balanceadores de carga de aplicações externos regionais com funcionalidades semelhantes para que o tráfego seja processado de forma consistente, independentemente do balanceador de carga que serve o pedido. Por exemplo, tem de se certificar de que está a usar o mesmo tipo de certificado SSL, as mesmas políticas do Cloud Armor e as mesmas definições de gestão de tráfego para todos os equilibradores de carga de aplicações externos regionais.
Recomendamos que use uma framework de automatização, como o Terraform, para ajudar a alcançar e manter a consistência nas configurações do equilibrador de carga nas diferentes implementações regionais.
Recomendamos que configure equilibradores de carga de aplicações externos regionais em todas as regiões que determinar que melhor suportam o tráfego para a sua aplicação.
Os balanceadores de carga de aplicações externos regionais suportam os níveis de serviço de rede Premium e Standard. Recomendamos que configure os equilibradores de carga de aplicações externos regionais adicionais no nível Premium para garantir uma latência baixa.
Para saber como configurar um Application Load Balancer externo regional, consulte o artigo Configure um Application Load Balancer externo regional com back-ends de grupos de instâncias de VMs.
Configure o Cloud DNS e as verificações de funcionamento
Esta secção descreve como usar o Cloud DNS e as Google Cloud verificações de estado para configurar o seu ambiente do Cloud Load Balancing de modo a detetar interrupções e encaminhar tráfego para equilibradores de carga noutras regiões.
Siga os passos abaixo para configurar as políticas de verificação de estado e encaminhamento necessárias:
Crie uma verificação de funcionamento para o endereço IP da regra de encaminhamento do balanceador de carga principal.
gcloud 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_PATHSubstitua o seguinte:
HEALTH_CHECK_NAME: o nome da verificação de funcionamentoSOURCE_REGION: as três Google Cloud regiões a partir das quais são enviadas sondagens de verificações de estado. Tem de especificar exatamente três regiões de origem.HEALTH_CHECK_INTERVAL: o período em segundos desde o início de uma sondagem emitida por um verificador de sondagens até ao início da sondagem seguinte emitida pelo mesmo verificador de sondagens. O valor mínimo suportado é de 30 segundos. Para ver os valores recomendados, consulte as práticas recomendadas.HEALTHY_THRESHOLDeUNHEALTHY_THRESHOLD: especifique o número de sondagens sequenciais que têm de ser bem-sucedidas ou falhar para que a instância da VM seja considerada em bom ou mau estado. Se qualquer um for omitido, Google Cloud usa um limite predefinido de 2.REQUEST_PATH: o caminho do URL para o qual o Google Cloud Armor envia pedidos de sondagem de verificação do estado.Google Cloud Se for omitido, Google Cloud envia pedidos de sondagem para o caminho raiz,/. Se os pontos finais cuja integridade está a ser verificada forem privados, o que não é típico para endereços IP de regras de encaminhamento externas, pode definir este caminho como/afhealthz.
No Cloud DNS, crie um conjunto de registos e aplique-lhe uma política de encaminhamento por geolocalização.
gcloud 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_NAMESubstitua o seguinte:
DNS_RECORD_SET_NAME: o DNS ou o nome de domínio do conjunto de registos a adicionar, por exemplo,test.example.comTIME_TO_LIVE: o tempo de vida (TTL), em segundos, do registo. Para ver os valores recomendados, consulte as considerações de DNS.RECORD_TYPE: o tipo de registo, por exemplo,AMANAGED_ZONE_NAME: o nome da zona gerida cujos conjuntos de registos quer gerir, por exemplo,my-zone-nameFORWARDING_RULE_NAME: os nomes das regras de encaminhamento do balanceador de carga em cadaREGIONREGION: as regiões onde cada balanceador de carga é implementado
Práticas recomendadas
Seguem-se algumas práticas recomendadas a ter em atenção quando configura o registo do Cloud DNS e as verificações de funcionamento:
O tempo necessário para o tráfego ser encaminhado de balanceadores de carga não íntegros para balanceadores de carga íntegros (ou seja, a duração da indisponibilidade) depende do valor TTL do DNS, do intervalo de verificação de estado e do parâmetro limite não íntegro da verificação de estado.
Com o Cloud DNS da Google, o limite superior deste período pode ser calculado através da seguinte fórmula:
Duration of outage = DNS TTL + Health Check Interval * Unhealthy ThresholdRecomendamos que defina o TTL do DNS entre 30 e 60 segundos. Os TTLs mais elevados resultam em tempos de inatividade mais longos porque os clientes na Internet continuam a aceder aos equilibradores de carga não íntegros, mesmo depois de o DNS ter mudado para outras regiões.
Configure os parâmetros de limite saudáveis e não saudáveis nas verificações de estado de forma a evitar o reencaminhamento desnecessário e abrupto do tráfego devido a erros transitórios. Os limites mais elevados aumentam o tempo que o tráfego demora a mudar para balanceadores de carga noutras regiões.