Entenda o papel de cada camada e por que confundir esses componentes torna o Oracle RAC muito mais difícil do que realmente é.
Quando alguém começa a estudar Oracle RAC, não demora muito para aparecer uma verdadeira sopa de letrinhas:
RAC, GI, Clusterware, CRS, ASM, OCR, Voting Disk, SCAN, VIP…
E então surge uma dúvida bastante comum:
Afinal, onde termina uma coisa e começa a outra?
Essa confusão pode fazer a arquitetura Oracle RAC parecer muito mais complicada do que realmente é.
Por isso, antes de falar sobre instalação, comandos ou administração de um cluster, existe uma pergunta mais importante:
Quem faz o quê dentro de um ambiente Oracle RAC?
Neste artigo, vamos começar por três componentes fundamentais: Oracle Grid Infrastructure, Oracle Clusterware e Oracle ASM.
Antes do RAC existe uma infraestrutura
Imagine que você pretende construir um ambiente Oracle RAC com dois servidores.
Muita gente pensa inicialmente assim:
Servidor 1 + Servidor 2 + Oracle Database = Oracle RAC
Mas existe uma camada fundamental entre o sistema operacional e as instâncias do banco de dados.
É justamente aqui que entra o Oracle Grid Infrastructure.
Visão simplificada das camadas que compõem uma arquitetura Oracle RAC.
Essa visão já resolve boa parte da confusão.
Oracle Grid Infrastructure: a base do ambiente
Uma pergunta que aparece frequentemente é:
Grid Infrastructure e Clusterware são a mesma coisa?
Não exatamente.
O Oracle Grid Infrastructure é o conjunto de software que fornece componentes essenciais da infraestrutura utilizada pelo ambiente clusterizado. Em uma instalação para cluster, dois elementos extremamente importantes fazem parte dessa infraestrutura:
Oracle Clusterware e Oracle ASM.
Portanto, quando instalamos o Grid Infrastructure para um ambiente RAC, não estamos simplesmente “instalando o RAC”. Estamos preparando a infraestrutura sobre a qual o ambiente RAC poderá operar.
E essa diferença conceitual é importante.
Oracle Clusterware: quem coordena o cluster?
Agora imagine nosso ambiente com dois servidores.
Os dois precisam funcionar como integrantes de um único cluster.
Mas alguém precisa saber:
Quais nós estão ativos?
Quais recursos devem estar executando em cada nó?
Um determinado recurso parou?
Um servidor deixou de responder?
Um serviço precisa ser iniciado novamente?
É aí que entra o Oracle Clusterware.
Ele fornece a infraestrutura responsável por gerenciar os nós e diversos recursos do cluster, monitorando seu estado e tomando ações conforme as políticas configuradas.
Isso nos leva a uma ideia fundamental:
RAC não é simplesmente dois bancos Oracle executando ao mesmo tempo. Existe uma infraestrutura de cluster coordenando todo o ambiente.
E isso explica por que estudar RAC sem compreender Clusterware normalmente resulta em conhecimento superficial.
E se um nó cair?
Aqui a arquitetura começa a ficar interessante.
Imagine que o Node 1 deixe de responder, enquanto o Node 2 continua operacional.
Como o ambiente identifica isso?
Como sabe que aquele servidor não faz mais parte do cluster?
Como os recursos são tratados?
Como impedir situações em que nós isolados possam comprometer a integridade do ambiente?
O Oracle Clusterware monitora os recursos do cluster e participa do tratamento das falhas dos nós e recursos.
Essas perguntas nos levam diretamente para conceitos como:
OCR, Voting Files, heartbeat, eviction e split-brain.
E cada um deles merece um conteúdo próprio.
Por enquanto, o mais importante é perceber que existe toda uma infraestrutura responsável pela coordenação e integridade do cluster.
Esse é um dos principais papéis do Oracle Clusterware.
Oracle ASM: quem cuida do armazenamento?
Agora aparece outro problema.
Se temos duas instâncias Oracle RAC executando em servidores diferentes, ambas precisam acessar os arquivos necessários ao banco de dados.
Precisamos então de uma infraestrutura apropriada para gerenciamento desse armazenamento.
É aqui que entra o Oracle Automatic Storage Management — ASM.
O ASM foi desenvolvido especificamente para gerenciar armazenamento utilizado pelo Oracle Database.
Ele organiza os discos em estruturas chamadas Disk Groups.
Dois exemplos bastante comuns são:
+DATA — utilizado para arquivos relacionados ao banco de dados.
+RECO — frequentemente utilizado para arquivos relacionados à recuperação, como archived redo logs e backups, dependendo da arquitetura adotada.
Exemplo conceitual do Oracle ASM gerenciando Disk Groups utilizados pelas instâncias de um Oracle RAC.
Naturalmente, a organização real dos Disk Groups depende da arquitetura definida para cada ambiente.
ASM não é simplesmente “um filesystem da Oracle”
Essa simplificação aparece bastante.
Ela pode ajudar alguém nos primeiros minutos de estudo, mas tecnicamente esconde justamente o que torna o ASM interessante.
O ASM trabalha com conceitos como:
Disk Groups, ASM Disks, Allocation Units, extents, striping e redundância.
Além disso, ele foi projetado para distribuir os dados entre os discos pertencentes aos Disk Groups.
Quando a configuração do grupo de discos é alterada, o ASM possui mecanismos de rebalanceamento para redistribuir os dados entre os discos disponíveis.
Isso elimina uma série de tarefas de gerenciamento manual de arquivos e volumes que seriam necessárias em outras arquiteturas.
Por isso, uma definição melhor seria:
ASM é uma tecnologia de gerenciamento de armazenamento desenvolvida especificamente para Oracle Database.
Agora podemos colocar o RAC na arquitetura
Depois de entender essas camadas, conseguimos finalmente enxergar melhor onde o Oracle RAC entra.
Visão das principais camadas: Oracle RAC Database, Grid Infrastructure, Clusterware, ASM e armazenamento compartilhado.
Agora temos uma arquitetura muito mais coerente.
O Clusterware coordena o cluster e seus recursos.
O ASM gerencia o armazenamento utilizado pelo Oracle Database.
E as instâncias do Oracle RAC trabalham sobre essa infraestrutura.
É por isso que existe uma frase que gosto de usar quando ensino RAC:
Para entender Oracle RAC, você precisa entender primeiro tudo aquilo que permite que o RAC exista.
Uma analogia para fixar
Podemos imaginar um condomínio.
O Grid Infrastructure representa a infraestrutura que permite ao condomínio funcionar.
O Clusterware seria a estrutura responsável por coordenar os serviços, saber o que está funcionando e reagir quando algo apresenta problema.
O ASM seria responsável pela organização e administração dos espaços de armazenamento utilizados pelo ambiente.
E o Oracle RAC seria aquilo que utiliza toda essa infraestrutura para entregar o serviço de banco de dados.
Naturalmente, a analogia tem seus limites técnicos.
Mas ela ajuda a perceber algo fundamental:
Grid Infrastructure, Clusterware, ASM e RAC não são nomes diferentes para a mesma coisa.
Eles possuem responsabilidades diferentes dentro da arquitetura.
Entender RAC começa antes do RAC
Esse talvez seja o principal aprendizado deste artigo.
Quando olhamos apenas para as instâncias do banco de dados, enxergamos somente uma parte da arquitetura.
Por trás delas existe uma infraestrutura responsável por clusterização, gerenciamento de recursos, comunicação, armazenamento e disponibilidade.
E isso abre várias perguntas interessantes:
Como os nós sabem que os outros continuam vivos?
O que acontece quando ocorre uma falha de comunicação entre eles?
Para que servem OCR e Voting Files?
Como o ASM distribui os dados?
Como SCAN, VIP, listeners e services entram nessa arquitetura?
É justamente quando começamos a responder essas perguntas que deixamos de apenas operar comandos de Oracle RAC e começamos efetivamente a entender Oracle RAC.
Quer aprender Oracle RAC indo além dos comandos?
Na Imersão Oracle RAC da Oradata, estudamos a arquitetura indo do fundamento à prática.
A proposta é entender não apenas quais comandos executar, mas principalmente o que está acontecendo por trás deles e por quê.
🎓 Temos uma aula aberta para você conhecer o treinamento
Oradata Treinamentos — Conhecimento que gera oportunidades.