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
Related posts
6 Comments
Deixe um comentário Cancelar resposta
Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.
Sobre
Disclaimer
Minhas postagens refletem minhas próprias opiniões e não representam necessariamente as opiniões do meu empregador, a Accenture.
Nem sei o que dizer, só posso parabenizar mesmo, fantastico Vinicius, excelente didática , ótima transparência na passagem do conhecimento enfim grande Post. Meus parabéns!
Abraço
Olá David!
Cara, muito obrigado pelas suas palavras!
É um orgulho vindo isso de você, meu amigo!
Abraço!
Nossa Vinicius, parabéns mesmo pelas explicações, foi muito detalhado e simples de entender.
Você tem algum link que você indica passo-a-passo para instalar o Oracle grid 11g release 2 e o ORACLE Rac release 2?
Olá Angela,
Tudo bem?
Muito obrigado pela visita ao blog!
Olha, ainda estou “estudando” bem o 11gR2 para postar algo bem detalhado e fácil de entender no blog.
Enquanto isso, talvez valha a pena verificar esse link:
http://www.oracle-base.com/articles/11g/OracleDB11gR2RACInstallationOnOEL5UsingVMwareServer2.php
Abraços!
Vinicius
Boa tarde Vinicius!
Você poderia me informar quais as vantagens entre utilizar ASM e não Datafile(dbf)? existe alguma diferença entre a quantidade de datafiles a ser gerenciada entre as duas forma de armazenamento.
o que vc me fala sobre uma estrutura NFS+ASM – storage Netapp
o que vc me fala sobre uma estrutura NFS+datafile – storage Netapp
estou realizando um comparativo entre as duas estruturas a serem montadas num redhat 5.5 com oracle 10gr2.
Abraço,
Júlio César.
úlio,
Tudo bem?
Desculpe pela demora.
Vamos lá:
Veja, com o ASM você também usa datafile!
O ASM é um local para armazenar datafiles, assim como um file system normal.
A diferença é que ele não fica mais “visível” montado em file system. Mas dá para acessá-los normalmente…
O ASM tem muitas vantagens frente a um file system normal:
– Você gerencia grupos de discos ao invés de discos individuais ou arquivos;
– Facilidade de configuração para espelhamento;
– Permite migração de um BD para um novo storage sem parada do banco de dados (nenhum outro mecanismo permite isso);
– Facilita gerenciamento de bases grandes;
– Balanceamento de carga de I/O automático bem mais eficiente que outros mecanismos.
Sobre as estruturas, prefira NFS + ASM no storage NetApp.
Abraços
Vinicius