Pode configurar um equilibrador de carga de rede de encaminhamento externo baseado em serviços de back-end para distribuir ligações entre instâncias de máquinas virtuais (VMs) em back-ends primários e, em seguida, mudar, se necessário, para a utilização de back-ends de failover. A comutação por falha oferece um método de aumentar a disponibilidade, ao mesmo tempo que lhe dá maior controlo sobre a forma de gerir a sua carga de trabalho quando as VMs de back-end principais não estão em bom estado.
Esta página descreve os conceitos e os requisitos específicos da comutação por falha para equilibradores de carga de rede de encaminhamento externo. Certifique-se de que conhece as informações conceptuais nos seguintes artigos antes de configurar a comutação por falha para o seu Network Load Balancer de encaminhamento externo:
- Vista geral do balanceador de carga de rede de encaminhamento externo
- Vista geral das verificações de saúde
É importante compreender estes conceitos porque a configuração da comutação por falha modifica o algoritmo de distribuição de tráfego padrão do balanceador de carga.
Por predefinição, quando adiciona um back-end ao serviço de back-end de um Network Load Balancer de passagem externo, esse back-end é um back-end principal. Pode designar um back-end como um back-end de alternativa quando o adiciona ao serviço de back-end do equilibrador de carga ou editando o serviço de back-end mais tarde. Os back-ends de failover só recebem ligações do equilibrador de carga depois de uma proporção configurável de VMs principais não passar nas verificações de estado.
Back-ends suportados
Os grupos de instâncias (geridos e não geridos) e os NEGs zonais (com GCE_VM_IP
pontos finais) são suportados como back-ends. Para simplificar, os exemplos nesta página mostram grupos de instâncias não geridos.
A utilização de grupos de instâncias geridos com o dimensionamento automático e a comutação por falha pode fazer com que o conjunto ativo faça repetidamente a comutação por falha e a comutação por falha de retorno entre os back-ends principal e de comutação por falha. OGoogle Cloud não impede que configure a comutação por falha com grupos de instâncias geridos, uma vez que a sua implementação pode beneficiar desta configuração.
Arquitetura
O exemplo seguinte representa um balanceador de carga de rede de encaminhamento externo com um back-end principal e um back-end de comutação por falha.
- O motor de processamento de dados principal é um grupo de instâncias não gerido em
us-west1-a. - O back-end de alternativa é um grupo de instâncias não gerido diferente em
us-west1-c.
O exemplo seguinte representa um balanceador de carga de rede de passagem externo com dois back-ends
principais e dois back-ends de alternativa, ambos distribuídos entre duas zonas na
região us-west1. Esta configuração aumenta a fiabilidade porque não depende de uma única zona para todos os backends principais ou de todos os backends de alternativa.
- Os back-ends principais são grupos de instâncias não geridos
ig-aeig-d. - Os back-ends de comutação por falha são grupos de instâncias não geridos
ig-beig-c.
Durante a comutação por falha, ambos os back-ends principais ficam inativos, enquanto as VMs em bom estado de funcionamento em ambos os back-ends de comutação por falha ficam ativas. Para uma explicação completa de como funciona a comutação por falha neste exemplo, consulte o exemplo de comutação por falha.
Grupos de instâncias e VMs de back-end
Os grupos de instâncias nos equilibradores de carga de rede de encaminhamento externo são back-ends principais ou back-ends de comutação por falha. Pode designar um back-end como um back-end de failover no momento em que o adiciona ao serviço de back-end ou editando o back-end depois de o adicionar. Caso contrário, os grupos de instâncias são primários por predefinição.
Pode configurar vários back-ends principais e vários back-ends de alternativa num único balanceador de carga de passagem externo adicionando-os ao serviço de back-end do balanceador de carga.
Uma VM principal é membro de um grupo de instâncias que definiu como um back-end principal. As VMs num back-end principal participam no conjunto ativo do balanceador de carga (descrito na secção seguinte), a menos que o balanceador de carga mude para usar os respetivos back-ends de failover.
Uma VM de cópia de segurança é um membro de um grupo de instâncias que definiu como um back-end de failover. As VMs num back-end de comutação por falha participam no conjunto ativo do equilibrador de carga quando as VMs principais ficam em mau estado. O número de VMs principais não íntegras que aciona a comutação por falha é uma percentagem configurável.
Limites
- Grupos de instâncias. Pode ter até 50 grupos de instâncias de back-end principais e até 50 grupos de instâncias de back-end de alternativa.
Conjunto ativo
O conjunto ativo é a coleção de VMs de back-end para as quais um Network Load Balancer de encaminhamento externo envia novas ligações. A associação de VMs de back-end no conjunto ativo é calculada automaticamente com base nos back-ends que estão em bom estado e nas condições que pode especificar, conforme descrito na Política de comutação por falha.
O conjunto ativo nunca combina VMs principais e VMs de cópia de segurança. Os exemplos seguintes clarificam as possibilidades de subscrição. Durante a comutação por falha, o conjunto ativo contém apenas VMs de cópia de segurança. Durante o funcionamento normal (failback), o conjunto ativo contém apenas VMs principais.
Comutação por falha e reversão
O failover e o failback são os processos automáticos que mudam as VMs de back-end para dentro ou para fora do conjunto ativo do equilibrador de carga. Quando Google Cloud remove VMs principais do conjunto ativo e adiciona VMs de alternativa saudáveis ao conjunto ativo, o processo chama-se alternativa. Quando Google Cloud inverte esta situação, o processo é denominado failback.
Política de comutação por falha
Uma política de alternativa é um conjunto de parâmetros que o Google Cloud usa para alternativa e recuperação. Cada balanceador de carga de passagem externo tem uma política de comutação por falha com várias definições:
- Rácio de comutação por falha
- Diminuir o tráfego quando todas as VMs de back-end estão em mau estado de funcionamento
- Drenagem da ligação na comutação por falha e na recuperação
Rácio de comutação por falha
Uma proporção de comutação por falha configurável determina quando Google Cloud faz uma comutação por falha ou uma reversão, alterando
a associação no conjunto ativo. O rácio pode estar entre 0.0 e 1.0, inclusive.
Se não especificar uma taxa de alternativa,o Google Ad Manager usa um valor predefinido de 0.0. Google Cloud É uma prática recomendada definir a taxa de comutação por falha para um número que funcione para o seu exemplo de utilização, em vez de depender desta predefinição.
| Condições | VMs no conjunto ativo |
|---|---|
|
Todas as VMs principais em bom estado |
Se, pelo menos, uma VM de cópia de segurança estiver em bom estado e:
|
Todas as VMs de cópias de segurança em bom estado |
| Quando todas as VMs principais e todas as VMs de cópia de segurança estão em mau estado e não configurou o equilibrador de carga para eliminar tráfego durante esta situação | Todas as VMs principais, como último recurso |
Os exemplos seguintes esclarecem a participação no conjunto ativo. Para ver um exemplo com cálculos, consulte o exemplo de alternativa.
- Uma taxa de comutação por falha de
1.0requer que todas as VMs principais estejam em bom estado. Quando pelo menos uma VM principal fica em mau estado, Google Cloud faz uma comutação por falha, movendo as VMs de cópia de segurança para o conjunto ativo. - Uma taxa de alternativa de
0.1requer que, pelo menos, 10% das VMs principais estejam em bom estado; caso contrário, Google Cloud faz uma alternativa. - Uma taxa de comutação por falha de
0.0significa que Google Cloud faz uma comutação por falha apenas quando todas as VMs principais estão em mau estado. A comutação por falha não ocorre se, pelo menos, uma VM principal estiver em bom estado.
Um Network Load Balancer de passagem externo distribui as ligações entre as VMs no conjunto ativo de acordo com o algoritmo de distribuição de tráfego.
Diminuir o tráfego quando todas as VMs de back-end estão em mau estado de funcionamento
Por predefinição, quando todas as VMs principais e de cópia de segurança estão em mau estado, Google Cloud distribui novas ligações entre todas as VMs principais. Faz isso como último recurso.
Se preferir, pode configurar o seu Network Load Balancer de encaminhamento externo para eliminar novas ligações quando todas as VMs principais e de cópia de segurança estiverem em mau estado.
Drenagem da ligação na comutação por falha e na recuperação
Quando a eliminação gradual de ligações está ativada para a política de comutação por falha, as ligações estabelecidas a instâncias nos grupos de instâncias principal ou de comutação por falha continuam a ser enviadas para as instâncias com as quais foram estabelecidas, mesmo após a comutação por falha ou a reversão, evitando assim a interrupção das ligações. Quando a eliminação gradual de ligações está desativada para a política de comutação por falha, todas as ligações existentes são terminadas imediatamente durante a comutação por falha ou a reversão.
Se o protocolo do seu balanceador de carga for TCP, o seguinte é verdadeiro:
Por predefinição, a drenagem de ligações está ativada. As sessões TCP existentes podem persistir nas respetivas VMs de back-end atuais, mesmo que a VM de back-end não esteja no conjunto ativo do equilibrador de carga.
Pode desativar a drenagem de ligações durante eventos de comutação por falha e recuperação. A desativação da drenagem de ligações durante a comutação por falha e a recuperação garante que todas as sessões TCP, incluindo as estabelecidas, são terminadas rapidamente. As ligações às VMs de back-end podem ser fechadas com um pacote de reposição de TCP.
A desativação da drenagem de ligações na comutação por falha e na recuperação é útil para cenários como os seguintes:
Aplicação de patches a VMs de back-end. Antes da aplicação de patches, configure as suas VMs principais para falharem nas verificações de funcionamento, de modo que o balanceador de carga execute uma comutação por falha. A desativação da drenagem de ligações garante que todas as ligações são movidas para as VMs de cópia de segurança de forma rápida e planeada. Isto permite-lhe instalar atualizações e reiniciar as VMs principais sem que as ligações existentes persistam. Após a aplicação de patches, Google Cloud pode fazer um failback quando um número suficiente de VMs primárias (conforme definido pela taxa de comutação por falha) passar nas respetivas verificações de estado.
VM de back-end única para consistência de dados. Se precisar de garantir que apenas uma VM é o destino de todas as ligações, desative a drenagem de ligações para que a mudança de uma VM principal para uma VM de yedekleme não permita que as ligações existentes persistam em ambas. Isto reduz a possibilidade de inconsistências nos dados, mantendo apenas uma VM de back-end ativa em qualquer altura.
Exemplo de comutação por falha
O exemplo seguinte descreve o comportamento de comutação por falha para o exemplo de Network Load Balancer de encaminhamento externo de várias zonas apresentado na secção arquitetura.
Os back-ends principais deste equilibrador de carga são os grupos de instâncias não geridos
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 de ambos os grupos de instâncias são VMs principais:
vm-a1emig-avm-a2emig-avm-d1emig-dvm-d2emig-d
Os backends de alternativa para este equilibrador de carga são os grupos de instâncias não geridos
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 de ambos os grupos de instâncias são VMs de cópia de segurança:
vm-b1emig-bvm-b2emig-bvm-c1emig-cvm-c2emig-c
Suponhamos que quer configurar uma política de comutação por falha para este equilibrador de carga de modo que as novas ligações sejam fornecidas às VMs de cópia de segurança quando o número de VMs primárias em bom estado for inferior a dois. Para o fazer, defina a taxa de comutação por falha como 0.5
(50%). Google Cloud usa a taxa de comutação por falha para calcular o número mínimo de VMs principais que têm de estar em bom estado de funcionamento multiplicando a taxa de comutação por falha pelo número de VMs principais: 4 × 0.5 = 2
Quando todas as quatro VMs principais estão em bom estado,o balanceador de carga Google Cloud distribui novas ligações por todas elas. Quando as VMs principais falham nas verificações de funcionamento:
Se
vm-a1evm-d1ficarem em mau estado, o Google Cloud distribui novas ligações entre as duas VMs primárias em bom estado restantes,vm-a2evm-d2, porque o número de VMs primárias em bom estado é, pelo menos, o mínimo.Se
vm-a2também falhar nas verificações de funcionamento, deixando apenas uma VM principal em bom estado,vm-d2, Google Cloud reconhece que o número de VMs principais em bom estado é inferior ao mínimo, pelo que executa uma comutação por falha. O conjunto ativo está definido para as quatro VMs de cópia de segurança em bom estado, e as novas ligações são distribuídas por essas quatro (nos grupos de instânciasig-beig-c). Apesar devm-d2permanecer em bom estado, é removida do conjunto ativo e não recebe novas ligações.Se
vm-a2recuperar e passar na verificação de estado, Google Cloud reconhece que o número de VMs principais em bom estado é, pelo menos, o mínimo de duas, pelo que executa uma reposição. O conjunto ativo está definido para as duas VMs principais em bom estado,vm-a2evm-d2, e as novas ligações são distribuídas entre elas. Todas as VMs de cópia de segurança são removidas do conjunto ativo.À medida que outras VMs principais recuperam e passam nas respetivas verificações de funcionamento, Google Cloud adiciona-as ao conjunto ativo. Por exemplo, se
vm-a1ficar em bom estado, Google Cloud define o conjunto ativo para as três VMs primárias em bom estado,vm-a1,vm-a2evm-d2, e distribui novas ligações entre elas.
O que se segue?
- Para configurar e testar um balanceador de carga de rede de encaminhamento externo que usa a comutação por falha, consulte o artigo Configurar a comutação por falha para balanceadores de carga de rede de encaminhamento externo.
- Para configurar e testar um balanceador de carga de rede de encaminhamento externo com um serviço de back-end, consulte o artigo Configure um balanceador de carga de rede de encaminhamento externo.