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

Nota: Esse tópico faz referência a um ou mais arquivos de log do servidor de aplicativos. Como uma recomendação alternativa, é possível configurar o servidor para usar a infraestrutura de log e rastreio do High Performance Extensible Logging (HPEL) em vez de usar os arquivos SystemOut.log , SystemErr.log, trace.log e activity.log em sistemas distribuídos e IBM® i. Também é possível usar HPEL em conjunção com os recursos de criação de log z/OS nativos. Se você estiver usando HPEL, será possível acessar todas as informações de log e rastreio usando a ferramenta de linha de comandos LogViewer a partir do diretório bin do perfil do servidor. Consulte as informações sobre a utilização do HPEL para resolução de problemas dos aplicativos para obter mais informações sobre o uso do HPEL.

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.

Quando é feita uma conexão com outro membro do grupo principal, o Protocolo de Descoberta notifica o Protocolo de Sincronia de Visualização e registra esse evento como uma mensagem informativa, semelhante à seguinte, no arquivo SystemOut.log.
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.

O Protocolo de Detecção de Falha utiliza dois mecanismos distintos para localizar membros com falha:
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][AIX Solaris HP-UX Linux Windows]

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]Se você decidir utilizar o provedor baseado em z/OS Cross-system Coupling Facility (XCF), esteja ciente de que na inicialização o processo do servidor é unido, como membro, a um grupo XCF. O grupo XCF contém todos os membros ativos do grupo principal. O XCF fornece notificação a todos os membros sempre que um membro se une ao grupo, e sempre que um membro não possa mais ser contactado por causa de encerramento do servidor, ou o XCF determina que o processo do servidor terminou. Sempre que uma conexão entre membros do grupo principal é estabelecida, o provedor de protocolo baseado em z/OS Cross-system Coupling Facility (XCF) notifica o Protocolo Visualizar Sincronia e coloca esse evento no log como mensagem informativa, semelhante à seguinte mensagem no arquivo SystemOut.log.
DCSV1032I: Pilha DCS DefaultCoreGroup no Membro MyCell\anzio\nodeagent: 
Conectado um membro definido MyCell\anzioCellManager\dmgr.
Antes de reconfigurar um grupo principal específico para utilizar como provedor de protocolo alternativo, é necessário verificar se o grupo principal atende aos seguintes requisitos. Se o grupo principal não atender a todos esses requisitos, você deverá continuar utilizando os Protocolos de Descoberta e de Detecção de Falha padrão com esse grupo principal.
  • 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.

    [z/OS]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.

Ícone que indica o tipo de tópico Tópico de Conceito



Ícone de registro de data e hora Última atualização: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=crun_ha_discovery
Nome do arquivo: crun_ha_discovery.html