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
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
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?
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.