Padrões para usar endereços IP flutuantes no Compute Engine

Last reviewed 2024-01-29 UTC

Neste documento, você verá como usar padrões de implementação de endereços IP flutuantes na migração de aplicativos para o Compute Engine a partir de um ambiente de rede local. Este documento destina-se a engenheiros de rede, administradores de sistemas e engenheiros de operações que estão migrando aplicativos para o Google Cloud.

Também conhecidos como endereços IP compartilhados ou virtuais, os endereços IP flutuantes costumam ser usados para tornar os ambientes de rede locais altamente disponíveis. Com endereços IP flutuantes, é possível transmitir um endereço IP entre vários servidores físicos ou virtuais configurados de maneira idêntica. Essa prática permite failover ou upgrade de software de produção. No entanto, não é possível implementar endereços IP flutuantes diretamente em um 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 exemplos de implantação para cada padrão que pode ser implantado automaticamente usando o Terraform.

Endereços IP flutuantes em ambientes locais

O uso de endereços IP flutuantes é comum em ambientes locais. Veja alguns exemplos de casos de uso:

Há várias maneiras de implantar endereços IP flutuantes em um ambiente local. Os servidores que compartilham endereços IP flutuantes normalmente também compartilham informações de estado por meio de um mecanismo de Heartbeat. Esse mecanismo permite que os servidores comuniquem o status de integridade uns aos outros; ele também permite que o servidor secundário assuma o endereço IP flutuante depois que o servidor principal falhar. Esse esquema é frequentemente implantado por meio do uso do Virtual Router Redundancy Protocol, mas também é possível usar outros mecanismos semelhantes.

Depois que um failover de endereço IP é iniciado, o servidor que assume o endereço IP flutuante adiciona o endereço à interface de rede dele. O servidor anuncia essa aquisição para outros dispositivos usando a Camada 2 por meio do envio de um frame gratuito de Protocolo de resolução de endereço (ARP). Como alternativa, às vezes um protocolo de roteamento, como o Open Shortest Path First (OSPF), divulga o endereço IP para o roteador upstream 3.

No diagrama a seguir, mostraremos uma configuração típica em um ambiente local.

Ambiente local típico

O diagrama anterior mostra como um servidor primário e um servidor secundário conectados à mesma chave de capacidade de resposta de troca por um mecanismo de Heartbeat. Se o servidor principal falhar, o servidor secundário enviará um frame ARP gratuito para a chave para assumir o endereço IP flutuante.

Você usa uma configuração um pouco diferente com soluções de balanceamento de carga no local, como o Windows Network Load Balancing ou um Linux Load Balancing com a resposta direta do servidor, como o IPVS. Nesses casos, o serviço também envia frames ARP gratuitos, mas com o endereço MAC de outro servidor como a origem ARP gratuita. Essencialmente, essa ação falsifica os frames ARP e assume o endereço IP de origem de outro servidor.

Esta ação é feita para distribuir a carga de um endereço IP entre diferentes servidores. No entanto, esse tipo de configuração está fora do escopo deste documento. Em quase todos os casos, ao usar endereços IP flutuantes para o balanceamento de carga local, a migração para o Cloud Load Balancing é preferível.

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

O Compute Engine usa uma pilha de rede virtualizada em uma rede de nuvem privada virtual (VPC). Portanto, mecanismos de implementação típicos não funcionam sem alterações no Google Cloud. Por exemplo, a rede VPC processa solicitações ARP na rede definida por software e ignora frames ARP gratuitos. Além disso, é impossível modificar diretamente a tabela de roteamento de rede VPC com protocolos de roteamento padrão, como OSPF ou Border Gateway Protocol (BGP). Os mecanismos típicos para endereços IP flutuantes dependem de solicitações ARP processadas pela troca de infraestrutura ou dependem de redes programáveis pelo OSPF ou BGP. Portanto, os endereços IP não fazem failover usando esses mecanismos no Google Cloud. Se você migrar uma imagem de máquina virtual (VM) usando um endereço IP flutuante local, esse endereço não poderá fazer o failover sem alterar o aplicativo.

Use 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 pelo uso de solicitações ARP. No entanto, configurar uma rede de sobreposição é complexo e dificulta o gerenciamento de recursos de rede do Compute Engine. Essa abordagem também está fora do escopo desse documento. Em vez disso, este documento descreve padrões para implementar cenários de failover em um ambiente de rede do Compute Engine sem criar redes de sobreposição.

Para implementar aplicativos altamente disponíveis e confiáveis no Compute Engine, use arquiteturas de escalonamento horizontal. Esse tipo de arquitetura minimiza o efeito de uma única falha do nó.

Neste documento, descrevemos vários padrões para migrar um aplicativo usando endereços IP flutuantes do local para o Compute Engine, incluindo os seguintes:

O uso de endereços IP de alias que se movem entre instâncias de VM não é recomendado como um mecanismo de failover porque não atende aos requisitos de alta disponibilidade. Em determinados cenários de falha, como um evento de falha zonal, talvez não seja possível remover um endereço IP de alias de uma instância. Portanto, talvez não seja possível adicioná-lo a outra instância, o que torna o failover impossível.

Como selecionar um padrão para seu caso de uso

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

Considere os seguintes fatores ao decidir o padrão mais adequado para usar um aplicativo:

  • Endereço IP interno flutuante ou externo flutuante: a maioria dos aplicativos que exige endereços IP flutuantes usam endereços IP flutuantes internos. Poucos aplicativos usam endereços IP externos flutuantes, porque normalmente o tráfego para aplicativos externos precisa ter balanceamento de carga.

    A tabela mais adiante nesta seção contém padrões que podem ser usados para endereços IP internos e externos flutuantes. Para casos de uso que dependem de endereços IP internos flutuantes, qualquer um desses padrões pode ser viável para suas necessidades. No entanto, recomendamos que os casos de uso que dependem de endereços IP externos flutuantes sejam migrados para um dos padrões que usam balanceamento de carga.

  • Protocolos de aplicativo: se a VM usa apenas TCP e UDP, use todos os padrões da tabela. Se ela usar outros protocolos em IPv4 para se conectar, apenas alguns padrões serão apropriados.

  • Compatibilidade com implantação ativa-ativa: alguns aplicativos, ao usar endereços IP flutuantes no local, podem funcionar em um modo de implantação ativo-ativo. Esse recurso significa que eles não exigem necessariamente o failover do servidor principal para o secundário. Há mais opções de padrões para mover esses tipos de aplicativo para o Compute Engine. Aplicativos que exigem apenas um servidor de aplicativos para receber tráfego a qualquer momento não são compatíveis com a implantação ativo-ativo. Só é possível implementar esses aplicativos com alguns padrões na tabela a seguir.

  • Comportamento de failback após a recuperação da VM principal: quando a VM primária original se recupera após um failover, dependendo do padrão usado, o tráfego realiza uma das seguintes ações: Ela é movida imediatamente de volta para a VM principal original ou permanece na nova VM principal até que o failback seja iniciado manualmente ou a nova VM principal falhe. Em todos os casos, apenas as conexões iniciadas recentemente falham. As conexões permanecem na nova VM principal até que sejam fechadas.

  • Compatibilidade da verificação de integridade: se não for possível verificar se o aplicativo é responsivo usando as verificações de integridade do Compute Engine, sem dificuldade, não será possível alguns padrões descritos na tabela a seguir.

  • Grupos de instâncias: qualquer padrão compatível com a verificação de integridade também é compatível com grupos de instâncias. Para recriar automaticamente instâncias com falha, use um grupo gerenciado de instâncias com recuperação automática. Se as VMs mantiverem o estado, será possível usar um grupo gerenciado de instâncias com estado. Se você não puder recriar automaticamente as VMs ou se precisar de failover manual, use um grupo não gerenciado de instâncias e recrie manualmente as VMs durante o failover.

  • Mecanismos de sinal de funcionamento: se a configuração de alta disponibilidade para seu aplicativo já usa um mecanismo de Heartbeat para acionar o failover, como o Heartbeat, o Pacemaker ou o Keepavital, é possível usar alguns padrões descritos na tabela a seguir.

A tabela a seguir lista os recursos de padrão. Cada aspecto é descrito nas seções a seguir.

Nome do padrão Endereço IP Protocolos compatíveis Modo de implantação Failback Compatibilidade de verificação de integridade do aplicativo necessária É possível integrar o mecanismo de sinal de funcionamento
Padrões que usam balanceamento de carga
Balanceamento de carga ativo-ativo Interno ou externo Somente TCP/UDP Ativo-ativo N/A Sim Não
Balanceamento de carga com failover e verificações de integridade expostas ao aplicativo Interno ou externo Somente TCP/UDP Ativo-passivo Imediata (exceto conexões existentes) Sim Não
Balanceamento de carga com failover e verificações de integridade expostas ao Heartbeat Interno ou externo Somente TCP/UDP Ativo-passivo Configurável Não Sim
Padrões que usam rotas do Google Cloud
Usar rotas ECMP Interno Todos os protocolos IP Ativo-ativo N/A Sim Não
Usar rotas de prioridade diferentes Interno Todos os protocolos IP Ativo-passivo Imediata (exceto conexões existentes) Sim Não
Como usar um mecanismo de sinal de funcionamento para trocar de rota no próximo salto Interno Todos os protocolos IP Ativo-passivo Configurável Não Sim
Padrão usando a recuperação automática
Usar uma instância única de recuperação automática Interno Todos os protocolos IP N/A N/A Sim Não

A decisão sobre qual padrão usar para seu caso de uso pode depender de vários fatores. A árvore de decisão a seguir pode ajudar a restringir suas escolhas a uma opção adequada.

Uma árvore de decisão que ajuda você a escolher um balanceador de carga.

O diagrama acima mostra as seguintes etapas:

  1. Uma única instância de recuperação automática oferece disponibilidade suficiente para suas necessidades?
    1. Em caso positivo, consulte Como usar uma instância única de recuperação automática mais adiante neste documento. A recuperação automática usa um mecanismo em um grupo de instâncias de VM para substituir automaticamente uma instância de VM com falha.
    2. Caso contrário, prossiga para o próximo ponto de decisão.
  2. Seu aplicativo precisa de protocolos em IPv4 além de TCP e UDP?
    1. Se sim, prossiga para o próximo ponto de decisão.
    2. Em caso negativo, prossiga para o próximo ponto de decisão.
  3. Seu aplicativo pode funcionar no modo ativo-ativo?
    1. Em caso positivo e se ele precisar de protocolos em IPv4 que não sejam TCP e UDP, consulte Usar rotas de vários caminhos de custo igual (ECMP) mais adiante neste documento. As rotas do ECMP distribuem o tráfego entre os próximos saltos de todos os candidatos de rota.
    2. Em caso positivo e se ele não precisar de protocolos em IPv4 que não sejam TCP e UDP, consulte Balanceamento de carga ativo-ativo mais adiante neste documento. O balanceamento de carga ativo-ativo usa suas VMs como back-ends para um balanceador de carga TCP/UDP interno.
    3. Caso contrário, prossiga para o próximo ponto de decisão.
  4. Seu aplicativo pode expor verificações de integridade do Google Cloud?
    1. Em caso positivo e se ele precisar de protocolos em IPv4 que não sejam TCP e UDP, consulte Balanceamento de carga com failover e verificações de integridade expostas ao aplicativo mais adiante neste documento. O balanceamento de carga com verificações de integridade de failover e de exposição de aplicativos usa suas VMs como back-ends para um balanceador de carga TCP/UDP interno. Ele também usa o endereço IP de balanceamento de carga TCP/UDP interno como um endereço IP virtual.
    2. Em caso positivo e se ele não precisar de protocolos em IPv4 que não sejam TCP e UDP, consulte Como usar rotas de prioridade diferentes mais adiante neste documento. O uso de rotas de prioridade diferentes ajuda a garantir que o tráfego sempre flua para uma instância principal, a menos que essa instância falhe.
    3. Em caso negativo e se ele precisar de protocolos em IPv4 que não sejam TCP e UDP, consulte Balanceamento de carga com failover e verificações de integridade expostas ao sinal de funcionamento mais adiante neste documento. No balanceamento de carga com failover e padrões de verificação de integridade expostos ao Heartbeat, as verificações de integridade não são expostas ao próprio aplicativo, mas a um mecanismo de Heartbeat em execução entre as duas VMs.
    4. Em caso negativo e se ele NÃO PRECISAR de protocolos em IPv4 que não sejam TCP e UDP, consulte Como usar um mecanismo de sinal de funcionamento para trocar o próximo salto de uma rota mais adiante neste documento. O uso de um mecanismo de Heartbeat para alternar o próximo salto de uma rota usa uma única rota estática com o próximo salto apontando para a instância de VM principal.

Padrões que usam balanceamento de carga

Normalmente, é possível migrar seu aplicativo usando endereços IP flutuantes para uma arquitetura no Google Cloud que usa o Cloud Load Balancing. Use um balanceador de carga de rede de passagem interna porque essa opção é adequada para a maioria dos casos de uso em que o serviço migrado no local só é exposto internamente. Essa opção de balanceamento de carga é usada em todos os exemplos desta seção e nas amostras de implantações no GitHub. Se você tiver clientes acessando o endereço IP flutuante de outras regiões, selecione a opção de acesso global.

Se o aplicativo se comunica por protocolos em IPv4, exceto TCP ou UDP, é preciso escolher um padrão que não use balanceamento de carga. Esses padrões são descritos posteriormente neste documento.

Se o aplicativo usar HTTP(S), use um balanceador de carga de aplicativo interno para implementar o padrão ativo-ativo.

Se o serviço que você está tentando migrar estiver disponível externamente, é possível implementar todos os padrões discutidos nesta seção usando um balanceador de carga de rede. Para implantações do tipo ativo-ativo, também é possível usar um balanceador de carga de aplicativo externo, um proxy TCP ou um proxy SSL quando o aplicativo usa protocolos e portas compatíveis com essas opções de balanceamento de carga.

Considere as seguintes diferenças entre as implementações locais baseadas em endereço IP flutuantes e todos os padrões baseados em balanceamento de carga:

  • Tempo de failover: o pareamento do KeepaLive com ARP gratuito em um ambiente local pode falhar por um endereço IP em alguns segundos. No ambiente do Compute Engine, o tempo médio de recuperação do failover depende dos parâmetros definidos. Caso a instância de máquina virtual (VM) ou o serviço de instância de VM falhe, o tráfego de tempo médio para failover depende dos parâmetros de verificação de integridade, como Check Interval e Unhealthy Threshold. Com esses parâmetros definidos nos valores padrão, o failover geralmente leva de 15 a 20 segundos. É possível reduzir o tempo diminuindo esses valores de parâmetro.

    No Compute Engine, os failovers dentro das zonas ou entre zonas levam o mesmo tempo.

  • Protocolos e portas: em uma 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 de uma a cinco portas, por número.
    • Especifique ALL para encaminhar 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 portas de 1 a 5: use uma regra de encaminhamento.
      • TCP e UDP e portas de 1 a 5: use várias regras de encaminhamento.
      • Seis portas ou mais e TCP ou UDP: use várias regras de encaminhamento.

  • Verificação de integridade: no local, é possível verificar a capacidade de resposta do aplicativo em uma máquina das seguintes maneiras:

Balanceamento de carga ativo-ativo

No padrão de balanceamento de carga ativo-ativo, as VMs são back-ends para um balanceador de carga de rede de passagem interna. Use o endereço IP do balanceador de carga de rede de passagem interna como 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 vai para a mesma instância de back-end, conforme definido nas configurações de afinidade da sessão.

Use o padrão de balanceamento de carga ativo-ativo se o aplicativo usar apenas protocolos baseados em TCP e UDP e não exigir failover entre máquinas. Use o padrão em um cenário em que os aplicativos possam responder a solicitações dependendo do conteúdo da própria solicitação. Se houver um estado de máquina que não é constantemente sincronizado, não use o padrão, por exemplo, em um banco de dados primário ou secundário.

No diagrama a seguir, mostramos uma implementação do padrão de balanceamento de carga ativo-ativo:

Como um cliente interno navega pelo padrão de balanceamento de carga ativo-ativo.

O diagrama anterior mostra como um cliente interno acessa um serviço executado em duas VMs por um balanceador de carga de rede de passagem interna. As duas VMs fazem parte de um grupo de instâncias.

O padrão de balanceamento de carga ativo-ativo exige que o serviço exponha verificações de integridade usando um dos protocolos de verificação de integridade compatíveis para garantir que apenas VMs responsivas recebam tráfego.

Para um exemplo completo de implementação desse padrão, consulte o exemplo de implantação com o Terraform no GitHub.

Balanceamento de carga com failover e verificações de integridade expostas ao aplicativo

Semelhante ao padrão ativo-ativo, o padrão de verificações de integridade com exposição ao aplicativo e balanceamento de carga através de failover usa as VMs como back-ends para um balanceador de carga de rede de passagem interna. Ele também usa o endereço IP do balanceador de carga de rede de passagem interna como endereço IP virtual. Para garantir que apenas uma VM receba tráfego por vez, esse padrão aplica o failover de balanceadores de carga de rede de passagem interna.

Esse padrão é recomendado se o aplicativo tiver apenas tráfego TCP ou UDP, mas não for compatível com uma implantação ativa-ativa. Quando você aplica esse padrão, todo o tráfego flui para a VM principal ou a de failover.

No diagrama a seguir, mostramos uma implementação do balanceamento de carga com failover e padrões de verificação de integridade expostos ao aplicativo:

Como um cliente interno navega por um serviço atrás de um balanceador de carga de rede de passagem interna.

O diagrama anterior mostra como um cliente interno acessa um serviço atrá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 back-end primário. O outro grupo de instâncias é definido como um back-end de failover para um balanceador de carga de rede de passagem interna.

Se o serviço na VM principal deixar de responder, o tráfego mudará para o grupo de instâncias de failover. Depois que a VM principal responde novamente, o tráfego volta automaticamente para o serviço de back-end primário.

Para um exemplo completo de implementação desse padrão, consulte o exemplo de implantação com o Terraform no GitHub.

Balanceamento de carga com failover e verificações de integridade expostas ao Heartbeat

O balanceamento de carga com failover e padrões de verificação de integridade expostos ao Heartbeat é o mesmo que o padrão anterior. A diferença é que as verificações de integridade não são expostas ao próprio aplicativo, mas a um mecanismo de Heartbeat em execução entre as duas VMs.

No diagrama a seguir, mostramos uma implementação do balanceamento de carga com o padrão de verificação de integridade exposta e de failover:

Como um cliente interno acessa 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 acessa um serviço por trás de um balanceador de carga interno. Duas VMs estão em grupos de instâncias separados. Um grupo de instâncias é definido como um back-end primário. O outro grupo de instâncias é definido como um back-end de failover para um balanceador de carga de rede de passagem interna. O Keepalived é usado como um mecanismo de sinal de funcionamento entre os nós da VM.

Os nós da VM trocam informações sobre o status do serviço usando o mecanismo de Heartbeat escolhido. Cada nó de VM verifica o próprio status e comunica esse status ao nó remoto. Dependendo do status do nó local e do status recebido pelo nó remoto, um nó é escolhido como o nó principal e um nó é escolhido como o nó de backup. Use essas informações de status para expor um resultado de verificação de integridade que garanta que o nó considerado principal no mecanismo de sinal de funcionamento também receba tráfego do balanceador de carga de rede de passagem interna.

Por exemplo, com o Keepalived, é possível invocar scripts usando as variáveis de configuração notify_master, notify_backup e notify_fault que alteram o status da verificação de integridade. Na transição para o estado principal (em Keepalive, esse estado é chamado de master), é possível iniciar um aplicativo que escute em uma porta TCP personalizada. Ao fazer a transição para um estado de backup ou falha, é possível interromper o aplicativo. A verificação de integridade pode ser uma verificação de integridade TCP bem-sucedida se essa porta TCP personalizada estiver aberta.

Esse padrão é mais complexo do que o padrão que usa failover com verificações de integridade expostas ao aplicativo. No entanto, ele oferece mais controle. Por exemplo, é possível configurá-lo para retornar de maneira imediata ou manual como parte da implementação do mecanismo de sinal de funcionamento.

Para ver um exemplo completo de implementação desse padrão que usa o Keepalive, consulte o exemplo de implantação com o Terraform no GitHub.

Padrões que usam rotas do Google Cloud

Nos casos em que o aplicativo usa protocolos diferentes de TCP ou UDP no IPv4, é possível migrar o endereço IP flutuante para um padrão com base nas rotas.

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

Usando um desses padrões, você define várias rotas estáticas para um endereço IP específico com as diferentes instâncias como próximos saltos. Esse endereço IP se tornará o endereço flutuante que todos os clientes usam. Ele precisa estar fora de todos os intervalos de endereços IP da sub-rede VPC porque rotas estáticas não podem substituir rotas de sub-rede atuais. É preciso ativar o encaminhamento de endereços IP nas instâncias de destino. Ativar o encaminhamento de endereço IP permite aceitar tráfego para endereços IP não atribuídos às instâncias. Nesse caso, o endereço IP flutuante.

Se você quiser que as rotas de endereço IP flutuante estejam disponíveis em redes VPC com peering, exporte rotas personalizadas para que as rotas de endereço IP flutuante sejam propagadas para todas as redes VPC com peering.

Para ter conectividade de uma rede local conectada por meio do Cloud Interconnect ou do Cloud VPN, você precisa usar divulgações de rota de endereço IP personalizado para que o endereço IP flutuante seja anunciado no local.

Os padrões baseados em rotas têm a seguinte vantagem sobre os padrões baseados em balanceamento de carga:

  • Protocolos e portas: os padrões baseados em rotas se aplicam a todo o tráfego enviado para um destino específico. Os padrões baseados em balanceamento 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 em balanceamento de carga:

  • Verificação de integridade: as verificações de integridade não podem ser anexadas a rotas do Google Cloud. As rotas são usadas independentemente da integridade dos serviços de VM subjacentes. Sempre que a VM está em execução, o tráfego é direcionado para as instâncias, mesmo que o serviço não esteja íntegro. Anexar uma política de recuperação automática a essas instâncias substitui as instâncias após um período não íntegro especificado por você. No entanto, depois que essas instâncias são reiniciadas, o tráfego é retomado imediatamente, mesmo antes do serviço ficar ativo. Essa lacuna de serviço pode levar a possíveis erros de serviço quando instâncias não íntegras ainda exibem tráfego ou estão sendo reiniciadas.
  • Tempo de failover: depois que você excluir ou interromper uma instância de VM, o Compute Engine desconsidera qualquer rota estática que aponte para essa instância. No entanto, como não há verificações de integridade nas rotas, o Compute Engine ainda usa a rota estática, desde que a instância ainda esteja disponível. Além disso, interromper a instância leva tempo, então o tempo de failover é consideravelmente maior do que com os padrões baseados em balanceamento de carga.
  • Somente endereços IP flutuantes internos: embora seja possível implementar padrões usando o balanceamento de carga com um balanceamento de carga de rede de passagem externa para criar um endereço IP flutuante externo, os padrões baseados em rotas funcionam apenas com endereços IP flutuantes internos.
  • Seleção de endereços IP flutuantes: é possível definir rotas somente para endereços IP flutuantes internos que não fazem parte de nenhuma sub-rede. As rotas de sub-rede não podem ser substituídas no Google Cloud. Acompanhe esses endereços IP flutuantes para que você não os atribua acidentalmente a outra rede.
  • Acessibilidade de rotas: para tornar os endereços IP flutuantes internos acessíveis por redes locais ou com peering, é necessário distribuir essas rotas estáticas conforme descrito anteriormente.

Como usar rotas com vários caminhos de custo igual (ECMP, na sigla em inglês)

O padrão de rotas de vários caminhos de custo igual (ECMP) é semelhante ao padrão de balanceamento de carga ativo-ativo. O tráfego é distribuído igualmente entre as duas instâncias de back-end. Quando você usa rotas estáticas, o ECMP distribui o tráfego entre os próximos saltos de todas as rotas candidatas usando um hash de cinco tuplas para afinidade.

Você implementa esse padrão criando duas rotas estáticas de prioridade igual com as instâncias do Compute Engine como próximos saltos.

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

Como um cliente interno acessa um serviço usando uma das duas rotas do ECMP.

O diagrama anterior mostra como um cliente interno acessa um serviço usando uma das duas rotas com o próximo salto apontando para as instâncias de VM que implementam o serviço.

Se o serviço em uma VM deixar de responder, a recuperação automática tentará recriar a instância não responsiva. Quando a recuperação automática exclui a instância, a rota que aponta para a instância fica inativa antes da nova instância ser criada. Depois que a nova instância existir, a rota apontada para ela será usada automaticamente e o tráfego será distribuído igualmente entre as instâncias.

O padrão de rotas ECMP requer que o serviço exponha verificações de integridade usando protocolos compatíveis para que a recuperação automática possa substituir automaticamente as VMs que não respondem.

Confira um exemplo de implementação desse padrão usando o Terraform no repositório do GitHub associado a este documento.

Usar rotas de prioridade diferentes

O padrão de rotas de prioridade diferente é semelhante ao padrão anterior. No entanto, ele usa rotas estáticas de prioridade diferente para que o tráfego sempre flua para uma instância principal, a menos que essa instância falhe.

Para implementar esse padrão, siga as mesmas etapas no padrão de rotas do ECMP. Ao criar as rotas estáticas, dê à rota com o próximo salto que aponte para a instância primária um valor de prioridade mais baixo (rota principal). Atribua à instância o próximo salto que aponte para a instância secundária um valor de prioridade mais alto (rota secundária).

O diagrama a seguir mostra uma implementação do padrão de rotas de prioridade diferente: Como um cliente interno acessando um serviço usa uma rota primária ou secundária com base nas circunstâncias da rede.

O diagrama anterior mostra como um cliente interno acessando 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. Uma segunda rota com um valor de prioridade de 1.000 está disponível apontando para a VM 2, a VM secundária, como o próximo salto.

Se o serviço na VM principal deixar de responder, a recuperação automática tentará recriar a instância. Depois que a recuperação automática exclui a instância e a nova instância que ela cria aparece, a rota principal, que tem a instância principal como próximo salto, fica inativa. Em seguida, o padrão usa a rota com a instância secundária como próximo salto. Quando a nova instância principal aparecer, a rota principal ficará ativa novamente, e todo o tráfego flui para a instância principal.

Como o padrão anterior, o padrão de rota de prioridade diferente exige que o serviço exponha verificações de integridade usando protocolos compatíveis para que a recuperação automática possa substituir as VMs que não respondem automaticamente.

Confira um exemplo de implementação desse padrão usando o Terraform no repositório do GitHub que acompanha este documento.

Usar um mecanismo de sinal de funcionamento para trocar o próximo salto de uma rota

Se o aplicativo implementar um mecanismo de sinal de funcionamento, como o Keepalive, para monitorar a capacidade de resposta do aplicativo, será possível aplicar o padrão do mecanismo de Heartbeat para mudar o próximo salto da rota estática. Nesse caso, você usa apenas uma rota estática com o próximo salto apontando para a instância de VM principal. Em failover, o mecanismo de Heartbeat aponta o próximo salto da rota para a VM secundária.

O diagrama a seguir mostra uma implementação do mecanismo de Heartbeat para alternar o padrão do próximo salto de uma rota:

Como um cliente interno acessa um serviço em que a VM primária e a secundária trocam informações de sinal de funcionamento.

O diagrama anterior mostra como um cliente interno acessa um serviço usando uma rota com o próximo salto que aponta para a VM principal. A VM principal troca informações de sinal de funcionamento com a VM secundária por meio do Keepalive. No failover, o Keepalive chama uma função do Cloud que usa chamadas de API para apontar o próximo salto na VM secundária.

Os nós usam o mecanismo de sinal de funcionamento escolhido para trocar informações sobre o status do serviço. Cada nó de VM verifica o próprio status e o comunica ao nó de VM remoto. Dependendo do status do nó da VM local e do status recebido pelo nó remoto, um nó de VM é eleito como o nó principal e um nó de VM é eleito como o nó de backup. Quando um nó se torna primário, ele aponta o próximo salto da rota para o próprio endereço IP flutuante. Ao usar o Keepalived, é possível invocar um script usando a variável de configuração notify_master que substitui a rota estática por meio de uma chamada de API ou da CLI do Google Cloud.

O mecanismo de Heartbeat para alternar o padrão do próximo salto de uma rota não exige que as VMs façam parte de um grupo de instâncias. Para que as VMs sejam substituídas automaticamente em caso de falha, coloque-as em um grupo de instâncias de recuperação automática. Também é possível reparar e recriar VMs manualmente.

Invocar o seguinte procedimento de failover garante que o tempo de failover seja minimizado, porque o tráfego faz failover depois que uma única chamada de API é concluída na Etapa 1:

  1. Crie uma nova rota estática com o endereço IP flutuante como o destino e a nova instância primária como o próximo salto. A nova rota precisa ter um nome de rota diferente e uma prioridade de rota mais baixa (400, por exemplo) que a rota original.
  2. Exclua a rota original para a VM principal antiga.
  3. Crie uma rota com o mesmo nome e a mesma prioridade da rota que você acabou de excluir. Aponte-o para a nova VM principal como o próximo salto.
  4. Exclua a nova rota estática que você criou. Você não precisa dele para garantir o fluxo de tráfego para a nova VM principal.

Como a rota original é substituída, apenas uma rota precisa estar ativa por vez, mesmo quando houver uma rede dividida.

Usar o mecanismo de sinal de funcionamento para alterar o padrão de prioridade da rota em vez dos outros padrões baseados em rota pode reduzir o tempo de failover. Não é preciso excluir e substituir VMs por meio da recuperação automática para failover. Isso também proporciona mais controle sobre quando retornar ao servidor principal original depois que ele ficar responsivo novamente.

Uma desvantagem do padrão é que você precisa gerenciar o mecanismo de sinal de funcionamento. Gerenciar o mecanismo pode aumentar a complexidade. Outra desvantagem é que você precisa conceder privilégios para alterar a tabela de roteamento global para as VMs que executam o processo de sinal de funcionamento ou uma chamada de função sem servidor do processo de sinal de funcionamento. Alterar a tabela de roteamento global para uma função sem servidor é mais seguro, já que reduz o escopo dos privilégios concedidos às VMs. No entanto, essa abordagem é mais complexa de implementar.

Para ver um exemplo completo de implementação desse padrão com o Keepalive, consulte o exemplo de implantação com o Terraform no GitHub.

Padrão usando a recuperação automática

Dependendo dos requisitos de tempo de recuperação, a migração para uma única instância de VM pode ser uma opção viável ao usar o Compute Engine. Essa opção é verdadeira, mesmo se vários servidores que usam um endereço IP flutuante forem usados no local. O motivo para que esse padrão possa ser usado às vezes, apesar do número de VMs estar sendo reduzida, é que é possível criar uma nova instância do Compute Engine em segundos ou minutos, enquanto a correção de falhas locais normalmente levam horas ou até mesmo dias.

Usar uma instância única de recuperação automática

Ao usar esse padrão, você conta com o mecanismo de recuperação automática em um grupo de instâncias de VM para substituir automaticamente uma instância de VM com falha. O aplicativo expõe uma verificação de integridade. Quando não está íntegro, a recuperação automática substitui automaticamente a VM.

O diagrama a seguir mostra uma implementação do padrão de instância única de recuperação automática:

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

O diagrama anterior mostra como um cliente interno se conecta diretamente a uma instância do Compute Engine colocada em um grupo de instâncias gerenciadas com tamanho 1 e a recuperação automática ativada.

Em comparação com os padrões que usam balanceamento de carga, o padrão de instância única de recuperação automática tem as seguintes vantagens:

  • Distribuição de tráfego: há apenas uma instância, portanto, a instância sempre recebe todo o tráfego.
  • Facilidade de uso: como há apenas uma instância, esse padrão é o menos complicado de implementar.
  • Economia de custos: usar uma única instância de VM em vez de duas pode reduzir pela metade o custo da implementação.

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

  • Tempo de failover: esse processo é muito mais lento do que os padrões baseados em balanceamento de carga. Depois que as verificações de integridade detectam uma falha na máquina, a exclusão e a recriação da instância com falha levam pelo menos um minuto, mas geralmente levam mais tempo. Esse padrão não é comum em ambientes de produção. No entanto, o tempo de failover pode ser bom o suficiente para alguns serviços internos ou experimentais
  • Reação a falhas de zona: um grupo de instâncias gerenciadas com tamanho 1 não sobrevive a falhas na zona. Para reagir a falhas de zona, adicione um alerta do Cloud Monitoring quando o serviço apresentar falha e crie um grupo de instâncias em outra zona após uma falha de zona. Como não é possível usar o mesmo endereço IP nesse caso, use uma zona particular do Cloud DNS para endereçar a VM e alternar o nome DNS para o novo endereço IP.

Veja um exemplo de implementação desse padrão usando o Terraform no repositório do GitHub.

A seguir