Protocolos de Detecção de Falha e Descoberta de Grupo Principal
Quando um membro do grupo principal é iniciado, não existem conexões com outros membros do grupo principal. Se um grupo principal estiver configurado para ser executado com os Protocolos de Detecção de Falha e Descoberta padrão ou com um provedor de protocolo alternativo, as tarefas de descoberta e detecção de falha ou do provedor de protocolo alternativo serão iniciadas como parte do procedimento de inicialização de processo. Essas tarefas estabelecem conectividade com outros membros do grupo principal, monitoram essa conectividade e identificam falhas de conectividade para esse membro do grupo principal, a intervalos regularmente planejados, desde que o membro do grupo principal esteja ativo.
O Protocolo de Descoberta Padrão
O Protocolo de Descoberta padrão estabelece conectividade de rede com os outros membros do grupo principal. Para estabelecer essa conectividade, o Protocolo de Descoberta recupera a lista de membros do grupo principal e as informações de rede associadas das definições de configuração do produto. Em seguida, ele tenta abrir conexões de rede com todos os outros membros do grupo principal. Em intervalos periódicos, ele recalcula o conjunto de membros não conectados e tenta abrir as conexões com esses membros.
DCSV1032I: Pilha DCS DefaultCoreGroup no Membro MyCell\anzio\nodeagent:
Conectado um membro definido MyCell\anzioCellManager\dmgr.
As conexões podem falhar a qualquer momento por várias razões. O Protocolo de Detecção de Falha detecta falhas na conexão e notifica o Protocolo de Descoberta. O Protocolo de Descoberta tenta, em seguida, abrir uma nova conexão de rede com esse membro no próximo intervalo planejado.
A quantidade de ciclos de CPU consumida pela tarefa do Protocolo de Descoberta é proporcional ao número de membros do grupo principal parados ou inatingíveis. Os ciclos de CPU consumidos pela tarefa do Protocolo de Descoberta são insignificantes nas configurações padrão.
Protocolo de Detecção de Falha Padrão
O Protocolo de Detecção de Falha monitora as conexões de rede do grupo principal estabelecidas pelo Protocolo de Descoberta. Quando o Protocolo de Detecção de Falha detecta uma falha na conexão de rede, ele relata essa falha para o Protocolo de Sincronia de Visualização e para o Protocolo de Descoberta. O Protocolo de Sincronia de Visualização ajusta a visualização para excluir o membro com falha. O Protocolo de Descoberta tenta reestabelecer uma conexão de rede com o membro com falha. Essa tarefa será executada enquanto o membro estiver ativo.
- Ele procura conexões que foram fechadas porque o soquete de base estava fechado.
Quando um membro do grupo principal é parado normalmente em resposta a um comando de administração, o transporte do grupo principal para esse membro também é parado e o soquete associado ao transporte é fechado. Quando um membro do grupo principal é finalizado de modo anormal, o sistema operacional de base, normalmente, fecha os soquetes abertos pelo processo e o soquete associado ao transporte do grupo principal .
Seja qual for o tipo de finalização, os membros do grupo principal que possuem uma conexão aberta com o membro finalizado são notificados de que a conexão não pode mais ser utilizada. O membro do grupo principal que recebe a notificação de soquete fechado considera o membro finalizado como falho.
Quando um membro com falha for detectado por causa do mecanismo de fechamento de soquete, a seguinte mensagem será registrada no arquivo SystemOut.log para os membros sobreviventes:DCSV1115W: DCS Stack DefaultCoreGroup at Member anzioCell01\anzio\ServerD: Member anzioCell01\anzio\ServerC connection was closed. Member will be removed from view. DCS connection status is Discovery|Ptp, transmitter closed.
O O mecanismo de soquete fechado é a maneira normal de se descobrir os membros falhos. As configurações do TCP no sistema operacional de base, como FIN_WAIT, afetam a rapidez com que os eventos de fechamento de soquete são recebidos.
- Ele atende pulsações ativas a partir dos membros do grupo principal.
O mecanismo de pulsação ativa é semelhante à função TCP manter ativo. Em intervalos planejados regularmente, cada membro do grupo principal envia um pacote de ping em cada conexão aberta do grupo principal. A taxa ou periodicidade na qual o pacote é enviado é chamada período de transmissão por pulsação.
Cada membro de grupo principal espera receber um pacote em cada conexão aberta do membro de grupo principal na outra extremidade da conexão. Se nenhum pacote for recebido por uma conexão aberta no período de tempo especificado para o tempo limite de pulsação, o membro na outra extremidade da conexão será marcado como falho.
O período de tempo limite de pulsação deve ser um número inteiro múltiplo do período de transmissão por pulsação. O período de tempo limite de pulsação também deve ser pelo menos duas vezes maior que o período de transmissão por pulsação.
Quando um membro é marcado como falho, a seguinte mensagem é enviada ao arquivo de log de erros:DCSV1112W: Pilha DCS DefaultCoreGroup no Membro anzioCell01\anzioCellManager01\dmgr: O membro suspenso é anzioCell01\nettuno\ServerB por causa do tempo limite da pulsação. O Tempo Limite Configurado é 180.000 milissegundos. O canal lógico do DCS é Connected|Ptp.
As pulsações ativas são muito úteis para a detecção de membros do grupo principal inatingíveis em razão de parada da rede. As pulsações ativas consomem algum uso de CPU. A quantidade consumida de uso da CPU é proporcional ao número de membros ativos no grupo principal. A configuração padrão para pulsações ativas é uma proporção entre o uso da CPU e a detecção adequada do membro falho.
É possível utilizar o console administrativo ou a ferramenta wsadmin para configurar o período de transmissão por pulsação e o período de tempo limite de pulsação. Leia o tópico Configurando o Protocolo de Detecção de Falha para um grupo principal para obter uma descrição de como utilizar o console administrativo para alterar essas configurações.
![[IBM i]](../images/iseries.gif)
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
Provedores de Protocolo Alternativo
Atualmente, nenhum provedor de protocolos alternativo está disponível para o IBM i e plataformas distribuídas.
Provedores de Protocolo Alternativo
É possível utilizar um provedor de protocolo alternativo em vez do Protocolo de Descoberta ou de Detecção de Falha padrão para monitorar e gerenciar a comunicação entre os membros do grupo principal. Em geral, provedores de protocolo alternativo, como o provedor baseado em z/OS Cross-system Coupling Facility (XCF), utilizam menos recursos do sistema do que os Protocolos de Descoberta e de Detecção de Falha padrão, especialmente enquanto os membros do grupo principal estão inativos. Um provedor de protocolo alternativo geralmente utiliza menos recursos do sistema, porque ele não realiza o pinging do TCP/IP membro para membro que os provedores de protocolo padrão utilizam para determinar se um membro do grupo principal ainda está ativo.
![[z/OS]](../images/ngzos.gif)
DCSV1032I: Pilha DCS DefaultCoreGroup no Membro MyCell\anzio\nodeagent:
Conectado um membro definido MyCell\anzioCellManager\dmgr.
- O grupo principal é homogêneo. Isso significa que os processos do grupo principal
devem todos residir na mesma plataforma. Por exemplo, o grupo principal não pode conter uma combinação de processos do z/OS e distribuídos.
Se o grupo principal contiver processos não z/OS, ou for composto por membros que estão em diferentes níveis de versões do produto, você não poderá utilizar o XCF para esse grupo principal.
- Se o grupo principal precisar ser ligado a outro, utilizando o serviço de ponte de grupo principal, todos os grupos principais ligados a ele também serão grupos principais homogêneos.
- Todos os membros do grupo principal deverão estar na Versão 7.x do produto. Se algum membro do grupo principal estiver sendo executado no nível de Versão 6.x do produto, você deverá atualizá-lo para a Versão 7.x, a fim de poder mudar para o provedor de protocolo alternativo.