Pode configurar um balanceador de carga de rede de passagem interno para distribuir as ligações entre instâncias de máquinas virtuais (VM) em back-ends primários e, em seguida, mudar, se necessário, para usar back-ends de failover. A comutação por falha oferece um método de aumento da disponibilidade, ao mesmo tempo que lhe dá um 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 interno. Certifique-se de que conhece as informações conceptuais nos seguintes artigos antes de configurar a comutação por falha para equilibradores de carga de rede de encaminhamento interno:
- Vista geral do balanceador de carga de rede de encaminhamento interno
- 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 Network Load Balancer de passagem interna.
Por predefinição, quando adiciona um back-end ao serviço de back-end de um Network Load Balancer de passagem interno, 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.
Grupos de instâncias suportados
Os grupos de instâncias geridas e não geridas 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 comute por falha e volte a comutar por falha repetidamente entre os back-ends principal e de comutação por falha. Trusted Cloud by S3NS 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 simples seguinte representa um equilibrador de carga de rede de encaminhamento interno 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 encaminhamento interno com dois back-ends principais e dois back-ends de comutação por falha, 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.
Para mais informações sobre considerações específicas da região, consulte o artigo Geografia e regiões.
- 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 não geridos em equilibradores de carga de rede de encaminhamento interno são back-ends principais ou back-ends de alternativa. 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 não geridos são predefinidos.
Pode configurar vários back-ends principais e vários back-ends de comutação por falha num único balanceador de carga de passagem interno 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 não íntegras que aciona a comutação por falha é uma percentagem configurável.
Limites
VMs. Pode ter até 250 VMs no conjunto ativo. Por outras palavras, os seus grupos de instâncias de back-end principais podem ter um total de até 250 VMs principais, e os seus grupos de instâncias de back-end de failover podem ter um total de até 250 VMs de cópia de segurança.
Grupos de instâncias não geridos. Pode ter até 50 grupos de instâncias de back-end principais e até 50 grupos de instâncias de back-end de alternativa.
Por exemplo, uma implementação máxima pode ter 5 back-ends principais e 5 back-ends de comutação por falha, com cada grupo de instâncias a conter 50 VMs.
Conjunto ativo
O conjunto ativo é a coleção de VMs de back-end para as quais um Network Load Balancer de encaminhamento interno 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 em Rácio 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 Trusted Cloud remove VMs principais do conjunto ativo e adiciona VMs de alternativa saudáveis ao conjunto ativo, o processo chama-se alternativa. Quando Trusted 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 Trusted Cloud usa para alternativa e recuperação. Cada balanceador de carga de rede de encaminhamento interno 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 Trusted 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. Trusted 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, Trusted 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, Trusted Cloud faz uma alternativa. - Uma taxa de comutação por falha de
0.0significa que Trusted 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 interno 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 primárias e de cópia de segurança não estão em bom estado, Trusted Cloud distribui novas ligações apenas entre as VMs primárias. Faz isso como último recurso. As VMs de cópia de segurança são excluídas desta distribuição de último recurso de ligações.
Se preferir, pode configurar o seu Network Load Balancer de encaminhamento interno para eliminar novas ligações quando todas as VMs principais e de cópia de segurança não estiverem em bom estado.
Drenagem da ligação na comutação por falha e na recuperação
A drenagem de ligações permite que as sessões TCP existentes permaneçam ativas durante um período configurável, mesmo depois de as VMs de back-end ficarem em mau estado. 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 numa VM de back-end durante um máximo de 300 segundos (5 minutos), mesmo que a VM de back-end fique em mau estado ou 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.
Desativar a 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, Trusted 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 principal é 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 cópia de segurança 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 interno 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%). Trusted 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 Trusted 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 Trusted 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, Trusted 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, Trusted 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, Trusted Cloud adiciona-as ao conjunto ativo. Por exemplo, se
vm-a1ficar em bom estado, Trusted 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 interno que usa a comutação por falha, consulte o artigo Configure a comutação por falha para balanceadores de carga de rede de encaminhamento interno.
- Para configurar e testar um balanceador de carga de rede de encaminhamento interno, consulte o artigo Configure um balanceador de carga de rede de encaminhamento interno.
- Para resolver problemas de comutação por falha com o balanceador de carga de rede de encaminhamento interno, consulte o artigo Resolva problemas de balanceadores de carga de rede de encaminhamento interno.