Olá amigos!

Hoje começaremos uma série de artigos onde discutiremos sobre a arquitetura do Oracle Clusterware.

No post de hoje, começaremos a falar dos daemons do Clusterware e de um processo no Linux que é fundamental para a utilização do Clusterware: hangcheck-timer.

Primeiramente, o que são daemons?

Basicamente, daemon é um programa de computador que é executado em background.

Geralmente eles respondem a requisições de rede, atividades de hardware, ou outros programas.

Comumente, o seu nome termina com a letra d, mas isso não é uma regra.

Referência: Wikipédia

Bom, vamos lá. No Oracle Clusterware, há basicamente 3 daemons, todos eles são iniciados com a opção de respawn, que significa que caso o processo termine abruptamente, o processo será reiniciado automaticamente.

O ambiente-base citado para exemplificar sobre os processos é o Red Hat Enterprise Linux.

  • CSSD (Cluster Syncronization Services Daemon)
    • Controla os membros do cluster;
    • Ele ajuda no monitoramento da “saúde dos nós, usando o Voting Disk e o InterConnect;
    • Também é responsável pela sincronização entre as instâncias de ASM e Banco de Dados;
    • É executado com o usuário oracle;
    • Considerado o principal processo no Cluster;
    • Como ele controla os membros do cluster, caso ele falhe abruptamente, o servidor em questão é reiniciado imediatemente.
  • CRSD (Cluster Ready Services Daemon)
    • Principal processo no gerenciamento de alta disponibilidade;
    • Realiza todas as operações de recuperação e gerenciamento da alta disponibilidade, como o gerenciamento do OCR e o gerenciamento dos recursos de aplicação (recursos do cluster);
    • Lê as configurações dos recursos que estão armazenadas no OCR;
    • Se um recurso falhar, tentará reiniciá-lo, até um limite definido pelo parâmetro RESTART_ATTEMPTS, o que geralmente é 5;
    • É executado com o usuário root;
    • Se o processo falhar, ele é automaticamente reiniciado (sem reinício do servidor).
  • EVMD (Event Manager Daemon)
    • Publica os eventos que o CRS cria (exemplo: instância up, instância down, listener up, listener down);
    • É executado com o usuário oracle;
    • Se o processo falhar, ele é automaticamente reiniciado (sem reinício do servidor).

Há também o seguinte daemon no Clusterware:

  • OPROCD (Process Monitor Daemon)
    • Monitora o cluster e fornece I/O fencing (quando um nó apresentar problemas, ele não poderá mais realizar operações de I/O);
    • O I/O fencing é garantido através do reinício imediato do servidor;
    • É executado com o usuário root (é um processo filho do CSSD);
    • Se o processo falhar, o servidor é reiniciado imediatamente;
    • No Linux, usa o hangcheck-timer para verificar a “saúde” do nó.

E também, há o módulo de kernel no Linux:

  • Hangcheck-Timer
    • Módulo do kernel que é lido no momento do boot;
    • Monitora o kernel do Linux em busca de operações longas que podem travar o sistema operacional e afetar a confiabilidade de um nó no RAC;
    • Usa o Time Stamp Counter (TSC) para obter delays previstos, ou então o travamento do nó;
    • O TSC é basicamente, um “ping” no kernel onde utiliza a CPU para fazer isso, portanto, é muito preciso. Caso ocorra delay nesse ping, significa que o nó está travando (hanging);
    • O hangcheck-timer, obviamente, usa um timer, onde se o valor do timer for ultrapassado, o servidor será reiniciado.
    • É usado em TODOS os clusters Oracle Clusterware no 10gR1, 10gR2 e 11gR1;
    • No 10gR2, tem como default, os seguintes parâmetros:
      • hangcheck_tick = 1: define com qual frequência, em segundos, o hangcheck-timer verificará por travamentos no nó;
      • hangcheck_margin = 10: define qual é a margem de erro tolerada, em segundos, antes do hangcheck_timer reiniciar o nó;
      • hangcheck_reboot = 1: define se o hangcheck_timer reiniciará o nó ou não. Se o valor estiver definido como 1, o nó será reiniciado caso esteja “travando”, se estiver diferente deste valor, o nó não será reiniciado.
    • O nó será reiniciado se o valor de hangcheck_tick + hangcheck_margin for atingido, isso é, no 10gR2, 11 segundos.

Bom pessoal, é isso, espero que esse post seja útil!

No próximo artigo, na próxima semana, veremos sobre os arquivos vitais para o funcionamento do Clusterware: OCR e Voting Disk.

Um abraço!

Vinicius