Para se proteger contra interrupções de infraestrutura ou erros de configuração, é possível criar estratégias de failover para balanceadores de carga de aplicativo externos globais. Essas estratégias usam balanceadores de carga de aplicativo externos regionais e encaminham o tráfego para eles de um balanceador de carga de aplicativo externo global para manter a alta disponibilidade durante interrupções ou erros de configuração da infraestrutura global.
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 de clientes 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 de 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 encaminhar 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 (bypass 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 encaminhar 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 global de back-end com reconhecimento de capacidade, prefira a estratégia ativo-ativo. No entanto, se o aplicativo exigir explicitamente o balanceamento de carga global de back-end 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 da 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 de estado de falha | Cliente → balanceador de carga de aplicativo externo regional → back-end. O serviço continua disponível, mas pode ter uma latência maior 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 continua disponível, mas pode ter uma latência maior 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, é necessário 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 em 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 da 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 em estado estável não as testa. | É possível aplicar 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 rotear automaticamente o tráfego para regiões íntegras. |
| Balanceamento de carga global de back-end | 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 processamento de dados simultaneamente porque o tráfego flui pelas camadas global e regional em estado estável. |
| Caso de uso recomendado | Cargas de trabalho que exigem balanceamento de carga global avançado de back-end e transbordamento de tráfego com base na capacidade em várias regiões. | Cargas de trabalho projetadas em torno do isolamento regional que usam a camada global para desempenho e armazenamento em cache de borda. |
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 ao lado do balanceador de carga de aplicativo externo global ou do balanceador de carga de aplicativo 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 de clientes para o balanceador de carga de aplicativo externo global.
- Detecção de falhas:o 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 vai 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 as 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 nos tempos de ida e volta (RTT) enquanto o failover está ativo.
- Failback: depois que as verificações de integridade forem aprovadas novamente, o Cloud DNS restaurará automaticamente o tráfego para o balanceador de carga principal sem tempo de inatividade porque os dois balanceadores de carga estão atendendo ao tráfego.
Estratégia ativo-ativo (bypass 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 bypass 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 aos 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 vai 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.
- Desvio: se o balanceador de carga de aplicativo externo global sofrer uma interrupção, as políticas de failover do Cloud DNS vão detectar a falha e encaminhar o tráfego diretamente para os balanceadores de carga de aplicativo externos regionais, ignorando completamente a camada global. Impacto na latência durante o bypass:o balanceador de carga de aplicativo externo global oferece benefícios de desempenho de borda, como encerramento de conexões mais próximas dos usuários e 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 de conexão e o RTT para clientes geograficamente distantes.
- Failback: quando o balanceador de carga global passa em verificações de integridade consecutivas, o Cloud DNS retoma automaticamente o retorno do VIP Anycast global em respostas de DNS, restaurando a camada 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 oferece suporte aos 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 principais de roteamento e segurança precisam ser configuradas diretamente na camada regional, enquanto os recursos globais de borda, como o Cloud CDN, são ignorados durante uma interrupção global.
| Recurso | Requisitos de compatibilidade |
|---|---|
| Implantações do Google Kubernetes Engine | Use o GKE Gateway para implantar os balanceadores de carga principais e de backup. Isso 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 implantados com 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 em que você quer que o tráfego seja redirecionado em caso de falha.
Considere o seguinte ao configurar seu balanceador de carga regional para arquiteturas de failover ou bypass:
É 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 do 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 lidar com o tráfego em uma determinada região e aumente a capacidade, se necessário. Para mais informações sobre limites de capacidade e cálculos de dimensionamento de proxy, 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 proxy de backup que atenda às suas necessidades e 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ê preferir 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, é necessário atender aos seguintes requisitos para ajudar a garantir que o failover ocorra:
- Configure o autoescalador apenas com o 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 escalonamento 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:
- Analise as considerações sobre arquitetura: antes de criar recursos, analise as considerações sobre balanceadores de carga regionais para verificar a compatibilidade de recursos, a capacidade de proxy e os requisitos de escalonamento automático de back-end compartilhado.
- Configure 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, gerenciamento de tráfego e 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.
- Configure 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 informações sobre 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.
- Configure 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 interrupções e rotear o tráfego do cliente para balanceadores de carga regionais de backup.
Configurar o bypass ativo-ativo
Para configurar a arquitetura ativo-ativo, siga estas etapas:
Analise as considerações sobre arquitetura: antes de criar recursos, analise as considerações sobre balanceadores de carga regionais para verificar a compatibilidade de recursos e garantir que a capacidade da sub-rede somente de proxy possa processar o tráfego de estado estável e de failover.
Configure 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.
Configure 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 de DNS nesse registro para detectar uma falha em uma região específica e rotear automaticamente o tráfego para outras regiões íntegras.Configure 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 apontando 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 URLs, 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 apontando para o endereço IP do balanceador de carga de aplicativo externo global e endpoints de backup apontando para os endereços IP externos 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
Confira algumas 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 do balanceador de carga principal para o 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 de 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 necessário para o tráfego 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 mudanças graduais e repentinas no tráfego de balanceadores de carga primários para de backup e se o tráfego retorna sem problemas para o balanceador de carga principal após o failback.