Oracle Clusterware – Arquitetura – Parte 2 – Principais Arquivos: Voting Disk e OCR

Olá amigos!

Continuamos hoje a série de artigos que aborda a arquitetura do Oracle Clusterware.

No post de hoje, veremos sobre os principais arquivos na arquitetura do Oracle Clusterware: Voting Disk e OCR.

• Voting Disk
  • Deve estar em storage compartilhado entre os nós: raw devices (até o Kernel 2.5.x), block devices, ou um cluster file system suportado;
  • Ele também é chamado de Disco de Quórum (Quorum Disk);
  • Pode ou não ser multiplexado: 1, 2 ou 3 cópias (é possível colocar mais de 3 cópias);
  • Sua utilidade ocorre quando há falha na rede de InterConnect, onde, todos os nós do Cluster precisam “votar” num lugar acessível a todos os nós (storage), o nó que tiver o menor número de votos como disponível (available) é eleito a sair do cluster (node eviction), e o processo de CSS faz o restart abrupto do nó;
  • O backup deve ser executado manualmente com o usuário root (em sistemas Unix/Linux), o utilitário dd é utilizado. Veremos na série sobre Administração do Clusterware como realizar essa tarefa;
  • Sempre que houver adição ou remoção de nós no cluster, é recomendado fazer o backup. Isso significa que um backup pode ser armazenado por muitos meses, que mesmo assim, continuará válido;
  • Se um nó perder acesso aos Voting Disks (problemas na fibra, controladora, etc.), o nó será reiniciado imediatamente, pois faz parte da arquitetura do CSS, e, sendo assim, qualquer componente da arquitetura do CSS que falhar, o servidor será reiniciado imediatemente.
  • A figura abaixo exemplifica o funcionamento do Voting Disk:

Na figura acima, podemos observar que num cluster de 3 nós, todos os nós se enxergam através do que chamamos de heart-beat (batida de coração), que é feita pela rede InterConnect. Essa informação é registrada no Voting Disk informando que todos os nós estão ativos no cluster.

Na figura acima, observamos que o nó 3 sofreu algum problema de conexão com a rede privada (InterConnect). O CSS realiza a votação, e o nó 1 “diz” que enxerga os nós 1 e 2; o nó 2 “diz” que enxerga os nós 1 e 2; e o nó 3 “diz” que enxerga somente o nó 3. Dessa forma, o nó 1 tem 2 votos como disponível, o nó 2 tem 2 votos como disponível, e o nó 3 tem apenas 1 voto com disponível. Logo, o nó 3 será evitado e será reiniciado imediatamente.

OK, o funcionamento do Voting Disk é fácil de ser entendido com um cluster de 3 ou mais nós. Mas, aí vem a pergunta, e no caso de um cluster de 2 nós, onde o nó 2 sofrerá o problema de conexão com a rede InterConnect. Como ficarão os votos dentro do Voting Disk? Ficarão da seguinte forma: o nó 1 “diz” que enxerga somente o nó 1, e o nó 2 “diz” que enxerga somente o nó 2. E aí, quem deverá sair do cluster temporariamente?

De acordo com o Metalink Note (RAC: Frequently Asked Questions [ID 220970.1]), o nó que será o “sobrevivente” no cluster será aquele que entrou primeiro no cluster, isto é, supondo que o nó 2 tenha entrado no cluster no dia 05/05/2010 às 0:01 e o nó 1 tenha entrado no cluster no dia 05/05/2010 às 0:02, o nó 2 será o nó sobrevivente no cluster, e o nó 1 será reiniciado.

• OCR (Oracle Cluster Registry)
  • Deve estar em storage compartilhado entre os nós: raw devices (até o Kernel 2.5.x), block devices, ou um cluster file system suportado;
  • Ele também é chamado arquivo de controle (control file) do Cluster, sendo o centro das informações no cluster;
  • Pode ou não ser multiplexado: 1 ou 2 cópias;
  • Ele armazena informações como:
    • Lista dos nós, bancos de dados, instâncias, listeners, ASM, etc -> todos esses componentes são chamados de recursos;
    • Status esperado de cada um dos recursos do cluster;
  • A perda implica em parada do ambiente;
  • Os backups são executados automaticamente a cada 4 horas, e tem a seguinte política de retenção:
    • Armazena 1 backup a cada 4 horas no dia, totalizando 6 backups num intervalo de 24 horas;
    • Armazena 1 backup diário (sempre 1 backup do dia anterior, mas nunca o backup de 2 dias anteriores ou mais);
    • Armazena 1 backup semanal;
  • Além do backup automático, também é possível realizar um backup lógico.

Bom pessoal, como vocês puderam ver, esses arquivos são a espinha dorsal do cluster. Sem eles, o cluster não entra em funcionamento. Também foi possível observar que para um DBA perder um backup do OCR, tem que estar muito desatento mesmo, pois com backup a cada 4 horas, é praticamente “impossível” perder um backup desses.

Novamente, espero que esse post seja útil!

No próximo artigo, da semana que vem, veremos sobre as redes utilizadas no cluster: pública e privada (InterConnect).

Um abraço!

Vinicius