Eu tenho encontrado várias perguntas sobre endereços IP virtuais (VIP) para Oracle RAC recentemente. Espero que esta postagem no blog possa ajudar a esclarecer o que é um VIP, como eles funcionam e por que o Oracle RAC os aproveita. Antes de prosseguir, devo explicar que não sou especialista em Redes. Na verdade, a rede de computadores é provavelmente o meu ponto mais fraco de tudo o que acontece nas lojas de TI. Portanto, não me chame se eu não conseguir o material de rede inteiramente, 100% preciso. Vou explicar isso em termos que me serviram bem em minha carreira de DBA, especialmente trabalhando com Oracle RAC.

A maioria das pessoas está familiarizada com a conexão de qualquer aplicativo, SQL*Plus ou outros, a um servidor de banco de dados de instância única. No final, sua solicitação de conexão é enviada para um endereço IP específico. Em nosso diagrama abaixo, o usuário final deseja se conectar ao 192.168.1.1 para acessar o banco de dados. A solicitação de rede é roteada para o switch de rede ao qual o servidor de banco de dados está conectado. Esse switch passa a solicitação para o servidor que possui o endereço IP solicitado.





A maioria dos DBAs Oracle não tem problemas para entender esse conceito. A vida fica um pouco mais complicada quando o RAC é implantado, pois há várias máquinas (nós) no cluster. No próximo diagrama, temos um cluster RAC de dois nós, cada nó com um endereço IP diferente.



O usuário final não se importa com qual nó sua sessão está conectada. O usuário final quer apenas acesso ao cluster. Qualquer nó será suficiente. A configuração TNSNAMES.ORA do usuário final pode dizer para tentar 192.168.1.1 primeiro e se isso não funcionar, tente 192.168.1.2. Dessa forma, o Oracle RAC está fornecendo uma solução de Alta Disponibilidade.

Agora chegamos a todo o motivo pelo qual os endereços IP virtuais devem ser usados. E se o usuário final estiver tentando acessar o primeiro nó (192.168.1.1), mas não estiver disponível? O nó está inativo por algum motivo. O usuário final pode se conectar facilmente ao nó 192.168.1.2. No entanto, devido à maneira como as redes TCP/IP funcionam, pode levar até dez minutos para que a conexão de rede com 192.168.1.1 atinja o tempo limite antes que 192.168.1.2 seja acessada. A longa espera de tempo limite do TCP/IP é o único motivo para o Oracle RAC aproveitar os VIPs. Simplesmente queremos reduzir o tempo para acessar outro nó no cluster caso nosso nó solicitado esteja indisponível.

Um IP tradicional geralmente é vinculado à placa de rede no servidor. O administrador de TI configurará o servidor para sempre usar esse endereço IP específico e nenhum outro dispositivo na rede usará o mesmo IP. Nota:estou tentando simplificar aqui e evitar DHCP e registro de concessão para aqueles que estão familiarizados com os tópicos.

Um endereço IP virtual não está vinculado à placa de rede. Nem está definido no sistema operacional. O VIP não é um endereço IP real da mesma forma que uma máquina virtual não é um sistema real. Apenas parece ser real para aqueles que o utilizam. Então, vamos olhar para o nosso cluster de dois nós, mas desta vez com os VIPs definidos para eles.



Nossos servidores ainda têm seus endereços IP regulares, 192.168.1.1 e 192.168.1.2 para NODE1 e NODE2, respectivamente. Esses dois nós também têm VIPs associados a eles. NODE1-VIP e NODE2-VIP são indicados como endereços IP 192.168.1.11 e 192.168.1.12, respectivamente. Cada nó no cluster RAC tem seu endereço IP regular e um VIP. Também pode ser benéfico saber que o nome do host e os nomes VIP são frequentemente definidos no DNS para que não precisemos lembrar os endereços IP especificamente.

Observe que o usuário final agora está solicitando o acesso a um dos VIPs. As únicas pessoas que devem usar esses endereços IP tradicionais são os administradores de TI que precisam realizar trabalhos no servidor. Os usuários finais e todos e quaisquer aplicativos devem se conectar ao VIP.

Lembra que eu disse anteriormente que o VIP nem está definido no sistema operacional? Bem, se for esse o caso, como tudo sabe que o VIP está atribuído a esse nó? Tudo isso é tratado pela Grid Infrastructure (GI). Quando o GI for instalado, uma das telas do Oracle Universal Installer (OUI) solicitará os nomes dos nós no cluster (os nomes de host) junto com o nome do host virtual. A captura de tela abaixo mostra como a instalação do 11g GI ficou ao solicitar essas informações (captura de tela da documentação do Oracle).



O nome de host público é configurado no sistema operacional pelo administrador. O IP virtual não está configurado no sistema operacional, mas o Grid Infrastructure sabe disso. Para entender como isso funciona, precisamos divagar um pouco e entender o Address Resolution Protocol (ARP).

Quando um servidor é inicializado e seus componentes de rede são iniciados, o Address Resolution Protocol é o mecanismo que informa ao switch na frente do servidor para rotear todo o tráfego de seu endereço IP para o endereço MAC de sua placa de rede. O sistema operacional, por meio do ARP, informa ao switch para ir para o NODE1 para solicitações 192.168.1.1.

Quando o Grid Infrastructure é iniciado, uma de suas tarefas de inicialização é fazer algo semelhante. O GI, por meio do ARP, informa ao switch para ir para NODE1 para todas as solicitações NODE1-VIP (192.168.1.11). Até que o GI inicie o VIP, esse endereço VIP não pode ser roteado.

Agora, aqui está a parte mágica... quando o NODE1 ficar inativo, o GI em outro nó do cluster detectará a interrupção. O GI executará então uma nova operação ARP que informa ao switch para rotear o VIP para outro nó no cluster. Como o VIP é virtual, ele pode ser redirecionado em tempo real. No diagrama abaixo, NODE1 falhou. Seu IP tradicional também não está mais disponível. O GI re-ARPed o VIP para o nó restante no cluster.



O re-ARPing do VIP pode ser realizado em segundos. O usuário final pode experimentar uma breve pausa na comunicação de rede entre o aplicativo e a instância do banco de dados, mas isso é muito, muito menos do que se esperássemos pelos tempos limite do TCP/IP.

O Oracle 11gR2 introduziu os Listeners SCAN. Um cluster Oracle RAC pode ter no máximo três SCAN Listeners. O nome SCAN ainda está no DNS, mas o DNS fará o round-robin da resolução do nome SCAN para um de até três endereços IP diferentes.

No diagrama abaixo, nosso cluster de dois nós agora tem dois listeners SCAN. O usuário final faz uma solicitação de conexão para my-scan.acme.com e o DNS resolve o nome para 192.168.1.21 ou 192.168.1.22.



Conforme mostrado acima, esses dois VIPs SCAN são atribuídos a nós diferentes no cluster. Se o NODE1 ficar inativo, o Grid Infrastructure irá realocar o NODE1-VIP e o MY-SCAN (192.168.1.21) para um nó sobrevivente no cluster, por meio da mesma operação de re-ARP sobre a qual falamos anteriormente. Os novos ouvintes SCAN e seus VIPs são tratados da mesma forma que os VIPs antigos.

Para recapitular, os endereços IP virtuais são usados ​​para fornecer failover mais rápido das comunicações de rede entre o aplicativo e os nós no cluster. O sistema operacional usa o Address Resolution Protocol para permitir que o switch de rede saiba rotear as conexões para o host. O Grid Infrastructure usa as mesmas operações ARP para permitir que o switch de rede saiba para onde rotear o tráfego para o VIP e o SCAN VIP. Caso um nó fique inativo, o GI fará um novo ARP do VIP e SCAN VIP para outro nó no cluster.