Padrões de utilização de endereços IP flutuantes no Compute Engine

Last reviewed 2025-02-03 UTC

Este documento descreve como usar padrões de implementação de endereços IP flutuantes quando migrar aplicações para o Compute Engine a partir de um ambiente de rede no local. Este documento destina-se a engenheiros de rede, administradores de sistemas e engenheiros de operações que estão a migrar aplicações para oGoogle Cloud.

Também conhecidos como endereços IP partilhados ou virtuais, os endereços IP flutuantes são usados frequentemente para tornar os ambientes de rede no local altamente disponíveis. Com os endereços IP flutuantes, pode transmitir um endereço IP entre vários servidores físicos ou virtuais configurados de forma idêntica. Esta prática permite a comutação por falha ou a atualização do software de produção. No entanto, não pode implementar diretamente endereços IP flutuantes num ambiente do Compute Engine sem alterar a arquitetura para um dos padrões descritos neste documento.

O repositório do GitHub que acompanha este documento inclui implementações de exemplo para cada padrão que pode implementar automaticamente através do Terraform.

Endereços IP flutuantes em ambientes no local

Os endereços IP flutuantes são usados frequentemente em ambientes no local. Seguem-se alguns exemplos de utilização:

Existem várias formas de implementar endereços IP flutuantes num ambiente no local. Normalmente, os servidores que partilham endereços IP flutuantes também partilham informações de estado através de um mecanismo de sinal de pulsação. Este mecanismo permite que os servidores comuniquem o respetivo estado de funcionamento entre si. Também permite que o servidor secundário assuma o endereço IP flutuante após a falha do servidor principal. Este esquema é frequentemente implementado através do protocolo de redundância do router virtual, mas também pode usar outros mecanismos semelhantes.

Assim que é iniciada uma comutação por falha de um endereço IP, o servidor que assume o endereço IP flutuante adiciona o endereço à respetiva interface de rede. O servidor anuncia esta aquisição a outros dispositivos através da camada 2 enviando um frame do protocolo de resolução de endereços (ARP) gratuito. Em alternativa, por vezes, um protocolo de encaminhamento, como o Open Shortest Path First (OSPF), anuncia o endereço IP ao router de camada 3 a montante.

O diagrama seguinte mostra uma configuração típica num ambiente no local.

Ambiente local típico.

O diagrama anterior mostra como um servidor principal e um servidor secundário ligados ao mesmo comutador trocam informações de capacidade de resposta através de um mecanismo de sinal de pulsação. Se o servidor principal falhar, o servidor secundário envia um frame ARP gratuito para o comutador para assumir o endereço IP flutuante.

Usa uma configuração ligeiramente diferente com soluções de equilíbrio de carga no local, como o equilíbrio de carga de rede do Windows ou um equilíbrio de carga do Linux com resposta direta do servidor, como o IPVS. Nestes casos, o serviço também envia frames ARP gratuitos, mas com o endereço MAC de outro servidor como a origem ARP gratuita. Esta ação falsifica essencialmente as frames ARP e assume o endereço IP de origem de outro servidor.

Esta ação é realizada para distribuir a carga de um endereço IP entre diferentes servidores. No entanto, este tipo de configuração está fora do âmbito deste documento. Na maioria dos casos, quando são usados endereços IP flutuantes para o equilíbrio de carga no local, é preferível migrar para o Cloud Load Balancing.

Desafios com a migração de endereços IP flutuantes para o Compute Engine

O Compute Engine usa uma pilha de rede virtualizada numa rede de nuvem virtual privada (VPC), pelo que os mecanismos de implementação típicos não funcionam sem alterações naGoogle Cloud. Por exemplo, a rede VPC processa pedidos ARP na rede definida por software e ignora frames ARP gratuitos. Além disso, é impossível modificar diretamente a tabela de encaminhamento da rede VPC com protocolos de encaminhamento padrão, como OSPF ou Border Gateway Protocol (BGP). Os mecanismos típicos para endereços IP flutuantes baseiam-se em pedidos ARP processados pela infraestrutura de comutação ou baseiam-se em redes programáveis por OSPF ou BGP. Por conseguinte, os endereços IP não fazem failover através destes mecanismos emGoogle Cloud. Se migrar uma imagem de máquina virtual (VM) através de um endereço IP flutuante no local, o endereço IP flutuante não pode comutar em caso de falha sem alterar a aplicação.

Pode usar uma rede de sobreposição para criar uma configuração que permita a comunicação completa da camada 2 e a aquisição de IP através de pedidos ARP. No entanto, a configuração de uma rede de sobreposição é complexa e dificulta a gestão dos recursos de rede do Compute Engine. Essa abordagem também está fora do âmbito deste documento. Em alternativa, este documento descreve padrões para implementar cenários de comutação por falha num ambiente de rede do Compute Engine sem criar redes de sobreposição.

Para implementar aplicações altamente disponíveis e fiáveis no Compute Engine, use arquiteturas de escalabilidade horizontal. Este tipo de arquitetura minimiza o efeito de uma única falha de nó.

Este documento descreve vários padrões para migrar uma aplicação existente que usa endereços IP flutuantes de um ambiente no local para o Compute Engine, incluindo o seguinte:

A utilização de endereços IP de alias que se movem entre instâncias de VMs não é recomendada como mecanismo de comutação por falha, uma vez que não cumpre os requisitos de elevada disponibilidade. Em determinados cenários de falha, como um evento de falha zonal, pode não conseguir remover um endereço IP de alias de uma instância. Por conseguinte, pode não conseguir adicioná-lo a outra instância, o que torna a comutação por falha impossível.

Selecionar um padrão para o seu exemplo de utilização

Consoante os seus requisitos, um ou mais dos padrões descritos nesta solução podem ser úteis para implementar endereços IP flutuantes num ambiente no local.

Considere os seguintes fatores quando decidir que padrão lhe permite usar melhor uma aplicação:

  • Endereço IP interno flutuante ou endereço IP externo flutuante: a maioria das aplicações que requerem endereços IP flutuantes usa endereços IP internos flutuantes. Poucas aplicações usam endereços IP externos flutuantes, porque, normalmente, o tráfego para aplicações externas deve ser equilibrado em termos de carga.

    A tabela mais adiante nesta secção recomenda padrões que pode usar para endereços IP internos flutuantes e para endereços IP externos flutuantes. Para exemplos de utilização que dependem de endereços IP internos flutuantes, qualquer um destes padrões pode ser viável para as suas necessidades. No entanto, recomendamos que os exemplos de utilização que dependem de endereços IP externos flutuantes sejam migrados para um dos padrões que usam o equilíbrio de carga.

  • Protocolos de aplicação: se a sua VM usar apenas TCP e UDP, pode usar todos os padrões na tabela. Se usar outros protocolos além do IPv4 para estabelecer ligação, apenas alguns padrões são adequados.

  • Compatibilidade com a implementação ativo-ativo: algumas aplicações, ao usar endereços IP flutuantes no local, podem funcionar num modo de implementação ativo-ativo. Esta capacidade significa que não precisam necessariamente de uma comutação por falha do servidor principal para o servidor secundário. Tem mais opções de padrões para mover estes tipos de aplicações para o Compute Engine. As aplicações que requerem apenas um servidor de aplicações para receber tráfego em qualquer altura não são compatíveis com a implementação ativo-ativo. Só pode implementar estas aplicações com alguns padrões na tabela seguinte.

  • Comportamento de reposição após a recuperação da VM principal: quando a VM principal original é recuperada após uma comutação por falha, dependendo do padrão usado, o tráfego faz uma de duas coisas. Move-se imediatamente de volta para a VM principal original ou permanece na nova VM principal até que a reposição seja iniciada manualmente ou a nova VM principal falhe. Em todos os casos, apenas as ligações iniciadas recentemente voltam a falhar. As ligações existentes permanecem na nova VM principal até serem fechadas.

  • Compatibilidade com verificações de estado: se não conseguir verificar se a sua aplicação está a responder através das verificações de estado do Compute Engine, sem dificuldade, não pode usar alguns padrões descritos na tabela seguinte.

  • Grupos de instâncias: qualquer padrão com compatibilidade de verificação de funcionamento também é compatível com grupos de instâncias. Para recriar automaticamente instâncias com falhas, pode usar um grupo de instâncias gerido com autorreparação. Se as suas VMs mantiverem o estado, pode usar um grupo de instâncias gerido com estado. Se não for possível recriar automaticamente as suas VMs ou precisar de uma comutação por falha manual, use um grupo de instâncias não gerido e recrie manualmente as VMs durante a comutação por falha.

  • Mecanismos de sinal de pulsação existentes: se a configuração de alta disponibilidade para a sua aplicação já usar um mecanismo de sinal de pulsação para acionar a comutação por falha, como Heartbeat, Pacemaker ou Keepalived, pode usar alguns padrões descritos na tabela seguinte.

A tabela seguinte lista as capacidades de padrões. Cada padrão é descrito nas secções seguintes:

Nome do padrão Endereço IP Protocolos suportados Modo de implementação Failback Compatibilidade da verificação do estado da aplicação necessária Pode integrar o mecanismo de pulsação
Padrões que usam o balanceamento de carga
Balanceamento de carga ativo-ativo Interno ou externo Apenas TCP/UDP Ativo-ativo N/A Sim Não
Balanceamento de carga com comutação por falha e verificações de funcionamento expostas pela aplicação Interno ou externo Apenas TCP/UDP Ativo-passivo Imediato (exceto associações existentes) Sim Não
Balanceamento de carga com comutação por falha e verificações de funcionamento expostas por batimento cardíaco Interno ou externo Apenas TCP/UDP Ativo-passivo Configurável Não Sim
Padrões que usam Google Cloud rotas
Usar rotas ECMP Internos Todos os protocolos IP Ativo-ativo N/A Sim Não
Usar rotas de prioridade diferentes Internos Todos os protocolos IP Ativo-passivo Imediato (exceto associações existentes) Sim Não
Usar um mecanismo de sinal de pulsação para mudar o próximo salto da rota Internos Todos os protocolos IP Ativo-passivo Configurável Não Sim
Padrão com autocorreção
Usar uma única instância de autorrecuperação Internos Todos os protocolos IP N/A N/A Sim Não

A decisão sobre que padrão usar para o seu exemplo de utilização pode depender de vários fatores. A seguinte árvore de decisão pode ajudar a restringir as suas escolhas a uma opção adequada.

Uma árvore de decisão que ajuda a escolher um equilibrador de carga.

O diagrama anterior descreve os seguintes passos:

  1. Uma única instância de autocorreção oferece uma disponibilidade suficientemente boa para as suas necessidades?
    1. Se sim, consulte a secção Usar uma instância única de autocorreção mais adiante neste documento. A autorreparação usa um mecanismo num grupo de instâncias de VM para substituir automaticamente uma instância de VM com falhas.
    2. Em caso negativo, avance para o ponto de decisão seguinte.
  2. A sua aplicação precisa de protocolos além do IPv4 que não sejam TCP e UDP?
    1. Em caso afirmativo, avance para o ponto de decisão seguinte.
    2. Em caso negativo, avance para o ponto de decisão seguinte.
  3. A sua aplicação pode funcionar no modo ativo-ativo?
    1. Se sim e precisar de protocolos além do IPv4 que não sejam TCP e UDP, consulte a secção Usar trajetos de vários caminhos de custo igual (ECMP) mais adiante neste documento. Os percursos ECMP distribuem o tráfego entre os próximos saltos de todos os candidatos a percursos.
    2. Se sim e não precisar de protocolos além do IPv4, exceto TCP e UDP, consulte o artigo Balanceamento de carga ativo-ativo mais adiante neste documento. O balanceamento de carga ativo-ativo usa as suas VMs como back-ends para um balanceador de carga de TCP/UDP interno.
    3. Em caso negativo, avance para o ponto de decisão seguinte.
  4. A sua aplicação pode expor Google Cloud verificações de funcionamento?
    1. Se sim e precisar de protocolos além do IPv4 que não sejam TCP e UDP, consulte Balanceamento de carga com ativação pós-falha e verificações de estado expostas pela aplicação mais adiante neste documento. O balanceamento de carga com ativação pós-falha e verificações de funcionamento expostas pela aplicação usa as suas VMs como back-ends para um balanceador de carga de TCP/UDP interno. Também usa o endereço IP do balanceamento de carga de TCP/UDP interno como um endereço IP virtual.
    2. Se sim e não precisar de protocolos além do IPv4, exceto TCP e UDP, consulte a secção Usar rotas de prioridade diferentes mais adiante neste documento. A utilização de diferentes caminhos de prioridade ajuda a garantir que o tráfego flui sempre para uma instância principal, a menos que essa instância falhe.
    3. Se não e precisar de protocolos além do IPv4, TCP e UDP, consulte a secção Balanceamento de carga com ativação pós-falha e verificações de estado expostas a batimentos cardíacos mais adiante neste documento. No equilíbrio de carga com comutação por falha e padrão de verificações de funcionamento expostas por pulsação, as verificações de funcionamento não são expostas pela própria aplicação, mas por um mecanismo de pulsação em execução entre ambas as VMs.
    4. Se a resposta for não e NÃO PRECISAR de protocolos além do IPv4, exceto TCP e UDP, consulte a secção Usar um mecanismo de sinal de pulsação para mudar o próximo salto de uma rota mais adiante neste documento. A utilização de um mecanismo de sinal de pulsação para comutar o próximo salto de uma rota usa uma única rota estática com o próximo salto a apontar para a instância de VM principal.

Padrões que usam o balanceamento de carga

Normalmente, pode migrar a sua aplicação usando endereços IP flutuantes para uma arquitetura no Google Cloud que usa o Cloud Load Balancing. Pode usar um balanceador de carga de rede de encaminhamento interno, uma vez que esta opção se adequa à maioria dos exemplos de utilização em que o serviço migrado no local é apenas exposto internamente. Esta opção de equilíbrio de carga é usada para todos os exemplos nesta secção e nas implementações de exemplo no GitHub. Se tiver clientes a aceder ao endereço IP flutuante de outras regiões, selecione a opção de acesso global.

Se a sua aplicação comunicar através de protocolos baseados em IPv4, que não sejam TCP nem UDP, tem de escolher um padrão que não use o equilíbrio de carga. Esses padrões são descritos mais adiante neste documento.

Se a sua aplicação usar HTTP(S), pode usar um balanceador de carga de aplicações interno para implementar o padrão ativo-ativo.

Se o serviço que está a tentar migrar estiver disponível externamente, pode implementar todos os padrões abordados nesta secção através de um Network Load Balancer de encaminhamento externo. Para implementações ativo-ativo, também pode usar um balanceador de carga de aplicações externo, um proxy TCP, ou um proxy SSL se a sua aplicação usar protocolos e portas suportados por essas opções de balanceamento de carga.

Considere as seguintes diferenças entre as implementações baseadas em endereços IP flutuantes no local e todos os padrões baseados no equilíbrio de carga:

  • Tempo de comutação por falha: a sincronização do Keepalived com o ARP gratuito num ambiente no local pode comutar por falha um endereço IP em alguns segundos. No ambiente do Compute Engine, o tempo médio de recuperação da comutação por falha depende dos parâmetros que definir. Caso a instância de máquina virtual (VM) ou o serviço de instância de VM falhe, o tempo médio para a comutação por falha do tráfego depende de parâmetros de verificação de estado, como Check Interval e Unhealthy Threshold. Com estes parâmetros definidos com os respetivos valores predefinidos, a comutação por falha demora normalmente 15 a 20 segundos. Pode reduzir o tempo diminuindo os valores desses parâmetros.

    No Compute Engine, as comutações por falha dentro de zonas ou entre zonas demoram o mesmo tempo.

  • Protocolos e portas: numa configuração no local, os endereços IP flutuantes aceitam todo o tráfego. Escolha uma das seguintes especificações de porta na regra de encaminhamento interno para o balanceador de carga de rede de passagem interna:

    • Especifique, pelo menos, uma porta e, no máximo, cinco portas por número.
    • Especifique ALL para encaminhar o tráfego em todas as portas para TCP ou UDP.
    • Use várias regras de encaminhamento com o mesmo endereço IP para encaminhar uma combinação de tráfego TCP e UDP ou para usar mais de cinco portas com um único endereço IP:
      • Apenas TCP ou UDP e 1 a 5 portas: use uma regra de encaminhamento.
      • TCP e UDP e 1 a 5 portas: use várias regras de encaminhamento.
      • 6 ou mais portas e TCP ou UDP: use várias regras de encaminhamento.

  • Verificação de funcionamento: no local, pode verificar a capacidade de resposta da aplicação numa máquina das seguintes formas:

Balanceamento de carga ativo-ativo

No padrão de equilíbrio de carga ativo-ativo, as suas VMs são back-ends para um Network Load Balancer de passagem interno. Usa o endereço IP do Network Load Balancer de passagem interno como um endereço IP virtual. O tráfego é distribuído igualmente entre as duas instâncias de back-end. O tráfego pertencente à mesma sessão é encaminhado para a mesma instância de back-end, conforme definido nas definições de afinidade de sessão.

Use o padrão de balanceamento de carga ativo-ativo se a sua aplicação usar apenas protocolos baseados em TCP e UDP e não exigir a comutação por falha entre máquinas. Use o padrão num cenário em que as aplicações podem responder a pedidos consoante o conteúdo do próprio pedido. Se existir um estado da máquina que não esteja constantemente sincronizado, não use o padrão, por exemplo, numa base de dados principal ou secundária.

O diagrama seguinte mostra uma implementação do padrão de equilíbrio de carga ativo-ativo:

Como um cliente interno navega no padrão de equilíbrio de carga ativo-ativo.

O diagrama anterior mostra como um cliente interno acede a um serviço que é executado em duas VMs através de um Network Load Balancer de passagem interno. Ambas as VMs fazem parte de um grupo de instâncias.

O padrão de balanceamento de carga ativo-ativo requer que o seu serviço exponha verificações de estado através de um dos protocolos de verificação de estado suportados para garantir que apenas as VMs responsivas recebem tráfego.

Para uma implementação de exemplo completa deste padrão, consulte a implementação de exemplo com o Terraform no GitHub.

Balanceamento de carga com comutação por falha e verificações de funcionamento expostas pela aplicação

Semelhante ao padrão ativo-ativo, o equilíbrio de carga através do padrão de verificações de estado expostas pela aplicação e de comutação por falha usa as suas VMs como back-ends para um equilibrador de carga de rede de passagem interno. Também usa o endereço IP do Network Load Balancer de encaminhamento direto interno como um endereço IP virtual. Para garantir que apenas uma VM recebe tráfego de cada vez, este padrão aplica-se à comutação por falha para equilibradores de carga de rede de encaminhamento interno.

Este padrão é recomendado se a sua aplicação tiver apenas tráfego TCP ou UDP, mas não suportar uma implementação ativa-ativa. Quando aplica este padrão, todo o tráfego flui para a VM principal ou para a VM de alternativa.

O diagrama seguinte mostra uma implementação do balanceamento de carga com failover e o padrão de verificações de funcionamento expostas pela aplicação:

Como um cliente interno navega num serviço atrás de um Network Load Balancer de passagem interno.

O diagrama anterior mostra como um cliente interno acede a um serviço através de um balanceador de carga de rede de passagem interna. Duas VMs estão em grupos de instâncias separados. Um grupo de instâncias é definido como um motor de processamento principal. O outro grupo de instâncias está definido como um back-end de failover para um Network Load Balancer de passagem interno.

Se o serviço na VM principal deixar de responder, o tráfego é comutado para o grupo de instâncias de failover. Assim que a VM principal voltar a responder, o tráfego é automaticamente redirecionado para o serviço de back-end principal.

Para uma implementação de exemplo completa deste padrão, consulte a implementação de exemplo com o Terraform no GitHub.

Balanceamento de carga com comutação por falha e verificações de funcionamento expostas por batimento cardíaco

O balanceamento de carga com o padrão de verificações de funcionamento expostas de heartbeat e com comutação por falha é igual ao padrão anterior. A diferença é que as verificações de saúde não são expostas pela própria aplicação, mas por um mecanismo de batimento cardíaco executado entre ambas as VMs.

O diagrama seguinte mostra uma implementação do balanceamento de carga com failover e o padrão de verificações de funcionamento expostas por heartbeat:

Como um cliente interno acede a um serviço atrás de um balanceador de carga interno com duas VMs em grupos de instâncias separados.

Este diagrama mostra como um cliente interno acede a um serviço através de um equilibrador de carga interno. Duas VMs estão em grupos de instâncias separados. Um grupo de instâncias é definido como um back-end principal. O outro grupo de instâncias está definido como um back-end de comutação por falha para um Network Load Balancer de passagem interno. O Keepalived é usado como um mecanismo de sinal de pulsação entre os nós de VM.

Os nós da VM trocam informações sobre o estado do serviço através do mecanismo de sinal de pulsação escolhido. Cada nó de VM verifica o seu próprio estado e comunica esse estado ao nó remoto. Consoante o estado do nó local e o estado recebido pelo nó remoto, um nó é eleito como o nó principal e um nó é eleito como o nó de cópia de segurança. Pode usar estas informações de estado para expor um resultado da verificação de estado que garante que o nó considerado principal no mecanismo de sinal de pulsação também recebe tráfego do Network Load Balancer de passagem interno.

Por exemplo, com o Keepalived, pode invocar scripts através das notify_master, notify_backup e notify_fault variáveis de configuração que alteram o estado da verificação de estado. Na transição para o estado principal (no Keepalived, este estado é denominado master), pode iniciar uma aplicação que escute numa porta TCP personalizada. Quando faz a transição para um estado de cópia de segurança ou de falha, pode parar esta aplicação. A verificação de funcionamento pode ser uma verificação de funcionamento TCP que tem êxito se esta porta TCP personalizada estiver aberta.

Este padrão é mais complexo do que o padrão que usa a comutação por falha com verificações de funcionamento expostas pela aplicação. No entanto, dá-lhe mais controlo. Por exemplo, pode configurá-lo para reverter imediatamente ou manualmente como parte da implementação do mecanismo de sinal de pulsação.

Para uma implementação de exemplo completa deste padrão que usa o Keepalived, consulte a implementação de exemplo com o Terraform no GitHub.

Padrões que usam Google Cloud rotas

Nos casos em que a sua aplicação usa protocolos diferentes de TCP ou UDP sobre o IPv4, pode migrar o seu endereço IP flutuante para um padrão baseado em rotas.

Nesta secção, as menções de rotas referem-se sempre a Google Cloud rotas que fazem parte de uma rede da VPC. As referências a trajetos estáticos referem-se sempre a trajetos estáticos no Google Cloud.

Usando um destes padrões, define várias rotas estáticas para um endereço IP específico com as diferentes instâncias como saltos seguintes. Este endereço IP torna-se o endereço IP flutuante que todos os clientes usam. Tem de estar fora de todos os intervalos de endereços IP de sub-rede da VPC, porque as rotas estáticas não podem substituir as rotas de sub-rede existentes. Tem de ativar o encaminhamento de endereços IP nas instâncias de destino. A ativação do encaminhamento de endereços IP permite-lhe aceitar tráfego para endereços IP não atribuídos às instâncias, neste caso, o endereço IP flutuante.

Se quiser que as rotas de endereços IP flutuantes estejam disponíveis a partir de redes VPC com peering, exporte rotas personalizadas para que as rotas de endereços IP flutuantes sejam propagadas a todas as redes VPC com peering.

Para ter conetividade a partir de uma rede nas instalações ligada através do Cloud Interconnect ou do Cloud VPN, tem de usar anúncios de rotas de endereços IP personalizados para que o endereço IP flutuante seja anunciado nas instalações.

Os padrões baseados no encaminhamento têm a seguinte vantagem em relação aos padrões baseados no equilíbrio de carga:

  • Protocolos e portas: os padrões baseados em rotas aplicam-se a todo o tráfego enviado para um destino específico. Os padrões baseados no equilíbrio de carga só permitem tráfego TCP e UDP.

Os padrões baseados em rotas têm as seguintes desvantagens em relação aos padrões baseados no equilíbrio de carga:

  • Verificação de funcionamento: não é possível anexar verificações de funcionamento a Google Cloud rotas. As rotas são usadas independentemente do estado dos serviços de VM subjacentes. Sempre que a VM está em execução, as rotas direcionam o tráfego para instâncias, mesmo que o serviço não esteja em bom estado. Anexar uma política de autocorreção a essas instâncias substitui as instâncias após um período de tempo não saudável que especificar. No entanto, assim que essas instâncias são reiniciadas, o tráfego é retomado imediatamente, mesmo antes de o serviço estar disponível. Esta lacuna de serviço pode originar potenciais erros de serviço quando as instâncias não íntegras continuam a publicar tráfego ou estão a ser reiniciadas.
  • Tempo de comutação por falha: depois de eliminar ou parar uma instância de VM, o Compute Engine ignora qualquer rota estática que a aponte. No entanto, uma vez que não existem verificações de estado nas rotas, o Compute Engine continua a usar a rota estática enquanto a instância estiver disponível. Além disso, a paragem da instância demora tempo, pelo que o tempo de comutação por falha é consideravelmente superior ao dos padrões baseados no equilíbrio de carga.
  • Apenas endereços IP flutuantes internos: embora possa implementar padrões usando o balanceamento de carga com um Network Load Balancer de passagem externo para criar um endereço IP flutuante externo, os padrões baseados em rotas só funcionam com endereços IP flutuantes internos.
  • Seleção de endereço IP flutuante: pode definir rotas apenas para endereços IP flutuantes internos que não fazem parte de nenhuma sub-rede. Não é possível substituir as rotas de sub-rede no Google Cloud. Monitorize estes endereços IP flutuantes para não os atribuir acidentalmente a outra rede.
  • Acessibilidade das rotas: para tornar os endereços IP flutuantes internos acessíveis a partir de redes no local ou redes com peering, tem de distribuir essas rotas estáticas, conforme descrito anteriormente.

Usar rotas de vários caminhos de custo igual (ECMP)

O padrão de rotas de vários caminhos de igual custo (ECMP) é semelhante ao padrão de equilíbrio de carga ativo-ativo. O tráfego é distribuído igualmente entre as duas instâncias de back-end. Quando usa rotas estáticas, o ECMP distribui o tráfego entre os próximos saltos de todos os candidatos a rotas através de um hash de cinco tuplos para afinidade.

Implemente este padrão criando duas rotas estáticas de igual prioridade com as instâncias do Compute Engine como saltos seguintes.

O diagrama seguinte mostra uma implementação do padrão de rotas ECMP:

Como um cliente interno acede a um serviço através de uma de duas rotas ECMP.

O diagrama anterior mostra como um cliente interno acede a um serviço através de um de dois caminhos com o próximo salto a apontar para as instâncias de VM que implementam o serviço.

Se o serviço numa VM deixar de responder, a autorreparação tenta recriar a instância que não responde. Assim que a autorreparação elimina a instância, a rota que aponta para a instância fica inativa antes de a nova instância ser criada. Assim que a nova instância existir, a rota que aponta para esta instância é usada automaticamente de imediato, e o tráfego é distribuído igualmente entre as instâncias.

O padrão de rotas ECMP requer que o seu serviço exponha verificações de estado através de protocolos suportados para que a autocura possa substituir automaticamente as VMs que não respondem.

Pode encontrar uma implementação de exemplo deste padrão com o Terraform no repositório do GitHub associado a este documento.

Usar rotas de prioridade diferentes

O padrão de trajetos de prioridade diferente é semelhante ao padrão anterior, exceto que usa trajetos estáticos de prioridade diferente para que o tráfego flua sempre para uma instância principal, a menos que essa instância falhe.

Para implementar este padrão, siga os mesmos passos no padrão de rotas ECMP. Ao criar os trajetos estáticos, atribua ao trajeto com o próximo salto a apontar para a instância principal um valor de prioridade inferior (trajeto principal). Atribua à instância com o próximo salto a apontar para a instância secundária um valor de prioridade mais elevado (rota secundária).

O diagrama seguinte mostra uma implementação do padrão de rotas de prioridade diferentes: Como um cliente interno que acede a um serviço usa uma rota principal ou secundária com base nas circunstâncias da rede.

O diagrama anterior mostra como um cliente interno que acede a um serviço usa uma rota principal com um valor de prioridade de 500 que aponta para a VM 1 como o próximo salto em circunstâncias normais. Está disponível uma segunda rota com um valor de prioridade de 1000 que aponta para a VM 2, a VM secundária, como o próximo salto.

Se o serviço na VM principal deixar de responder, a autorrecuperação tenta recriar a instância. Assim que a autocorreção elimina a instância e antes de a nova instância criada ficar disponível, a rota principal, com a instância principal como um próximo salto, fica inativa. Em seguida, o padrão usa a rota com a instância secundária como um salto seguinte. Assim que a nova instância principal estiver disponível, a rota principal volta a ficar ativa e todo o tráfego flui para a instância principal.

Tal como no padrão anterior, o padrão de caminho de prioridade diferente requer que o seu serviço exponha verificações de estado através de protocolos suportados para que a autorrecuperação possa substituir automaticamente as VMs que não respondem.

Pode encontrar uma implementação de exemplo deste padrão com o Terraform no repositório do GitHub que acompanha este documento.

Usar um mecanismo de sinal de pulsação para mudar o próximo salto de uma rota

Se a sua aplicação implementar um mecanismo de sinal de pulsação, como o Keepalived, para monitorizar a capacidade de resposta da aplicação, pode aplicar o padrão do mecanismo de sinal de pulsação para alterar o próximo salto da rota estática. Neste caso, usa apenas um único trajeto estático com o próximo salto a apontar para a instância de VM principal. Em caso de failover, o mecanismo de sinal de pulsação aponta o próximo salto da rota para a VM secundária.

O diagrama seguinte mostra uma implementação do mecanismo de sinal de pulsação para mudar o padrão de salto seguinte de um trajeto:

Como um cliente interno acede a um serviço onde a VM principal e secundária trocam informações de heartbeat.

O diagrama anterior mostra como um cliente interno acede a um serviço através de uma rota com o próximo salto a apontar para a VM principal. A VM principal troca informações de pulsação com a VM secundária através do Keepalived. Em caso de comutação por falha, o Keepalived chama uma função do Cloud Run que usa chamadas de API para direcionar o próximo salto para a VM secundária.

Os nós usam o mecanismo de sinal de pulsação escolhido para trocar informações entre si sobre o estado do serviço. Cada nó de VM verifica o seu próprio estado e comunica-o ao nó de VM remoto. Consoante o estado do nó de VM local e o estado recebido pelo nó remoto, um nó de VM é eleito como o nó principal e um nó de VM é eleito como o nó de cópia de segurança. Quando um nó se torna principal, direciona o próximo salto da rota para o endereço IP flutuante para si próprio. Se usar o Keepalived, pode invocar um script através da notify_master variável de configuração que substitui a rota estática através de uma chamada API ou da CLI Google Cloud.

O mecanismo de sinal de pulsação para mudar o padrão de próximo salto de uma rota não requer que as VMs façam parte de um grupo de instâncias. Se quiser que as VMs sejam substituídas automaticamente em caso de falha, pode colocá-las num grupo de instâncias de autorreparação. Também pode reparar e recriar manualmente VMs que não respondem.

A invocação do procedimento seguinte na comutação por falha garante que o tempo de comutação por falha é minimizado porque o tráfego comuta por falha após a conclusão de uma única chamada API no passo 1:

  1. Crie uma nova rota estática com o endereço IP flutuante como destino e a nova instância principal como o próximo salto. A nova rota deve ter um nome de rota diferente e uma prioridade de rota inferior (por exemplo, 400) à da rota original.
  2. Elimine a rota original para a VM principal antiga.
  3. Crie um trajeto com o mesmo nome e prioridade do trajeto que acabou de eliminar. Aponte-o para a nova VM principal como o próximo salto.
  4. Elimine a nova rota estática que criou. Não precisa de o fazer para garantir que o tráfego flui para a nova VM principal.

Uma vez que a rota original é substituída, apenas deve estar ativa uma rota de cada vez, mesmo quando existe uma rede dividida.

A utilização do mecanismo de sinal de pulsação para mudar o padrão de prioridade da rota em vez dos outros padrões baseados em rotas pode reduzir o tempo de comutação por falha. Não tem de eliminar nem substituir VMs através da autocura para a comutação por falha. Também lhe dá mais controlo sobre quando voltar ao servidor principal original depois de este voltar a responder.

Uma desvantagem do padrão é que tem de gerir o mecanismo de sinal de pulsação por si. A gestão do mecanismo pode levar a uma maior complexidade. Outra desvantagem é que tem de conceder privilégios para alterar a tabela de encaminhamento global às VMs que executam o processo de sinal de pulsação ou a uma função sem servidor chamada a partir do processo de sinal de pulsação. Alterar a tabela de encaminhamento global para uma função sem servidor é mais seguro, uma vez que pode reduzir o âmbito dos privilégios concedidos às VMs. No entanto, esta abordagem é mais complexa de implementar.

Para uma implementação de exemplo completa deste padrão com o Keepalived, consulte a implementação de exemplo com o Terraform no GitHub.

Padrão com autorreparação

Consoante os requisitos de tempo de recuperação, a migração para uma única instância de VM pode ser uma opção viável quando usa o Compute Engine. Esta opção é verdadeira mesmo que tenham sido usados vários servidores com um endereço IP flutuante no local. O motivo pelo qual este padrão pode ser usado por vezes, apesar de o número de VMs ter sido reduzido, é que pode criar uma nova instância do Compute Engine em segundos ou minutos, enquanto as falhas no local requerem normalmente horas ou até dias para serem corrigidas.

Usar uma única instância de autorrecuperação

Ao usar este padrão, confia no mecanismo de autorreparação num grupo de instâncias de VM para substituir automaticamente uma instância de VM com falhas. A aplicação expõe uma verificação de estado e, quando a aplicação não está em bom estado, a autocura substitui automaticamente a VM.

O diagrama seguinte mostra uma implementação do padrão de instância única de autocorreção:

Como um cliente interno se liga diretamente a uma instância do Compute Engine.

O diagrama anterior mostra como um cliente interno se liga diretamente a uma instância do Compute Engine colocada num grupo de instâncias geridas com um tamanho de 1 e com a autorreparação ativada.

Em comparação com os padrões que usam o equilíbrio de carga, o padrão de instância única de autocura tem as seguintes vantagens:

  • Distribuição de tráfego: existe apenas uma instância, pelo que a instância recebe sempre todo o tráfego.
  • Facilidade de utilização: uma vez que existe apenas uma instância, este padrão é o menos complicado de implementar.
  • Poupança de custos: usar uma única instância de VM em vez de duas pode reduzir o custo da implementação em metade.

No entanto, o padrão tem as seguintes desvantagens:

  • Tempo de comutação por falha: este processo é muito mais lento do que os padrões baseados no equilíbrio de carga. Depois de as verificações de estado detetarem uma falha da máquina, a eliminação e a recriação da instância com falha demoram, pelo menos, um minuto, mas, muitas vezes, demoram mais tempo. Este padrão não é comum em ambientes de produção. No entanto, o tempo de comutação por falha pode ser suficientemente bom para alguns serviços internos ou experimentais
  • Reação a falhas de zona: um grupo de instâncias gerido com um tamanho de 1 não sobrevive a uma falha de zona. Para reagir a falhas de zonas, considere adicionar um alerta do Cloud Monitoring quando o serviço falhar e criar um grupo de instâncias noutra zona em caso de falha de uma zona. Como não pode usar o mesmo endereço IP neste caso, use uma zona privada do Cloud DNS para aceder à VM e mude o nome DNS para o novo endereço IP.

Pode encontrar uma implementação de exemplo deste padrão com o Terraform no repositório do GitHub.

O que se segue?