Um requisito importante do Oracle Grid Infrastructure é o suporte a Multicast na rede do interconnect.
A Virtual Cloud Network (VCN) na OCI não suporta Multicast, o que é comum na maioria dos provedores de Cloud. Essa restrição impede uma instalação bem sucedida do Grid Infrastructure.
Outra restrição encontrada foi ao atribuir mais de um IP para a mesma VNIC, impossibilitando a comunicação entre as VM’s através dos VIP (Virtual IP configurado pelo Clusterware).
Neste post abordo um workround usando uma VPN n2n da ntop que permite dar um bypass nessas restrições e finalmente poder instalar o Oracle RAC para laboratórios usando VM instances na OCI.
Note que isso não é suportado e trata-se de um laboratório.
Se estiver se perguntando porque eu simplesmente não crio um RAC pelo serviço OCI DB System:
a) Eu queria fazer a instalação manual como faço nos meus laboratórios com VMware vSphere ESXi.
b) É muito mais barato o valor OCPU/hora.
c) Eu acabo aprendendo mais os recursos de rede e storage da OCI.
Como isso funciona?
Utilizando uma VPN n2n, podemos criar uma rede virtual entre os nodes utilizados pelo Cluster, opcionalmente com o auxílio de uma terceira VM que funciona como “router” dessa rede virtual.
Essa terceira VM (eu usei uma always free) atua como supernode, e os nós do cluster atuam como Edge. Todos os Edge apontam para um Supernode para conhecer os outros Edges.
Essa ilustração apresenta uma rede com 2 supernodes, mas só precisamos de um.
Abaixo como eu usei no meu laboratório:
Baixando e compilando o n2n
Download
O n2n é disponibilizado no Github, a gente precisa compilar os executáveis “supernode” e “edge”, depois copiá-los para o diretório /usr/sbin de todos os servidores.
Acesse o link do repositório e baixe a versão estável.
Copie o arquivo .zip baixado para um dos servidores Linux, eu usei na VM que uso como bastion e que também uso como supernode dessa configuração pelo fato de ela estar sempre ligada.
Compilando os executáveis
Instale esses pacotes via yum, pois serão requisitados ou pelo autogen.sh, configure.sh ou pelo make.
yum install -y pfring-dkms n2disk nprobe ntopng cento
yum install -y kernel-headers automake autoconf gcc
Navegue para o diretório de onde os arquivos foram extraídos .
Neste exemplo a pasta foi extraída no home do usuário opc: /home/opc.
# cd /home/opc/n2n-2.6-stable/
Obs: Se der erro na execução de algum dos 3 comandos a seguir por causa alguma dependência, procure no google/yum. Eu listei todos que precisei instalar na minha VM após algumas tentativas e erro, acredito que serão o suficiente para você.
Execute o primeiro script: autogen.sh
# ./autogen.sh
Tendo sucesso no primeiro, execute o segundo: configure.sh
# ./configure
Tendo sucesso no segundo, execute o make:
# make
Verifique se foi gerado os dois executáveis supernode e edge:
# ls -l supernode
# ls -l edge
Instalando o n2n nos servidores
A instalação não é nada mais do que copiar os 2 executáveis para o diretório /usr/sbin de cada nó do cluster, e a VM que será o supernode, claro.
Como eu realizei esse procedimento na VM que será meu supernode, já copiei os arquivos nela:
cp supernode /usr/sbin/
cp edge /usr/sbin/
Copiando para os dois nós de cluster.
# scp supernode root@rac01:/usr/sbin
# scp edge root@rac01:/usr/sbin
# scp supernode root@rac02:/usr/sbin
# scp edge root@rac02:/usr/sbin
Nota: Eu configurei o acesso ssh do root com senha sem a chave publica nessas VM, talvez você precise usar o scp com usuário opc e informando a chave pública com o parâmetro -i.
Configurando o supernode
Execute o comando supernode informando uma porta na qual ele ficará recebendo o registro dos edges com o parâmetro -l. Nesse exemplo eu usei a porta 1200 para a rede privada e porta 1300 para rede pública.
# nohup supernode -l 1200 &
# nohup supernode -l 1300 &
Libere essa porta no firewall. Eu desabilitei o firewall.
# systemctl stop firewalld
Configurando os clientes (edge) para rede privada
Execute esse comando na própria VM que é supernode e em todos os nós do cluster.
edge -l 10.1.0.2:1200 -c RAC_Private -a 192.168.1.21 -E -r -d edge0 -s 255.255.255.0
Entendendo o comando:
-l identifica o IP e a porta da VM em que o supernode está executando. No meu laboratório, está no IP 10.1.0.2.
-c identifica uma community no n2n, em outras palavras, isso é o nome da rede. No meu exemplo, eu criei como “RAC_Private”.
-a identifica o IP que você quer atribuir para essa VM atual, dentro da rede virtual. Eu usei o IP 192.168.1.21 para o nó rac01 e 192.168.1.22 para nó rac02.
-d identifica o nome do device que será criado no Linux, o nome apresentado no comando ifconfig.
-s identifica a máscara da rede, eu estou usando 255.255.255.0.
Verifique o device criado com o comando ifconfig:
Configurando os clientes (edge) para rede pública (SCAN, VIP)
O procedimento é o mesmo, apenas mude a rede, o nome do device e a porta do supernode de 1200 para 1300.
edge -l 10.1.0.2:1300 -c RAC_Public -a 100.10.1.21 -E -r -d edge1 -s 255.255.255.0
Neste exemplo, o Scan e VIP`s devem ser configurados nessa rede 100.10.1.0/24.
Configurando o roteamento da rede interna do interconnect 169.254.0.0/16
Durante a instalação do Grid Infrastructure, é criado uma rede 169.254.0.0/16 como virtual IP sobre a rede privada. Também é realizado um teste de broadcast na rede 224.0.0.0.
A configuração a seguir permite o tráfego dessas redes pelo device edge0:
Execute no supernode e todos os nós do cluster.
route add -net 224.0.0.0 netmask 240.0.0.0 dev edge0
route add -net 169.254.0.0 netmask 255.255.0.0 dev edge0
Configuração para iniciar a rede virtual no reboot
Essa configuração não persiste no reboot do Linux, é necessário executar como script ou como serviço na inicialização do sistema. Porém, precisa iniciar depois que a placa de rede padrão já foi iniciada e antes do startup do Clusterware.
Então mais um workround nesse laboratório foi incluir esses comandos utilizados anteriormente na configuração dos edges no final do script que carrega as placas de rede do Linux no boot, fiz isso em cada nó do cluster.
# vi /etc/rc.d/init.d/network
Inclua no final do arquivo, depois do esac e antes da linha contendo “exit $rc”. Deve ficar assim:
Lembre de colocar os comandos com os IP corretos em cada servidor.
Execute um reboot e verifique se as placas de rede edge0 e edge1 foram carregadas, e se estão comunicando-se corretamente.
Conclusão
Após realizar essas configurações, você pode instalar o Clusterware selecionando o device edge0 para a rede privada e edge1 para a rede pública. Para o device ens3 (default) deixe como “não use”.
Salve os executáveis supernode e edge em algum local e apenas copie para novas VM quando quiser criar um laboratório novo ou estender o seu cluster atual, sem a necessidade de compilar toda vez que for usar.
Esse procedimento pode ser adotado em outras Cloud, afinal parte das minhas pesquisas se basearam em exemplos de deploy na AWS.
Referências:
http://www.ntop.org/products/n2n/
blog.pythian.com/network-multicast-support-azure/
db.geeksinsight.com/wp-content/uploads/2016/05/Installing-Two-Node-RAC-in-AWS-Cloud.pdf
http://www.oracle.com/cloud/networking/virtual-cloud-network-faq.html
docs.oracle.com/en/database/oracle/oracle-database/19/cwlin/multicast-requirements-for-networks-used-by-oracle-grid-infrastructure.html#GUID-09DA3502-5880-4E72-88C0-CBE8E4893DF7