É possível configurar um balanceador de carga baseado em serviço de back-end para distribuir conexões entre instâncias de máquina virtual (VM, na sigla em inglês) no back-end principal e, em seguida, alternar, se necessário, para usar back-end failover. 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.
Nesta página, descrevemos conceitos e requisitos específicos de failover para balanceadores de carga de rede de passagem externa. Certifique-se de que você esteja familiarizado com as informações conceituais nos artigos a seguir antes de configurar o failover para o balanceador de carga de rede de passagem externa:
- Visão geral do balanceador de carga de rede de passagem externa
- 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.
Por padrão, quando você adiciona um back-end a um serviço de back-end do balanceador de carga de rede de passagem externo, 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.
Back-ends compatíveis
Grupos de instâncias (gerenciados e não gerenciados) e NEGs zonais (com endpoints
GCE_VM_IP) 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 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 externo 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 externo 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 em balanceadores de carga de rede de passagem externa 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 serão primários por padrão.
É possível configurar vários back-ends principais e de failover em um único balanceador de carga de rede de passagem externo. 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 primárias não íntegras que acionam o failover é uma porcentagem configurável.
Limites
- Grupos de instâncias. É 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.
Pool ativo
O pool ativo é o conjunto de VMs de back-end a que um balanceador de carga de rede de passagem externo 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 na Política 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 externo 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 externo 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 principais e de backup não são íntegras, o Google Cloud distribui novas conexões entre todas elas. Isso só é feito como último recurso.
Se preferir, configure o balanceador de carga de rede de passagem externo 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
Quando a diminuição da conexão estiver ativada para a política de failover, as conexões estabelecidas com instâncias nos grupos de instâncias principais ou de failover continuarão a ser enviadas para as instâncias com que foram estabelecidas, mesmo após o failover ou a falha, evitando assim as interrupções na conexão. Quando a diminuição de conexão é desativada para a política de failover, todas as conexões existentes são encerradas imediatamente durante o failover ou o failback.
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 podem permanecer nas VMs de back-end atuais mesmo que a VM de back-end 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. Isso permite 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 seja o destino de todas as conexões, desative a diminuição de conexão para que a migração de uma VM principal para uma 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 externo 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 externa que usa failover, consulte Como configurar failover para balanceadores de carga de rede de passagem externa.
- Para configurar e testar um balanceador de carga de rede de passagem externa com um serviço de back-end, consulte Configurar um balanceador de carga de rede de passagem externa.