As informações das seções seguintes podem ajudá-lo na administração da configuração de software do cluster.
Um cluster usa diversos mecanismos de comunicação interna para garantir a integridade dos dados e o comportamento correto do cluster no caso de uma falha. O cluster usa estes mecanismos para:
Controlar quando um sistema pode tornar-se um membro do cluster
Determinar o estado dos sistemas do cluster
Controlar o comportamento do cluster quando uma falha ocorrer
Os mecanismos de comunicação do cluster são os seguintes:
Partições (quorum) compartilhadas
Periodicamente, cada sistema do cluster grava um timestamp e estado do sistema nas partições primária e shadow compartilhadas, que são partições raw localizadas no armazenamento compartilhado. Cada membro acessa o estado e o timestamp gravados pelos outros membros e determina se estão atualizados. Os membros tentam ler as informações da partição primária compartilhada. Se esta partição estiver corrompida, os membros lêem as informações pela partição shadow compartilhada e consertam a partição primária simultaneamente. A consistência dos dados é mantida através de verificações de consistência (checksums) e quaisquer inconsistências encontradas entre as partições são automaticamente corrigidas.
Se um membro reinicializar, mas não puder gravar nas duas partições compartilhadas, o sistema não terá permissão para juntar-se ao cluster. Além disso, se um membro não puder mais gravar em ambas partições, se auto remove do cluster desligando-se.
As partições compartilhadas são usadas somente como um mecanismo de comunicação em clusters de dois membros que tem o tiebreaker de rede desabilitado.
Monitoramento do comutador de rede remoto
Periodicamente, cada membro monitora a saúde da conexão do comutador de energia remoto, se houver. O membro usa esta informação para ajudar a determinar o estado dos outros membros do cluster. A falha completa do mecanismo de comunicação do comutador de energia não resulta automaticamente numa queda. Se um comutador de energia falhar em transferir os serviços de um sistema pendente, não é efetuada a transferência (failover), já que a infra-estrutura do cluster não pode garantir o estado atual do membro.
Heartbeats Ethernet
Os membros são inter-conectados usando linha Ethernet ponto-a-ponto. Periodicamente, cada membro envia heartbeats (pings) através destas linhas. O cluster usa estas informações para ajudar a determinar o estado dos membros e para garantir a operação correta do cluster. A falha completa do mecanismo de comunicação de heartbeat não resulta automaticamente numa queda (failover).
Se um membro determinar que um timestamp de outro membro não está atualizado, verifica o estado do heartbeat. Se os heartbeats para o membro ainda estão operando, o software do cluster não toma nenhuma ação. Se um membro não atualizar seu timestamp após um certo período e não responder aos pings heartbeat, é considerado caído (down).
O cluster continua operacional, desde que um sistema possa gravar nas partições compartilhadas, mesmo que todos os outros mecanismos de comunicação falhem.
Note que a partição compartilhada é usada somente como um backup em algumas configurações de dois membros. O algoritmo de associação da rede é o fator principal para determinar quais membros do cluster estão ativos e quais não estão. Um membro que não atualiza seu timestamp nesta configuração nunca causa uma queda, a não ser que o clumembd reportar que o membro caiu.