Configure um balanceador de carga de rede de passagem 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.
Nesta página, descrevemos conceitos e requisitos específicos de failover para balanceadores de carga de rede de passagem interna. Certifique-se de ter familiaridade com as informações conceituais nos artigos a seguir antes de configurar o failover para balanceadores de carga de rede de passagem internos:
- Visão geral do balanceador de carga de rede de passagem interna
- Visão geral das verificações de integridade
É 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 de passagem interno.
Por padrão, quando você adiciona um back-end a um serviço de back-end do balanceador de carga de rede de passagem 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
No exemplo a seguir, você verá um balanceador de carga de rede de passagem interna 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 de rede de passagem 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
Grupos de instâncias não gerenciadas em balanceadores de carga de rede de passagem interna 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 de rede de passagem 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 de rede de passagem 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 de rede de passagem interna tem uma política de failover com várias configurações:
- Proporção de failover
- Tráfego em queda 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 de rede de passagem 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 de rede de passagem 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 de rede de passagem interna em 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 de rede de passagem interna que usa failover, consulte Configurar failover para balanceadores de carga de rede de passagem interna.
- Para configurar e testar um balanceador de carga de rede de passagem interna, consulte Configurar um balanceador de carga de rede de passagem interna.
- Para solucionar problemas de failover com o balanceador de carga de rede de passagem interna, consulte Resolver problemas em balanceadores de carga de rede de passagem interna.