Pacemaker: Estudando a Arquitetura – Parte 002

no artigo anterior vimos que resources são os serviços ou programas instalados em um computador ou servidor e chamamos de nó ao computador. Veja: Pacemaker: Trabalhando com Alta Disponibilidade(high-availability) – Parte 001

Também é bom saber que cluster são dois ou mais computadores (chamados nós ou membros) que trabalham juntos para executar uma tarefa.  Veja: Termos Usados em Alta-Disponibilidade(High Availability): Cluster, Fencing, Quorum, split-brain

No nível mais alto, o cluster é composto de três partes:

• Componentes sem reconhecimento de cluster: Essas peças incluem os próprios resources; scripts que os iniciam, param e monitoram; e um daemon local que mascara as diferenças entre os diferentes padrões que esses scripts implementam. Mesmo que as interações desses resources quando executados como várias instâncias possam se assemelhar a um sistema distribuído, eles ainda carecem dos mecanismos HA adequados e/ou da governança autônoma em todo o cluster, conforme resumido no item a seguir.
• Gerenciamento de Resources(recursos): Pacemaker faz essa “gerência”, ele fornece o cérebro que processa e reage a eventos relacionados ao cluster. Esses eventos incluem nós(computadores) entrando ou saindo do cluster; eventos de resources causados ​​por falhas, manutenções e atividades programadas; e outras ações administrativas. O Pacemaker calculará o estado ideal do cluster e traçará um caminho para alcançá-lo após qualquer um desses eventos. Isso pode incluir mover resources, parar nós e até mesmo forçá-los a ficar offline com interruptores remotos.
• Infraestrutura de baixo nível: Projetos como Corosync, CMAN e Heartbeat fornecem mensagens confiáveis, associação e informações de quorum sobre o cluster.

Quando combinado com o Corosync, o Pacemaker também oferece suporte a sistemas de arquivos de cluster de código aberto populares.

Devido à padronização anterior na comunidade do sistema de arquivos cluster, os sistemas de arquivos cluster fazem uso de um gerenciador de distributed lock manager(bloqueio distribuído comum), que faz uso do Corosync para seus recursos de mensagens e associação(cujos nós estão ativos/inativos) e Pacemaker para serviços de isolamento.

Componentes Internos

Pacemaker em si é composto por cinco componentes principais:

• CIB(Cluster Information Base) ou Base de informações do cluster
• CRMd(Cluster Resource Management daemon) ou Daemon de gerenciamento de recursos de cluster
• LRMd(Local Resource Management daemon)
• PE(Policy Engine) ou PEngine ou, em português, Mecanismo de política.
• STONITHd(Fencing daemon)

O CIB usa XML para representar a configuração do cluster e o estado atual de todos os recursos no cluster. O conteúdo do CIB é automaticamente mantido em sincronia em todo o cluster e é usado pelo PEngine para calcular o estado ideal do cluster e como ele deve ser alcançado.

Esta lista de instruções é então alimentada para o DC(Designated Controller ou Controlador Designado). O Pacemaker centraliza toda a tomada de decisão do cluster, elegendo uma das instâncias do CRMd para atuar como mestre. Se o processo CRMd eleito(ou o nó em que ele está) falhar, um novo é rapidamente estabelecido.

O DC executa as instruções do PEngine na ordem necessária, passando-as para o daemon de gerenciamento de resources locais(LRMd) ou pares CRMd em outros nós por meio da infraestrutura de mensagens do cluster (que, por sua vez, as passa para o processo LRMd).

Todos os nós pares relatam os resultados de suas operações de volta ao DC e, com base nos resultados esperados e reais, executarão quaisquer ações que precisem aguardar a conclusão da ação anterior ou abortar o processamento e solicitar ao PEngine que recalcule o estado de cluster ideal com base nos resultados inesperados.

Em alguns casos, pode ser necessário desligar os nós para proteger os dados compartilhados ou para concluir a recuperação dos recursos. Para isso, o Pacemaker vem com o STONITHd. STONITH é um acrônimo para Shoot-The-Other-Node-In-The-Head ou Atire-na-cabeça-do-outro-nó, uma prática recomendada de que o nó que se comporta mal deve ser imediatamente protegido(desligado, cortado de recursos compartilhados ou imobilizado de outra forma) e geralmente é implementado com um interruptor de alimentação remoto.

No Pacemaker, os dispositivos STONITH são modelados como resources(e configurados no CIB) para permitir que sejam facilmente monitorados quanto a falhas. descansar.

Fonte: ClusterLabs