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.
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-aeig-d. - Os back-ends de failover são grupos de instâncias não gerenciadas
ig-beig-c.
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.
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 |
|---|---|
|
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 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.0requer 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.1exige 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.0significa 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.
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-a1emig-avm-a2emig-avm-d1emig-dvm-d2emig-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-b1emig-bvm-b2emig-bvm-c1emig-cvm-c2emig-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-a1evm-d1não forem íntegros, o Google Cloud distribuirá novas conexões entre as duas VMs principais íntegras restantes,vm-a2evm-d2, porque o número de VMs íntegras principais é pelo menos o mínimo.Se
vm-a2també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ânciasig-beig-c). Mesmo quevm-d2permaneça íntegra, ela será removida do pool ativo e não receberá novas conexões.Se
vm-a2se 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-a2evm-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-a1se tornar íntegra, o Google Cloud definirá o pool ativo com as três VMs principais íntegrasvm-a1,vm-a2evm-d2e distribuirá novas conexões entre elas.
A seguir
- Para configurar e testar um balanceador de carga TCP/UDP interno que usa failover, consulte Como configurar o failover para balanceamento de carga TCP/UDP interno.
- Para configurar e testar um balanceador de carga TCP/UDP interno, consulte Como configurar o balanceamento de carga TCP/UDP interno.
- Para solucionar problemas de failover com seu balanceador de carga TCP/UDP interno, consulte Solução de problemas de balanceamento de carga TCP/UDP interno.