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
.
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
eig-d
. - Os back-ends de failover são grupos de instâncias não gerenciadas,
ig-b
eig-c
.
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.
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 |
---|---|
|
Todas as VMs primárias íntegras |
Se pelo menos uma VM de backup for íntegra e:
|
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
emig-a
vm-a2
emig-a
vm-d1
emig-d
vm-d2
emig-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
emig-b
vm-b2
emig-b
vm-c1
emig-c
vm-c2
emig-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
evm-d1
se tornarem não íntegras, o GCP distribuirá novas conexões entre as duas VMs primárias íntegras restantes,vm-a2
evm-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ânciasig-b
eig-c
. Mesmo quevm-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
evm-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
evm-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.