Failover para balanceamento de carga interno TCP/UDP

Configure um balanceador de carga TCP/UDP interno para distribuir conexões entre instâncias de máquina virtual (VM, na sigla em inglês) em back-ends principais e depois troque para os back-ends de failover, se necessário. 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 principais não estiverem íntegras.

Veja nesta página os conceitos e requisitos específicos do failover para balanceadores de carga TCP/UDP internos. 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 TCP/UDP interno:

É 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 TCP/UDP interno.

Por padrão, quando você adiciona um back-end a um serviço de back-end do balanceador de carga TCP/UDP interno, ele é definido como principal. 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 TCP/UDP interno 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 TCP/UDP interno (clique para ampliar)
Exemplo simples de failover para balanceamento de carga TCP/UDP interno (clique para ampliar)

Veja no exemplo a seguir um balanceador de carga TCP/UDP interno com dois back-ends principais e dois de failover, ambos 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 TCP/UDP interno multizona (clique para ampliar)
Failover de balanceamento de carga TCP/UDP interno de 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 não gerenciadas no balanceamento de carga TCP/UDP interno 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 não gerenciadas serão principais por padrão.

É possível configurar vários back-ends principais e de failover em um único balanceador de carga TCP/UDP interno. 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 não íntegras que aciona o failover é uma porcentagem configurável.

Limites

  • VMs É possível ter até 250 VMs no conjunto ativo. Em outras palavras, os grupos de instâncias do back-end primário podem ter até 250 VMs primárias. Já os grupos de instâncias do back-end de failover podem ter até 250 VMs de backup.

  • Grupos de instâncias não gerenciadas: é possível ter até 50 grupos de instâncias de back-end principal e até 50 grupos de instâncias de back-end de failover.

Por exemplo, uma implantação máxima pode ter cinco back-ends primárias e de failover, com cada grupo de instâncias contendo 50 VMs.

Pool ativo

O pool ativo é o conjunto de VMs de back-end a que um balanceador de carga TCP/UDP interno envia novas conexões. A participação dessas VMs no pool ativo é processada automaticamente com base nos back-ends que são íntegros e nas condições especificadas, conforme descrito em Proporção 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 TCP/UDP interno 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 TCP/UDP interno 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 primárias e de backup não são íntegras, o Google Cloud distribui novas conexões somente entre as VMs primárias. Isso é só um último recurso. As VMs de backup são excluídas desta distribuição de conexões mais recente.

Se preferir, configure o balanceador de carga TCP/UDP interno 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

Com a diminuição de conexão, as sessões TCP atuais permanecem ativas por um período definido mesmo depois que as VMs de back-end se tornarem não íntegras. 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 permanecem em uma VM de back-end por até 300 segundos (5 minutos), mesmo que ela não seja íntegra ou 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 principal seja o destino de todas as conexões, desative a diminuição da conexão para que a migração de uma VM principal para uma de 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 TCP/UDP interno de várias zonas apresentado na seção Arquitetura.

Failover de balanceamento de carga TCP/UDP interno multizona (clique para ampliar)
Failover de balanceamento de carga TCP/UDP interno de 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