Este artigo analisa quatro opções para conectar ao Oracle Database hospedado na OCI a partir de redes externas: IP público reservado, Network Load Balancer, NLB + Oracle Connection Manager e conectividade privada (VPN ou FastConnect). A conclusão é que, para ambientes RAC, apenas CMAN ou conectividade privada preservam SCAN, failover e balanceamento. Bypassar o SCAN com VIPs de nós em um NLB elimina funcionalidades críticas do RAC. Empresas brasileiras devem priorizar segurança e evitar atalhos que comprometam a alta disponibilidade.
Na maioria das arquiteturas, bancos Oracle são mantidos privados — acessíveis apenas dentro de redes confiáveis. No entanto, existem situações onde a conectividade de fora do Oracle Cloud Infrastructure (OCI) é necessária:
- Aplicações externas em outra nuvem ou datacenter
- Integrações com parceiros ou fornecedores
- Desenvolvimento ou testes remotos
- Arquiteturas de transição durante migrações
As opções abaixo estão ordenadas da mais simples (e menos segura) para a mais segura. Cada uma envolve um trade-off diferente entre complexidade, segurança e funcionalidades do banco.
Nota: Este artigo aplica-se ao Oracle Base Database Service (DBCS) no OCI — configurações standalone e RAC. Não se aplica ao Oracle Autonomous Database (ADB), que usa um modelo de conectividade diferente (endpoints gerenciados, TLS mútuo, porta 1522). As configurações específicas de OCI aqui discutidas não se aplicam a deployments Oracle em outros provedores de nuvem. Detalhes de implementação, comandos CLI e arquivos de configuração estão disponíveis no artigo complementar do Architecture Center.
1. Reserved Public IP — simples e direto
Atribuir um IP público reservado fornece um endereço fixo que permanece inalterado durante reboots, patching e ciclos de stop/start — sem infraestrutura adicional necessária.
Como isso expõe o banco diretamente à internet, restrinja o acesso usando Network Security Groups (NSGs) para permitir apenas IPs de origem específicos na porta TCP/1521. Considere emparelhar o IP reservado com um nome DNS para que os clientes se conectem a um hostname em vez de um endereço IP cru.
Trade-off: Mais simples de configurar, mas oferece a menor segurança. O banco fica diretamente acessível pela internet, sem camada intermediária para inspeção de tráfego ou controle de acesso além das regras do NSG.
2. Network Load Balancer — banco permanece privado
Quando a exposição direta não é aceitável, um OCI Network Load Balancer (NLB) oferece uma separação limpa. O NLB apresenta um endpoint público estável enquanto encaminha o tráfego para o banco em uma subnet privada. Como o tráfego Oracle Net é TCP (não HTTP), o NLB deve operar na Camada 4 — o Load Balancer padrão do OCI (Camada 7) não consegue lidar com SQL*Net.
Como o NLB opera na Camada 4, ele não valida a prontidão da sessão do banco, não faz terminação TLS nem fornece inteligência no nível da conexão. Health checks são baseados apenas em TCP — confirmam que a porta 1521 está acessível, não que o banco está aberto e aceitando sessões. Os clientes devem lidar com retries e resiliência de conexão.
Trade-off: O banco não fica mais diretamente exposto, mas o NLB não tem conhecimento do estado do banco ou do protocolo Oracle Net. É uma abstração de nível de rede, não um proxy consciente do banco.
Dica: Nós gerenciados pelo DBCS não aparecem no dropdown "Compute instances" do NLB — selecione "IP Address" como tipo de backend. Desabilite "Preserve Source IP" antes de adicionar backends por IP, ou a opção ficará cinza. O artigo do Architecture Center cobre o passo a passo completo no console e CLI.
3. NLB + CMAN — produção RAC com capacidades completas
O Oracle Connection Manager (CMAN) atua como um proxy consciente do protocolo que entende o tráfego Oracle Net e processa redirecionamentos SCAN (Single Client Access Name) internamente. O cliente externo se conecta através do NLB ao CMAN, e o CMAN lida com o redirecionamento em nome do cliente — o cliente nunca o vê.
Além de proxy SCAN, o CMAN fornece regras de controle de acesso para aceitar ou rejeitar conexões por IP de origem, destino e nome de serviço. Suporta filtragem de conexão para restringir quais clientes podem acessar quais serviços do banco, e multiplexação de sessões para reduzir o número de conexões ao banco. Para produção HA, implante múltiplas instâncias do CMAN atrás do NLB.
Trade-off: Preserva as capacidades completas do RAC (balanceamento SCAN, failover, roteamento por serviço) e adiciona segurança no nível da conexão, mas requer uma instância de computação separada para o CMAN, que precisa ser implantada e mantida.
4. Conectividade privada — a abordagem recomendada
Com IPSec VPN ou Oracle FastConnect, clientes externos se conectam ao OCI como se estivessem na mesma rede privada. O SCAN funciona nativamente — sem NLBs, sem CMAN, sem workarounds. Balanceamento de carga, failover e roteamento por serviço funcionam como foram projetados.
IPSec VPN é rápido de implantar para conectividade imediata. O Oracle FastConnect oferece um link privado dedicado para uso empresarial de longo prazo.
Trade-off: Maior segurança, sem exposição pública e com capacidades completas do RAC, mas requer infraestrutura de VPN ou um circuito FastConnect — o que envolve coordenação com a equipe de rede do cliente.
NLB com VIPs de nós RAC — uma nota sobre bypassar o SCAN
Em Oracle RAC, o listener SCAN redireciona clientes para um VIP de nó específico, exigindo uma nova conexão TCP para aquele endereço privado. Quando um NLB fica na frente do SCAN, clientes externos recebem um redirecionamento para um IP privado inalcançável — a conexão falha.
Configurar o NLB com VIPs de nós individuais como backends fornece um caminho de conexão tecnicamente funcional que bypassa o SCAN completamente. O NLB distribui conexões usando roteamento baseado em hash entre os nós RAC disponíveis.
É importante entender o que isso significa na prática. Com o SCAN bypassado, toda capacidade que diferencia o RAC de múltiplas instâncias standalone de banco deixa de valer:
- Balanceamento de carga consciente do workload — o NLB usa roteamento hash 5-tuple sem visibilidade da carga do banco; as conexões não são distribuídas com base na utilização da instância
- Roteamento por serviço — workloads OLTP e relatórios não podem ser direcionados para subconjuntos de nós designados
- Transparent Application Failover (TAF) — sessões ativas não são realocadas automaticamente quando um nó falha
- Fast Connection Failover (FCF) — a aplicação não recebe notificação de mudanças no estado do nó ou serviço
- Multiplexação de sessões — cada conexão do cliente mapeia diretamente para uma sessão no banco, sem consolidação
Nessa configuração, a infraestrutura RAC está presente, mas suas capacidades de gerenciamento de conexão não são utilizadas. A aplicação deve lidar de forma independente com distribuição de conexões, detecção de falhas, lógica de retry e resiliência de sessão — responsabilidades que SCAN, TAF e FCF são projetados para gerenciar na camada do banco.
Organizações que avaliam essa abordagem devem confirmar que seu framework de aplicação fornece gerenciamento de conexão equivalente, ou que essas capacidades não são necessárias para o workload. As opções 3 e 4 preservam o fluxo completo de conexão SCAN.
Perspectiva do cliente
Clientes que avaliam essas opções frequentemente priorizam segurança, confiabilidade e alinhamento com sua arquitetura geral. Em um desses casos, Michael Bilberry, Diretor de Infraestrutura e Segurança da RecVue, compartilhou sua perspectiva:
"Revisar as abordagens de conectividade disponíveis nos ajudou a identificar a opção que melhor se adequa ao nosso ambiente. Focamos em implementar uma solução alinhada aos nossos padrões de segurança, mantendo a arquitetura simples e confiável. A abordagem adotada se encaixa bem em nossos objetivos operacionais e de escalabilidade de longo prazo." — Michael Bilberry, Director of Infra & Security, RecVue
Comparação
A tabela a seguir resume as quatro opções recomendadas em dimensões chave para ajudar a identificar a mais adequada ao seu ambiente.
| Dimensão | Reserved IP | NLB | NLB + CMAN | Privada (VPN/FC) |
|---|---|---|---|---|
| Segurança | Baixa | Média | Alta | Muito Alta |
| Suporte RAC | Não | Não | Sim | Sim |
| SCAN preservado | N/A | Não | Sim | Sim |
| Roteamento consciente do DB | Não | Não | Sim | Sim |
| Latência | Baixa | Baixa | Média | Muito Baixa |
| Complexidade | Baixa | Média | Alta | Média |
Para um guia direto sobre qual opção escolher baseado no tipo de banco e requisitos de conectividade, use o diagrama de decisão abaixo.
Conclusão
A abordagem certa depende do ambiente. Para bancos standalone, um IP público reservado (com NSGs) ou um NLB oferecem um caminho direto — com segurança crescente à medida que você se move da exposição direta para uma subnet privada. Para Oracle RAC, o CMAN preserva o fluxo completo de conexão SCAN quando a conectividade privada não é viável, enquanto VPN ou FastConnect permanece a abordagem recomendada de longo prazo. A configuração de NLB com VIPs de nós, embora tecnicamente funcional, deve ser avaliada contra as capacidades do RAC que ela deixa de usar.
Perguntas Frequentes
-
Por que não posso simplesmente usar um NLB com VIPs de nós RAC para conectar de fora?
Bypassar o SCAN faz com que o NLB distribua conexões por hash, sem consciência de carga ou estado do banco. Recursos como balanceamento por workload, roteamento por serviço, TAF e FCF são perdidos. A aplicação precisa gerenciar sozinha failover e resiliência, o que pode ser arriscado para ambientes de produção. -
Qual a diferença entre NLB e NLB + CMAN para ambientes RAC?
O NLB puro opera em nível de rede (Layer 4) e não entende o tráfego Oracle Net. Já o CMAN é um proxy consciente do protocolo, capaz de interpretar redirecionamentos SCAN, aplicar regras de acesso e multiplexação de sessões, preservando as capacidades completas do RAC, incluindo balanceamento e failover. -
Conectividade privada é sempre a melhor escolha?
Sim, para ambientes críticos e de longo prazo. VPN ou FastConnect eliminam exposição pública, mantêm o SCAN nativo e oferecem baixa latência. Exige coordenação com a equipe de rede e, no caso do FastConnect, custos adicionais, mas é a opção mais segura e completa para produção. -
O artigo se aplica ao Autonomous Database (ADB)?
Não. O ADB usa um modelo de conectividade diferente — endpoints gerenciados, TLS mútuo e porta 1522. As opções discutidas são exclusivas para Oracle Base Database Service (DBCS) na OCI, tanto standalone quanto RAC. -
Quando faz sentido usar Reserved Public IP?
Apenas em cenários temporários, desenvolvimento ou testes, com restrição rigorosa por Network Security Groups. É a opção mais simples, mas expõe o banco diretamente à internet — não recomendada para produção, especialmente em ambientes regulados como os do mercado brasileiro.
Artigo originalmente publicado por Thangaraj Karol Stuart e Shiva Gurumurthy em cloud-infrastructure.
