segunda-feira, 15 de abril de 2013

Oracle RAC Cache Fusion - Oracle HAIP - Saiba como configurar


Oracle Cache Fusion é um dos componentes mais importante de um ambiente Oracle RAC. Como o próprio nome já indica, trata-se da fusão dos caches (buffers) de memória dos vários servidores que compõem a arquitetura de cluster da Oracle.

Cada instância possui seu próprio buffer local. Imagine que uma transação na Instância "A" precisa acessar um bloco de dados que está em uso na Instância "B". O mecanismo que possibilita que a instância "A" tenha acesso ao bloco da instância "B" é denominado CACHE FUSION. Ou seja, uma instância pode acessar um bloco de dados que se encontra no cache de outra instância via uma interconexão de alta velocidade.

Podemos agora imaginar o quanto este processo é crítico para a performance da solução Oracle RAC. Mas e se configurarmos somente uma placa de rede para executar esta tarefa e esta ficar indisponível por qualquer razão que seja. Imagine agora outra situação que é a limitação de banda da rede, geralmente limitada a 1GB, que pode ficar saturada facilmente dependendo do tipo de aplicação que está sendo rodada no ambiente.

Até pouco tempo poderíamos contornar esta limitação de banda e de disponibilidade do canal configurando o mecanismo de "BONDING". Este termo é usado para representar a junção de 2 placas de rede para aparecer como um único dispositivo com o mesmo endereço MAC. O objetivo é aumentar a largura de banda e possibilitar o contingenciamento da rede na eventual falha de um de seus componentes.

A Oracle, a partir da versão 11gR2 criou o protocolo HAIP (High Availability Internet Protocol) para substituir o bonding. A intenção da Oracle é prover melhor performance e alta disponibilidade com a configuração de até 4 placas de rede.

Como configurar o Oracle HAIP?

Vamos usar o utilitário da Oracle chamado: oifcfg

O Oracle Grid irá criar um apelido denominado IP Privado usando a sub-rede 169.254.*.* para usar no HAIP. 

Passo 1: Identifique os endereços privados de IP
[root@db01 bin]# ./oifcfg getif
eth0  192.168.1.0  global  cluster_interconnect
eth1  10.91.119.0  global  public


Passo 2: Adicione e configure uma nova interface de rede privada (eth4)
[oracle@db01 bin]$ ./oifcfg iflist
eth0  192.168.1.0
eth0  169.254.0.0
eth4  192.168.1.0
eth1  10.91.119.0


Passo 3: Use o utilitário setif para configurar a nova interface de rede com o tipo cluster interconnect.
[oracle@db01 ~]$ oifcfg setif -global eth4/192.168.1.0:cluster_interconnect

Passo 4: Pare o serviço de cluster em todos os servidores(nós do cluster):
[oracle@db01 ~]# sudo /u01/app/11.2.0/grid/bin/crsctl stop cluster -all

(usar sudo - passo 4 - ou logar como root - passo 5)

Passo 5: Inicie o serviço de cluster nos servidores
[root@db01 ~]# /u01/app/11.2.0/grid/bin/crsctl start cluster -all


Passo 6: Confira suas alterações do ambiente:
[root@coltdb01 bin]# ./oifcfg getif
eth0  192.168.1.0  global  cluster_interconnect
eth1  10.91.119.0  global  public
eth4  192.168.1.0  global  cluster_interconnect


[root@coltdb01 bin]# ./oifcfg iflist -p -n
eth0  192.168.1.0  PRIVATE  255.255.255.0
eth0  169.254.0.0  UNKNOWN  255.255.128.0
eth4  192.168.1.0  PRIVATE  255.255.255.0
eth4  169.254.128.0  UNKNOWN  255.255.128.0
eth1  10.91.119.0  PRIVATE  255.255.255.0





quinta-feira, 11 de abril de 2013

Oracle RAC Usar Admin-managed ou Policy-managed database?

A partir da versão 11.2 do banco de dados Oracle surgiram estes conceitos de admin-managed e policy-managed. Mas qual é a diferença entre eles?

Para simplificar, digo que quando se usa a opção admin-managed estamos assumindo o controle de recursos do banco de dados. Na opção policy-managed, deixamos o controle para o serviço de cluster RAC.

Admin-managed é a antiga forma de configurar o serviço de cluster, veja mais sobre o conceito de serviço clicando aqui.

Usando a opção policy-managed, simplificamos a vida do DBA que não mais precisa estar preocupado em gerenciar cada instância em cada servidor individualmente. Agora inserimos o conceito de conjunto (pool) de servidores para gerenciar as diversas instâncias.


Quando você define um serviço como admin-managed será preciso definir também quais instâncias irão suportar este serviço. A instância escolhida é denominada PREFERRED. Também podem ser definidas instâncias chamadas AVAILABLE que podem vir a suportar o serviço em caso de falha da principal (PREFERRED).

Quando você define um serviço como policy-managed significa dizer que um conjunto de servidores (server pool) irá atender a este serviço. Nesta modalidade ainda podemos ter uma política uniforme (uniform policy) ou simples (singleton). Na política uniform o serviço será atendido por todas as instâncias do pool de servidores. Na opção singleton o RAC escolhe a instância do pool que irá atender ao serviço, em caso de falha desta, o serviço migra (failover) para elege uma instância disponível.

Então, qual opção usar?

Caso você tenha um amplo conhecimento do que roda no seu ambiente e tem tempo para ficar administrando recurso use admin-managed.

Mas a minha opção é usar a policy-managed, com política uniforme, pois deixamos no automático com melhor escalabilidade. Adicionamos novos servidores ou removemos conforme a necessidade e deixamos para o RAC decidir qual  nó o serviço irá rodar.

Você conhece uma situação comum que se recomende o uso do serviço admin-managed?