Configuração da Rede para Instâncias do Exadata Cloud Infrastructure

Este tópico descreve a configuração recomendada da VCN e diversos requisitos relacionados da instância do Exadata Cloud Infrastructure.

Antes de configurar uma instância do Exadata Cloud Infrastructure, configure uma VCN (rede virtual na nuvem) e outros Componentes do serviço Networking.

VCN e Sub-redes
Para iniciar uma instância do Exadata Cloud Infrastructure, você deve ter uma Rede Virtual na Nuvem e pelo menos duas sub-redes:
Acesso do Nó ao Serviço Object Storage: Rota Estática
Para poder fazer backup de bancos de dados e aplicar patch e atualizar ferramentas de nuvem em uma instância do Exadata Cloud Infrastructure, configure o acesso ao Oracle Cloud Infrastructure Object Storage.
Gateway de Serviço para a VCN
Sua VCN precisa de acesso ao Object Storage para backups e ao repositório YUM da Oracle para atualizações do sistema operacional.
Regras de Segurança do Oracle Exadata Database Service on Dedicated Infrastructure
Esta seção lista as regras de segurança a serem usadas com o Exadata Cloud Infrastructure.
Formas de Implementar as Regras de Segurança
Saiba como implementar regras de segurança na sua VCN usando o serviço de rede.
Requisitos de Rede para o Oracle Database Autonomous Recovery Service
O Oracle Database Autonomous Recovery Service requer uma sub-rede registrada do Recovery Service dedicada a operações de backup e recuperação na rede virtual na nuvem (VCN) do seu banco de dados.

Tópico principal: Preparação para o Exadata Cloud Infrastructure

VCN e Sub-redes

Para iniciar uma instância do Exadata Cloud Infrastructure, você deve ter uma Rede Virtual na Nuvem e pelo menos duas sub-redes:

Para iniciar uma instância do Exadata Cloud Infrastructure, você deve ter uma Rede Virtual na Nuvem, pelo menos duas sub-redes e selecionar o tipo de resolvedor de DNS que usará:

Uma VCN na região em que você deseja a instância do Exadata Cloud Infrastructure
Pelo menos duas sub-redes na VCN. As duas sub-redes são:
- Sub-rede do cliente
- Sub-rede de backup
Escolha qual método de resolução de nome DNS você usará. Consulte Opções para DNS na Sua VCN

Observação

Para instâncias do Exadata Cloud Infrastructure que usam O Novo Modelo de Recurso do Exadata Cloud Infrastructure, a rede é configurada no recurso de cluster de VMs na nuvem.

A sub-rede do cliente pode ser configurada com a rede de pilha dupla IPv4 ou IPv4/IPv6.

Em geral, a Oracle recomenda o uso de sub-redes regionais , que abrangem todos os domínios de disponibilidade da região. Para obter mais informações, consulte Visão Geral de VCNs e Sub-redes.

Você criará tabelas de roteamento tabelas de roteamento personalizadas para cada sub-rede. Você também criará regras de segurançaregras de segurança para controlar o tráfego de/para a rede do cliente e a rede de backup dos nós de computação do Exadata (para O Recurso de Cluster de VMs na Nuvem, os nós são chamados de máquinas virtuais). São exibidas mais informações a seguir sobre esses itens.

Opção 1: Sub-rede de Cliente Pública com Gateway de Internet
Esta opção pode ser útil ao realizar um trabalho de desenvolvimento ou de prova de conceito.
Opção 2: Sub-redes Privadas
A Oracle recomenda sub-redes privadas para um sistema de produção.
Requisitos para Espaço de Endereço IP
Os endereços IP não devem ser sobrepostos, especialmente quando os Clusters de VMs do Exadata Cloud Infrastructure (e, portanto, VCNs) estiverem em mais de uma região.
Configurando uma Rota Estática para Acessar o Armazenamento de Objetos
Para rotear o tráfego de backup para a interface de backup (BONDETH1), é preciso configurar uma rota estática em cada um dos nós de computação do cluster.
Configurando o DNS para uma Instância do Exadata Cloud Infrastructure
O DNS permite que você use nomes de host em vez de endereços IP para comunicação com uma instância do Exadata Cloud Infrastructure.
DNS: Nomes Curtos para a instância da VCN, Sub-redes e Exadata Cloud Infrastructure
O resolvedor de Internet e VCN permite a designação de nome de host para os nós e a resolução de DNS desses nomes de host por recursos na VCN.
DNS: Entre Rede Local e VCN
A Oracle recomenda o uso de um resolvedor de DNS privado para permitir o uso de nomes de host quando hosts locais e recursos de VCN se comunicarem.
Configurar DNS Privado
Pré-requisitos necessários para usar DNS Privado.

Tópicos Relacionados

Tópico principal: Configuração de Rede para Instâncias do Exadata Cloud Infrastructure

Opção 1: Sub-rede de Cliente Pública com Gateway de Internet

Essa opção pode ser útil ao realizar um trabalho de desenvolvimento ou de prova de conceito.

Você pode usar essa configuração na produção, se quiser usar um gateway de internet com a VCN ou se tiver serviços que são executados apenas em uma rede pública e precisar de acesso ao banco de dados. Consulte o diagrama e a descrição a seguir.

Veja a seguir a descrição de network_exa_public_client.png

Descrição da ilustração network_exa_public_client.png

Você configura:

Sub-redes:
- Sub-rede de cliente Pública (pública significa que os recursos na sub-rede podem ter endereços IP públicos a seu critério).
- Sub-rede de backupPrivada (privada significa que os recursos da sub-rede não podem ter endereços IP públicos e, portanto, não podem receber conexões de entrada da internet).
Gateways para a VCN:
- Gateway de Internet (para uso da sub-rede do cliente).
- Gateway de serviço (para uso da sub-rede de backup). Consulte também Opção 1: Acesso do Gateway de Serviço aos Serviços do OCI.
Tabelas de roteamento:
- Tabela de roteamento personalizada para a sub-rede de cliente pública, com uma rota para 0.0.0.0/0 e destino = o gateway de internet.
- Tabela de roteamento personalizada separada para a sub-rede de backup privada, com uma regra de roteamento para os labels CIDR de serviço (consulte Sobre Labels CIDR em Visão Geral dos Gateways de Serviço e Labels CIDR de Serviços Disponíveis) e destino = o gateway de serviço. Consulte também Opção 1: Acesso do Gateway de Serviço aos Serviços do OCI.
Regras de segurança para permitir o tráfego desejado de/para os nós de computação das máquinas virtuais do Exadata. Consulte Regras de Segurança do Oracle Exadata Database Service on Dedicated Infrastructure.
Acesso do Nó ao Object Storage: Rota Estática nos nós de computação da instância do Exadata Cloud Service (para permitir o acesso aos serviços do OCI por meio da sub-rede de backup).

Observação

Importante Consulte este problema conhecido para obter informações sobre como configurar regras de roteamento com o gateway de serviço como destino em tabelas de roteamento associadas a sub-redes públicas.

Tópico principal: VCN e Sub-redes

Opção 2: Sub-rede Privada

A Oracle recomenda sub-redes privadas para um sistema de produção.

Ambas as sub-redes são privadas e não podem ser acessadas pela internet. Consulte o diagrama e a descrição a seguir.

Veja a seguir a descrição de network_exa_private_client.png

Descrição da ilustração network_exa_private_client.png

Você configura:

Sub-redes:
- Sub-rede de cliente Privada.
- Sub-rede de backup Privada.
Gateways para a VCN:
- DRG (Gateway de roteamento dinâmico), com um FastConnect ou VPN IPSec para sua rede on-premises (para uso da sub-rede do cliente).
- Gateway de serviço Para uso das sub-redes de backup e do cliente para acessar Serviços do OCI, como o Object Storage para backups, YUM para atualizações do sistema operacional, IAM (Identitiy Access Management) e OCI Vault (Integração do KMS), consulte também Opção 2: Acesso do Gateway de Serviço ao Object Storage e ao Repositório YUM.
- Gateway NAT(opcional) Para uso da sub-rede do cliente para acessar pontos finais públicos não suportados pelo gateway de serviço.
Tabelas de roteamento:
- Tabela de roteamento personalizada para a sub-rede de cliente privada, com as seguintes regras:
  - Uma regra para o CIDR da rede on-premises e destino = DRG.
  - Uma regra para o label do CIDR de serviço chamado Todos os Serviços de <region> no Oracle Services Network e destino = o gateway de serviço. O Oracle Services Network é uma rede conceptual no Oracle Cloud Infrastructure reservada para os serviços Oracle. A regra permite que a sub-rede do cliente acesse o repositório regional YUM da Oracle para atualizações do sistema operacional. Consulte também Opção 2: Acesso do Gateway de Serviço ao Object Storage e ao Repositório YUM.
  - Opcionalmente, uma regra para 0.0.0.0/0 e destino = gateway NAT.
- Tabela de rota personalizada separada para a sub-rede de backup privada, com uma regra:
  - A mesma regra da sub-rede do cliente: para o label do CIDR de serviço chamado Todos os Serviços de <region> no Oracle Services Network e destino = o gateway de serviço. Essa regra permite que a sub-rede de backup acesse o Object Storage regional para backups.
Regras de segurança para ativar o tráfego desejado de/para os nós do Exadata. Consulte Regras de Segurança da instância do Exadata Cloud Service.
Opcionalmente, adicione uma Rota estática nos nós de computação a outros serviços do OCI (para clusters de VMs, as máquinas virtuais) para permitir o acesso, se os serviços só puderem ser acessados na sub-rede de backup e não via sub-rede do cliente, por exemplo, ao usar um Gateway NAT.

Tópico principal: VCN e Sub-redes

Requisitos de Espaço de Endereço IP

Os endereços IP não devem se sobrepor, especialmente quando os Clusters de VMs (e, portanto, VCNs) do Exadata Cloud Infrastructure estiverem em mais de uma região.

Se você estiver configurando Clusters de VMs do Exadata Cloud Infrastructure (e, portanto, VCNs) em mais de uma região, certifique-se de que o espaço de endereço IP das VCNs não se sobreponha. Isso é importante se você quiser configurar a recuperação de desastre com o Oracle Data Guard.

Para o Exadata X8 e versões anteriores, as duas sub-redes que você cria para os Clusters de VMs do Exadata Cloud Infrastructure não devem se sobrepor a 192.168.128.0/20.

Para o Exadata X8M, X9M e X11M, os endereços IP 100.64.0.0/10 são reservados para a interconexão e não devem ser usados para as VCNs do cliente ou de backup, bem como para clientes de banco de dados.

A tabela a seguir lista os tamanhos mínimos de sub-rede necessários, dependendo do Exadata VM Infrastructure para cada tamanho de Cluster de VMs. Para a sub-rede do cliente, cada nó exige quatro endereços IP e, além disso, três endereços são reservados para SCANs (Single Client Access Names). Para a sub-rede de backup, cada nó exige três endereços.

Tamanho do Rack	Sub-rede do Cliente: Número de Endereços IP Necessários	Sub-rede do Cliente: Observação do Tamanho Mínimo	Sub-rede de Backup: Número de Endereços IP Necessários	Sub-rede de Backup: Observação do Tamanho Mínimo
Sistema Base ou Quarter Rack por Cluster de VMs	(4 endereços * 2 nós) + 3 para SCANs = 11	/28 (16 endereços IP)	3 endereço * 2 nós = 6	/28 (16 endereços IP)
Meio Rack por Cluster de VMs	(4 * 4 nós) + 3 = 19	/27 (32 endereços IP)	3 * 4 nós = 12	/28 (16 endereços IP)
Rack Completo por Cluster de VMs	(4* 8 nós) + 3 = 35	/26 (64 endereços IP)	3 * 8 nós = 24	/27 (32 endereços IP)
Sistemas de infraestrutura flexível (X8M e posteriores) por Cluster de VMs	4 endereços por nó de banco de dados (no mínimo 2 nós) + 3 para SCANs	Tamanho mínimo determinado pelo número total de endereços IP necessários para nós de banco de dados	3 endereços por nó de banco de dados (no mínimo 2 nós)	Tamanho mínimo determinado pelo número total de endereços IP necessários para nós de banco de dados

Observação

O serviço Networking reserva três endereços IP em cada sub-rede. Alocar um espaço maior que o mínimo necessário para a sub-rede (por exemplo, pelo menos /25 em vez de /28) pode reduzir o impacto relativo desses endereços reservados no espaço disponível da sub-rede.

Tópico principal: VCN e Sub-redes

Configurando uma Rota Estática para Acessar o Armazenamento de Objetos

Todo o tráfego de uma instância do Exadata Cloud Infrastructure é, por padrão, roteado pela rede de dados. Para rotear o tráfego de backup para a interface de backup (BONDETH1), é preciso configurar uma rota estática em cada um dos nós de computação do cluster.

Para obter instruções, consulte Acesso do Nó ao Object Storage: Rota Estática.

Tópico principal: VCN e Sub-redes

Configurando o DNS para uma Instância do Exadata Cloud Infrastructure

O DNS permite que você use nomes de host em vez de endereços IP para comunicação com uma instância do Exadata Cloud Infrastructure.

Você pode usar o Resolvedor de Internet e VCN (o recurso DNS incorporado na VCN), conforme descrito em DNS na sua Rede Virtual na Nuvem. A Oracle recomenda o uso de um Resolvedor de VCN para resolução de nome DNS da sub-rede do cliente. Ele resolve automaticamente os pontos finais Swift necessários para fazer backup de bancos de dados, aplicar patches e atualizar o conjunto de ferramentas da nuvem em uma instância do Exadata.

Tópico principal: VCN e Sub-redes

DNS: Nomes Curtos para a VCN, Sub-redes e instância do Exadata Cloud Infrastructure

Para que os nós se comuniquem, a VCN deve usar o Resolvedor de Internet e VCN. O resolvedor de Internet e VCN permite a designação de nomes aos nós e a resolução de DNS deles por recursos na VCN.

O resolvedor de Internet e VCN permite a resolução de repetição alternada dos SCANs do banco de dados. Também permite a resolução de pontos finais de serviços importantes necessários para fazer backup de bancos de dados, aplicar patches e atualizar o conjunto de ferramentas da nuvem em uma instância do Exadata Cloud Infrastructure. O Resolvedor de Internet e VCN é a opção padrão da VCN para DNS na VCN. Para obter mais informações, consulte DNS na sua Rede Virtual na Nuvem e também Opções de DHCP.

Ao criar a VCN, as sub-redes e o Exadata, defina com cuidado os seguintes identificadores que estão relacionados ao DNS na VCN:

Label de domínio da VCN
Label de domínio da sub-rede
Prefixo de nome de host do recurso de cluster de VMs na nuvem ou sistema de banco de dados da instância do Exadata Cloud Infrastructure

Esses valores compõem o FQDN (nome de domínio totalmente qualificado) do nó:

<hostname_prefix>-######.<subnet_domain_label>.<vcn_domain_label>.oraclevcn.com

Por exemplo:

exacs-abcde1.clientpvtad1.acmevcniad.oraclevcn.com

Neste exemplo, você designa exacs como o prefixo do nome do host ao criar o cluster de VMs na nuvem ou o sistema de banco de dados. O serviço Database inclui automaticamente um hífen e uma string de cinco letras com o número do nó no final. Por exemplo:

Nó 1: exacs-abcde1.clientpvtad1.acmevcniad.oraclevcn.com
Nó 2: exacs-abcde2.clientpvtad1.acmevcniad.oraclevcn.com
Nó 3: exacs-abcde3.clientpvtad1.acmevcniad.oraclevcn.com
E assim por diante

Requisitos para o prefixo do nome do host:

Máximo recomendado: 12 caracteres. Para obter mais informações, consulte o exemplo na seção a seguir, "Requisitos para os labels de domínio da VCN e da sub-rede".
Não pode ser a string localhost

Requisitos para labels de domínio da VCN e da sub-rede:

Máximo recomendado: 14 caracteres cada. O requisito subjacente real é um total de 28 caracteres nos dois labels de domínio (excluindo o período entre os labels). Por exemplo, ambos são aceitáveis: subnetad1.verylongvcnphx ou verylongsubnetad1.vcnphx. Para simplificar, a recomendação é de 14 caracteres cada.
Sem hifens ou sublinhados.
Recomendado: inclua o nome da região no label de domínio da VCN e inclua o nome do domínio de disponibilidade no label de domínio da sub-rede.
Em geral, FQDN tem um limite total máximo de 63 caracteres. Veja a seguir uma regra geral segura:

<12_chars_max>-######.<14_chars_max>.<14_chars_max>.oraclevcn.com

Os máximos anteriores não são impostos quando você cria a VCN e as sub-redes. No entanto, se os labels excederem o máximo, a implantação do Exadata falhará.

Tópico principal: VCN e Sub-redes

DNS: Entre Rede On-Premises e VCN

A Oracle recomenda o uso de um resolvedor de DNS privado para permitir o uso de nomes de host quando hosts on-premises e recursos de VCN se comunicarem.

Consulte Resolvedores de DNS Privados para obter informações sobre como criar e usar resolvedores privados. Para obter uma arquitetura de referência, consulte Usar DNS privado na VCN no Oracle Architecture Center.

Tópico principal: VCN e Sub-redes

Configurar DNS Privado

Pré-requisitos necessários para usar DNS Privado.

A view privada e a zona privada devem ser criadas antes da inicialização do provisionamento do sistema de banco de dados. Para obter detalhes, consulte Resolvedores de DNS Privados.
O encaminhamento para outro servidor DNS deve ser configurado antecipadamente na console do DNS. Isso pode ser feito indo para o resolvedor da VCN e criando o ponto final e depois as regras. Para obter detalhes, consulte DNS na Sua Rede Virtual na Nuvem.
O nome da zona privada não pode ter mais de 4 rótulos. Por exemplo, a.b.c.d é permitido enquanto a.b.c.d.e não for.
Também é necessário adicionar a view privada ao resolvedor da VCN. Para obter detalhes, consulte Adicionando uma View Privada a um Resolvedor.
Ao provisionar um Cluster de VMs do Exadata usando a funcionalidade de DNS Privado, o Exadata precisa criar zonas de DNS reversas no compartimento do Cluster de VMs do Exadata. Se o compartimento tiver tags ou padrões de tag definidos, políticas adicionais relacionadas ao gerenciamento de tags serão necessárias. Para obter detalhes, consulte:
- permissões necessárias para trabalhar com tags definidas
- permissões necessárias para trabalhar com padrões de tag

Tópico principal: VCN e Sub-redes

Acesso do Nó ao Object Storage: Rota Estática

Para poder fazer backup de bancos de dados e aplicar patches e atualizar ferramentas de nuvem em uma instância do Exadata Cloud Infrastructure, configure o acesso ao Oracle Cloud Infrastructure Object Storage. Independentemente de como você configura a VCN com esse acesso (por exemplo, com um gateway de serviço), talvez você também precise configurar uma rota estática para o Object Storage em cada um dos nós de computação no cluster. Isso só é necessário se você não estiver usando backups automáticos. Se você estiver usando backups personalizados com as APIs de backup, deverá rotear o tráfego destinado ao serviço Object Storage por meio da interface de backup (BONDETH1). Isso não será necessário se você estiver usando os backups automáticos criados com a Console, APIs ou CLIs.

Cuidado:

Configure uma rota estática para acesso ao serviço Object Storage em cada nó de computação de uma instância do Exadata Cloud Infrastructure se você não estiver criando backups automáticos com a Console, APIs ou CLIs. Caso contrário, as tentativas de fazer backup de bancos de dados e aplicar patches ou atualizar ferramentas no sistema poderão falhar.

Observação

Quando você ativar o primeiro backup automático para um banco de dados, a configuração de rota estática será feita automaticamente no serviço.

Se você quiser aplicar patches ao serviço antes de criar um banco de dados, a rota estática manual deverá ser capaz de aplicar patches ao Home do grid infrastructure ou do banco de dados.

A rota estática também pode ser necessária para acessar outros serviços (IAM, KMS) se não for possível acessá-los por meio da sub-rede do cliente e somente a sub-rede de backup usar a definição para acessar todos os serviços em uma região.

Tópico principal: Configuração de Rede para Instâncias do Exadata Cloud Infrastructure

Alocações de IP do Object Storage

Tópico principal: Acesso do Nó ao Object Storage: Rota Estática

Para configurar uma rota estática para acesso ao Object Storage

Estabeleça conexão via SSH com um nó de computação na instância do Exadata Cloud Infrastructure.
```
ssh -i <private_key_path> opc@<node_ip_address>
```
Faça log-in como opc e, em seguida, sudo para o usuário raiz. Use sudo su - com um hífen para chamar o perfil do usuário raiz.
```
login as: opc
			
[opc@dbsys ~]$ sudo su - 
```

Identifique o gateway configurado para a interface BONDETH1.

[root@dbsys ~]# grep GATEWAY /etc/sysconfig/network-scripts/ifcfg-bondeth1 |awk -F"=" '{print $2}'


10.0.4.1

Adicione a seguinte regra estática de BONDETH1 ao arquivo /etc/sysconfig/network-scripts/route-bondeth1:

10.0.X.0/XX dev bondeth1 table 211
default via <gateway> dev bondeth1 table 211
134.70.0.0/17 via <gateway_from_previous_step> dev bondeth1

Reinicie a interface.
```
[root@dbsys ~]# ifdown bondeth1; ifup bondeth1;
```
As alterações do arquivo da etapa anterior ocorrem imediatamente após a execução dos comandos ifdown e ifup.
Repita as etapas anteriores em cada nó de computação da instância do Exadata Cloud Infrastructure.

Tópico principal: Acesso do Nó ao Object Storage: Rota Estática

Gateway de Serviço para a VCN

Sua VCN precisa acessar o Object Storage para backups e o repositório YUM da Oracle para atualizações do sistema operacional.

Dependendo do uso da Opção 1: Sub-rede de Cliente Pública com Gateway de Internet ou da Opção 2: Sub-redes Privadas descritas anteriormente, use o gateway de serviço de maneiras distintas. Consulte as duas seções a seguir.

Opção 1: Acesso do Gateway de Serviço aos Serviços do OCI
Configure a sub-rede de backup para usar o gateway de serviço para acesso somente ao Object Storage.
Opção 2: Acesso do Gateway de Serviço ao Object Storage e ao Repositório YUM
Configure a sub-rede do cliente e a sub-rede de backup para usar o gateway de serviço para acesso ao Oracle Services Network, que inclui o Object Storage e o repositório YUM da Oracle.

Tópicos Relacionados

Tópico principal: Configuração de Rede para Instâncias do Exadata Cloud Infrastructure

Opção 1: Acesso do Gateway de Serviço aos Serviços do OCI

Tópicos Relacionados

Tópico principal: Gateway de Serviço para a VCN

Opção 2: Acesso do Gateway de Serviço ao Object Storage e ao Repositório YUM

Você configura a sub-rede do cliente e a sub-rede de backup para usar o gateway de serviço para acesso ao Oracle Services Network, que inclui o Object Storage e o repositório YUM da Oracle.

Observação

Consulte estes problemas conhecidos para obter informações sobre como acessar os serviços YUM da Oracle por meio do gateway de serviço.

Como lembrete, veja aqui o diagrama da opção 2:

Esta imagem mostra a configuração de rede com uma sub-rede de cliente privada.

Em geral, você deve:

Execute as tarefas para configurar um gateway de serviço em uma VCN e ativar especificamente o label do CIDR de serviço chamado Todos os Serviços de <region> no Oracle Services Network.
Na tarefa para atualizar o roteamento em cada sub-rede, adicione uma regra a cada tabela de roteamento personalizada da sub-rede. Para o serviço de destino, use Todos os Serviços de <region> no Oracle Services Network e destino = o gateway de serviço.
Na tarefa para atualizar regras de segurança da sub-rede, execute a tarefa no NSG (grupo de segurança de rede) da rede de backup ou na lista de segurança personalizada. Configure uma regra de segurança com o serviço de destino definido como OCI <region> Object Storage. Consulte Regras de Segurança do Oracle Exadata Cloud Service Regras de Segurança do Oracle Exadata Database Service on Dedicated Infrastructure. Observe que a sub-rede do cliente já tem uma regra de saída ampla que abrange o acesso ao repositório YUM.

Aqui estão alguns detalhes adicionais sobre o uso do gateway de serviço para a opção 2:

A sub-rede do cliente e a sub-rede de backup usam o gateway de serviço, mas para acessar serviços diferentes. Você não pode ativar o label do CIDR de serviço OCI <region> Object Storage e Todos os Serviços de <region> no Oracle Services Network para o gateway de serviço. Para abranger as necessidades de ambas as sub-redes, é necessário ativar Todos os Serviços de <region> no Oracle Services Network para o gateway de serviço. A VCN só pode ter um único gateway de serviço.
Qualquer regra de roteamento destinada a um determinado gateway de serviço deve usar um label do CIDR de serviço ativado e não um bloco CIDR como destino da regra. Isso significa que, para a opção 2, as tabelas de roteamento de ambas as sub-redes devem usar Todos os Serviços de <region> no Oracle Services Network para suas respectivas regras do gateway de serviço.
Diferentemente das regras de roteamento, as regras de segurança podem usar qualquer label do CIDR de serviço (se a VCN tiver ou não um gateway de serviço) ou um bloco CIDR como CIDR de origem ou destino para a regra. Portanto, embora a sub-rede de backup tenha uma regra de roteamento que use Todos os Serviços de <region> no Oracle Services Network, a sub-rede pode ter uma regra de segurança que use o OCI <region> Object Storage. Consulte Regras de Segurança da instância do Exadata Cloud Service.

Tópicos Relacionados

Tópico principal: Gateway de Serviço para a VCN

Regras de Segurança do Oracle Exadata Database Service on Dedicated Infrastructure

Esta seção lista as regras de segurança a serem usadas com o Exadata Cloud Infrastructure.

As regras de segurança controlam os tipos de tráfego permitidos para a rede do cliente e a rede de backup dos nós de computação do Exadata. As regras são divididas em três seções.

Há diferentes formas de implementar essas regras. Para obter mais informações, consulte Formas de Implementar as Regras de Segurança.

Observação

Para sistemas X8M e X9M, a Oracle recomenda que todas as portas na sub-rede do cliente estejam abertas para tráfego de entrada e saída. Esse é um requisito para a adição de mais servidores de banco de dados ao sistema.

Observação

Se você planeja usar o Roteamento de Pacotes de confiança zero para controlar as redes dos seus serviços de banco de dados e planeja configurar os pares do Data Guard dentro da mesma VCN, todos os Clusters de VMs na configuração da VCN e do Data Guard deverão ter o mesmo Atributo de Segurança ZPR. Os pares do Data Guard que estão em outra VCN ou em outra região devem ser especificados pelo CIDR na configuração do ZPR.

Regras Obrigatórias para a Rede do Cliente e a Rede de Backup

Esta seção tem várias regras gerais que permitem a conectividade essencial para hosts na VCN.

Se você usar listas de segurança para implementar suas regras de segurança, lembre-se de que as regras a seguir serão incluídas por padrão na lista de segurança padrão. Atualize ou substitua a lista para atender às suas necessidades de segurança específicas. As duas regras de ICMP (regras gerais de entrada 2 e 3) são necessárias para o funcionamento adequado do tráfego de rede no ambiente do Oracle Cloud Infrastructure. Ajuste a regra de entrada geral 1 (a regra SSH) e a regra de saída geral 1 para permitir o tráfego apenas de/ para hosts que requerem comunicação com recursos da sua VCN.

Regras Obrigatórias Especificamente para a Rede do Cliente

As regras de segurança a seguir são importantes para a rede do cliente.

Observação

As regras de entrada do cliente 1 e 2 abrangem somente conexões iniciadas na sub-rede cliente. Se você tiver um cliente que resida fora da VCN, a Oracle recomenda configurar duas regras semelhantes adicionais que, em vez disso, tenham o CIDR de Origem definido como o endereço IP público do cliente.
As regras de saída de cliente 1 e 2 na configuração de rede do cliente permitem tráfego TCP e ICMP, permitindo a comunicação segura entre nós dentro da rede do cliente. Essas regras são críticas, pois facilitam a conectividade TCP essencial nos nós. Se a conectividade TCP falhar entre os nós, o provisionamento do recurso de cluster de VMs do Exadata Cloud não será concluído com sucesso.

Regra Obrigatória Especificamente para a Rede de Backup

A regra de segurança a seguir é importante para a rede de backup porque ela permite que o sistema de banco de dados se comunique com o Object Storage por meio do gateway de serviço (e, opcionalmente, com o repositório YUM da Oracle se a rede do cliente não tiver acesso a eles). Ela é redundante com a regra de saída geral nesse tópico (e na lista de segurança padrão). Ela é opcional, mas recomendada, caso a regra geral de saída (ou lista de segurança padrão) seja alterada de forma inadvertida.

Regras Obrigatórias para a Rede do Cliente e a Rede de Backup
Este tópico tem várias regras gerais que permitem a conectividade essencial para hosts na VCN.
Regras Obrigatórias Especificamente para a Rede do Cliente
As regras de segurança a seguir são importantes para a rede do cliente.
Regra Obrigatória Especificamente para a Rede de Backup
A regra de segurança a seguir é importante para a rede de backup porque ela permite que o sistema de banco de dados se comunique com o Object Storage por meio do gateway de serviço (e, opcionalmente, com o repositório YUM da Oracle se a rede do cliente não tiver acesso a eles).
Regras Obrigatórias para o Serviço Events
A instância de computação deve ter um endereço IP público ou um gateway de serviço para poder enviar métricas da instância de computação ao serviço Events.
Regras Obrigatórias para o Serviço Monitoring
A instância de computação deve ter um endereço IP público ou um gateway de serviço para poder enviar métricas da instância de computação ao serviço Monitoring.

Tópico principal: Configuração de Rede para Instâncias do Exadata Cloud Infrastructure

Regras Obrigatórias para a Rede do Cliente e a Rede de Backup

Este tópico tem várias regras gerais que permitem a conectividade essencial para hosts na VCN.

Se você usar listas de segurança para implementar suas regras de segurança, lembre-se de que as regras a seguir serão incluídas por padrão na lista de segurança padrão. Atualize ou substitua a lista para atender às suas necessidades de segurança específicas. As duas regras de ICMP (regras gerais de entrada 2 e 3) são necessárias para o funcionamento adequado do tráfego de rede no ambiente do Oracle Cloud Infrastructure. Ajuste a regra de entrada geral 1 (a regra SSH) e a regra de saída geral 1 para permitir o tráfego apenas de/ para hosts que requerem comunicação com recursos da sua VCN.

Regra de entrada geral 1: Permite o tráfego SSH de qualquer lugar
Regra de entrada 2 geral: Permite mensagens de fragmentação de Descoberta de MTU do Caminho
Regra de entrada geral 3: Permite mensagens de erro de conectividade na VCN
Esta regra permite que os hosts da VCN recebam mensagens de erro de conectividade um do outro.
Regra de saída geral 1: Permite todo o tráfego de saída

Tópicos Relacionados

lista de segurança padrão

Tópico principal: Regras de Segurança do Oracle Exadata Database Service on Dedicated Infrastructure

Regra de entrada geral 1: Permite o tráfego SSH de qualquer lugar

Tópico principal: Regras Obrigatórias para a Rede do Cliente e a Rede de Backup

Regra de entrada geral 2: Permite mensagens de fragmentação de Descoberta de MTU do Caminho

Tópico principal: Regras Obrigatórias para a Rede do Cliente e a Rede de Backup

Regra de entrada geral 3: Permite mensagens de erro de conectividade na VCN

Essa regra permite que os hosts da VCN recebam mensagens de erro de conectividade uns dos outros.

Sem monitoramento de estado: Não (todas as regras devem ser com monitoramento de estado)
Tipo de Origem: CIDR
CIDR de Origem: IPv4: o IPv4 CIDR da sua VCN, IPv6: o CIDR IPv6 da sua VCN
Protocolo IP: ICMP
Tipo: Tudo
Código: Todos

Tópico principal: Regras Obrigatórias para a Rede do Cliente e a Rede de Backup

Regra de saída geral 1: Permite todo o tráfego de saída

Tópico principal: Regras Obrigatórias para a Rede do Cliente e a Rede de Backup

Regras Obrigatórias Especificamente para a Rede do Cliente

As regras de segurança a seguir são importantes para a rede do cliente.

Observação

Para sistemas X8M, a Oracle recomenda a abertura de todas as portas na sub-rede do cliente para tráfego de entrada e saída. Esse é um requisito para a adição de mais servidores de banco de dados ao sistema.
As regras de entrada do cliente 1 e 2 abrangem somente conexões iniciadas na sub-rede cliente. Se você tiver um cliente que resida fora da VCN, a Oracle recomenda configurar duas regras semelhantes adicionais que, em vez disso, tenham o CIDR de Origem definido como o endereço IP público do cliente.
As regras de entrada do cliente 3 e 4 e as regras de saída do cliente 1 e 2 permitem tráfego TCP e ICMP dentro da rede do cliente e permitem que os nós se comuniquem entre si. Se a conectividade TCP falhar entre os nós, o cluster de VMs na nuvem Exadata ou o recurso do sistema de banco de dados não será provisionado.

Regra de entrada do cliente 1: Permite tráfego de ONS e FAN na sub-rede do cliente
A primeira regra é recomendada e permite que o ONS (Oracle Notification Services) se comunique sobre eventos de FAN (Fast Application Notification).
Regra de entrada do cliente 2: Permite o tráfego SQL*NET de dentro da sub-rede do cliente
Essa regra é para tráfego SQL*NET e é obrigatória nestes casos:
Regra de saída do cliente 1: Permite todo o tráfego TCP dentro da sub-rede do cliente
Esta regra é para o tráfego SQL*NET, conforme observado.
Regra de saída do cliente 2: Permite todo o tráfego de saída (permite conexões com o repositório YUM da Oracle)
A regra de saída do cliente 3 é importante porque permite conexões com o repositório YUM da Oracle.

Tópico principal: Regras de Segurança do Oracle Exadata Database Service on Dedicated Infrastructure

Regra de entrada do cliente 1: Permite tráfego de ONS e FAN na sub-rede do cliente

A primeira regra é recomendada e permite que o ONS (Oracle Notification Services) se comunique sobre eventos de FAN (Fast Application Notification).

Sem monitoramento de estado: Não (todas as regras devem ser com monitoramento de estado)
Tipo de Origem: CIDR
CIDR de Origem: IPv4: IPv4 CIDR da sub-rede do cliente, IPv6: CIDR IPv6 da sub-rede do cliente
Protocolo IP: TCP
Intervalo de Portas de Origem: Tudo
Intervalo de Portas de Destino: 6200
Descrição: Uma descrição opcional da regra.

Tópico principal: Regras Obrigatórias Especificamente para a Rede do Cliente

Regra de entrada do cliente 2: Permite o tráfego SQL*NET de dentro da sub-rede do cliente

Esta regra é para tráfego SQL*NET e é necessária nestes casos:

Se você precisar ativar conexões de cliente com o banco de dados
Se você planejar usar o Oracle Data Guard,

Sem monitoramento de estado: Não (todas as regras devem ser com monitoramento de estado)
Tipo de Origem: CIDR
CIDR de Origem: IPv4: IPv4 CIDR da sub-rede do cliente, IPv6: CIDR IPv6 da sub-rede do cliente
Protocolo IP: TCP
Intervalo de Portas de Origem: Tudo
Intervalo de Portas de Destino: 1521
Descrição: Uma descrição opcional da regra.

Tópico principal: Regras Obrigatórias Especificamente para a Rede do Cliente

Regra de saída do cliente 1: Permite todo o tráfego TCP dentro da sub-rede do cliente

Esta regra é para tráfego do SQL*NET, conforme observado.

Sem monitoramento de estado: Não (todas as regras devem ser com monitoramento de estado)
Tipo de Destino: CIDR
CIDR de Destino: 0.0.0.0/0 (IPv4), ::/0 (IPv6)
Protocolo IP: TCP
Intervalo de Portas de Origem: Tudo
Intervalo de Portas de Destino: 22
Descrição: Uma descrição opcional da regra.

Tópico principal: Regras Obrigatórias Especificamente para a Rede do Cliente

Regra de saída do cliente 2: Permite todo o tráfego de saída (permite conexões com o repositório YUM da Oracle)

A regra de saída do cliente 3 é importante porque permite conexões com o repositório YUM da Oracle.

Ela é redundante com a regra de saída geral 1: Permite todo o tráfego de saída (e na lista de segurança padrão). Ela é opcional, mas recomendada, caso a regra geral de saída (ou lista de segurança padrão) seja alterada de forma inadvertida.

Sem monitoramento de estado: Não (todas as regras devem ser com monitoramento de estado)
Tipo de Destino: CIDR
CIDR de Destino: 0.0.0.0/0 (IPv4), ::/0 (IPv6)
Protocolo IP: Todos
Descrição: Uma descrição opcional da regra.

Tópicos Relacionados

lista de segurança padrão

Tópico principal: Regras Obrigatórias Especificamente para a Rede do Cliente

Regra Obrigatória Especificamente para a Rede de Backup

Ela é redundante com a regra de saída geral 1: Permite todo o tráfego de saída (e na lista de segurança padrão). Ela é opcional, mas recomendada, caso a regra geral de saída (ou lista de segurança padrão) seja alterada de forma inadvertida.

Regra de saída de backup: Permite acesso ao Object Storage

Tópicos Relacionados

Tópico principal: Regras de Segurança do Oracle Exadata Database Service on Dedicated Infrastructure

Regra de saída de backup: Permite acesso ao Object Storage

Tópico principal: Regra Obrigatória Especificamente para a Rede de Backup

Regras Obrigatórias para o Serviço Events

A instância de computação deve ter um endereço IP público ou um gateway de serviço para poder enviar métricas da instância de computação ao serviço Events.

As regras de saída padrão são suficientes para permitir que a instância de computação envie métricas da instância de computação para o serviço Events.

Se a instância não tiver um endereço IP público, configure um gateway de serviço na VCN (rede virtual na nuvem). O gateway de serviço permite que a instância envie métricas de instância de computação para o serviço Events sem que o tráfego passe pela internet. Veja aqui as observações especiais para configurar o gateway de serviço para acessar o serviço Events:

Ao criar o gateway de serviço, ative o label de serviço chamado Todos os Serviços de <region> no Oracle Services Network. Ele inclui o serviço Events.
Ao configurar o roteamento da sub-rede que contém a instância, configure uma regra de roteamento com o Tipo de Destino definido como Gateway de Serviço e o Serviço de Destino definido como Todos os Serviços de <region> no Oracle Services Network.

Para ver instruções, consulte Acesso aos Serviços Oracle: Gateway de Serviço.

Tópico principal: Regras de Segurança do Oracle Exadata Database Service on Dedicated Infrastructure

Regras Obrigatórias para o Serviço Monitoring

A instância de computação deve ter um endereço IP público ou um gateway de serviço para poder enviar métricas da instância de computação ao serviço Monitoring.

As regras de saída padrão são suficientes para permitir que a instância de computação envie métricas da instância de computação para o serviço Monitoring.

Se a instância não tiver um endereço IP público, configure um gateway de serviço na VCN (rede virtual na nuvem). O gateway de serviço permite que a instância envie métricas de instância de computação para o serviço Monitoring sem que o tráfego passe pela internet. Veja aqui as observações especiais para configurar o gateway de serviço para acessar o serviço Monitoring:

Ao criar o gateway de serviço, ative o label de serviço chamado Todos os Serviços de <region> no Oracle Services Network. Ele inclui o serviço Monitoring.
Ao configurar o roteamento da sub-rede que contém a instância, configure uma regra de roteamento com o Tipo de Destino definido como Gateway de Serviço e o Serviço de Destino definido como Todos os Serviços de <region> no Oracle Services Network.

Para ver instruções, consulte Acesso aos Serviços Oracle: Gateway de Serviço.

Tópico principal: Regras de Segurança do Oracle Exadata Database Service on Dedicated Infrastructure

Formas de Implementar as Regras de Segurança

Saiba como implementar regras de segurança na sua VCN usando o serviço de rede.

O serviço Networking oferece duas maneiras de implementar regras de segurança na sua VCN:

Para obter uma comparação dos dois métodos, consulte Comparação de Listas de Segurança e Grupos de Segurança de Rede.

Se você usar grupos de segurança de rede
Se você usar listas de segurança
Se optar por usar listas de segurança, este é o processo recomendado:

Tópico principal: Configuração de Rede para Instâncias do Exadata Cloud Infrastructure

Se você usar grupos de segurança de rede

Tópico principal: Formas de Implementar as Regras de Segurança

Se você usar listas de segurança

Tópico principal: Formas de Implementar as Regras de Segurança

Requisitos de Rede para o Oracle Database Autonomous Recovery Service

O Oracle Database Autonomous Recovery Service requer uma sub-rede registrada do Recovery Service dedicada a operações de backup e recuperação na sua rede virtual na nuvem (VCN) de banco de dados.

Para usar o Recovery Service para backups, siga as etapas descritas em Configurando o Recovery Service.

Criar um Gateway de Serviço para o Object Storage
Na Console do OCI, crie um gateway de serviço para o Object Storage. O gateway de serviço é necessário para atualizações de automação e metadados de configuração.

Tópicos Relacionados

Configurando o Recovery Service

Tópico principal: Configuração de Rede para Instâncias do Exadata Cloud Infrastructure

Criar um Gateway de Serviço para o Object Storage

Na Console do OCI, crie um gateway de serviço para o Object Storage. O gateway de serviço é necessário para atualizações de automação e metadados de configuração.

Abra o menu de navegação. Clique em Networking e, em seguida, clique em Redes Virtuais na Nuvem.
Selecione a VCN na qual os serviços de banco de dados a serem submetidos a backup estão localizados.
Na página Detalhes da Rede Virtual na Nuvem resultante, em Recursos, clique em Gateways de Serviço.
Clique em Criar Gateway de Serviço e forneça os detalhes a seguir.
1. Nome: um nome descritivo para o gateway de serviço. Ele não precisa ser exclusivo. Evite digitar informações confidenciais.
2. Compartimento: o compartimento no qual você deseja criar o gateway de serviço, se diferente do compartimento no qual você está trabalhando no momento.
3. Serviços: Selecione o Label CIDR de serviço, All <region> Services in Oracle Services Network, na lista drop-down.
4. Tags: ( opção avançada) Se você tiver permissões para criar um recurso, também terá permissões para aplicar tags de formato livre a esse recurso. Para aplicar uma tag definida, você deverá ter permissões para usar o namespace de tag. Para obter mais informações sobre tags, consulte Tags de Recurso. Se você não tiver certeza se deve aplicar tags, ignore essa opção (você poderá aplicar tags posteriormente) ou pergunte ao administrador.
Clique em Criar Gateway de Serviço.

Aguarde a criação do gateway antes de continuar com a próxima etapa.
Em Recursos, clique em Tabela de Roteamento

Associação de Tabela de Roteamento: Você pode associar uma tabela de roteamento de VCN específica a esse gateway. Se você associar uma tabela de roteamento, depois o gateway sempre deverá ter uma tabela de roteamento associada a ele. Você pode modificar as regras na tabela de roteamento atual ou substituí-las por outra tabela.
Clique no nome da Tabela de Roteamento que está sendo usada pela sub-rede para o Recovery Service.
Na página Detalhes da Tabela de Roteamento resultante, clique em Adicionar Regras de Roteamento na seção Regras de Roteamento.

Ao configurar um gateway de serviço para um determinado label de CIDR de serviço, você também deverá criar uma regra de roteamento que especifique esse label como o destino e o alvo como o gateway de serviço. Você deve fazer isso para cada sub-rede que precise acessar o gateway.
Na caixa de diálogo Adicionar Regras de Roteamento resultante, informe os seguintes detalhes:
1. Tipo de Destino: Gateway de Serviço.
2. Serviço de Destino: O label CIDR de serviço ativado para o gateway. All <region> Services in Oracle Services Network
3. Gateway de Serviço de Destino: Selecione o nome fornecido na etapa 4.
4. Descrição: Uma descrição opcional da regra.
Clique em Adicionar Regras de Roteamento.

Tópicos Relacionados

Tags de Recurso

Tópico principal: Requisitos de Rede para o Oracle Database Autonomous Recovery Service

Documentação do Oracle Cloud Infrastructure