Comutação por falha para balanceadores de carga de aplicações externos

Esta página descreve como funciona a comutação por falha para equilibradores de carga de aplicações externos. A configuração de comutação por falha envolve dois balanceadores de carga: um balanceador de carga principal e um balanceador de carga de cópia de segurança. Para efeitos desta discussão, o equilibrador de carga principal é o equilibrador de carga para o qual quer configurar a comutação por falha. O balanceador de carga alternativo é o balanceador de carga que recebe ligações quando o balanceador de carga principal começa a falhar nas verificações de estado.

A comutação por falha e a recuperação são os processos automáticos que encaminham o tráfego de e para um balanceador de carga. Quando o Cloud DNS deteta uma indisponibilidade e encaminha o tráfego do balanceador de carga principal para o balanceador de carga alternativo, o processo é denominado failover. Quando o Cloud DNS inverte este processo e redireciona o tráfego para o balanceador de carga principal, o processo é denominado retorno.

Como funciona a comutação por falha

A comutação por falha global para regional para balanceadores de carga de aplicações externos é processada através da criação de dois ou mais balanceadores de carga de aplicações externos regionais nas regiões para as quais quer que o tráfego comute por falha. Só é possível usar balanceadores de carga de aplicações externos regionais como balanceadores de carga de backup. Os balanceadores de carga de aplicações externos regionais não só são autónomos nas Google Cloud regiões individuais, 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.

Os balanceadores de carga de aplicações externos regionais funcionam melhor como balanceadores de carga de comutação por falha para balanceadores de carga de aplicações externos globais porque ambos se baseiam em proxies Envoy e processam o tráfego de formas muito semelhantes. Isto contrasta com um balanceador de carga de aplicações clássico que tem diferenças notáveis na forma como o tráfego é processado.

Em resumo, são suportados os seguintes cenários de alternativa:

  • De um balanceador de carga de aplicações externo global para um balanceador de carga de aplicações externo regional
  • De um balanceador de carga de aplicações externo regional para um balanceador de carga de aplicações externo regional
  • De um balanceador de carga de aplicações clássico para um balanceador de carga de aplicações externo regional

Fluxo de trabalho de comutação por falha e recuperação

A configuração seguinte demonstra a comutação por falha de um Application Load Balancer externo global para dois Application Load Balancers externos regionais, com um em cada região onde o balanceador de carga global implementou back-ends.

Realizar uma comutação por falha de um Application Load Balancer externo global para dois Application Load Balancers externos regionais.
Failover de um Application Load Balancer externo global para dois Application Load Balancers externos regionais (clique para aumentar).

As secções seguintes descrevem um fluxo de trabalho típico com os diferentes componentes envolvidos numa configuração de comutação por falha.

  1. Detetar falhas no equilibrador de carga principal

    Google Cloud usa verificações de estado para detetar se o seu balanceador de carga de aplicações externo principal está 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 vão aceder ao equilibrador de carga. Por exemplo, se tiver um Application Load Balancer externo global e a maioria do tráfego de clientes for originário da América do Norte e da Europa, pode configurar sondagens originárias de duas regiões na América do Norte e uma região na Europa.

    Se as verificações de saúde originárias de duas ou mais destas regiões falharem, isto aciona a comutação por falha para o Application Load Balancer externo regional de cópia de segurança.

    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.

  2. Encaminhe o tráfego para balanceadores de carga de cópia de segurança

    Se o balanceador de carga principal começar a falhar nas verificações de funcionamento, Google Cloud usa políticas de encaminhamento de comutação por falha do Cloud DNS para determinar como encaminhar o tráfego para os balanceadores de carga de cópia de segurança.

    A duração da indisponibilidade ou o tempo que o tráfego demora a comutar do balanceador de carga principal para o balanceador de carga de cópia de segurança é determinado pelo valor TTL do DNS, o intervalo de verificação do estado e o limite de estado não saudável da verificação do estado. Para ver as definições recomendadas, consulte as práticas recomendadas.

  3. Recuperação para o balanceador de carga principal

    Depois de as verificações de estado voltarem a ser aprovadas, a reversão para o equilibrador de carga principal é automática. Não é esperada nenhuma indisponibilidade durante o retorno porque os balanceadores de carga principal e secundário estão a publicar tráfego.

  4. Teste a comutação por falha periodicamente

    Recomendamos que teste periodicamente o fluxo de trabalho de comutação por falha como parte do seu plano de continuidade operacional. Certifique-se de que testa as mudanças graduais e instantâneas no tráfego dos balanceadores de carga principais para os balanceadores de carga de backup. Depois de verificar se a comutação por falha funciona, acione uma comutação por recuperação para verificar se o tráfego é reencaminhado para o balanceador de carga principal conforme esperado.

Configure a comutação por falha

Para configurar a comutação por falha, siga estes passos:

  1. Reveja a configuração do balanceador de carga principal existente e verifique se as funcionalidades (como funcionalidades de segurança, gestão de tráfego e funcionalidades de encaminhamento, e RFC) usadas pelo balanceador de carga principal estão disponíveis com o balanceador de carga de aplicações externo regional de cópia de segurança. Se não estiverem disponíveis funcionalidades semelhantes, este equilibrador de carga pode não ser uma boa opção para a comutação por falha.
  2. Crie o balanceador de carga de aplicações externo regional de yedek com uma configuração que espelhe o balanceador de carga principal o máximo possível.
  3. Crie a verificação de funcionamento e a política de encaminhamento DNS para detetar interrupções e encaminhar tráfego do balanceador de carga principal para o balanceador de carga de segurança durante a comutação por falha.

Reveja a configuração do balanceador de carga principal

Antes de começar, verifique se o balanceador de carga de aplicações externo regional de backup suporta todas as funcionalidades atualmente usadas com o balanceador de carga principal.

Para evitar a interrupção do tráfego, reveja as seguintes diferenças:

  • Implementações do GKE. Os utilizadores do GKE devem ter em atenção que os balanceadores de carga implementados através do GKE Gateway são mais compatíveis com este mecanismo de comutação por falha do que os balanceadores de carga implementados através do controlador GKE Ingress. Isto deve-se ao facto de o GKE Gateway suportar a configuração dos balanceadores de carga de aplicações externos globais e regionais. No entanto, o controlador GKE Ingress só suporta o Application Load Balancer clássico.

    Para os melhores resultados, use o GKE Gateway para implementar os balanceadores de carga principal e de cópia de segurança.

  • Cloud CDN. Os balanceadores de carga de aplicações externos regionais não suportam o Cloud CDN. Por conseguinte, em caso de falha, todas as operações que dependam do Cloud CDN também são afetadas. Para uma melhor redundância, recomendamos que configure uma solução de RFC de terceiros que possa funcionar como alternativa à RFC da Google Cloud.

  • Cloud Armor. Se usar o Cloud Armor para o equilibrador de carga principal, certifique-se de que também configura as mesmas funcionalidades do Cloud Armor quando configurar o equilibrador de carga de aplicações externo regional de cópia de segurança. O Cloud Armor tem diferentes funcionalidades disponíveis no âmbito regional em comparação com o âmbito global. Para mais informações, consulte as seguintes secções na documentação do Cloud Armor:

  • Certificados SSL. Se quiser usar um certificado SSL comum para os balanceadores de carga principal e de reserva, confirme que o tipo de certificado SSL usado com o balanceador de carga principal é compatível com o balanceador de carga de aplicações externo regional de reserva. Reveja as diferenças entre os certificados SSL disponíveis com equilibradores de carga globais, regionais e clássicos. Para mais detalhes, consulte as seguintes secções:

  • Recipientes de back-end. Os balanceadores de carga de aplicações externos regionais não suportam contentores do Cloud Storage como back-ends. Não pode configurar a comutação por falha para equilibradores de carga que usam contentores de back-end.

Configure o balanceador de carga alternativo

O balanceador de carga de cópia de segurança é um balanceador de carga de aplicações externo regional que configura na região onde quer que o tráfego seja redirecionado em caso de falha.

Tenha em atenção as seguintes considerações ao configurar o balanceador de carga de backup:

  • Tem de configurar as funcionalidades do balanceador de carga de aplicações externo regional de cópia de segurança para serem o mais semelhantes possível ao balanceador de carga principal, de modo que o tráfego seja processado de forma semelhante em ambas as implementações.

    • Balanceador de carga de aplicações externo global. Os balanceadores de carga de aplicações externos regionais suportam a maioria das mesmas funcionalidades que os balanceadores de carga de aplicações externos globais, com algumas exceções. O balanceador de carga regional também suporta as mesmas capacidades de gestão de tráfego avançadas que o balanceador de carga global, o que facilita a equivalência entre os balanceadores de carga principal e de cópia de segurança.

    • Classic Application Load Balancer. Com o balanceador de carga de aplicações clássico, é mais difícil alcançar a paridade de funcionalidades entre o balanceador de carga principal e o de cópia de segurança, porque o balanceador de carga de aplicações externo regional é um balanceador de carga baseado no Envoy que processa o tráfego de forma diferente. Certifique-se de que testa exaustivamente a comutação por falha e a recuperação antes da implementação em produção.

    Para ver as capacidades específicas dos balanceadores de carga de aplicações regionais, globais e clássicos, consulte a página de comparação de funcionalidades do balanceador de carga.

    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 implementações primárias e de cópia de segurança.

  • Recomendamos que configure balanceadores de carga de aplicações externos regionais alternativos em todas as regiões onde tem back-ends. Por exemplo, se fizer failover de uma implementação global com grupos de instâncias em cinco regiões para equilibradores de carga regionais de yedback-up apenas em três regiões, corre o risco de sobrecarregar os seus serviços de back-end nestas três regiões, enquanto os serviços de back-end nas duas regiões restantes estão inativos.

    Além disso, recomendamos que configure o Cloud DNS para usar políticas de round robin ponderado quando reencaminhar tráfego de comutação por falha de um balanceador de carga global principal para estes balanceadores de carga regionais de backup. Atribua ponderações a cada equilibrador de carga de cópia de segurança tendo em conta os tamanhos máximos dos grupos de instâncias de back-end em diferentes regiões.

  • Os balanceadores de carga de aplicações externos regionais suportam os níveis de serviço de rede Premium e Standard. Se a latência não for a sua principal preocupação durante a comutação por falha, recomendamos que configure os equilibradores de carga de aplicações externos regionais de yedekleme com o nível padrão. A utilização da infraestrutura do Nível padrão oferece isolamento adicional da infraestrutura do Nível premium usada pelos equilibradores de carga de aplicações externos globais.

  • Se quiser usar os mesmos back-ends para os balanceadores de carga principal e de cópia de segurança, crie o balanceador de carga de aplicações externo regional de cópia de segurança na região onde os back-ends estão localizados. Se ativou o dimensionamento automático para os grupos de instâncias de back-end, tem de cumprir os requisitos para partilhar back-ends em implementações.

  • Se necessário, reserve proxies Envoy adicionais para equilibradores de carga de aplicações externos regionais para ajudar a garantir que, em caso de um evento de comutação por falha, o tráfego adicional não interrompe quaisquer outras implementações de equilibradores de carga na mesma região. Para ver detalhes, consulte o artigo Reserve capacidade adicional de sub-rede apenas de proxy.

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.

Reserve capacidade adicional da sub-rede só de proxy

Todos os balanceadores de carga baseados no Envoy regionais numa região e numa rede VPC partilham o mesmo conjunto de proxies do Envoy. Num evento de comutação por falha, os Application Load Balancers externos regionais de yedekleme veem um aumento na utilização de proxy para processar o tráfego de comutação por falha do balanceador de carga principal. Para ajudar a garantir que a capacidade está sempre disponível para os balanceadores de carga de backup, recomendamos que reveja o tamanho da sua sub-rede só de proxy. Recomendamos que calcule o número estimado de proxies necessários para processar o tráfego numa determinada região e aumente a capacidade, se necessário. Isto também ajuda a garantir que os eventos de comutação por falha não interrompem outros equilibradores de carga baseados no Envoy na mesma região e rede.

Geralmente, um proxy do balanceador de carga de aplicações externo regional pode gerir até:

  • 600 (HTTP) ou 150 (HTTPS) novas ligações por segundo
  • 3000 ligações ativas
  • 1400 pedidos por segundo

Se estiver a usar políticas de DNS para dividir o tráfego por vários equilibradores de carga de cópia de segurança em diferentes regiões, tem de ter isso em conta ao estimar os requisitos de proxy por região e rede. Uma sub-rede só de proxy maior permiteGoogle Cloud atribuir um número maior de proxies do Envoy ao seu balanceador de carga quando necessário.

Não pode expandir uma sub-rede apenas de proxy da mesma forma que faria para um intervalo de endereços principal (com o comando expand-ip-range). Em alternativa, tem de criar uma sub-rede só de proxy de cópia de segurança que satisfaça as suas necessidades e, em seguida, promovê-la para a função ativa.

Para saber como alterar o tamanho da sua sub-rede apenas de proxy, consulte o artigo Altere o tamanho ou o intervalo de endereços de uma sub-rede apenas de proxy.

Partilhar back-ends entre balanceadores de carga principal e de cópia de segurança

Para alcançar a redundância infraestrutural completa, tem de introduzir a redundância ao nível do equilibrador de carga e ao nível do back-end. Isto significa que tem de configurar os balanceadores de carga de aplicações externos regionais de cópia de segurança com back-ends (grupos de instâncias ou grupos de pontos finais de rede) que não tenham sobreposição com os balanceadores de carga principais.

No entanto, se quiser partilhar um grupo de instâncias de back-end entre os balanceadores de carga primário e secundário, e o dimensionamento automático estiver ativado para os grupos de instâncias, tem de cumprir os seguintes requisitos para ajudar a garantir que ocorre uma comutação por falha adequada:

  • O escalador automático tem de ser configurado apenas com o escalonamento baseado na CPU. O método de escalabilidade baseado na utilização do balanceador de carga não é suportado.
  • Os serviços de back-end globais e regionais têm de usar apenas o modo de balanceamento.UTILIZATION A utilização do modo de equilíbrio RATE não é recomendada porque as suas instâncias podem receber 2 vezes o tráfego dos equilibradores de carga globais e regionais durante o processo de comutação por falha.
  • Os controlos de redução têm de ser configurados para impedir que o escalador automático reduza prematuramente o grupo durante o tempo de inatividade quando o tráfego está a mudar do balanceador de carga global para o balanceador de carga regional. Este tempo de inatividade pode ser tão elevado quanto a soma do TTL do DNS mais o intervalo de verificação de funcionamento configurado.

A falha na configuração da escalabilidade automática corretamente pode resultar numa interrupção secundária durante a comutação por falha, porque a perda de tráfego do balanceador de carga global faz com que o grupo de instâncias diminua rapidamente.

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 os balanceadores de carga de cópia de segurança.

Siga os passos abaixo para configurar as políticas de verificação de estado e encaminhamento necessárias:

  1. 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_PATH

    Substitua o seguinte:

    • HEALTH_CHECK_NAME: o nome da verificação de funcionamento
    • SOURCE_REGION: as três Google Cloud regiões a partir das quais as verificações de funcionamento são realizadas. 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_THRESHOLD e UNHEALTHY_THRESHOLD: 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.

  2. Crie um conjunto de registos de DNS do Cloud no Cloud DNS e aplique-lhe uma política de encaminhamento. A política de encaminhamento tem de ser configurada para resolver o nome do domínio para o endereço IP da regra de encaminhamento do balanceador de carga principal ou, em caso de falha na verificação de funcionamento, para um dos endereços IP da regra de encaminhamento dos balanceadores de carga de backup.

    gcloud dns record-sets create DNS_RECORD_SET_NAME \
    --ttl=TIME_TO_LIVE \
    --type=RECORD_TYPE \
    --zone="MANAGED_ZONE_NAME" \
    --routing-policy-type=FAILOVER \
    --routing-policy-primary-data=PRIMARY_LOAD_BALANCER_FORWARDING_RULE \
    --routing-policy-backup-data_type=GEO \
    --routing-policy-backup-data="BACKUP_REGION_1=BACKUP_LOAD_BALANCER_1_IP_ADDRESS[;BACKUP_REGION_2=BACKUP_LOAD_BALANCER_2_IP_ADDRESS;BACKUP_REGION_3=BACKUP_LOAD_BALANCER_3_IP_ADDRESS]" \
    --health-check=HEALTH_CHECK_NAME \
    --backup-data-trickle-ratio=BACKUP_DATA_TRICKLE_RATIO

    Substitua o seguinte:

    • DNS_RECORD_SET_NAME: o DNS ou o nome do domínio do conjunto de registos a adicionar, por exemplo, test.example.com
    • TIME_TO_LIVE: o tempo de vida (TTL) do conjunto de registos em número de segundos. Para ver os valores recomendados, consulte as práticas recomendadas.
    • RECORD_TYPE: o tipo de registo, por exemplo, A
    • MANAGED_ZONE_NAME: o nome da zona gerida cujos conjuntos de registos quer gerir, por exemplo, my-zone-name
    • PRIMARY_LOAD_BALANCER_FORWARDING_RULE: o nome da regra de encaminhamento do balanceador de carga principal
    • BACKUP_REGION: as regiões onde os balanceadores de carga de substituição estão implementados
    • BACKUP_LOAD_BALANCER_IP_ADDRESS: os endereços IP da regra de encaminhamento dos balanceadores de carga de cópia de segurança correspondentes a cada região
    • BACKUP_DATA_TRICKLE_RATIO: a proporção de tráfego a enviar para os balanceadores de carga de cópia de segurança, mesmo quando o balanceador de carga principal está em bom estado. A proporção tem de estar entre 0 e 1, como 0,1. A predefinição é 0.

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 que o tráfego demora a comutar dos balanceadores de carga primários para os de cópia de segurança (ou seja, a duração da indisponibilidade) depende do valor TTL do DNS, do intervalo da verificação de estado e do parâmetro limite de estado 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 Threshold

    Para a configuração de comutação por falha, recomendamos que defina o TTL de DNS para 30 a 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 de aplicações externos principais, mesmo depois de o DNS ter mudado para o equilibrador de carga de aplicações externo regional de yedekleme.

  • Configure os parâmetros de limite saudáveis e não saudáveis nas verificações de estado de forma a evitar failovers desnecessários causados por erros transitórios. Os limites mais elevados aumentam o tempo necessário para que o tráfego com falhas passe para os balanceadores de carga de cópia de segurança.

  • Para ajudar a garantir que a configuração de comutação por falha funciona como esperado, pode configurar a política de encaminhamento de DNS para enviar sempre uma pequena percentagem do tráfego para os equilibradores de carga de yedundância, mesmo quando os equilibradores de carga principais estão em bom estado. Isto pode ser feito através do parâmetro --backup-data-trickle-ratio quando cria o conjunto de registos DNS.

    Pode configurar a percentagem do tráfego enviado para a solução alternativa como uma fração de 0 a 1. O valor típico é 0,1, embora o Cloud DNS lhe permita enviar 100% do tráfego para os endereços VIP de cópia de segurança, para acionar manualmente uma comutação por falha.