Failover para balanceamento de carga da rede

É possível configurar um balanceador de carga de rede baseado em serviço de back-end para distribuir conexões entre instâncias de máquina virtual (VM, na sigla em inglês) no back-end principal e, em seguida, alternar, se necessário, para usar back-end failover. Com o failover, você garante um método para aumentar a disponibilidade e ter maior controle sobre como gerenciar a carga de trabalho quando as VMs de back-end primárias não estiverem íntegras.

Nesta página, você verá conceitos e requisitos específicos para failover para balanceadores de carga de rede. Certifique-se de que você esteja familiarizado com as informações conceituais nos artigos a seguir antes de configurar o failover para o balanceamento de carga de rede:

É importante entender esses conceitos porque a configuração do failover modifica o algoritmo de distribuição de tráfego padrão do balanceador de carga de rede.

Por padrão, quando você adiciona um back-end ao serviço de back-end do balanceador de carga de rede, ele é definido como primário. Para designá-lo como back-end de failover, faça isso quando adicioná-lo ao serviço de back-end do balanceador de carga ou edite esse serviço posteriormente. Os back-ends de failover só recebem conexões do balanceador de carga quando uma proporção de VMs primárias definida não é aprovada nas verificações de integridade.

Grupos de instâncias compatíveis

Os grupos de instâncias gerenciadas e não gerenciadas são compatíveis como back-ends. Para simplificar seu entendimento, nos exemplos desta página, são mostrados grupos de instâncias não gerenciadas.

O uso de grupos de instâncias gerenciadas com escalonamento automático e failover pode fazer o pool ativo realizar failover e failback repetidamente entre os back-ends principal e de failover. O Google Cloud não impede que você configure o failover com grupos de instâncias gerenciadas, porque sua implantação pode se beneficiar dessa configuração.

Arquitetura

Veja no exemplo simples a seguir um balanceador de carga de rede com um back-end primário e um de failover.

  • O back-end primário é um grupo de instâncias não gerenciadas em us-west1-a.
  • O back-end de failover é um grupo diferente de instâncias não gerenciadas em us-west1-c.
Exemplo simples de failover para balanceamento de carga de rede (clique para ampliar)
Exemplo simples de failover para balanceamento de carga de rede (clique para ampliar)

Veja no exemplo a seguir um balanceador de carga de rede com dois back-ends primários e dois de failover. Ambos estão distribuídos entre duas zonas na região us-west1. Essa configuração aumenta a confiabilidade porque todos os back-ends primários e de failover não dependem de uma única zona.

  • Os back-ends principais são grupos de instâncias não gerenciadas ig-a e ig-d.
  • Os back-ends de failover são grupos de instâncias não gerenciadas ig-b e ig-c.
Failover de balanceamento de carga de rede em várias zonas (clique para ampliar)
Failover de balanceamento de carga de rede em várias zonas (clique para ampliar)

Durante o failover, os dois back-ends principais ficam inativos, enquanto as VMs íntegras em ambos os back-ends de failover ficam ativas. Para uma explicação completa de como o failover funciona neste exemplo, consulte o exemplo de failover.

Grupos de instâncias de back-end e VMs

Os grupos de instâncias no balanceamento de carga de rede são back-ends primários ou de failover. Para designar um back-end de failover, faça isso quando adicioná-lo ao serviço de back-end ou edite-o depois dessa adição. Caso contrário, os grupos de instâncias serão primários por padrão.

É possível configurar vários back-ends primários e de failover em um único balanceador de carga de rede. Basta adicioná-los ao serviço de back-end do balanceador de carga.

Uma VM principal é membro de um grupo de instâncias definido como um back-end principal. A menos que o balanceador de carga passe a usar os back-ends de failover, as VMs em um back-end principal fazem parte do pool ativo do balanceador, descrito na próxima seção.

Uma VM de backup é participante de um grupo de instâncias definido como um back-end de failover. As VMs em um back-end de failover participam do pool ativo do balanceador de carga quando as VMs principais deixam de ser íntegras. O número de VMs primárias não íntegras que acionam o failover é uma porcentagem configurável.

Limites

  • Grupos de instâncias. É possível ter até 50 grupos de instâncias do back-end primário e até 50 grupos de instâncias do back-end de failover.

Pool ativo

O pool ativo é o conjunto de VMs de back-end a que um balanceador de carga de rede envia novas conexões. A associação dessas VMs no pool ativo é calculada automaticamente com base nos back-ends que são íntegros e nas condições especificadas, conforme descrito na Política de failover.

O pool ativo nunca combina VMs principais e VMs de backup. Os exemplos a seguir esclarecem as possibilidades de participação. Durante o failover, o pool ativo contém apenas VMs de backup. Durante a operação normal (failback), o pool ativo contém apenas VMs principais.

Pool ativo no failover e no failback (clique para ampliar)
Pool ativo no failover e no failback (clique para ampliar)

Failover e failback

O failover e o failback são processos automáticos que incluem e removem VMs de back-end no pool ativo do balanceador de carga. Quando o Google Cloud remove as VMs principais do pool ativo e adiciona VMs de failover íntegras a esse pool, o processo é chamado de failover. Quando o Google Cloud reverte esse processo, ele é chamado de failback.

Política de failover

Uma política de failover é um conjunto de parâmetros que o Google Cloud usa para failover e failback. Cada balanceador de carga de rede tem uma política de failover com várias configurações:

  • Proporção de failover
  • Descarte do tráfego quando todas as VMs de back-end não forem íntegras
  • Diminuição da conexão no failover e no failback

Proporção de failover

Uma proporção de failover configurável determina quando o Google Cloud realiza um failover ou failback, alterando a participação no pool ativo. A proporção pode ser um valor entre 0.0 e 1.0, inclusive. Se você não especificar uma proporção de failover, o Google Cloud usará um valor padrão de 0.0. É uma prática recomendada definir a proporção de failover como um número apropriado ao seu caso de uso em vez de depender desse padrão.

Condições VMs no pool ativo
  1. A proporção de failover (x) é != 0.0!
    A proporção de VMs principais íntegras é >= x.
  2. A proporção de failover (x) é = 0.0!
    O número de VMs principais íntegras é > 0.
Todas as VMs primárias íntegras
Se pelo menos uma VM de backup for íntegra e:
  1. A proporção de failover (x) é != 0.0!
    A proporção de VMs principais íntegras for < x.
  2. A proporção de failover for = 0.0.
    O número de VMs principais íntegras for = 0.
Todas as VMs de backup íntegras
Quando todas as VMs principais e de backup não forem íntegras, e você não tiver definido o balanceador de carga para descartar o tráfego nesse caso Todas as VMs primárias, como último recurso

Nos exemplos a seguir, a associação no pool ativo é esclarecida. Para um exemplo com cálculos, consulte o exemplo de failover.

  • Uma proporção de failover de 1.0 requer que todas as VMs primárias estejam íntegras. Quando pelo menos uma VM principal deixar de ser íntegra, o Google Cloud realizará um failover, movendo as VMs de backup para o pool ativo.
  • Uma proporção de failover de 0.1 exige que pelo menos 10% das VMs principais sejam íntegras; caso contrário, o Google Cloud realizará um failover.
  • Uma proporção de failover de 0.0 significa que o Google Cloud realiza um failover apenas quando todas as VMs principais não são íntegras. O failover não será feito se pelo menos uma VM primária for íntegra.

Um balanceador de carga de rede distribui conexões entre as VMs no pool ativo de acordo com o algoritmo de distribuição de tráfego.

Tráfego em queda quando todas as VMs de back-end não forem íntegras

Por padrão, quando todas as VMs principais e de backup não são íntegras, o Google Cloud distribui novas conexões entre todas elas. Isso só é feito como último recurso.

Se preferir, configure o balanceador de carga de rede para descartar novas conexões quando todas as VMs primárias e de backup não forem íntegras.

Diminuição da conexão no failover e no failback

Quando a diminuição da conexão estiver ativada para a política de failover, as conexões estabelecidas com instâncias nos grupos de instâncias principais ou de failover continuarão a ser enviadas para as instâncias com que foram estabelecidas, mesmo após o failover ou a falha, evitando assim as interrupções na conexão. Quando a diminuição de conexão é desativada para a política de failover, todas as conexões existentes são encerradas imediatamente durante o failover ou o failback.

Se o protocolo para seu balanceador de carga for TCP, o seguinte será verdadeiro:

  • Por padrão, a diminuição de conexão está ativada. As sessões TCP atuais podem permanecer nas VMs de back-end atuais mesmo que a VM de back-end não esteja no pool ativo do balanceador de carga.

  • É possível desativar a diminuição de conexão durante os eventos de failover e failback. Ao fazer isso, você garante que todas as sessões TCP, incluindo aquelas estabelecidas, sejam rapidamente encerradas. As conexões com as VMs de back-end podem ser encerradas com um pacote de redefinição TCP.

A desativação da diminuição de conexão no failover e no failback é útil nestes cenários:

  • Patches de VMs de back-end. Antes da aplicação de patches, configure as VMs principais para que as verificações de integridade falhem para que o balanceador de carga faça um failover. Ao desativar a diminuição de conexão, você garante que todas as conexões sejam movidas para as VMs de backup com rapidez e planejamento. Assim, é possível instalar atualizações e reiniciar as VMs primárias sem manter as conexões atuais. Depois da aplicação de patches, o Google Cloud poderá fazer um failback quando um número suficiente de VMs principais, conforme definido pela proporção de failover, for aprovado nas verificações de integridade.

  • VM de back-end única para consistência de dados. Se você precisa garantir que apenas uma VM seja o destino de todas as conexões, desative a diminuição de conexão para que a migração de uma VM principal para uma backup não permita que as conexões existentes persistam em ambas. Isso reduz a possibilidade de inconsistências nos dados ao manter apenas uma VM de back-end ativa em um determinado momento.

Exemplo de failover

Veja no exemplo a seguir o comportamento do failover para o exemplo de balanceador de carga de rede em várias zonas apresentado na seção Arquitetura.

Failover de balanceamento de carga de rede em várias zonas (clique para ampliar)
Failover de balanceamento de carga de rede em várias zonas (clique para ampliar)

Os back-ends principais deste balanceador de carga são os grupos de instâncias não gerenciadas ig-a em us-west1-a e ig-d em us-west1-c. Cada grupo de instâncias contém duas VMs. Todas as quatro VMs dos dois grupos de instâncias são VMs primárias:

  • vm-a1 em ig-a
  • vm-a2 em ig-a
  • vm-d1 em ig-d
  • vm-d2 em ig-d

Os back-ends de failover deste balanceador de carga são os grupos de instâncias não gerenciadas ig-b em us-west1-a e ig-c em us-west1-c. Cada grupo de instâncias contém duas VMs. Todas as quatro VMs dos dois grupos de instâncias são VMs backup:

  • vm-b1 em ig-b
  • vm-b2 em ig-b
  • vm-c1 em ig-c
  • vm-c2 em ig-c

Suponha que você queira configurar uma política de failover para esse balanceador de carga de modo que novas conexões sejam entregues a VMs de backup quando o número de VMs principais íntegras for menor que dois. Para isso, defina a proporção de failover como 0.5 (50%). O Google Cloud usa a proporção de failover para calcular o número mínimo de VMs principais que precisam ser íntegras multiplicando a proporção de failover pelo número de VMs principais: 4 × 0.5 = 2

Quando as quatro VMs principais estiverem íntegras, o Google Cloud distribuirá novas conexões para todas elas. Quando as verificações de integridade das VMs primárias falham:

  • Se vm-a1 e vm-d1 não forem íntegros, o Google Cloud distribuirá novas conexões entre as duas VMs principais íntegras restantes, vm-a2 e vm-d2, porque o número de VMs íntegras principais é pelo menos o mínimo.

  • Se vm-a2 também falhar nas verificações de integridade, deixando apenas uma VM principal íntegra, vm-d2, o Google Cloud reconhecerá que o número de VMs principais íntegras é menor que o mínimo, por isso fará um failover. O pool ativo é definido como as quatro VMs de backup íntegras, e as novas conexões são distribuídas entre elas (nos grupos de instâncias ig-b e ig-c). Mesmo que vm-d2 permaneça íntegra, ela será removida do pool ativo e não receberá novas conexões.

  • Se vm-a2 se recuperar e passar na verificação de integridade, o Google Cloud reconhecerá que o número de VMs principais íntegras precisa ser no mínimo dois e fará um failback. O pool ativo é definido como as duas VMs principais íntegras, vm-a2 e vm-d2, e novas conexões são distribuídas entre elas. Todas as VMs de backup serão removidas do pool ativo.

  • À medida que outras VMs principais são recuperadas e aprovadas nas verificações de integridade, o Google Cloud as adiciona ao pool ativo. Por exemplo, se vm-a1 se tornar íntegra, o Google Cloud definirá o pool ativo com as três VMs principais íntegras vm-a1, vm-a2 e vm-d2 e distribuirá novas conexões entre elas.

A seguir