Conceitos de failover para balanceamento de carga TCP/UDP interno

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 primários 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 primárias não estiverem íntegras.

Veja nesta página os conceitos e requisitos específicos do failover para balanceadores de carga TCP/UDP internos. Você precisa estar familiarizado com os conceitos dos documentos a seguir antes de configurar esse failover:

É 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.

Visão geral

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 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 primário e de failover. O GCP 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, e o de failover é outro grupo de instâncias não gerenciadas em us-west1-c.

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 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 primários 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)

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

Sobre VMs e grupos de instâncias de back-end

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 primários por padrão.

É possível configurar vários back-ends primários 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 primária é participante de um grupo de instâncias definido como um back-end primário. A menos que o balanceador de carga passe a usar os back-ends de failover, as VMs em um back-end primário 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 fazem parte do pool ativo do balanceador de carga quando uma proporção de VMs primárias definida se tornar não íntegra.

Limites

VMs: é possível ter até 250 VMs no pool 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 do back-end primário e até 50 grupos de instâncias do 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 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 em Proporção de failover.

O pool ativo nunca combina VMs primárias e de backup. Nos exemplos a seguir, as possibilidades de associação são esclarecidas. Durante o failover, o pool ativo contém apenas VMs de backup. Durante a operação normal, ou failback, o pool ativo contém apenas VMs primárias.

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 GCP remove as VMs primárias do pool ativo e adiciona VMs de failover íntegras a esse pool, o processo é chamado de failover. Quando o GCP reverte essa ação, o processo é chamado de failback.

Política de failover

Uma política de failover é um conjunto de parâmetros que o GCP usa no failover e no failback. Cada balanceador de carga TCP/UDP interno tem uma política de failover, mas ela conta com várias configurações como as seguintes:

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 GCP realiza um failover ou failback, alterando a associação no pool ativo. A proporção pode ser um valor entre 0.0 e 1.0. Se você não especificar uma proporção de failover, o GCP usará o valor padrão 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
A proporção de failover (x) é `!= 0.0`. A proporção de VMs primárias íntegras é `>= x`. A proporção de failover (x) é `= 0.0`. O número de VMs primárias íntegras é `> 0`.	Todas as VMs primárias íntegras
Se pelo menos uma VM de backup for íntegra e: A proporção de failover (x) for `!= 0.0`. A proporção de VMs primárias íntegras for `< x`. A proporção de failover for `= 0.0`. O número de VMs primárias íntegras for `= 0`.	Todas as VMs de backup íntegras
Quando todas as VMs primárias e de backup não forem íntegras, e você não tiver definido o balanceador de carga para descartar o tráfego durante esse caso	Todas as VMs primárias, como último recurso

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

A proporção de failover de 1.0 requer que todas as VMs primárias sejam íntegras. Quando pelo menos uma VM primária se tornar não íntegra, o GCP realizará um failover, movendo as VMs de backup para o pool ativo.
A proporção de failover de 0.1 requer que pelo menos 10% das VMs primárias sejam íntegras. Caso contrário, o GCP realizará um failover.
A proporção de failover de 0.0 indica que o GCP realizará um failover apenas quando todas as VMs primárias não forem í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.

Descarte do tráfego 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 GCP distribui novas conexões entre todas as VMs primárias. Isso só é feito como último recurso.

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 do seu balanceador de carga for TCP:

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 (10 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 em VMs de back-end: antes da aplicação de patches, configure as VMs primárias para falhar nas verificações de integridade para que o balanceador de carga realize 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 GCP poderá executar um failback quando um número suficiente de VMs primárias, conforme definido pela proporção de failover, for aprovado nas verificações de integridade.
Única VM de back-end para ter dados consistentes: se você precisa garantir que apenas uma VM primária seja o destino de todas as conexões, desative a diminuição de conexão. Assim, ao trocar de uma VM primária para uma de backup, as conexões atuais não serão mantidas 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 multizona apresentado na seção "Arquitetura".

Os back-ends primários desse 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 contém duas VMs, e todas elas são 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 desse 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 contém duas VMs, e todas elas são de backup:

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

Imagine que você queira configurar uma política de failover nesse balanceador de carga para que novas conexões sejam fornecidas a VMs de backup quando o número de VMs primárias íntegras for menor do que dois. Para isso, defina a proporção de failover como 0.5 (50%). O GCP usa essa proporção para calcular o número mínimo de VMs primárias que precisam ser íntegras, multiplicando a proporção de failover pelo número de VMs primárias: 4 × 0.5 = 2.

Quando as quatro VMs primárias são íntegras, o GCP distribui novas conexões para todas elas. Quando as verificações de integridade das VMs primárias falham:

Se vm-a1 e vm-d1 se tornarem não íntegras, o GCP distribuirá novas conexões entre as duas VMs primárias íntegras restantes, vm-a2 e vm-d2. Isso acontece porque o número de VMs primárias íntegras é o valor mínimo.
Se as verificações de integridade também falharem em vm-a2, restando apenas uma VM primária íntegra, vm-d2, o GCP reconhecerá que o número de VMs primárias íntegras é menor do que o valor mínimo. Por isso, o failover será executado. O pool ativo será definido como as quatro VMs de backup íntegras, e as novas conexões serão distribuídas entre elas nos grupos de instâncias ig-b e ig-c. Mesmo que vm-d2 continue íntegra, ela será removida do pool ativo e não receberá novas conexões.
Se vm-a2 se recuperar e for aprovada na verificação de integridade, o GCP reconhecerá que o número de VMs primárias íntegras é o valor mínimo de dois. Por isso, o failback será executado. O pool ativo será definido como as duas VMs primárias íntegras, vm-a2 e vm-d2, e novas conexões serão distribuídas entre elas. Todas as VMs de backup serão removidas do pool ativo.
À medida que outras VMs primárias se recuperam e são aprovadas nas verificações de integridade, o GCP as adiciona ao pool ativo. Por exemplo, se vm-a1 se tornar íntegra, o GCP definirá o pool ativo como as três VMs primárias íntegras, vm-a1, vm-a2 e vm-d2, e distribuirá novas conexões entre elas.

A seguir

Para noções básicas importantes, consulte Conceitos de balanceamento de carga TCP/UDP interno.
Consulte Balanceamento de carga interno e nomes do DNS para as opções de nome do DNS disponíveis que seu balanceador de carga pode usar.
Para um exemplo de configuração de balanceador de carga TCP/UDP interno, consulte esta página.
Para as etapas de configuração e um exemplo de configuração de failover do balanceador de carga TCP/UDP interno, consulte esta página.
Para mais informações sobre como configurar a geração de registros e o monitoramento do Stackdriver para o balanceamento de carga TCP/UDP interno, consulte esta página.
Para mais informações sobre como acessar balanceadores de carga TCP/UDP internos de redes de peering conectadas à rede VPC, consulte esta página.
Para mais informações sobre como solucionar problemas com o balanceador de carga TCP/UDP interno, consulte esta página.