Para se proteger contra interrupções de infraestrutura ou erros de configuração, é possível projetar estratégias de failover para balanceadores de carga de aplicativo externos globais. Essas estratégias usam balanceadores de carga de aplicativo externos regionais e roteiam o tráfego de um balanceador de carga de aplicativo externo global para manter a alta disponibilidade durante interrupções da infraestrutura global ou erros de configuração.
Em uma arquitetura de failover, você implanta um balanceador de carga principal e um ou mais balanceadores de carga de backup:
- O balanceador de carga principal é o balanceador de carga de aplicativo externo global que processa o tráfego do cliente durante as operações normais.
- O balanceador de carga de backup é um balanceador de carga de aplicativo externo regional que recebe tráfego quando o balanceador de carga principal falha nas verificações de integridade.
Failover e failback são processos automáticos de roteamento de tráfego:
- O failover ocorre quando o Cloud DNS detecta uma interrupção e encaminha o tráfego do balanceador de carga principal para os de backup.
- O failback ocorre quando o Cloud DNS reverte esse roteamento e redireciona o tráfego para o balanceador de carga principal depois que as verificações de integridade são aprovadas.
Este documento aborda o failover de um balanceador de carga de aplicativo externo global para balanceadores de carga de backup regionais. Se você quiser configurar o failover entre balanceadores de carga de aplicativo externos regionais em diferentes regiões, consulte Alta disponibilidade para balanceadores de carga de aplicativo externos regionais.
Por que usar balanceadores de carga regionais para failover
Os balanceadores de carga de aplicativo externos regionais funcionam melhor como balanceadores de carga de failover para balanceadores de carga de aplicativo externos globais devido às seguintes propriedades:
- Os balanceadores de carga de aplicativo externos regionais são autocontidos em regiões individuais doGoogle Cloud e também são isolados de qualquer infraestrutura de balanceador de carga de aplicativo externo global em execução na mesma região.
- Os balanceadores de carga de aplicativo externos regionais e globais são baseados em proxies Envoy e processam o tráfego de maneiras semelhantes.
Para implementar o failover global para regional em balanceadores de carga de aplicativo externos globais, crie dois ou mais balanceadores de carga de aplicativo externos regionais nas regiões para onde você quer que o tráfego seja redirecionado.
Estratégias de failover
É possível implementar o failover para balanceadores de carga de aplicativo externos globais usando as seguintes estratégias:
- Ativo-passivo (failover global para regional): você implanta um ou mais balanceadores de carga de aplicativo externos regionais apenas para fins de backup. Em estado estável, o Cloud DNS é resolvido para o endereço IP do balanceador de carga de aplicativo externo global. Se o balanceador de carga global falhar, o Cloud DNS vai rotear o tráfego para os balanceadores de carga regionais de backup. Essa configuração usa uma política de roteamento de failover do Cloud DNS.
- Ativo-ativo (desvio global para regional): um balanceador de carga de aplicativo externo global atua como um front-end de borda que fornece funções do Cloud CDN, como armazenamento em cache de borda, que encaminha solicitações para balanceadores de carga de aplicativo externos regionais usando grupos de endpoints de rede (NEGs) da Internet com nomes de domínio totalmente qualificados (FQDNs). No estado estável, o tráfego flui sequencialmente pelas duas camadas de balanceamento de carga. Isso pode ser configurado usando uma política de roteamento de geolocalização do Cloud DNS. Se o balanceador de carga global sofrer uma interrupção, as políticas de roteamento de DNS vão ignorar a camada global e rotear o tráfego do cliente diretamente para os balanceadores de carga regionais.
Como prática recomendada, se a arquitetura não depender do balanceamento de carga de back-end global com reconhecimento de capacidade, prefira a estratégia ativo-ativo. No entanto, se o aplicativo exigir explicitamente o balanceamento de carga de back-end global para distribuir e transferir o tráfego entre regiões com base na capacidade do back-end, implemente a estratégia ativo-passivo.
Comparação de estratégias de failover
A tabela a seguir compara as estratégias de failover ativo-passivo e ativo-ativo:
| Atributo de estratégia | Ativo-passivo | Ativo-ativo |
|---|---|---|
| Fluxo de tráfego em estado estável | Cliente → Balanceador de carga de aplicativo externo global → Back-end | Cliente → Balanceador de carga de aplicativo externo global → Balanceador de carga de aplicativo externo regional → Back-end |
| Fluxo de tráfego em estado de falha | Cliente → Balanceador de carga de aplicativo externo regional → Back-end. O serviço permanece disponível, mas pode apresentar maior latência devido à perda dos benefícios de desempenho de borda. |
Cliente → Balanceador de carga de aplicativo externo regional → Back-end (ignorando o balanceador de carga de aplicativo externo global). O serviço permanece disponível, mas pode apresentar maior latência devido à perda dos benefícios de desempenho de borda. |
| Gerenciamento de configurações | Requer a sincronização de configurações independentes em balanceadores de carga globais e regionais. | A camada global requer configuração mínima, porque a maior parte da lógica do aplicativo reside em balanceadores de carga regionais. No entanto, é preciso duplicar as políticas de segurança de borda (Cloud Armor) e a configuração de encerramento de conexão (certificados TLS) nas duas camadas. |
| Verificação de confiabilidade | O balanceador de carga de aplicativo externo regional fica inativo em estado estável. Recomendamos testes periódicos ou tráfego do trickle de DNS. | O tráfego de estado estável testa continuamente o balanceador de carga de aplicativo externo regional. Recomendamos testes periódicos ou tráfego do trickle diretamente para o balanceador de carga regional. |
| Segurança de implantação progressiva | As mudanças na configuração do balanceador de carga de aplicativo externo global são aplicadas globalmente. As mudanças no balanceador de carga de aplicativo externo regional são isoladas, mas o tráfego de estado estável não as testa. | É possível aplicar as mudanças no balanceador de carga de aplicativo externo regional de forma progressiva, região por região. Se uma região falhar, a camada global vai redirecionar automaticamente o tráfego para regiões íntegras. |
| Balanceamento de carga de back-end global | Compatível O balanceador de carga de aplicativo externo global pode balancear o tráfego entre back-ends em diferentes regiões com base na capacidade. |
Limitado O balanceador de carga de aplicativo externo global encaminha o tráfego para o balanceador de carga de aplicativo externo regional mais próximo. O balanceador de carga regional equilibra o tráfego apenas localmente e não o distribui entre regiões com base na capacidade do back-end. |
| Custo e faturamento | As taxas de processamento de dados se aplicam a uma única camada de balanceamento de carga. Em estado estável, os custos vêm do balanceador de carga de aplicativo externo global. As cobranças do balanceador de carga de aplicativo externo regional se aplicam apenas durante eventos de teste ou failover. | As duas camadas de balanceamento de carga geram cobranças de tratamento de dados simultaneamente porque o tráfego flui pelos níveis global e regional em estado estável. |
| Caso de uso recomendado | Cargas de trabalho que exigem balanceamento de carga de back-end global avançado e distribuição de tráfego com base na capacidade entre regiões. | Cargas de trabalho projetadas em torno do isolamento regional que usam a camada global para desempenho de borda e armazenamento em cache. |
Estratégia ativo-passivo
Em uma configuração ativo-passivo, você implanta balanceadores de carga de aplicativo externos regionais independentes em uma ou mais regiões, além do balanceador de carga de aplicativo externo global ou clássico principal.
Como funciona o failover ativo-passivo
A configuração a seguir demonstra o failover de um balanceador de carga de aplicativo externo global para dois balanceadores de carga de aplicativo externos regionais de backup, com um em cada região em que o balanceador de carga global implantou back-ends.
O failover ativo-passivo segue este fluxo de trabalho:
- Estado estável: o Cloud DNS encaminha todo o tráfego do cliente para o balanceador de carga de aplicativo externo global.
- Detecção de falhas: Google Cloud usa verificações de integridade configuradas com três regiões de origem para detectar se o balanceador de carga principal está íntegro. Se as verificações de integridade originadas de duas ou mais regiões de origem falharem, o Cloud DNS acionará o failover.
- Failover: as políticas de roteamento de failover do Cloud DNS encaminham o tráfego do cliente diretamente para os balanceadores de carga de aplicativo externos regionais de backup. Impacto da latência durante o failover: como os balanceadores de carga de aplicativo externos regionais encerram conexões em uma região Google Cloud específica, os clientes localizados longe da região de destino podem ter um aumento na latência e no tempo de retorno (RTT) enquanto o failover estiver ativo.
- Failback: depois que as verificações de integridade forem bem-sucedidas novamente, o Cloud DNS vai restaurar automaticamente o tráfego para o balanceador de carga principal sem inatividade, porque os dois balanceadores de carga estão exibindo tráfego.
Estratégia ativo-ativo (desvio global para regional)
Em uma estratégia ativo-ativo, o balanceador de carga de aplicativo externo global usa um NEG de FQDN da Internet (INTERNET_FQDN_PORT) para enviar tráfego a balanceadores de carga de aplicativo externos regionais em duas ou mais regiões.
Como funciona o desvio ativo-ativo
A configuração a seguir demonstra o failover de um balanceador de carga de aplicativo externo global para dois balanceadores de carga de aplicativo externos regionais de backup, com um em cada região em que o balanceador de carga global implantou back-ends.
O failover ativo-ativo segue este fluxo de trabalho:
- Estado estável: o tráfego flui do cliente para o balanceador de carga de aplicativo externo global.
O balanceador de carga global usa um grupo de endpoints de rede (NEG) de FQDN da Internet do tipo
INTERNET_FQDN_PORTpara encaminhar o tráfego aos balanceadores de carga de aplicativo externos regionais mais próximos. Em seguida, os balanceadores de carga regionais entregam o tráfego para os back-ends locais. - Detecção de falhas: em estado estável, se um único balanceador de carga de aplicativo externo regional ou a região dele falhar, o balanceador de carga de aplicativo externo global detectará a falha usando a política de verificação de integridade do Cloud DNS no NEG da Internet. O balanceador de carga global encaminha automaticamente o tráfego da região não íntegra para balanceadores de carga regionais íntegros.
- Ignorar: se o balanceador de carga de aplicativo externo global tiver uma interrupção, as políticas de failover do Cloud DNS vão detectar a falha e rotear o tráfego diretamente para os balanceadores de carga de aplicativo externos regionais, ignorando completamente a camada global. Impacto na latência durante o desvio: o balanceador de carga de aplicativo externo global oferece benefícios de desempenho de borda, como o encerramento de conexões mais próximas dos usuários e o armazenamento em cache de borda. Quando o tráfego ignora o balanceador de carga global, as conexões do cliente são estabelecidas diretamente com os VIPs regionais, o que pode aumentar a latência da conexão e o RTT para clientes geograficamente distantes.
- Failback: quando o balanceador de carga global passa por verificações de integridade consecutivas, o Cloud DNS retoma automaticamente o retorno do VIP de Anycast global nas respostas de DNS, restaurando o nível de roteamento de borda global.
Revisar a configuração do balanceador de carga principal
Antes de configurar o failover, confirme se o balanceador de carga de aplicativo externo regional de backup é compatível com os recursos usados pelo balanceador de carga principal.
- No modo ativo-passivo, o balanceador de carga regional de backup precisa oferecer suporte a recursos semelhantes para assumir o tráfego sem problemas durante uma interrupção.
- No modo ativo-ativo, as regras de roteamento e segurança principais precisam ser configuradas diretamente no nível regional, enquanto os recursos de borda global, como o Cloud CDN, são ignorados durante uma interrupção global.
| Recurso | Requisitos de compatibilidade |
|---|---|
| Implantações do Google Kubernetes Engine | Use o gateway do GKE para implantar os balanceadores de carga principais e de backup. Isso ocorre porque os balanceadores de carga implantados com o gateway do GKE são mais compatíveis com esse mecanismo de failover do que os balanceadores de carga que usam o controlador de entrada do GKE. O controlador de Ingress do GKE oferece suporte apenas ao balanceador de carga de aplicativo clássico. |
| Cloud CDN | Os balanceadores de carga de aplicativo externos regionais não são compatíveis com o Cloud CDN. Se ocorrer um failover, as operações que dependem do Cloud CDN serão afetadas. |
| Cloud Armor | Se você usa o Cloud Armor no balanceador de carga principal, configure políticas de segurança regionais equivalentes do Cloud Armor nos balanceadores de carga de backup. O Cloud Armor tem diferentes recursos disponíveis no escopo regional e global. Para mais informações, consulte Políticas de segurança regionais do Cloud Armor e Políticas de segurança globais do Cloud Armor. |
| Certificados SSL | Verifique se o tipo de certificado SSL usado pelo balanceador de carga principal é compatível com o balanceador de carga de aplicativo externo regional de backup. Analise as diferenças entre os certificados SSL disponíveis com balanceadores de carga globais, regionais e clássicos. Para mais informações, consulte Certificados SSL do Compute Engine e Certificados SSL do Certificate Manager. |
Considerações sobre os balanceadores de carga regionais
Configure e implante balanceadores de carga de aplicativo externos regionais na região para onde você quer que o tráfego seja redirecionado em caso de falha.
Considere o seguinte para arquiteturas de failover ou bypass ao configurar o balanceador de carga regional:
É necessário configurar os recursos do balanceador de carga de aplicativo externo regional de backup para que sejam o mais semelhantes possível ao balanceador de carga principal, para que o tráfego seja processado de maneira semelhante nas duas implantações.
Balanceador de carga de aplicativo externo global. Os balanceadores de carga de aplicativo externos regionais dão suporte à maioria dos mesmos recursos dos balanceadores de carga de aplicativo externos globais, com algumas exceções. O balanceador de carga regional também oferece suporte aos mesmos recursos avançados de gerenciamento de tráfego do balanceador de carga global, o que facilita a equivalência entre os balanceadores de carga principal e de backup.
Balanceador de carga de aplicativo clássico. Com o balanceador de carga de aplicativo clássico, a paridade de recursos entre o balanceador de carga primário e o de backup é mais difícil de ser alcançada porque o Application Load Balancer externo regional é um balanceador de carga baseado no Envoy que processa o tráfego de forma diferente. Teste o failover e o failback completamente antes de implantar na produção.
Para conferir os recursos específicos dos balanceadores de carga de aplicativo regionais, globais e clássicos, consulte a página de comparação de recursos do balanceador de carga.
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 implantações primárias e de backup.
Os balanceadores de carga de aplicativo externos regionais dão suporte aos níveis de serviço de rede Premium e Standard. Se a latência não for sua principal preocupação durante o failover, recomendamos configurar os balanceadores de carga de aplicativo externos regionais de backup usando o nível padrão. O uso da infraestrutura do nível padrão oferece isolamento adicional em relação à infraestrutura do nível Premium usada pelos balanceadores de carga de aplicativo externos globais.
Verifique se a sub-rede somente proxy tem tamanho suficiente para acomodar o aumento de tráfego durante um evento de failover sem interromper outros balanceadores de carga regionais na mesma região e rede. Para mais detalhes, consulte Reservar capacidade adicional da sub-rede somente proxy.
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.
Reservar capacidade adicional da sub-rede somente proxy
Todos os balanceadores de carga regionais baseados no Envoy em uma região e rede VPC compartilham o mesmo pool de proxies do Envoy. Em um evento de failover, os balanceadores de carga de aplicativo externos regionais de backup têm um aumento no uso de proxy para processar o tráfego de failover do balanceador de carga principal. Reservar capacidade de proxy suficiente garante que os eventos de failover não interrompam outros balanceadores de carga regionais baseados no Envoy na mesma região e rede.
Para garantir que a capacidade esteja sempre disponível para os balanceadores de carga de backup, analise o tamanho da sua sub-rede somente proxy. Recomendamos que você calcule o número estimado de proxies necessários para uma determinada região e aumentar a capacidade, se necessário. Para mais informações sobre limites de capacidade de proxy e cálculos de dimensionamento, consulte a seção Cobrança de instância de proxy em "Preços do Cloud Load Balancing".
Se você estiver usando políticas de DNS para dividir o tráfego entre vários balanceadores de carga de backup em regiões diferentes, leve isso em consideração ao estimar os requisitos de proxy por região e rede. Uma sub-rede somente proxy maior permite que oGoogle Cloud atribua um número maior de proxies Envoy ao seu balanceador de carga quando necessário.
Não é possível expandir uma sub-rede somente de proxy da mesma maneira que você faria para um intervalo de endereços principal (com o comando expand-ip-range). Em vez disso, crie uma sub-rede somente de proxy alternativa que atenda às suas necessidades e depois a promova para o papel ativo.
Para saber como mudar o tamanho da sub-rede somente proxy, consulte Como alterar o tamanho ou o intervalo de endereços de uma sub-rede somente proxy.
Compartilhamento de back-ends entre balanceadores de carga principais e de backup
Para alcançar a redundância completa da infraestrutura, é necessário introduzir redundância no nível do balanceador de carga e no nível do back-end. Isso significa que você precisa configurar os balanceadores de carga de aplicativo externos regionais de backup com back-ends (grupos de instâncias ou de endpoints de rede) que não se sobrepõem aos balanceadores de carga principais.
Se você optar por usar os mesmos back-ends para os balanceadores de carga principais e de backup, crie cada balanceador de carga de aplicativo externo regional de backup na região em que esses back-ends estão localizados. Além disso, se o escalonamento automático estiver ativado para os grupos de instâncias, você precisará atender aos seguintes requisitos para ajudar a garantir que o failover ocorra:
- Configurar o escalonador automático apenas com escalonamento baseado em CPU. O escalonamento automático com base na utilização do balanceador de carga não é compatível.
- Os serviços de back-end globais e regionais precisam usar apenas o modo de balanceamento
UTILIZATION. Não use o modo de balanceamentoRATEporque suas instâncias poderão receber o dobro do tráfego de balanceadores de carga globais e regionais durante o processo de failover. - Configure os controles de redução de escala horizontal para impedir que o escalonador automático reduza prematuramente o grupo durante o tempo de inatividade, quando o tráfego está mudando do balanceador de carga global para o regional. Esse tempo de inatividade pode ser tão alto quanto a soma do TTL (time to live) do DNS mais o intervalo de verificação de integridade configurado.
A falha na configuração do escalonamento automático pode resultar em uma interrupção secundária durante o failover, porque a perda de tráfego do balanceador de carga global faz com que o grupo de instâncias encolha rapidamente antes que o balanceador de carga regional assuma o controle.
Configurar failover ativo-passivo
Para configurar o failover ativo-passivo, siga estas etapas:
- Revise as considerações de arquitetura: antes de criar recursos, revise as considerações para balanceadores de carga regionais para verificar a compatibilidade de recursos, a capacidade do proxy e os requisitos de escalonamento automático de back-end compartilhado.
- Configurar o balanceador de carga principal: configure o balanceador de carga de aplicativo externo global com serviços de back-end distribuídos em uma ou mais regiões. Para mais informações sobre como configurar um balanceador de carga de aplicativo externo global, consulte Configurar um balanceador de carga de aplicativo externo global.
- Analise a configuração do balanceador de carga principal: confirme se os recursos (como recursos de segurança, de gerenciamento de tráfego e de roteamento e Cloud CDN) usados pelo balanceador de carga principal estão disponíveis com o balanceador de carga de aplicativo externo regional de backup. Se atributos semelhantes estiverem indisponíveis, então esse balanceador de carga pode não ser um bom candidato para o failover.
- Configurar os balanceadores de carga de aplicativo externos regionais de backup: configure balanceadores de carga de aplicativo externos regionais independentes nas regiões em que você quer que o tráfego faça failover. 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 roteamento de DNS e as verificações de integridade: crie uma verificação de integridade para o balanceador de carga principal e configure uma política de roteamento de failover do Cloud DNS para detectar falhas e rotear o tráfego do cliente para balanceadores de carga regionais de backup.
Configurar o desvio ativo-ativo
Para configurar a arquitetura ativo-ativo, siga estas etapas:
Analise as considerações de arquitetura: antes de criar recursos, analise as considerações para balanceadores de carga regionais para verificar a compatibilidade de recursos e garantir que a capacidade da sub-rede somente proxy possa lidar com o tráfego de estado estável e de failover.
Configurar balanceadores de carga de aplicativo externos regionais: antes de configurar balanceadores de carga regionais, consulte Compatibilidade e limitações de recursos. Implante balanceadores de carga de aplicativo externos regionais em duas ou mais regiões com seus serviços de back-end, endereços IP externo, certificados SSL e políticas de segurança regionais do Cloud Armor. Para instruções de configuração, consulte Configurar um balanceador de carga de aplicativo externo regional com back-ends de grupos de instâncias de VM.
Configurar o DNS para balanceadores de carga regionais: crie um registro DNS (por exemplo,
regional-api.example.com) que aponte para os endereços IP externo dos balanceadores de carga de aplicativo externos regionais usando uma política de roteamento de geolocalização ou latência. Ative a verificação de integridade do DNS nesse registro para detectar uma falha em uma região específica e rotear automaticamente o tráfego para outras regiões íntegras.Configurar o balanceador de carga de aplicativo externo global: reserve um endereço IP externo global e crie um grupo de endpoints de rede (NEG) global da Internet do tipo
INTERNET_FQDN_PORT. Adicione um endpoint ao NEG da Internet que aponte para o FQDN do registro DNS regional, por exemplo,regional-api.example.com. Configure um serviço de back-end para o balanceador de carga de aplicativo externo global, anexe o NEG da Internet e ative o Cloud CDN ou o Cloud Armor, se necessário. Configure o mapa de URL, o proxy HTTP(S) de destino e a regra de encaminhamento global.Configure o DNS para failover e verificações de integridade: crie o registro DNS do serviço principal (por exemplo,
api.example.com) usando uma política de roteamentoFAILOVER. Verifique se o conjunto de registros tem um endpoint principal que aponta para o endereço IP do balanceador de carga de aplicativo externo global e endpoints de backup que apontam para os endereços IP externo dos balanceadores de carga de aplicativo externos regionais. Configure uma verificação de integridade de DNS para monitorar o balanceador de carga de aplicativo externo global.
Práticas recomendadas
Lembre-se das seguintes práticas recomendadas ao configurar o registro DNS do Cloud DNS e as verificações de integridade:
Calcular a duração da interrupção: o tempo necessário para o failover do tráfego dos balanceadores de carga principal para os de backup depende do 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 ThresholdDefina o TTL do DNS como 30 a 60 segundos. Valores de TTL mais altos levam a tempos de failover mais longos porque os clientes na Internet continuam acessando os balanceadores de carga de aplicativo externos principais mesmo após o failover do DNS para o balanceador de carga de aplicativo externo regional de backup.
Configure os limites da verificação de integridade: defina os parâmetros de limite íntegro e não íntegro para evitar failovers causados por erros de rede temporários. Limites mais altos aumentam o tempo que o tráfego leva para fazer failover para balanceadores de carga de backup.
Use o tráfego do trickle para validação: configure a flag
--backup-data-trickle-ratiopara enviar continuamente uma pequena porcentagem de tráfego aos balanceadores de carga de backup, mesmo quando os principais estiverem íntegros. Isso garante que a infraestrutura de backup esteja ativa e pronta para lidar com o tráfego. Configure a porcentagem do tráfego enviado aos balanceadores de carga de backup como uma fração de 0 a 1. O valor típico é 0, 1, embora o Cloud DNS permita que você envie 100% do tráfego para os endereços VIP de backup para acionar manualmente um failover.Teste o failover e o failback periodicamente: inclua testes de failover no seu plano de recuperação de desastres. Verifique as mudanças graduais e repentinas no tráfego dos balanceadores de carga primários para os de backup e se o tráfego retorna sem problemas para o balanceador de carga primário após o failback.