Diferente de um single instance, o Oracle Real Application Clusters (RAC) permite a execução em de um único Oracle Database em vários servidores para maximizar a disponibilidade do ambiente, além de permitir a escalabilidade horizontal enquanto o ambiente está em uso.
Antes de começar com a leitura, reflita sobre as seguintes questões: Você já se perguntou quando a empresa deve usar Oracle RAC? Se um servidor cai (fica fora do ar), em quanto tempo o serviço precisa ser reestabelecido? Quanto a área de negócio perde quando a aplicação não está disponível durante o tempo de recovery? - Ao final dessa leitura, você será capaz de entender os prós e contras em utilizar o Oracle RAC além de ter uma visão geral sobre a sua arquitetura.
Se você é um DBA, pode estar se perguntando. Por que eu deveria aprender essa tecnologia? O Oracle RAC é muito utilizado em empresas que precisam de ambientes de alta disponibilidade além da alta demanda de mercado para DBA's que sabem gerenciar estes ambientes.
Existem várias vantagens ao usar o Oracle RAC database, em caso de falha de uma instância, ou de um servidor, as outras continuam funcionando normalmente de forma transparente para o usuário ou aplicação sendo aderente ao atendimento de SLA que requer alta disponibilidade.
Quedas planejadas para upgrade de hardware ou correção de problemas, aplicação de patch ou upgrade de sistema operacional ou banco de dados. Devido sua escalabilidade horizontal, é possível adicionar ou remover recursos de hardware de forma transparente para o usuário, além do load balancing que permite uma melhor utilização destes recursos. Ele provê alta disponibilidade de banco de dados, prevenindo contra falhas de hardware ou do sistema operacional.
Vejo sua desvantagem principalmente em relação aos custos de licença, no Oracle Database Enterprise Edition a licença do Oracle RAC é separada, no Oracle Database Standart Edition ela é incluída, mas o número total de CPU em todos os servidores do cluster precisa ser menor ou igual a 4.
Sua arquitetura e requisitos de hardware são complexos, ele funciona bem como solução de alta disponibilidade contra quedas planejadas ou não planejadas, mas não é projetado para Disaster Recovery. O Oracle Data Guard é a solução correta para ambientes de DR. Sua administração também é mais complexa se comparada a um ambiente single instance.
Quando pensamos na implementação do Oracle RAC devemos levar em consideração o seu custo de implementação com: Infraestrutura de hardware, licenças de Oracle RAC e Database, além do custo de gerenciamento. Se o seu orçamento é baixo, considere a opção de Oracle RAC de 1 nó.
Arquitetura do Oracle RAC
Para melhor entendimento da arquitetura do Oracle RAC, fiz uma divisão por tópicos e faremos uma navegação por cada uma delas.
1: Componentes do Oracle RAC (Software Stack)
O Oracle RAC é formado por uma pilha de softwares (stack) como vemos a seguir:
Oracle Grid Infrastructure
ASM
Oracle Database
Oracle Grid Infrastructure
Clusterware
O clusterware é responsável pela funcionalidade do cluster, um cluster é um grupo de servidores interconectados e funcionando como um único sistema, de forma transparente para a aplicação ou para o usuário final.
Funções do clusterware
Gerenciar todo o cluster
Monitorar a disponibilidade dos recursos
Controla a ordem de inicialização dos recursos
Pode ser programado para aplicações de usuário
ASM
O Oracle ASM funciona como um gerenciador de volume, ele compartilha os discos usados pelo Oracle RAC Database, é altamente recomendado que seja utilizado em um ambiente Oracle RAC.
Oracle Database
Responsável por organizar informações - ou dados - estruturados.
2: Arquitetura do Oracle RAC
Para fácil entendimento, farei um resumo da arquitetura do Oracle RAC.
Todo servidor é uma parte do Oracle RAC e este é chamado de node (nó).
Os clients se conectam entre eles através de uma rede pública (public network).
Os nodes se conectam entre eles através de rede privada (private network), conhecido como interconnect.
Os bancos de dados estão armazenados em uma área chamada Shared Storage.
O Oracle RAC possuí várias instâncias e toda instância é executada como um único nó (single node).
Para um banco de dados ficar disponível para seus clientes, ao menos uma instância deve estar no ar e funcionando.
Requerimentos de hardware
Dois ou mais servidores:
Arquitetura similar de hardware e mesmo sistema operacional
Duas placas de rede instaladas em cada servidor:
Rede pública: disponibilizada para os clients
Rede privada: para conexão entre os nodes
Configuração de redundância de rede privada é altamente recomendada
Shared storage
Requer rede de storage de alta velocidade
Redundância de conexões de storage com configuração de multipathing
Requerimentos de memória
Se você tem uma carga de trabalho que funciona em uma única instância, quando migrar de uma single instance para o RAC, mais memória será necessária:
10% a mais para buffer cache
15% a mais para shared pool
A memória será usada pelo ASM e processos de clusterware
A memória consumida pelas sessões dos clientes será distribuída entre as instâncias.
Opções de Shared Storage
ASM (opção recomendada)
Gerenciamento de volumes e file system para banco de dados Oracle
Mais eficiente para bancos de dados Oracle
Única opção suportada pela versão Oracle Standard Edition
Oracle ACFS
Estende a funcionalidade ASM para suportar todos os arquivos
Fornece redimensionamento automático de File System, acesso direto ao disk group do ASM, paralelismo de I/O
OCFS2 (Oracle Cluster File System 2)
Sistema de arquivos de uso geral de código aberto desenvolvido pela Oracle para linux ou General Parallel File System (GPFS) em plataformas IBM
Sistemas de arquivos de terceiros certificados pela Oracle
Veritas Storage Foundation Cluster File System (SFCFS) para Oracle RAC
NFS Server
Apenas o protocolo NFS versão 3 é suportado (NFSv3)
Engineered Systems
Oracle Database Appliance (ODA)
Prós: Testado para o máximo desempenho, fácil gerenciamento
Contras: Suporta apenas 2 nodes
Mais eficiente para uso em pequenos a médios ambientes.
Oracle Exadata Database Machine
Para grandes ambientes.
3: Sobre o Oracle Grid e Oracle Clusterware
Oracle Grid Infrastructure
Fornece recursos de gerenciamento de cluster mais recursos do ASM
Deve ser instalado em “local home”
Geralmente possui um usuário dedicado no sistema operacional “grid”
Recursos do Cluster Ready Service (CRS)
Instâncias ASM
ASM Diskgroup
Virtual IP (VIP) services
Single Client Access Name (SCAN)
SCAN listener
Database services
Oracle Net listener
Oracle Notification Service (ONS)
Oracle clusterware
Requer shared storage para armazenar:
Voting file para cada node
Oracle Clusterware Registry (OCR) para informação de configuração do cluster
Eles devem ser salvos em discos de alta redundância
Dados de configuração são armazenados em dois locais diferentes
Oracle Local registry (OLR): armazena os metadados do node local
Grid Plug and Play (GPnP) profile: network profile e Voting Files
Ele usa a rede privada (interconnect) para transportar a comunicação heartbeat.
Oracle Clusterware Network Configuration
Para configurar a rede do Oracle Clusterware, você tem duas opções.
Oracle Grid Naming Service (GNS)
Um subdomínio é delegado pelo DNS Server para o cluster
Você apenas define o GNS server VIP no DNS
DHCP é suportado apenas em sistemas operacionais Linux
Configuração Estática
Nenhum subdomínio é delegado no DNS server
Todos os nomes e endereços são resolvidos pelo DNS
Um SCAN name para resolver a árvore de endereço de IP estático no cluster
Um nome e endereço público e IP virtual para cada node
Um IP virtual e endereço para cada node
Single client Access Name (SCAN)
Um nome de domínio registrado de um até três endereços IP’s, seja em DNS ou GNS
Deve ser usado pelos clients quando se conectam ao RAC database
Node Virtual IP (VIP) é gerenciado pelo Clusterware
Deve ser atribuído a cada node
Deve estar na mesma subrede de um IP público
Fornece notificação de falha rápida e failover
Ciclo de conectividade Oracle RAC
O ciclo de conectvidade do Oracle RAC acontece basicamente em 4 passos:
Passo 1: Client faz uma requisição de conexão usando o SCAN name e um service name. O DNS ou GNS retorna para o client no endereço IP SCAN.
Passo 2: Usando um IP SCAN, o client conecta ao SCAN listener que fornece um nome de serviço.
Passo 3: O SCAN listener determina qual instância de banco de dados hospeda o serviço solicitado e determina a rota do client para o listener local do node.
Passo 4: O local listener conecta o client a instance local.
Localização de arquivos do Oracle RAC e Database
A localização dos arquivos de instalação do Oracle RAC ficam em cada node do ambiente, são chamados DB Home, o DB Home também pode ser instalado no shared storage mas não é recomendado pois em uma manutenção de aplicação de patch, por exemplo, será necessário baixar todos os nós para execução da mesma.
A shared storage é responsável por armazenar os arquivos de dados (datafiles) de sistema de e usuários, os arquivos de control file, SPFILE, password file e compartilhar com cada instância. Arquivos da tablespace de Undo e grupos de redo também são armazenados no mesmo local porém tem específicos para cada instância.
Espero que para você que chegou até o final dessa leitura tenha ficado mais fácil entender a arquitetura básica do Oracle RAC e seu funcionamento. Recomendo fortemente ver o tutorial completo disponibilizado pela Oracle (Oracle Real Application Clusters), no qual eu usei como referência para criar este conteúdo.
Abraço e De hands on!
Comentarios