Topologias
Saiba mais sobre topologias de rede para o Oracle AI Database@Azure.
A Oracle fornece exemplos de topologias de rede com base em diferentes casos de uso do Oracle AI Database@Azure, incluindo:
- Topologia VNet Local: Mesma conectividade de zona de disponibilidade
- VNet Topologia de Pareamento: Mesma zona de disponibilidade com vários clusters de VMs
- Topologia de Pareamento VNet Hub-and-Spoke: Conectividade entre VNet na mesma região com hub e spoke
- Conectividade Global entre Regiões: Conectividade entre regiões
- Rede on-premises com Hub-and-Spoke: conectividade on-premises (híbrida) com hub e spoke
Componentes da Topologia
As topologias usam os seguintes componentes:
- Região do Azure: Uma região do Azure é uma área geográfica na qual um ou mais data centers físicos do Azure, chamados de zonas de disponibilidade, residem. Regiões são independentes de outras regiões, e grandes distâncias podem separá-las (entre países ou mesmo continentes).
As regiões do Azure e da OCI são áreas geográficas localizadas. Para o Oracle AI Database@Azure, uma região do Azure é conectada a uma região da OCI, com zonas de disponibilidade (AZs) no Azure conectadas a domínios de disponibilidade (ADs) na OCI. Os pares de regiões do Azure e da OCI são selecionados para minimizar a distância e a latência.
- Azure VNet: A Rede Virtual do Microsoft Azure (VNet) é o bloco de construção fundamental da sua rede privada no Azure. O VNet permite que muitos tipos de recursos do Azure, como máquinas virtuais (VM) do Azure, se comuniquem com segurança entre si, com a internet e com redes on-premises.
- Sub-rede Delegada do Azure: A delegação de sub-rede é a capacidade da Microsoft de injetar um serviço gerenciado, especificamente um serviço de plataforma como serviço (PaaS), diretamente na sua rede virtual. Isso permite que você designe ou delegue uma sub-rede para ser um home de um serviço gerenciado externo dentro da sua rede virtual, de modo que o serviço externo atue como um recurso de rede virtual, mesmo que seja um serviço PaaS externo.
- VNIC do Azure: Os serviços nos data centers do Azure têm placas de interface de rede (NICs) físicas. As instâncias de máquina virtual se comunicam usando NICs virtuais (VNICs) associadas às NICs físicas. Cada instância tem uma VNIC principal que é criada e anexada automaticamente durante a inicialização e está disponível durante o tempo de vida da instância.
- Tabela de Roteamento do Azure (Rota Definida pelo Usuário – UDR): As tabelas de roteamento virtual contêm regras para rotear o tráfego de sub-redes para destinos fora de um VNet, geralmente por meio de gateways. As tabelas de roteamento são associadas a sub-redes em um VNet.
- Gateway de Rede Virtual do Azure: O Gateway de Rede Virtual do Azure estabelece conectividade segura entre locais entre uma rede virtual do Azure e uma rede local. Ele permite que você crie uma rede híbrida que abrange seu data center e o Azure.
Topologias de Exemplo
O Oracle AI Database@Azure e a conectividade de aplicativos podem ser configurados de várias maneiras para atender às necessidades organizacionais. As seguintes seções são as principais topologias de rede:
Topologia VNet Local
A Topologia Local VNet enfatiza fundamentalmente o princípio de co-localização de recursos de aplicativos e o banco de dados Oracle AI Database@Azure no mesmo Azure VNet, principalmente para otimização de desempenho. Embora pode ser implantado em uma única AZ, esse padrão de topologia também pode abranger várias Zonas de Disponibilidade se o próprio VNet for projetado para isso (por exemplo, sub-redes de aplicativos em AZ1 e AZ2, sub-rede delegada Oracle AI Database@Azure em AZ1). O princípio básico permanece: os aplicativos e o banco de dados residem dentro do mesmo limite VNet.
A seguinte arquitetura mostra uma topologia VNet local:
Casos de Uso
Esta topologia é a escolha preferida quando:
- Minimizar a latência de rede entre os aplicativos e o banco de dados Oracle é a principal preocupação.
- A simplicidade da rede e evitar custos de pareamento VNet são preferíveis.
- Várias aplicações ou camadas de aplicações distintas precisam acessar o mesmo cluster Oracle AI Database@Azure, mas exigem separação lógica usando sub-redes diferentes dentro do VNet compartilhado.
Detalhamento do Componente
Os componentes são os seguintes:
- Componentes do Azure: VNet, Sub-rede Delegada, Sub-rede(s) do Aplicativo, Tabelas de Roteamento (rotas do sistema), Zona de DNS Privado do Azure.
- Componentes do OCI Implícitos: VCN de Serviço, Sub-rede do Cliente, Sub-rede de Backup, Link do Plano de Controle, DNS Privado do OCI, Listas de Segurança/NSGs do OCI.
Principais Considerações
- Latência: Fornece melhor (menor) latência de rede entre aplicativos co-localizados e o banco de dados.
- Custo: A maioria da topologia de rede econômica devido à ausência de encargos de pareamento VNet.
- Segurança Confia no isolamento no nível da sub-rede usando NSGs do Azure (para aplicativos) e Listas de Segurança/NSGs do OCI (para o banco de dados). Oferece menos segmentação de rede em comparação com projetos usando VNets separado (como Hub-Spoke). Todos os aplicativos compartilham o mesmo espaço de endereço VNet, o que pode ser uma preocupação em ambientes altamente segmentados.
- Gerenciabilidade: Configuração e gerenciamento de rede relativamente simples.
VNet Topologia de Pareamento
Essa topologia envolve o estabelecimento de conexões diretas entre o Aplicativo VNets e o VNet que hospeda a sub-rede delegada Oracle AI Database@Azure usando o Pareamento VNet do Azure. Essa configuração não depende necessariamente de um Hub central VNet para trânsito entre esses VNets específicos. A configuração pode variar de um pareamento simples entre o theOracle AI Database@Azure VNet e um único Aplicativo VNet a uma malha mais complexa em que vários Aplicativos VNets são pareados diretamente com o Oracle AI Database@Azure VNet.
A seguinte arquitetura mostra uma topologia de pareamento VNet local:
Casos de Uso
Esta topologia é a escolha preferida quando ocorre o seguinte:
- Implantação de Aplicação Única: Pareamento direto entre o aplicativo VNet e o Oracle AI Database@Azure VNet para comunicação de baixa latência.
- Arquitetura de Aplicativos Multicamadas: Pareamento direto entre VNets de diferentes camadas de aplicativos e o Oracle AI Database@Azure VNet para uma comunicação eficiente.
- Arquitetura de Microsserviços: Pareamento direto entre vários microsserviços VNets e o Oracle AI Database@Azure VNet para implementação escalável.
- Ambientes de Desenvolvimento e Teste: Pareamento direto entre o desenvolvimento, o teste e a produção VNets e o Oracle AI Database@Azure VNet para acesso isolado.
- Configuração de Recuperação de Desastres: Pareamento direto entre a recuperação de desastres VNet e o Oracle AI Database@Azure VNet para failover eficiente.
- Análise e Geração de Relatórios de Dados: Pareamento direto entre a análise VNet e o Oracle AI Database@Azure VNet para obter insights de dados oportunos.
- Requisitos de Conformidade e Regulamentação: Pareamento direto entre o VNets compatível e o Oracle AI Database@Azure VNet para acesso seguro e eficiente.
Detalhamento do Componente
Os seguintes componentes para esta topologia:
- Componentes do Azure:
- VNet (hospedando o Oracle AI Database@Azure)
- Sub-rede do Azure (Delegada)
- VNet(s) (Aplicativos de hospedagem)
- Sub-rede(s) do Azure (Aplicativo)
- VNet Conexão(ões) de pareamento (Regional)
- Tabelas de Roteamento do Azure (Normalmente, as rotas do sistema são suficientes para pareamento direto, a menos que sejam necessárias substituições específicas)
- Zona(s) de DNS Privado(s) do Azure (Vinculada em VNets pareado para resolução)
- (Opcional para Global) Gateway VPN / WAN Virtual do Azure
- Componentes Implícitos do OCI:
- VCN de Serviço, Sub-rede do Cliente, Sub-rede de Backup, Link do Plano de Controle, DNS Privado do OCI, Listas de Segurança/NSGs do OCI.
Principais Considerações
- Latência: Oferece baixa latência para pareamento regional, comparável à topologia Local VNet à medida que o tráfego flui diretamente pelo backbone do Azure entre o VNets pareado. A latência para pareamento global (via VPN/vWAN) é muito maior, ditada pela distância entre regiões.
- Custo: O pareamento VNet incorre em encargos de transferência de dados de entrada e saída entre o VNets pareado. Em um cenário de malha com muitos VNets pareados com o Oracle AI Database@Azure VNet, esses custos podem se acumular com base no volume de tráfego.
- Segurança: A segurança de rede depende dos NSGs do Azure aplicados às VNets/sub-redes do Aplicativo e às Listas/NSGs de Segurança do OCI aplicadas à sub-rede/VNICs delegadas do Oracle AI Database@Azure. Este modelo não tem o ponto de inspeção centralizado oferecido pela topologia Hub-Spoke. O gerenciamento da política de segurança é distribuído pelo VNets pareado.
- Gerenciabilidade: A configuração é mais simples do que o Hub-Spoke para um pequeno número de pareamentos. No entanto, o gerenciamento de um grande número de relacionamentos de pareamento direto (uma "malha completa") pode se tornar complexo em termos de rastreamento de conexões, gerenciamento de possíveis sobreposições de IP (embora o pareamento exija IPs não sobrepostos) e implementação de roteamento consistente ou políticas de segurança.
- Escalabilidade: embora o próprio pareamento seja escalável, a complexidade operacional do gerenciamento de vários pareamentos diretos pode ser um desafio em comparação com a abordagem estruturada do Hub-Spoke.
- Limitação de Conectividade Global: A incapacidade de usar o Pareamento Global VNet direto para o tráfego do Oracle AI Database@Azure sem tunelamento (VPN) ou serviços extras (vWAN) é uma restrição significativa para projetar acesso simples e direto a aplicativos entre regiões.
Topologia de Pareamento VNet Hub-and-Spoke
O Hub VNet funciona como um ponto centralizado de conectividade, ajudando na comunicação entre aplicativos e bancos de dados. O spoke VNets estabelece conexões com o Hub por pareamento VNet e requer uma tabela de Roteamento (UDR) do Azure para rotear para o Hub NVA. Selecione essa topologia se você não tiver aplicativos sensíveis à latência por causa do salto adicional necessário e considere que o pareamento VNet resulta em custos de entrada e saída.
A seguinte arquitetura mostra uma topologia de pareamento VNet hub-and-spoke com o Azure Firewall ou NVA:
Casos de Uso
- Gerenciamento de Segurança Centralizado: Use um hub VNet para centralizar serviços de segurança, como firewalls e gateways de VPN para vários spoke VNets.
- Acesso ao Shared Services: Ative serviços compartilhados, como DNS e Active Directory, no hub VNet acessível por todos os spoke VNets.
- Gerenciamento de Rede Simplificado: Gerencie políticas de rede e roteamento centralmente no hub VNet para aplicativos consistentes em todos os spoke VNets.
- Integração da Nuvem Híbrida: Conecte redes locais ao hub VNet para integração perfeita com recursos do Azure no spoke VNets.
- Conectividade entre Várias Regiões: Use o hub VNet para ajudar na conectividade global entre o spoke regional VNets para alta disponibilidade e resiliência.
- Isolamento de Recursos: Isole diferentes departamentos ou projetos em spoke separado VNets, mantendo o controle centralizado no hub VNet.
- Otimização de Custos: Otimize os custos operacionais centralizando recursos de rede caros no hub VNet compartilhado por vários spoke VNets.
Detalhamento de Componentes
- Componentes do Azure:
- Hub VNet (hospedando serviços compartilhados)
- Spoke VNet(s) (para Aplicativos)
- Spoke VNet (para Oracle AI Database@Azure, contendo Sub-rede Delegada)
- Sub-rede do Azure (Delegada)
- Sub-rede(s) do Azure (Aplicativo)
- Sub-rede do Azure (GatewaySubnet no Hub)
- Sub-rede do Azure (AzureFirewallSubnet ou sub-rede NVA no Hub)
- VNet Pareamento (Spokes to Hub)
- Tabelas de Roteamento do Azure com UDRs (em Spokes, sub-redes do Hub)
- Firewall do Azure ou NVA de terceiros (no Hub)
- Gateway VPN/ExpressRoute do Azure (Opcional, no Hub)
- Zona(s) DNS Privada(s) do Azure (vinculada(s) a VNets)
- Componentes Implícitos do OCI:
- VCN de Serviço, Sub-rede do Cliente, Sub-rede de Backup, Link do Plano de Controle, DNS Privado do OCI, Listas de Segurança/NSGs do OCI.
Principais Considerações
- Centralização e Controle: Fornece excelente centralização para aplicação de políticas de segurança, gerenciamento de conectividade (on-premises, entre regiões) e implantação de serviços compartilhados.
- Latência: Introduz mais latência de rede em comparação com a topologia Local VNet por causa do salto extra necessário por meio do Hub VNet e, potencialmente, do Firewall/NVA. Cada salto adiciona atraso, o que pode ser significativo para aplicativos de chat. Minimizar o lúpulo usando pareamento direto entre falas (se viável e seguro) ou evitar travessias desnecessárias de NVA é recomendado quando o desempenho é crítico.
- Custo: incorre em encargos de pareamento VNet para todo o tráfego que transita pelo Hub. Custos significativos associados ao licenciamento e throughput do Azure Firewall ou NVA, além de custos potenciais do Gateway.
- Segurança: postura de segurança aprimorada devido à inspeção e segmentação centralizadas.
- Gerenciabilidade: Mais complexo de configurar e gerenciar por causa do aumento do número de VNets, configurações de pareamento e gerenciamento de UDR complexo necessário na topologia.
Roteamento e segurança
Roteamento e segurança são as características definidoras desta topologia:
- Rotas Definidas pelo Usuário (UDRs): Os UDRs são essenciais para controlar o fluxo de tráfego.
- Em Spokes de Aplicativo: os UDRs são necessários para forçar o tráfego destinado ao intervalo de endereços do Spoke do Oracle AI Database@Azure (ou potencialmente todo o tráfego não local) para o endereço IP interno do Firewall/NVA do Azure no Hub VNet como o próximo salto.
- No Spoke do Oracle AI Database@Azure (incluindo sub-rede delegada): os UDRs são necessários para rotear o tráfego de retorno para os Spokes do Aplicativo por meio do Firewall do Hub/NVA. As regras de especificidade do prefixo UDR (o prefixo deve ser >= CIDR da sub-rede delegada) devem ser seguidas.
- Na Sub-rede de Gateway do Hub (se aplicável): os UDRs podem direcionar o tráfego que chega do local para o Firewall/NVA antes de atingir os raios.
- Firewall de NVA/Azure: O appliance de segurança central no Hub VNet inspeciona e filtra o tráfego que flui entre os Spokes de Aplicativos e o Spoke de Oracle AI Database@Azure, impondo políticas de segurança organizacionais. Ele também pode fornecer NAT (Network Address Translation) se necessário.
Conectividade Global entre Regiões
Para implementar a conectividade entre regiões entre as sub-redes delegadas do Oracle AI Database@Azure, com recursos de rede avançados ativados, configure o pareamento VNet Global do Azure para estabelecer conectividade global perfeita entre as VNets. Considere essa topologia para replicação de dados entre regiões ou para conectar cargas de trabalho entre regiões. Como alternativa, você pode implantar o Azure VWAN ou Hub-and-spoke para passar por um Hub em vez de parear as sub-redes delegadas VNet diretamente. Essa topologia incorre em custos adicionais e introduz latência; avalie suas cargas de trabalho e desempenho.
A seguinte arquitetura mostra a conectividade global entre regiões:
Casos de Uso
- Acesso Global a Dados: Ative o acesso contínuo ao Oracle AI Database@Azure em várias regiões para aplicações globais.
- Recuperação de Desastres: Implemente a conectividade entre regiões para garantir recursos robustos de recuperação de desastres e failover.
- Alta Disponibilidade: Obtenha alta disponibilidade distribuindo instâncias do Oracle AI Database@Azure em diferentes regiões.
- Otimização de Desempenho: Otimize o desempenho do aplicativo conectando recursos regionais à instância mais próxima do Oracle AI Database@Azure.
- Conformidade e soberania de dados: atenda aos requisitos de conformidade e soberania de dados hospedando dados em regiões específicas, mantendo a conectividade.
- Gerenciamento Centralizado: Use a conectividade entre regiões para centralizar o gerenciamento da rede e simplificar as operações.
- Eficiência de Custos: Equilibre custos operacionais aproveitando recursos regionais e conectividade para o Oracle AI Database@Azure.
Detalhamento de Componentes
- Componentes do Azure:
- VNets (nas Regiões Principal e Stand-by)
- Sub-redes do Azure (Delegadas em cada VNet)
- Serviço de Conectividade: WAN Virtual do Azure (Hubs, Conexões) OU VPN Gateways OU Pareamento VNet (Regional, potencialmente Global com sobreposição de VPN)
- Tabelas de Roteamento do Azure com UDRs (para direcionar o tráfego entre regiões por meio do caminho escolhido)
- Zona(s) DNS Privada(s) do Azure (exigindo uma estratégia para resolução de nomes entre regiões, possivelmente por meio de recursos de DNS vWAN ou encaminhamento condicional)
- Componentes Implícitos do OCI:
- VCNs de Serviço (nas Regiões Principal e Stand-by do OCI pareadas)
- Sub-redes do Cliente, Sub-redes de Backup
- Links do Plano de Controle
- Listas de Segurança do OCI/NSG(s)
- Zonas de DNS Privadas do OCI
- DRGs do OCI, potencialmente RPGs (Remote Peering Gateways) do OCI se estiverem usando o caminho de rede do OCI para replicação.
- Componentes Oracle:
- Configuração do Oracle Data Guard (atribuições Principal/Stand-by, definições de transporte de redo).
Principais Considerações
- Latência: A latência de rede entre regiões é o principal fator que influencia o desempenho do Data Guard e a escolha do modo de replicação (Assíncrono recomendado). O mecanismo de conectividade específico (vWAN, VPN, OCI Path) afetará a latência real alcançada.
- Custo: As cobranças de saída de dados entre regiões do Azure podem ser grandes para o tráfego de replicação do Data Guard que flui pela rede do Azure. Os custos associados a vWAN, VPN Gateways ou potencialmente o caminho da OCI (embora mencione os primeiros 10 TB/mês gratuitos para a OCI entre regiões) devem ser considerados.
- Largura de Banda: O link de rede entre regiões deve ter largura de banda suficiente para acomodar a taxa de pico de geração de redo do banco de dados principal para evitar atraso de replicação.
- RPO/RTO: O design deve se alinhar ao RPO (Recovery Point Objective) e ao RTO (Recovery Time Objective) da organização. A replicação assíncrona implica RPO > 0. O RTO depende do mecanismo de failover (manual ou automatizado com Failover de Início Rápido) e do tempo necessário para alternar funções e redirecionar aplicativos.
- Complexidade: A implementação e o gerenciamento de redes entre regiões e o Data Guard adicionam uma complexidade significativa em comparação com implantações de região única. Os procedimentos de failover e switchover devem ser bem definidos e testados regularmente.
- Opção de Caminho de Conectividade: Decidir se rotear o tráfego do Data Guard por meio do caminho padrão do Azure ou explicitamente por meio do caminho de rede do OCI é uma decisão de design crítica. O caminho do Azure pode ser mais simples de configurar inicialmente, mas sujeito ao desempenho e aos custos padrão entre regiões do Azure. O caminho da OCI, embora potencialmente ofereça melhor desempenho ou diferentes estruturas de custo, requer configurações de roteamento mais complexas envolvendo UDRs do Azure e potencialmente políticas de roteamento da OCI para substituir o caminho padrão do Azure. Essa decisão requer uma avaliação cuidadosa com base em testes de desempenho, análise de custos e recursos operacionais.
Roteamento e segurança
- Roteamento:
- Gerenciamento de Roteamento Centralizado: O VWAN Hub gerencia de forma centralizada o roteamento, simplificando as operações de rede e garantindo políticas de roteamento consistentes entre as regiões.
- Seleção de Caminho Otimizado: O VWAN Hub seleciona os caminhos mais eficientes para a transmissão de dados entre regiões, reduzindo a latência e melhorando o desempenho.
- Atualizações de Roteamento Dinâmico: atualiza automaticamente as tabelas de roteamento para se adaptar às alterações de rede e manter a conectividade ideal.
- Conectividade entre Regiões: Facilita a conectividade perfeita entre o VNets em diferentes regiões, permitindo acesso global ao Oracle AI Database@Azure.
- Propagação de Rota: Propaga rotas entre VNets conectadas e redes on-premises, garantindo uma integração de rede abrangente.
- Segurança:
- Configuração de Firewall: Configure firewalls dentro do Hub VWAN para inspecionar e filtrar todo o tráfego, aumentando a segurança.
- Inspeção de Tráfego: Implemente inspeção profunda de pacotes para monitorar e controlar o fluxo de dados entre regiões, impedindo o acesso não autorizado.
- Segmentação de Rede: Use o Hub VWAN para segmentar o tráfego de rede, isolando dados confidenciais e aplicativos para maior segurança.
- Conectividade Segura: Estabeleça conexões seguras usando VPN ou ExpressRoute para proteger dados em trânsito entre regiões.
- Controle de Acesso: Aplique políticas de controle de acesso rigorosas para gerenciar permissões e garantir que somente entidades autorizadas possam acessar o Oracle AI Database@Azure.
- Detecção de Ameaças: Integre mecanismos de detecção e resposta de ameaças dentro do VWAN Hub para identificar e mitigar ameaças de segurança em tempo real.
Rede On-Premises com Hub e Spoke
Conectar data centers on-premises ou redes de usuários com segurança a aplicações no Azure que usam o Oracle AI Database@Azure é um requisito comum. O gateway aprende as rotas através da transitividade. O spoke do banco de dados VNet aprende a rota por meio de pareamento. Se você selecionar essa topologia, considere que essa topologia incorre em custos e adiciona latência. O Azure fornece dois mecanismos principais para estabelecer essa conectividade híbrida:
- Gateway de VPN do Azure: Esse serviço permite a criação de túneis de VPN IPsec/IKE criptografados Site a Site (S2S) na internet pública entre um dispositivo de VPN local e um Gateway de VPN do Azure implantado em um Azure VNet (normalmente um Hub VNet em cenários corporativos). O Oracle AI Database@Azure suporta conectividade por meio de gateways de VPN Ativos/Passivos e gateways de VPN Ativos/Ativos Redundantes de Zonas, mas notavelmente não gateways de VPN Ativos/Ativos padrão.
- Azure ExpressRoute: Este serviço fornece uma conexão privada dedicada entre a rede on-premises e a rede global da Microsoft por meio de um provedor de conectividade. Um circuito ExpressRoute termina em um Gateway ExpressRoute implantado em um VNet do Azure (novamente, geralmente um Hub VNet). O Oracle AI Database@Azure suporta conectividade por meio de circuitos ExpressRoute Locais e Globais. No entanto, o ExpressRoute FastPath, uma otimização que ignora o gateway para determinado tráfego, não é suportado para conectividade Oracle AI Database@Azure.
A seguinte arquitetura mostra uma topologia local hub-and-spoke:
Casos de Uso
- Integração da Nuvem Híbrida: Conecte redes locais ao hub VNet para integração perfeita com recursos do Azure no spoke VNets.
- Gerenciamento de Segurança Centralizado: Use o hub VNet para centralizar serviços de segurança para recursos locais e do Azure.
- Migração de Dados: Facilite a migração de dados segura e eficiente de bancos de dados on-premises para o Oracle AI Database@Azure por meio do hub VNet.
- Recuperação de Desastres: Implemente soluções de recuperação de desastres conectando redes locais ao hub VNet para failover para o Oracle AI Database@Azure.
- Requisitos de Conformidade e Regulamentação: Garanta a conformidade conectando com segurança redes locais ao hub VNet para acesso controlado ao Oracle AI Database@Azure.
- Otimização de Desempenho: Otimize o desempenho da aplicação conectando redes locais ao hub mais próximo VNet para obter acesso eficiente ao Oracle AI Database@Azure.
- Isolamento de Recursos: Isole recursos locais confidenciais, mantendo a conectividade segura com o Oracle AI Database@Azure por meio do hub VNet.
Detalhamento de Componentes
- Componentes do Azure:
- Hub VNet (Comum, hospedando Gateway e opcionalmente Firewall)
- Oracle AI Database@Azure Falado VNet
- Sub-rede do Azure (Delegada)
- Sub-rede do Azure (GatewaySubnet no Hub)
- Sub-rede do Azure (AzureFirewallSubnet ou sub-rede NVA no Hub, opcional)
- Gateway de VPN do Azure ou Gateway do Azure ExpressRoute (no Hub)
- Pareamento VNet (Hub para o Oracle AI Database@Azure Spoke, com o Gateway Transit ativado)
- Tabelas de Roteamento do Azure com UDRs (na Sub-rede Delegada, GatewaySubnet, potencialmente Sub-redes de Aplicativo)
- Firewall do Azure ou NVA (Opcional, no Hub)
- Componentes Implícitos do OCI:
- VCN de Serviço, Sub-rede do Cliente, Sub-rede de Backup, Link do Plano de Controle, Listas de Segurança/NSGs do OCI.
- Componentes On-Premises:
- Gateway de Cliente / Dispositivo VPN / Roteador
- Firewall
- Circuito ExpressRoute (se estiver usando ExpressRoute)
Principais Considerações
- Bandwidth & Latency: ExpressRoute geralmente oferece largura de banda mais alta e mais previsível e menor latência em comparação com VPNs baseadas na internet. A escolha depende dos requisitos de desempenho e do orçamento do aplicativo.
- Confiabilidade e SLA: O ExpressRoute geralmente fornece SLAs de maior disponibilidade em comparação com o VPN Gateways. A redundância é crítica; use vários túneis VPN, gateways redundantes de zona ou circuitos ExpressRoute duplos conectados a diferentes locais para alta disponibilidade.
- Segurança: A VPN fornece criptografia IPsec pela internet. O ExpressRoute fornece uma conexão privada, ignorando a internet pública; a criptografia (por exemplo, túneis MACsec ou IPsec pelo pareamento privado) pode ser adicionada, se necessário. Firewalls on-premises e potencialmente no Hub do Azure fornecem filtragem de tráfego essencial.
- Complexidade de Roteamento: Requer configuração cuidadosa de protocolos de roteamento (o BGP é comum para ExpressRoute e VPNs dinâmicas) ou rotas estáticas on-premises, UDRs do Azure e definições de Trânsito do Peering Gateway VNet. Configurações incorretas podem levar a falhas de conectividade ou roteamento abaixo do ideal.
- Custo: Inclui custos para Gateways de VPN do Azure ou ExpressRoute, cobranças do circuito ExpressRoute (velocidade da porta, plano de dados, taxas do provedor) e custos de transferência de dados associados.
Roteamento e segurança
- Roteamento:
- Gerenciamento de Roteamento Centralizado: O hub VNet gerencia o roteamento de forma centralizada, garantindo políticas de roteamento consistentes nas regiões do Azure e nas redes locais.
- Seleção de Caminho Otimizado: O hub VNet seleciona os caminhos mais eficientes para transmissão de dados entre regiões e redes on-premises, reduzindo a latência e melhorando o desempenho.
- Atualizações de Roteamento Dinâmico: atualiza automaticamente as tabelas de roteamento para se adaptar às alterações de rede, mantendo a conectividade ideal entre os recursos locais e do Azure.
- Conectividade entre Regiões: Facilita a conectividade perfeita entre VNets em diferentes regiões e redes on-premises, permitindo o acesso global ao Oracle AI Database@Azure.
- Propagação de Rota: Propaga rotas entre VNets conectadas, redes on-premises e outras regiões, garantindo uma integração de rede abrangente.
- Integração de Rede Híbrida: Integra redes locais com o Azure VNets por meio do hub, permitindo gerenciamento unificado e operações simplificadas.
- Segurança:
- Configuração de Firewall: Configure firewalls dentro do hub VNet para inspecionar e filtrar todo o tráfego, aprimorando a segurança para redes locais e do Azure.
- Inspeção de Tráfego: Implemente inspeção profunda de pacotes para monitorar e controlar o fluxo de dados entre regiões e redes on-premises, evitando acesso não autorizado.
- Segmentação de Rede: Use o hub VNet para segmentar o tráfego de rede, isolando dados confidenciais e aplicativos para melhorar a segurança entre regiões e redes locais.
- Conectividade Segura: Estabeleça conexões seguras usando VPN ou ExpressRoute para proteger dados em trânsito entre redes on-premises e regiões do Azure.
- Controle de Acesso: Aplique políticas de controle de acesso rigorosas para gerenciar permissões e garantir que somente entidades autorizadas possam acessar o Oracle AI Database@Azure de redes locais.
- Detecção de Ameaças: Integre mecanismos de detecção e resposta a ameaças dentro do hub VNet para identificar e mitigar ameaças de segurança em tempo real entre regiões e redes locais.
- Conformidade e Adesão Regulatória: Garanta a conformidade com os requisitos regulatórios implementando medidas de segurança robustas no hub VNet para conectividade on-premises e do Azure.
Recursos
Para saber mais sobre as Topologias de Rede do Azure, consulte Planejamento de rede para Oracle Database@Azure na biblioteca de documentação da Microsoft.