Red Hat Training

A Red Hat training course is available for RHEL 8

Capítulo 27. Configuração de clusters de múltiplos locais com Pacemaker

Quando um cluster abrange mais de um site, os problemas de conectividade de rede entre os sites podem levar a situações de cérebro dividido. Quando a conectividade cai, não há maneira de um nó em um site determinar se um nó em outro site falhou ou ainda está funcionando com uma interligação de site falhada. Além disso, pode ser problemático fornecer serviços de alta disponibilidade em dois sites que estão muito distantes para manter a sincronia.

Para resolver estes problemas, a Pacemaker oferece suporte total para a capacidade de configurar clusters de alta disponibilidade que abrangem vários locais através do uso de um gerente de ingressos para clusters de estande.

27.1. Visão geral do gerente de bilheteria de estandes

O estande ticket manager é um serviço distribuído que deve ser executado em uma rede física diferente das redes que conectam os nós de cluster em determinados locais. Ele produz outro cluster solto, um Booth formation, que fica em cima dos clusters regulares nos sites. Esta camada de comunicação agregada facilita os processos de decisão baseados em consenso para os bilhetes individuais dos estandes.

Um estande ticket é um singleton na formação do estande e representa uma unidade de autorização móvel e sensível ao tempo. Os recursos podem ser configurados para exigir um determinado bilhete para rodar. Isto pode garantir que os recursos sejam executados em apenas um local de cada vez, para o qual um bilhete ou bilhetes foram concedidos.

Você pode pensar na formação de um estande como um aglomerado sobreposto que consiste em clusters funcionando em locais diferentes, onde todos os clusters originais são independentes uns dos outros. É o serviço de estande que comunica aos aglomerados se foi concedido um bilhete, e é o Pacemaker que determina se os recursos devem ser administrados em um aglomerado com base em uma restrição de bilhetes do Pacemaker. Isto significa que ao utilizar o gerenciador de bilhetes, cada um dos clusters pode administrar seus próprios recursos, bem como os recursos compartilhados. Por exemplo, pode haver recursos A, B e C rodando apenas em um cluster, recursos D, E e F rodando apenas no outro cluster, e recursos G e H rodando em qualquer um dos dois clusters conforme determinado por um ticket. Também é possível ter um recurso adicional J que poderia funcionar em qualquer um dos dois aglomerados, conforme determinado por um bilhete separado.