Nesta página, descrevemos como o failover funciona para balanceadores de carga de aplicativo externos. A configuração de failover envolve dois balanceadores de carga: um balanceador de carga principal e um balanceador de carga de backup. Para os fins desta discussão, o balanceador de carga principal é o balanceador de carga em que você quer configurar o failover. O balanceador de carga de backup é aquele que recebe conexões quando o balanceador de carga principal começa a falhar nas verificações de integridade.
Failover e failback são os processos automáticos que roteiam o tráfego de e para um balanceador de carga. Quando o Cloud DNS detecta uma interrupção e encaminha o tráfego do balanceador de carga principal para o backup, o processo é chamado de failover. Quando o Cloud DNS reverte isso e redireciona o tráfego para o balanceador de carga principal, o processo é chamado de failover.
Como funciona o failover
O failover global para regional de balanceadores de carga de aplicativo externos é processado criando dois ou mais balanceadores de carga de aplicativo externos regionais nas regiões para onde você quer que o tráfego seja redirecionado. Somente balanceadores de carga de aplicativo externos regionais podem ser usados como balanceadores de carga de backup. Os balanceadores de carga de aplicativo externos regionais não são apenas autocontidos em regiões individuais do Google Cloud, 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.
Os balanceadores de carga de aplicativo externos regionais funcionam melhor como balanceadores de carga de failover para balanceadores de carga de aplicativo externos globais porque ambos são baseados em proxies Envoy e processam o tráfego de maneiras muito semelhantes. Isso contrasta com um balanceador de carga de aplicativo clássico, que tem diferenças significativas na forma como o tráfego é gerenciado.
Em resumo, os seguintes cenários de failover são compatíveis:
- De um balanceador de carga de aplicativo externo global para um balanceador de carga de aplicativo externo regional
- De um balanceador de carga de aplicativo externo regional para um balanceador de carga de aplicativo regional externo
- De um balanceador de carga de aplicativo clássico para um balanceador de carga de aplicativo regional externo
Fluxo de trabalho de failover e failback
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, com um em cada região em que o balanceador de carga global implantou back-ends.
As seções a seguir descrevem um fluxo de trabalho típico com os diferentes componentes na configuração de failover.
Detectar falhas no balanceador de carga principal
O Google Cloud usa verificações de integridade para detectar se o balanceador de carga de aplicativo externo principal está em bom estado. 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 os clientes vão acessar o balanceador de carga. Por exemplo, se você tiver um balanceador de carga de aplicativo externo global e a maioria com origem na América do Norte e na Europa, é possível configurar sondagens com origem em duas regiões na América do Norte e em uma região na Europa.
Se as verificações de integridade originadas de duas ou mais dessas regiões falharem, isso aciona o failover para o balanceador de carga de aplicativo externo regional de backup.
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 de backup
Se o balanceador de carga principal começar a falhar nas verificações de integridade, o Google Cloud usará as políticas de roteamento de failover do Cloud DNS para determinar como rotear o tráfego para os balanceadores de carga de backup.
A duração da interrupção ou o tempo decorrido até o failover do tráfego o principal para balanceadores de carga de backup, é determinado pelo valor de TTL do DNS, o intervalo de verificação de integridade e o limite não íntegro de verificações de saúde. Para configurações recomendadas, consulte as Práticas recomendadas.
Failback para o balanceador de carga principal
Depois que as verificações de integridade começarem a ser aprovadas novamente, execute o failback para o balanceador de carga primário é automático. Não há inatividade esperada durante o failback porque os balanceadores de carga de backup e primário disponibilizam o tráfego.
Testar o failover periodicamente
Recomendamos que você teste periodicamente o fluxo de trabalho de failover como parte do seu plano de continuidade dos negócios. Teste mudanças graduais e instantâneas no tráfego de balanceadores de carga primários para balanceadores de carga de backup. Depois de verificar se o failover funciona, acione um failback para verificar se o tráfego é redirecionado de volta para o balanceador de carga principal, conforme o esperado.
Configurar failover
Para configurar o failover, siga estas etapas:
- Analise a configuração atual do balanceador de carga principal e verifique se os recursos (como recursos de segurança, de gerenciamento de tráfego e de roteamento e 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.
- Crie o balanceador de carga de aplicativo externo regional de backup com uma configuração que espelhe o balanceador de carga principal o máximo possível.
- Crie a verificação de integridade e a política de roteamento de DNS para detectar falhas e rotear o tráfego do balanceador de carga principal para o de backup durante a failover.
Revisar a configuração do balanceador de carga principal
Antes de começar, verifique se o balanceador de carga de aplicativo externo regional de backup oferece suporte a todos os recursos usados atualmente com o balanceador de carga principal.
Para evitar a interrupção do tráfego, analise as seguintes diferenças:
Implantações do GKE. Os usuários do GKE precisam saber que 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. Isso ocorre porque o Gateway do GKE dá suporte à configuração tanto dos balanceadores de carga de aplicativos externos globais quanto dos regionais. No entanto, o controlador de Ingress do GKE oferece suporte apenas ao balanceador de carga de aplicativo clássico.
Para melhores resultados, use o GKE Gateway para implantar os balanceadores de carga principais e de backup.
Cloud CDN. Os balanceadores de carga de aplicativo externos regionais não são compatíveis com o Cloud CDN. Portanto, em caso de falha, todas as operações que dependem do Cloud CDN também são afetadas. Para melhorar a redundância, recomendamos configurar uma solução de CDN de terceiros que possa funcionar como um substituto para o Cloud CDN.
Google Cloud Armor. Se você usa o Google Cloud Armor para o balanceador de carga principal, configure também os mesmos recursos do Google Cloud Armor ao configurar o backup do balanceador de carga de aplicativo externo regional. O Google Cloud Armor tem diferentes recursos disponíveis no escopo regional e global. Para mais informações, consulte as seguintes seções na documentação do Google Cloud Armor:
Certificados SSL. Se você quiser usar um certificado SSL comum para os balanceadores de carga primário e de backup, confirme se o tipo de certificado SSL usado com o balanceador de carga primário é 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. Veja mais detalhes nas próximas seções.
Buckets de back-end. Os balanceadores de carga de aplicativo externos regionais não dão suporte a buckets do Cloud Storage como back-ends. Não é possível configurar o failover para balanceadores de carga usando buckets de back-end.
Configurar o balanceador de carga de backup
O balanceador de carga de backup é um balanceador de carga de aplicativo externo regional que você configura na região em que quer que o tráfego seja redirecionado em caso de falha.
Considere o seguinte ao configurar o balanceador de carga de backup:
É 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.
Recomendamos que você configure balanceadores de carga de aplicativo externos regionais em cada região em que você tem back-ends. Por exemplo, se você fizer failover de uma implantação global com grupos de instâncias em cinco regiões para fazer backup de balanceadores de carga regionais em apenas três regiões, você corre o risco de sobrecarregar seus serviços de back-end nessas três regiões, enquanto os serviços de back-end nas duas regiões restantes estão inativos.
Além disso, recomendamos que você configure o Cloud DNS para usar round-robin ponderado de firewall ao redirecionar o failover do tráfego de um balanceador de carga global primário para essas cargas de balanceadores de carga HTTP(S) externos. Atribua pesos a cada balanceador de carga de backup considerando os tamanhos máximos dos grupos de instâncias de back-end em diferentes regiões.
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.
Se você quiser usar os mesmos back-ends para os balanceadores de carga principais e de backup, crie o balanceador de carga de aplicativo externo regional de backup na região em que os back-ends estão localizados. Se você ativou o escalonamento automático no back-end grupos de instâncias, é preciso cumprir os requisitos de compartilhamento back-ends em várias implantações.
Se necessário, reserve outros proxies Envoy para balanceadores de carga de aplicativo externos regionais para garantir que, em caso de failover, o tráfego adicional não interrompa outras implantações de balanceadores de carga na mesma região. 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. Para garantir que a capacidade esteja sempre disponível para os balanceadores de carga de backup, recomendamos que você 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. Isso também ajuda a garantir que os eventos de failover não interrompam outras cargas regionais baseadas no Envoy na mesma região e rede.
Geralmente, um proxy do balanceador de carga de aplicativo externo regional pode gerenciar até:
- 600 (HTTP) ou 150 (HTTPS) conexões novas por segundo
- 3.000 conexões ativas
- 1.400 solicitações por segundo
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 o Google 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.
No entanto, se você quiser compartilhar um grupo de instâncias de back-end entre os balanceadores de carga principais e secundários, e o escalonamento automático esteja ativado nos grupos de instância, é necessário atender aos seguintes requisitos para ajudar a garantir que o failover ocorra:
- O escalonador automático precisa ser configurado apenas com escalonamento baseado em CPU. O método de escalonamento baseado em utilização do balanceador de carga não é aceito.
- Os serviços de back-end globais e regionais precisam usar apenas o modo de balanceamento
UTILIZATION. O uso do modo de balanceamentoRATEnão é recomendado porque suas instâncias poderão receber o dobro do tráfego de balanceadores de carga globais e regionais durante o processo de failover. - É preciso configurar os controles de escalonamento vertical para impedir que o escalonador automático sofra uma redução prematura do 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 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.
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 os balanceadores de carga de backup.
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_PATHSubstitua:
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 realizadas. 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_THRESHOLDeUNHEALTHY_THRESHOLD: o número de sondagens sequenciais que precisam ser bem-sucedidas ou falhar para que a instância da VM seja considerada íntegra ou não íntegra. 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 omitido, o Google Cloud envia 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.
Crie um conjunto de registros do Cloud DNS e aplique uma política de roteamento a ele. A política de roteamento precisa ser configurada para resolver seu nome de 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 integridade, a um dos balanceadores de carga os endereços IP da regra de encaminhamento.
gcloud beta 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_RATIOSubstitua:
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) do conjunto de registros em número de segundos. Para valores recomendados, consulte Práticas recomendadas.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-namePRIMARY_LOAD_BALANCER_FORWARDING_RULE: o nome da regra de encaminhamento do balanceador de carga principal.BACKUP_REGION: as regiões em que os balanceadores de carga de backup são implantados.BACKUP_LOAD_BALANCER_IP_ADDRESS: os endereços IP da regra de encaminhamento dos balanceadores de carga de backup correspondentes a cada região.BACKUP_DATA_TRICKLE_RATIO: a proporção de tráfego a ser enviada aos balanceadores de carga de backup, mesmo quando o balanceador de carga principal está íntegro. A proporção precisa estar entre 0 e 1, como 0,1. O padrão é 0.
Práticas recomendadas
Confira algumas práticas recomendadas ao configurar o registro do Cloud DNS e as verificações de integridade:
O tempo que o tráfego leva para falhar do balanceador de carga principal para o de backup (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 saudável 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 ThresholdPara a configuração de failover, recomendamos definir 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 de aplicativo externos principais mesmo após o failover do DNS para o balanceador de carga de aplicativo externo regional de backup.
Configure os parâmetros de limite íntegro e não íntegro nas verificações de integridade para evitar failovers desnecessários causados por erros temporários. Limites mais altos aumentam o tempo que o tráfego leva para fazer failover para balanceadores de carga de backup.
Para ajudar a garantir que a configuração de failover funcione conforme esperado, configure a política de roteamento de DNS para sempre enviar uma pequena porcentagem do tráfego aos balanceadores de carga de backup, mesmo quando os principais estiverem íntegros. Isso pode ser feito usando o parâmetro
--backup-data-trickle-ratioao criar o conjunto de registros DNS.Configure a porcentagem do tráfego enviado ao backup como uma fração de 0 a 1. O valor típico é 0,1, embora o Cloud DNS permite que você envie 100% do tráfego para os endereços VIP de backup para acionar manualmente um failover.