Documentazione di Oracle Cloud Infrastructure

Impostazione di rete per le istanze dell'infrastruttura Exadata Cloud

Questo argomento descrive la configurazione consigliata per la VCN e diversi requisiti correlati per l'istanza dell'infrastruttura Exadata Cloud.

Prima di impostare un'istanza dell'infrastruttura Exadata Cloud, è necessario impostare una rete cloud virtuale (VCN) e altri componenti del servizio di networking.

Argomento padre: Preparazione per l'infrastruttura Exadata Cloud

VCN e subnet

Per avviare un'istanza dell'infrastruttura Exadata Cloud, è necessario disporre di una rete cloud virtuale e di almeno due subnet:

Per avviare un'istanza dell'infrastruttura Exadata Cloud, è necessario disporre di una rete cloud virtuale, almeno due subnet e selezionare il tipo di resolver DNS che verrà utilizzato:

  • Una VCN nell'area in cui si desidera l'istanza dell'infrastruttura Exadata Cloud
  • Almeno due subnet nella VCN. Le due sottoreti sono:
    • subnet client
    • subnet di backup
  • Scegli quale metodo di risoluzione dei nomi DNS utilizzerai. Consulta la sezione relativa alle scelte per il DNS nella tua VCN
Nota

Per le istanze dell'infrastruttura Exadata Cloud che utilizzano il nuovo modello di risorsa dell'infrastruttura Exadata Cloud, il networking viene configurato nella risorsa cluster VM cloud.

La sottorete client può essere configurata con la rete a doppio stack IPv4 o IPv4/IPv6.

In generale, Oracle consiglia di utilizzare le subnet regionali , che si estendono su tutti i domini di disponibilità nell'area. Per ulteriori informazioni, vedere Panoramica di VCN e subnet.

Le tabelle di instradamento verranno create per ogni subnet. Inoltre, verranno create le regole di sicurezza per controllare il traffico da e verso la rete client e la rete di backup dei nodi di calcolo Exadata (per la risorsa cluster VM cloud, i nodi sono denominati virtual machine). Ulteriori informazioni su questi elementi.

Argomenti correlati

Argomento padre: Impostazione della rete per le istanze dell'infrastruttura Exadata Cloud

Opzione 1: Subnet client pubblico con gateway Internet

Questa opzione può essere utile quando si esegue un lavoro di proof-of-concept o di sviluppo.

È possibile utilizzare questa impostazione in produzione se si desidera utilizzare un gateway Internet con la VCN oppure se si dispone di servizi che vengono eseguiti solo su una rete pubblica e devono accedere al database. Vedere il diagramma e la descrizione riportati di seguito.

Segue la descrizione di network_exa_public_client.png
Descrizione dell'immagine network_exa_public_client.png

È possibile impostare:

Nota

Importante Per informazioni sulla configurazione delle regole di instradamento con il gateway del servizio come destinazione nelle tabelle di instradamento associate a subnet pubbliche, vedere questo problema noto.

Argomento padre: VCN e subnet

Opzione 2: Subnet private

Oracle consiglia subnet private per un sistema di produzione.

Entrambe le subnet sono private e non possono essere raggiunte da Internet. Vedere il diagramma e la descrizione riportati di seguito.

Segue la descrizione di network_exa_private_client.png
Descrizione dell'immagine network_exa_private_client.png

È possibile impostare:

  • Subnet:
    • Subnet del client privato.
    • Subnet di backup Privata.
  • Gateway per la VCN:
  • Table di instradamento:
    • Tabella di instradamento personalizzata per la subnet client privata con le regole riportate di seguito.
      • Regola per il CIDR della rete on premise e target = DRG.
      • Regola per l'etichetta CIDR del servizio denominata All <region> Services in Oracle Services Network e target = the service gateway. Oracle Services Network è una rete concettuale in Oracle Cloud Infrastructure riservata ai servizi Oracle. La regola consente alla subnet client di raggiungere il repository Oracle YUM regionale per gli aggiornamenti del sistema operativo. Vedere anche Opzione 2: Accesso al gateway di servizi allo storage degli oggetti e repository YUM.
      • Facoltativamente, una regola per 0.0.0.0/0 e target = NAT gateway.
    • Separa la tabella di instradamento personalizzata per la subnet di backup privata con una regola:
      • La stessa regola della sottorete client per l'etichetta CIDR del servizio denominata All <region> Services in Oracle Services Network e target = the service gateway. Questa regola consente alla subnet di backup di raggiungere lo storage degli oggetti regionale per i backup.
  • Regole di sicurezza per abilitare il traffico desiderato da e verso i nodi Exadata. Vedere Regole di sicurezza per l'istanza di Exadata Cloud Service.
  • Facoltativamente, aggiungere un instradamento statico sui nodi di calcolo ad altri servizi OCI (per i cluster VM, le virtual machine) per abilitare l'accesso, se i servizi sono raggiungibili solo nella subnet di backup e non tramite. la subnet client, ad esempio quando si utilizza un gateway NAT.

Argomento padre: VCN e subnet

Requisiti per lo spazio di indirizzi IP

Gli indirizzi IP non devono sovrapporsi, soprattutto quando i cluster VM dell'infrastruttura Exadata Cloud (e quindi i VCN) si trovano in più aree.

Se si stanno impostando i cluster VM dell'infrastruttura Exadata Cloud (e quindi le reti VCN) in più aree, assicurarsi che lo spazio degli indirizzi IP delle reti VCN non si sovrapponga. Questo aspetto è importante se desideri impostare il disaster recovery con Oracle Data Guard.

Per Exadata X8 e versioni successive, le due subnet create per i cluster VM dell'infrastruttura Exadata Cloud non devono sovrapporsi a 192.168.128.0/20.

Per Exadata X8M, X9M e X11M, gli indirizzi IP 100.64.0.0/10 sono riservati all'interconnessione e non devono essere utilizzati per le VCN client o di backup e per i client del database.

La tabella riportata di seguito elenca le dimensioni minime richieste della subnet, in base all'infrastruttura VM Exadata per ogni dimensione del cluster VM. Per la subnet del client, ogni nodo richiede quattro indirizzi IP e tre indirizzi sono riservati ai nomi di accesso Single Client (SCAN). Per la subnet di backup, ogni nodo richiede tre indirizzi.

Dimensione rack Subnet client: n. di indirizzi IP richiesti Subnet client: dimensione minima Nota Subnet di backup: n. di indirizzi IP richiesti Subnet di backup: dimensione minima Nota
Sistema di base o Quarter Rack per cluster VM (4 indirizzi * 2 nodi) + 3 per SCAN = 11 /28 (16 indirizzi IP) 3 indirizzo * 2 nodi = 6 /28 (16 indirizzi IP)
Half Rack per cluster VM (4 * 4 nodi) + 3 = 19 /27 (32 indirizzi IP) 3 * 4 nodi = 12 /28 (16 indirizzi IP)
Full Rack per cluster VM (4* 8 nodi) + 3 = 35 /26 (64 indirizzi IP) 3 * 8 nodi = 24 /27 (32 indirizzi IP)
Sistemi di infrastruttura flessibili (X8M e successivi) per cluster VM 4 indirizzi per nodo di database (minimo 2 nodi) + 3 per SCAN Dimensione minima determinata dal numero totale di indirizzi IP necessari per i nodi del database 3 indirizzi per nodo di database (minimo 2 nodi) Dimensione minima determinata dal numero totale di indirizzi IP necessari per i nodi del database
Nota

Il servizio di rete conserva tre indirizzi IP in ogni sottorete. L'allocazione di uno spazio maggiore per la subnet rispetto al minimo richiesto (ad esempio, almeno /25 anziché /28) può ridurre l'impatto relativo di tali indirizzi riservati sullo spazio disponibile della subnet.

Argomento padre: VCN e subnet

Configurazione di un instradamento statico per l'accesso all'area di memorizzazione degli oggetti

Per impostazione predefinita, tutto il traffico in un'istanza dell'infrastruttura Exadata Cloud viene instradato tramite la rete dati. Per instradare il traffico di backup all'interfaccia di backup (BONDETH1), è necessario configurare un instradamento statico su ciascuno dei nodi di calcolo nel cluster.

Per istruzioni, vedere Accesso al nodo allo storage degli oggetti: instradamento statico.

Argomento padre: VCN e subnet

Impostazione di DNS per un'istanza dell'infrastruttura Exadata Cloud

Il DNS ti consente di utilizzare i nomi host anziché gli indirizzi IP per comunicare con un'istanza dell'infrastruttura Exadata Cloud.

Puoi utilizzare il resolver Internet e VCN (la funzionalità DNS integrata nella VCN) come descritto nel DNS della tua rete cloud virtuale. Oracle consiglia di utilizzare un resolver VCN per la risoluzione dei nomi DNS per la subnet client. Risolve automaticamente gli endpoint Swift necessari per il backup dei database, l'applicazione di patch e l'aggiornamento degli strumenti cloud su un'istanza Exadata.

Argomento padre: VCN e subnet

DNS: nomi brevi per l'istanza di VCN, subnet ed infrastruttura Exadata Cloud

Affinché i nodi possano comunicare, la VCN deve utilizzare il resolver Internet e VCN. Il resolver Internet e VCN consente l'assegnazione del nome host ai nodi e la risoluzione DNS di tali nomi host da parte delle risorse nella VCN.

Il resolver Internet e VCN abilita la risoluzione round robin dei SCAN del database. Consente inoltre di risolvere importanti endpoint del servizio necessari per eseguire il backup dei database, l'applicazione di patch e l'aggiornamento degli strumenti cloud su un'istanza dell'infrastruttura Exadata Cloud. Il Resolver Internet e VCN è la scelta predefinita della VCN per il DNS nella VCN. Per ulteriori informazioni, vedere DNS nella rete cloud virtuale e anche Opzioni DHCP.

Quando crei VCN, subnet ed Exadata, devi impostare con attenzione gli identificativi riportati di seguito, correlati al DNS nella VCN.

  • Etichetta dominio VCN
  • Etichetta dominio subnet
  • Prefisso del nome host per il cluster VM cloud o la risorsa del sistema DB dell'istanza dell'infrastruttura Exadata Cloud

Questi valori costituiscono il nome dominio completamente qualificato (FQDN) del nodo:

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

Ad esempio:

exacs-abcde1.clientpvtad1.acmevcniad.oraclevcn.com

In questo esempio, si assegna exacs come prefisso del nome host quando si crea il cluster VM cloud o il sistema DB. Il servizio di database aggiunge automaticamente un trattino e una stringa di cinque lettere con il numero di nodo alla fine. Ad esempio:

  • Nodo 1: exacs-abcde1.clientpvtad1.acmevcniad.oraclevcn.com
  • Nodo 2: exacs-abcde2.clientpvtad1.acmevcniad.oraclevcn.com
  • Nodo 3: exacs-abcde3.clientpvtad1.acmevcniad.oraclevcn.com
  • E così via

Requisiti per il prefisso del nome host:

  • Numero massimo consigliato: 12 caratteri. Per ulteriori informazioni, vedere l'esempio nella sezione "Requisiti per le etichette di dominio VCN e subnet" riportata di seguito.
  • Non può essere la stringa localhost

Requisiti per le etichette di dominio VCN e subnet:

  • Massimo consigliato: 14 caratteri ciascuno. Il requisito di base effettivo è un totale di 28 caratteri in entrambe le etichette di dominio (ad esclusione del periodo tra le etichette). Ad esempio, entrambi sono accettabili: subnetad1.verylongvcnphx o verylongsubnetad1.vcnphx. Per semplicità, la raccomandazione è di 14 caratteri ciascuno.
  • Nessun trattino o carattere di sottolineatura.

  • Consigliato: includere il nome dell'area nell'etichetta del dominio della VCN e includere il nome del dominio di disponibilità nell'etichetta del dominio della subnet.

  • In generale, il nome FQDN ha un limite totale massimo di 63 caratteri. Ecco una regola generale sicura:

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

I valori massimi precedenti non vengono applicati quando si creano la VCN e le subnet. Tuttavia, se le etichette superano il numero massimo, la distribuzione Exadata non riesce.

Argomento padre: VCN e subnet

DNS: tra la rete in locale e la VCN

Oracle consiglia di utilizzare un resolver DNS privato per abilitare l'uso dei nomi host quando gli host on premise e le risorse VCN comunicano tra loro.

Consulta la sezione relativa ai resolver DNS privati per informazioni sulla creazione e l'utilizzo di resolver privati. Per un'architettura di riferimento, consulta la sezione relativa all'uso del DNS privato nella VCN in Oracle Architecture Center.

Argomento padre: VCN e subnet

Configura DNS privato

Prerequisiti necessari per utilizzare il DNS privato.

  • Prima di avviare il provisioning del sistema DB, è necessario creare la vista privata e la zona privata. Per i dettagli, vedere Risolutori DNS privati.
  • L'inoltro a un altro server DNS deve essere configurato in anticipo nella console DNS. Questa operazione può essere eseguita andando al resolver della VCN e creando l'endpoint e quindi le regole. Per i dettagli, vedi DNS nella tua rete cloud virtuale.
  • Il nome della zona privata non può avere più di 4 etichette. Ad esempio, a.b.c.d è consentito mentre a.b.c.d.e non lo è.
  • È inoltre necessario aggiungere la vista privata al resolver della VCN. Per ulteriori informazioni, vedere Aggiunta di una vista privata a un resolver.
  • Quando si esegue il provisioning di un cluster VM Exadata utilizzando la funzione DNS privata, Exadata deve creare zone DNS inverse nel compartimento del cluster VM Exadata. Se il compartimento ha tag definite o impostazioni predefinite delle tag, sono necessari criteri aggiuntivi correlati alla gestione delle tag. Per dettagli, vedere:

Argomento padre: VCN e subnet

Accesso al nodo allo storage degli oggetti: instradamento statico

Per poter eseguire il backup dei database e applicare patch e aggiornare gli strumenti cloud su un'istanza dell'infrastruttura Exadata Cloud, è necessario configurare l'accesso a Oracle Cloud Infrastructure Object Storage. Indipendentemente dal modo in cui configuri la VCN con tale accesso (ad esempio, con un gateway di servizi), potresti anche dover configurare un instradamento statico allo storage degli oggetti su ciascuno dei nodi di calcolo nel cluster. Ciò è necessario solo se non si utilizzano backup automatici. Se utilizzi i backup personalizzati utilizzando le API di backup, devi instradare il traffico destinato allo storage degli oggetti tramite l'interfaccia di backup (BONDETH1). Ciò non è necessario se si utilizzano i backup automatici creati con la console, le API o le interfacce CLI.

Attenzione:

È necessario configurare un instradamento statico per l'accesso allo storage degli oggetti su ogni nodo di calcolo in un'istanza dell'infrastruttura Exadata Cloud se non si creano backup automatici con la console, le API o le interfacce CLI. In caso contrario, i tentativi di eseguire il backup dei database e di applicare patch o aggiornare gli strumenti sul sistema potrebbero non riuscire.
Nota

Quando si abilita il primo backup automatico per un database, la configurazione dell'instradamento statico verrà eseguita automaticamente sul servizio.

Se si desidera applicare le patch al servizio prima di creare un database, è necessario l'instradamento statico manuale per poter applicare le patch alla home GI o DB.

L'instradamento statico può anche essere necessario per accedere ad altri servizi (IAM, KMS) se questi non sono raggiungibili tramite la subnet client e solo la subnet di backup utilizza l'impostazione per accedere a tutti i servizi all'interno di un'area.

Allocazioni IP di storage degli oggetti

Oracle Cloud Infrastructure Object Storage utilizza l'intervallo IP dei blocchi CIDR 134.70.0.0/16 per tutte le aree.

A partire dal 1° giugno 2018, lo storage degli oggetti non supporta più i seguenti intervalli IP interrotti. Oracle consiglia di rimuovere gli indirizzi IP precedenti dalle liste di controllo dell'accesso, dalle regole firewall e da altre regole dopo aver adottato i nuovi intervalli IP.

Di seguito sono riportati gli intervalli IP discontinued.

  • Germania centro (Francoforte): 130.61.0.0/16
  • Sud del Regno Unito (Londra): 132.145.0.0/16
  • Stati Uniti (Est): 129.213.0.0/16
  • Stati Uniti occidentali (Phoenix): 129.146.0.0/16

Per configurare un instradamento statico per l'accesso allo storage degli oggetti

  1. SSH a un nodo di calcolo nell'istanza dell'infrastruttura Exadata Cloud. 

    ssh -i <private_key_path> opc@<node_ip_address>

  2. Eseguire il login come opc, quindi sudo per l'utente root. Usare sudo su - con un trattino per richiamare il profilo dell'utente root. 

    
login as: opc
			
[opc@dbsys ~]$ sudo su -

  3. Identificare il gateway configurato per l'interfaccia BONDETH1. 

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


10.0.4.1

  4. Aggiungere la seguente regola statica per BONDETH1 al file /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

  5. Riavviare l'interfaccia. 

    
[root@dbsys ~]# ifdown bondeth1; ifup bondeth1;

    Le modifiche apportate al file dal passaggio precedente diventano effettive immediatamente dopo l'esecuzione dei comandi ifdown e ifup.

  6. Ripetere i passi precedenti su ogni nodo di calcolo nell'istanza dell'infrastruttura Exadata Cloud.

Gateway di servizi per la VCN

Assicurati che la tua VCN possa raggiungere Oracle Services Network, in particolare lo storage degli oggetti per i backup, i repository Oracle YUM per gli aggiornamenti del sistema operativo, l'integrazione di IAM (Identity and Access Management) e OCI Vault (KMS).

Nota

Se la VCN non dispone di connettività a Oracle Services Network, il provisioning dei nuovi cluster VM potrebbe non riuscire e potrebbe essere interessata anche la gestibilità dei cluster VM esistenti.

A seconda che si utilizzi Option1: Subnet del client pubblico con gateway Internet o Opzione 2: Subnet private, è possibile utilizzare il gateway del servizio in modi diversi. Vedere le due sezioni successive.

Argomenti correlati

Argomento padre: Impostazione della rete per le istanze dell'infrastruttura Exadata Cloud

Opzione 1: Accesso del gateway del servizio al servizio OCI per la subnet di backup

Puoi configurare la subnet di backup in modo che utilizzi il gateway del servizio per l'accesso solo allo storage degli oggetti.

Come promemoria, ecco il diagramma per l'opzione 1:

Questa immagine mostra l'impostazione della rete con una subnet client pubblica.

In generale, è necessario:

  • Eseguire i task per impostare un gateway di servizio su una VCN e abilitare in modo specifico l'etichetta CIDR del servizio denominata OCI <region> Object Storage.
  • Nel task di aggiornamento dell'instradamento, aggiungere una regola di instradamento alla tabella di instradamento personalizzata della subnet di backup. Per il servizio di destinazione, utilizzare OCI <region> Object Storage e target = the service gateway.
  • Nel task per l'aggiornamento delle regole di sicurezza nella subnet, eseguire il task sul gruppo di sicurezza di rete (NSG) o sulla lista di sicurezza personalizzata della rete di backup. Impostare una regola di sicurezza con il servizio di destinazione impostato su OCI <region> Object Storage. Vedere Regola richiesta specificamente per la rete di backup.

Opzione 2: Accesso del gateway del servizio al servizio OCI per le subnet client e di backup

Puoi configurare sia la subnet client che la subnet di backup in modo che utilizzi il gateway del servizio per l'accesso a Oracle Services Network, che include lo storage degli oggetti per i backup, i repository Oracle YUM per gli aggiornamenti del sistema operativo, IAM (Identity and Access Management) e OCI Vault (integrazione KMS).

Nota

Per informazioni sull'accesso ai servizi Oracle YUM tramite il gateway di servizi, vedere questo problema noto.

Come promemoria, ecco il diagramma per l'opzione 2:

Questa immagine mostra l'impostazione della rete con una sottorete client privata.

In generale, è necessario:

  • Eseguire i task per impostare un gateway di servizio su una VCN e abilitare in modo specifico l'etichetta CIDR del servizio denominata All <region> Services in Oracle Services Network.
  • Nel task per l'aggiornamento dell'instradamento in ogni subnet, aggiungere una regola alla tabella di instradamento personalizzata di ogni subnet. Per il servizio di destinazione, utilizzare All <region> Services in Oracle Services Network e target = the service gateway.
  • Nel task per l'aggiornamento delle regole di sicurezza per la subnet, eseguire il task sul gruppo di sicurezza di rete (NSG) o sulla lista di sicurezza personalizzata della rete di backup. Impostare una regola di sicurezza con il servizio di destinazione impostato su OCI <region> Object Storage. Consulta le Regole di sicurezza per Oracle Exadata Cloud Service Regole di sicurezza per Oracle Exadata Database Service on Dedicated Infrastructure. Tenere presente che la subnet client dispone già di una regola di uscita estesa che copre l'accesso ai repository YUM.

Di seguito sono riportati alcuni dettagli aggiuntivi sull'uso del gateway di servizi per l'opzione 2.

  • Sia la subnet client che la subnet di backup utilizzano il gateway del servizio, ma per accedere a servizi diversi. Non è possibile abilitare sia l'etichetta OCI <region> Object Storage service CIDR che All <region> Services in Oracle Services Network per il gateway del servizio. Per soddisfare le esigenze di entrambe le subnet, è necessario abilitare All <region> Services in Oracle Services Network per il gateway del servizio. La VCN può avere un solo gateway di servizi.
  • Qualsiasi regola di instradamento che si rivolge a un determinato gateway di servizio deve utilizzare un'etichetta CIDR di servizio abilitata e non un blocco CIDR come destinazione per la regola. Ciò significa che per l'opzione 2, le tabelle di instradamento per entrambe le subnet devono utilizzare All <region> Services in Oracle Services Network per le regole del gateway di servizio.
  • A differenza delle regole di instradamento, le regole di sicurezza possono utilizzare qualsiasi etichetta CIDR del servizio (che la VCN disponga o meno di un gateway di servizio) o un blocco CIDR come CIDR di origine o di destinazione per la regola. Pertanto, sebbene la subnet di backup disponga di una regola di instradamento che utilizza All <region> Services in Oracle Services Network, la subnet può disporre di una regola di sicurezza che utilizza OCI <region> Object Storage. Vedere Regole di sicurezza per l'istanza di Exadata Cloud Service.

Regole di sicurezza per Oracle Exadata Database Service on Dedicated Infrastructure

In questa sezione vengono elencate le regole di sicurezza da utilizzare con l'infrastruttura Exadata Cloud.

Le regole di sicurezza controllano i tipi di traffico consentiti per la rete client e la rete di backup dei nodi di calcolo di Exadata. Le regole sono suddivise in tre sezioni.

Esistono diversi modi per applicare queste regole. Per ulteriori informazioni, vedere Modalità di implementazione delle regole di sicurezza.
Nota

Per i sistemi X8M e X9M, Oracle consiglia di aprire tutte le porte della subnet client per il traffico in entrata e in uscita. Questo è un requisito per l'aggiunta di ulteriori database server al sistema.
Nota

Se si prevede di utilizzare l'instradamento dei pacchetti zero-trust per controllare le reti per i servizi di database e si prevede di configurare i peer Data Guard all'interno della stessa VCN, tutti i cluster VM nella configurazione VCN e Data Guard devono avere lo stesso attributo di sicurezza ZPR. I peer Data Guard che si trovano in una VCN o in un'area diversa devono essere specificati dal CIDR nella configurazione ZPR.

Regole richieste sia per la rete client che per la rete di backup

Questa sezione contiene diverse regole generali che abilitano la connettività essenziale per gli host nella VCN.

Se si utilizzano liste di sicurezza per implementare le regole di sicurezza, tenere presente che le regole riportate di seguito vengono incluse per impostazione predefinita nella lista di sicurezza predefinita. Aggiornare o sostituire l'elenco per soddisfare le esigenze di sicurezza specifiche. Le due regole ICMP (regole di entrata generali 2 e 3) sono necessarie per il corretto funzionamento del traffico di rete all'interno dell'ambiente Oracle Cloud Infrastructure. Regola la regola di entrata generale 1 (la regola SSH) e la regola di uscita generale 1 per consentire il traffico solo verso e da host che richiedono la comunicazione con le risorse nella tua VCN.

Regola di entrata generale 1: consente il traffico SSH da qualsiasi luogo

  • Senza conservazione dello stato: No (tutte le regole devono avere lo stato)
  • Tipo di origine: CIDR
  • CIDR di origine: 0.0.0.0/0 (IPv4), ::/0 (IPv6)
  • Protocollo IP: SSH
  • Intervallo porte di origine: tutto
  • Intervallo di porte di destinazione:22

Regola di entrata generale 2: consente i messaggi di frammentazione della ricerca automatica MTU percorso

Questa regola consente agli host nella VCN di ricevere i messaggi di frammentazione della ricerca automatica MTU del percorso. Senza accesso a questi messaggi, gli host nella VCN possono avere problemi di comunicazione con gli host esterni alla VCN.

  • Senza conservazione dello stato: No (tutte le regole devono avere lo stato)
  • Tipo di origine: CIDR
  • CIDR di origine: 0.0.0.0/0 (IPv4), ::/0 (IPv6)
  • Protocollo IP: ICMP
  • Tipo: 3
  • Codice: 4

Regola di entrata generale 3: consente i messaggi di errore di connettività all'interno della VCN

Questa regola consente agli host nella VCN di ricevere tra loro messaggi di errore di connettività.

  • Senza conservazione dello stato: No (tutte le regole devono avere lo stato)
  • Tipo di origine: CIDR
  • Source CIDR: IPv4: your VCN's IPv4 CIDR, IPv6: your VCN's IPv6 CIDR
  • Protocollo IP: ICMP
  • Tipo: TUTTO
  • Codice: tutto

Regola generale di uscita 1: consente tutto il traffico in uscita

  • Senza conservazione dello stato: No (tutte le regole devono avere lo stato)
  • Tipo di destinazione: CIDR
  • CIDR di destinazione: 0.0.0.0/0 (IPv4), ::/0 (IPv6)
  • Protocollo IP: tutto

Regole richieste in modo specifico per la rete client

Le regole di sicurezza riportate di seguito sono importanti per la rete client.

Nota

  • Le regole di entrata client 1 e 2 coprono solo le connessioni avviate dall'interno della subnet client. Se si dispone di un client che risiede al di fuori della VCN, Oracle consiglia di impostare due aggiuntive regole simili che invece hanno il CIDR di origine impostato sull'indirizzo IP pubblico del client.
  • Le regole di uscita client 1 e 2 nella configurazione di rete client consentono il traffico TCP e ICMP, consentendo la comunicazione nodo-nodo sicura all'interno della rete client. Queste regole sono fondamentali in quanto facilitano la connettività TCP essenziale tra i nodi. Se la connettività TCP non riesce tra i nodi, il provisioning della risorsa cluster VM Exadata Cloud non verrà completato correttamente.

Regola di entrata client 1: consente il traffico ONS e FAN dall'interno della subnet client

La prima regola è consigliata e consente a Oracle Notification Services (ONS) di comunicare gli eventi FAN (Fast Application Notification).

  • Senza conservazione dello stato: No (tutte le regole devono avere lo stato)
  • Tipo di origine: CIDR
  • Source CIDR: IPv4: client subnet's IPv4 CIDR, IPv6: client subnet's IPv6 CIDR
  • Protocollo IP: TCP
  • Intervallo porte di origine: tutto
  • Intervallo di porte di destinazione: 6200
  • Descrizione: una descrizione facoltativa della regola.

Regola di entrata client 2: consente il traffico SQL*NET dall'interno della subnet client

Questa regola è per il traffico SQL*NET ed è richiesta nei seguenti casi:

  • Se è necessario abilitare le connessioni client al database
  • Se si prevede di utilizzare Oracle Data Guard
  • Senza conservazione dello stato: No (tutte le regole devono avere lo stato)
  • Tipo di origine: CIDR
  • Source CIDR: IPv4: client subnet's IPv4 CIDR, IPv6: client subnet's IPv6 CIDR
  • Protocollo IP: TCP
  • Intervallo porte di origine: tutto
  • Intervallo di porte di destinazione: 1521
  • Descrizione: una descrizione facoltativa della regola.

Regola di uscita client 1: consente il traffico TCP SSH all'interno della subnet client

  • Senza conservazione dello stato: No (tutte le regole devono avere lo stato)
  • Tipo di destinazione: CIDR
  • CIDR di destinazione: 0.0.0.0/0 (IPv4), ::/0 (IPv6)
  • Protocollo IP: TCP
  • Intervallo porte di origine: tutto
  • Intervallo di porte di destinazione:22
  • Descrizione: una descrizione facoltativa della regola.

Regola di uscita client 2: consente tutto il traffico in uscita (consente le connessioni ai repository Oracle YUM)

La regola 2 di uscita del client è importante perché consente le connessioni ai repository Oracle YUM. È ridondante con la regola di uscita generale in questo argomento (e nella lista di sicurezza predefinita). È facoltativo, ma consigliato nel caso in cui la regola di uscita generale (o la lista di sicurezza predefinita) venga modificata inavvertitamente.

  • Senza conservazione dello stato: No (tutte le regole devono avere lo stato)
  • Tipo di destinazione: CIDR
  • CIDR di destinazione: 0.0.0.0/0 (IPv4), ::/0 (IPv6)
  • Protocollo IP: tutto
  • Descrizione: una descrizione facoltativa della regola.

Regola richiesta in modo specifico per la rete di backup

La regola di sicurezza seguente è importante per la rete di backup perché consente al sistema DB di comunicare con lo storage degli oggetti tramite il gateway del servizio (e, facoltativamente, con i repository Oracle YUM se la rete client non dispone dell'accesso a tali repository). È ridondante con la regola di uscita generale in questo argomento (e nella lista di sicurezza predefinita). È facoltativo, ma consigliato nel caso in cui la regola di uscita generale (o la lista di sicurezza predefinita) venga modificata inavvertitamente.

Regola di uscita backup: consente l'accesso allo storage degli oggetti

  • Senza conservazione dello stato: No (tutte le regole devono avere lo stato)
  • Tipo destinazione: servizio

  • Servizio di destinazione:

    • Etichetta CIDR del servizio denominata OCI <region> Object Storage
    • Se la rete client non dispone dell'accesso ai repository Oracle YUM, utilizzare l'etichetta CIDR del servizio denominata Tutti i servizi <region> in Oracle Services Network
  • Protocollo IP: TCP
  • Intervallo porte di origine: tutto
  • Intervallo porte di destinazione: 443 (HTTPS)
  • Descrizione: una descrizione facoltativa della regola.

Argomento padre: Impostazione della rete per le istanze dell'infrastruttura Exadata Cloud

Regole richieste sia per la rete client che per la rete di backup

In questo argomento sono disponibili diverse regole generali che abilitano la connettività essenziale per gli host nella VCN.

Se si utilizzano gli elenchi di sicurezza per implementare le regole di sicurezza, tenere presente che le regole riportate di seguito vengono incluse per impostazione predefinita nell'elenco di sicurezza predefinito. Aggiornare o sostituire l'elenco per soddisfare le esigenze di sicurezza specifiche. Le due regole ICMP (regole di entrata generali 2 e 3) sono necessarie per il corretto funzionamento del traffico di rete all'interno dell'ambiente Oracle Cloud Infrastructure. Regola la regola di entrata generale 1 (la regola SSH) e la regola di uscita generale 1 per consentire il traffico solo verso e da host che richiedono la comunicazione con le risorse nella tua VCN.

Regola di entrata generale 1: consente il traffico SSH da qualsiasi luogo
  • Senza conservazione dello stato: No (tutte le regole devono avere lo stato)
  • Tipo di origine: CIDR
  • CIDR di origine: 0.0.0.0/0 (IPv4), ::/0 (IPv6)
  • Protocollo IP: SSH
  • Intervallo porte di origine: tutto
  • Intervallo di porte di destinazione:22
Regola di entrata generale 2: consente i messaggi di frammentazione della ricerca automatica MTU percorso

Questa regola consente agli host nella VCN di ricevere i messaggi di frammentazione della ricerca automatica MTU del percorso. Senza accesso a questi messaggi, gli host nella VCN possono avere problemi di comunicazione con gli host esterni alla VCN.

  • Senza conservazione dello stato: No (tutte le regole devono avere lo stato)
  • Tipo di origine: CIDR
  • CIDR di origine: 0.0.0.0/0 (IPv4), ::/0 (IPv6)
  • Protocollo IP: ICMP
  • Tipo: 3
  • Codice: 4
Regola di entrata generale 3: consente i messaggi di errore di connettività all'interno della VCN

Questa regola consente agli host nella VCN di ricevere tra loro messaggi di errore di connettività.

  • Senza conservazione dello stato: No (tutte le regole devono avere lo stato)
  • Tipo di origine: CIDR
  • Source CIDR: IPv4: your VCN's IPv4 CIDR, IPv6: your VCN's IPv6 CIDR
  • Protocollo IP: ICMP
  • Tipo: tutto
  • Codice: tutto
Regola generale di uscita 1: consente tutto il traffico in uscita
  • Senza conservazione dello stato: No (tutte le regole devono avere lo stato)
  • Tipo di destinazione: CIDR
  • CIDR di destinazione: 0.0.0.0/0 (IPv4), ::/0 (IPv6)
  • Protocollo IP: tutto

Se il cliente abilita la notifica degli eventi VM guest del piano dati, la regola di uscita predefinita è sufficiente.

Regole richieste in modo specifico per la rete client

Le regole di sicurezza riportate di seguito sono importanti per la rete client.

Nota

  • Per i sistemi X8M, Oracle consiglia di aprire tutte le porte della subnet client per il traffico in entrata e in uscita. Questo è un requisito per l'aggiunta di ulteriori database server al sistema.
  • Le regole di entrata client 1 e 2 coprono solo le connessioni avviate dall'interno della subnet client. Se si dispone di un client che risiede al di fuori della VCN, Oracle consiglia di impostare due aggiuntive regole simili che invece hanno il CIDR di origine impostato sull'indirizzo IP pubblico del client.
  • Le regole di entrata client 3 e 4 e le regole di uscita client 1 e 2 consentono il traffico TCP e ICMP all'interno della rete client e consentono ai nodi di comunicare tra loro. Se la connettività TCP non riesce tra i nodi, il provisioning del cluster VM cloud Exadata o della risorsa del sistema DB non riesce.

Argomento padre: Regole di sicurezza per Oracle Exadata Database Service on Dedicated Infrastructure

Regola di entrata client 1: consente il traffico ONS e FAN dall'interno della subnet client

La prima regola è consigliata e consente a Oracle Notification Services (ONS) di comunicare gli eventi FAN (Fast Application Notification).

  • Senza conservazione dello stato: No (tutte le regole devono avere lo stato)
  • Tipo di origine: CIDR
  • Source CIDR: IPv4: client subnet's IPv4 CIDR, IPv6: client subnet's IPv6 CIDR
  • Protocollo IP: TCP
  • Intervallo porte di origine: tutto
  • Intervallo di porte di destinazione: 6200
  • Descrizione: una descrizione facoltativa della regola.
Regola di entrata client 2: consente il traffico SQL*NET dall'interno della subnet client

Questa regola è per il traffico SQL*NET ed è richiesta nei seguenti casi:

  • Se è necessario abilitare le connessioni client al database
  • Se si prevede di utilizzare Oracle Data Guard
  • Senza conservazione dello stato: No (tutte le regole devono avere lo stato)
  • Tipo di origine: CIDR
  • Source CIDR: IPv4: client subnet's IPv4 CIDR, IPv6: client subnet's IPv6 CIDR
  • Protocollo IP: TCP
  • Intervallo porte di origine: tutto
  • Intervallo di porte di destinazione: 1521
  • Descrizione: una descrizione facoltativa della regola.
Regola di uscita client 1: consente tutto il traffico TCP all'interno della subnet client

Questa regola è per il traffico SQL*NET come indicato.

  • Senza conservazione dello stato: No (tutte le regole devono avere lo stato)
  • Tipo di destinazione: CIDR
  • CIDR di destinazione: 0.0.0.0/0 (IPv4), ::/0 (IPv6)
  • Protocollo IP: TCP
  • Intervallo porte di origine: tutto
  • Intervallo di porte di destinazione:22
  • Descrizione: una descrizione facoltativa della regola.
Regola di uscita client 2: consente tutto il traffico in uscita (consente le connessioni ai repository Oracle YUM)

La regola 3 di uscita del client è importante perché consente le connessioni ai repository Oracle YUM.

È ridondante con la regola generale di uscita 1: consenti tutto il traffico in uscita (e nella lista di sicurezza predefinita). È facoltativo, ma consigliato nel caso in cui la regola di uscita generale (o la lista di sicurezza predefinita) venga modificata inavvertitamente.

  • Senza conservazione dello stato: No (tutte le regole devono avere lo stato)
  • Tipo di destinazione: CIDR
  • CIDR di destinazione: 0.0.0.0/0 (IPv4), ::/0 (IPv6)
  • Protocollo IP: tutto
  • Descrizione: una descrizione facoltativa della regola.

Regola richiesta in modo specifico per la rete di backup

La regola di sicurezza seguente è importante per la rete di backup perché consente al sistema DB di comunicare con lo storage degli oggetti tramite il gateway del servizio (e, facoltativamente, con i repository Oracle YUM se la rete client non dispone dell'accesso a tali repository).

È ridondante con la regola di uscita generale 1: consente tutto il traffico in uscita in (e nella ). È facoltativo, ma consigliato nel caso in cui la regola di uscita generale (o la lista di sicurezza predefinita) venga modificata inavvertitamente.

Regola di uscita backup: consente l'accesso allo storage degli oggetti
  • Senza conservazione dello stato: No (tutte le regole devono avere lo stato)
  • Tipo destinazione: servizio

  • Servizio di destinazione:

    • Etichetta CIDR del servizio denominata OCI <region> Object Storage
    • Se la rete client non dispone dell'accesso ai repository Oracle YUM, utilizzare l'etichetta CIDR del servizio denominata Tutti i servizi <region> in Oracle Services Network
  • Protocollo IP: TCP
  • Intervallo porte di origine: tutto
  • Intervallo porte di destinazione: 443 (HTTPS)
  • Descrizione: una descrizione facoltativa della regola.

Regole necessarie per il servizio eventi

L'istanza di computazione deve disporre di un indirizzo IP pubblico o di un gateway di servizi per poter inviare le metriche dell'istanza di computazione al servizio Eventi.

Le regole di uscita predefinite sono sufficienti per consentire all'istanza di computazione di inviare le metriche dell'istanza di computazione al servizio Eventi.

Se l'istanza non dispone di un indirizzo IP pubblico, impostare un gateway di servizi sulla rete VCN (Virtual Cloud Network). Il gateway di servizi consente all'istanza di inviare le metriche dell'istanza di computazione al servizio Eventi senza che il traffico passi su Internet. Di seguito sono riportate note speciali per l'impostazione del gateway di servizi per l'accesso al servizio Eventi.

  • Quando si crea il gateway del servizio, abilitare l'etichetta del servizio denominata Tutti i servizi <region> in Oracle Services Network. Include il servizio Eventi.

  • Quando si imposta l'instradamento per la subnet che contiene l'istanza, impostare una regola di instradamento con Tipo di destinazione impostato su Gateway di servizio e il Servizio di destinazione impostato su Tutti i servizi <region> in Oracle Services Network.

    Per istruzioni dettagliate, consulta la sezione Accesso ai servizi Oracle: gateway di servizi.

Regole necessarie per il servizio di monitoraggio

L'istanza di computazione deve disporre di un indirizzo IP pubblico o di un gateway di servizi per poter inviare le metriche dell'istanza di computazione al servizio di monitoraggio.

Le regole di uscita predefinite sono sufficienti per consentire all'istanza di computazione di inviare le metriche dell'istanza di computazione al servizio di monitoraggio.

Se l'istanza non dispone di un indirizzo IP pubblico, impostare un gateway di servizi sulla rete VCN (Virtual Cloud Network). Il gateway di servizi consente all'istanza di inviare le metriche dell'istanza di computazione al servizio di monitoraggio senza che il traffico passi su Internet. Di seguito sono riportate note speciali per l'impostazione del gateway del servizio per accedere al servizio di monitoraggio.

  • Quando si crea il gateway del servizio, abilitare l'etichetta del servizio denominata Tutti i servizi <region> in Oracle Services Network. Include il servizio di monitoraggio.

  • Quando si imposta l'instradamento per la subnet che contiene l'istanza, impostare una regola di instradamento con Tipo di destinazione impostato su Gateway di servizio e il Servizio di destinazione impostato su Tutti i servizi <region> in Oracle Services Network.

    Per istruzioni dettagliate, consulta la sezione Accesso ai servizi Oracle: gateway di servizi.

Modalità di implementazione delle regole di sicurezza

Scopri come implementare le regole di sicurezza all'interno della tua VCN utilizzando il servizio di networking.

Il servizio di networking offre due modi per implementare le regole di sicurezza all'interno della VCN:

Per un confronto dei due metodi, vedere Gestione delle liste di sicurezza e dei gruppi di sicurezza di rete.

Se si utilizzano i gruppi di sicurezza di rete

Se si sceglie di utilizzare i gruppi di sicurezza di rete (NSG), ecco il processo consigliato:

  1. Creare un gruppo NSG per la rete client. Aggiungere le seguenti regole di sicurezza a tale gruppo NSG:

  2. Creare un gruppo NSG separato per la rete di backup. Aggiungere le seguenti regole di sicurezza a tale gruppo NSG:

  3. Quando l'amministratore del database crea un'istanza dell'infrastruttura Exadata Cloud, deve scegliere diversi componenti di rete, ad esempio la VCN e le subnet da utilizzare:
    • Quando scelgono la subnet client, possono anche scegliere quali NSG o NSG utilizzare. Assicurarsi di scegliere il gruppo NSG della rete client.
    • Quando scelgono la subnet di backup, possono anche scegliere quali NSG o NSG utilizzare. Assicurati che scelgano il gruppo NSG della rete di backup.

È invece possibile creare un gruppo NSG separato per le regole generali. Quindi, quando l'amministratore del database sceglie quali NSG utilizzare per la rete client, assicurarsi che scelgano sia il gruppo NSG generale che il gruppo NSG della rete client. Allo stesso modo per la rete di backup, scelgono sia il gruppo NSG generale che il gruppo NSG della rete di backup.

Se si utilizzano liste di sicurezza

Se si sceglie di utilizzare le liste di sicurezza, ecco il processo consigliato:

Se si sceglie di utilizzare le liste di sicurezza, ecco il processo consigliato:

  1. Configurare la subnet client per l'uso delle regole di sicurezza necessarie:

    1. Creare una lista di sicurezza personalizzata per la subnet client e aggiungere le regole elencate in Regole richieste in modo specifico per la rete client.

    2. Associare le due liste di sicurezza seguenti alla subnet client:

      • Lista di sicurezza predefinita della VCN con tutte le relative regole predefinite. Questa funzionalità viene fornita automaticamente con la VCN. Per impostazione predefinita, contiene le regole in Regole necessarie sia per la rete client che per la rete di backup.
      • La nuova lista di sicurezza personalizzata creata per la subnet client.

  2. Configurare la subnet di backup in modo che utilizzi le regole di sicurezza necessarie:

    1. Creare una lista di sicurezza personalizzata per la subnet di backup e aggiungere le regole elencate nella regola richiesta in modo specifico per la rete di backup.

    2. Associare le due liste di sicurezza seguenti alla subnet di backup:

      • Lista di sicurezza predefinita della VCN con tutte le relative regole predefinite. Questa funzionalità viene fornita automaticamente con la VCN. Per impostazione predefinita, contiene le regole in Regole necessarie sia per la rete client che per la rete di backup.
      • La nuova lista di sicurezza personalizzata creata per la subnet di backup.

Successivamente, quando l'amministratore del database crea l'istanza di Exadata Cloud Service, deve scegliere diversi componenti di rete. Quando selezionano la subnet client e la subnet di backup già create e configurate, le regole di sicurezza vengono applicate automaticamente per i nodi creati in tali subnet.

AVVERTENZA:

Non rimuovere la regola di uscita predefinita dalla lista di sicurezza predefinita. In tal caso, assicurati di includere la seguente regola di uscita di sostituzione nella lista di sicurezza della subnet del client:

  • Senza conservazione dello stato: No (tutte le regole devono avere lo stato)
  • Tipo di destinazione: CIDR
  • CIDR di destinazione: 0.0.0.0/0
  • Protocollo IP: tutto

Requisiti di rete per Oracle Database Autonomous Recovery Service

Oracle Database Autonomous Recovery Service richiede una subnet del servizio di recupero registrata dedicata alle operazioni di backup e recupero nella rete cloud virtuale (VCN) del database.

Per utilizzare il servizio di recupero per i backup, attenersi alla procedura descritta in Configurazione del servizio di recupero.

Argomenti correlati

Argomento padre: Impostazione della rete per le istanze dell'infrastruttura Exadata Cloud

Creare un gateway del servizio per lo storage degli oggetti

Nella console OCI, creare un gateway di servizi per lo storage degli oggetti. Il gateway del servizio è necessario per gli aggiornamenti di automazione e i metadati di configurazione.

  1. Aprire il menu di navigazione. Fare clic su Rete, quindi fare clic su Reti cloud virtuali.
  2. Selezionare la VCN in cui si trovano i servizi di database di cui eseguire il backup.
  3. Nella pagina Dettagli rete cloud virtuale risultante, in Risorse, fare clic su Gateway di servizio.
  4. Fare clic su Crea gateway del servizio e fornire i dettagli riportati di seguito.
    1. Nome: nome descrittivo per il gateway del servizio. Non deve essere unico. Evitare di fornire informazioni riservate.
    2. Compartimento: compartimento in cui si desidera creare il gateway del servizio, se diverso dal compartimento in cui si sta attualmente lavorando.
    3. Servizi: selezionare l'etichetta CIDR del servizio, All <region> Services in Oracle Services Network, dall'elenco a discesa.
    4. Tag: (opzione avanzata) se si dispone delle autorizzazioni per creare una risorsa, si dispone anche delle autorizzazioni per applicare tag in formato libero a tale risorsa. Per applicare una tag definita, è necessario disporre delle autorizzazioni per utilizzare lo spazio di nomi tag. Per ulteriori informazioni sull'applicazione di tag, vedere Tag delle risorse. Se non si è certi di applicare le tag, saltare questa opzione (è possibile applicare le tag in un secondo momento) o chiedere all'amministratore.

  5. Fare clic su Crea gateway del servizio.

    Prima di procedere al passo successivo, attendere la creazione del gateway.

  6. In Risorse fare clic su Tabelle di instradamento.

    Associazione tabella di instradamento: è possibile associare una tabella di instradamento VCN specifica a questo gateway. Se si associa una tabella di instradamento, in seguito il gateway deve sempre avere una tabella di instradamento associata. È possibile modificare le regole nella tabella di instradamento corrente o sostituirle con un'altra.

  7. Fare clic sul nome della tabella di instradamento utilizzato dalla subnet per il servizio di recupero.

  8. Nella pagina Dettagli tabella di instradamento visualizzata, fare clic su Aggiungi regole di instradamento nella sezione Regole di instradamento.

    Quando configuri un gateway di servizi per una determinata etichetta CIDR del servizio, devi anche creare una regola di instradamento che specifichi tale etichetta come destinazione e la destinazione come gateway di servizi. Questa operazione viene eseguita per ogni subnet che deve accedere al gateway.

  9. Nella finestra di dialogo Aggiungi regole di instradamento visualizzata, immettere i dettagli riportati di seguito.
    1. Tipo di destinazione: gateway del servizio.
    2. Servizio di destinazione: l'etichetta CIDR del servizio abilitata per il gateway. All <region> Services in Oracle Services Network
    3. Gateway del servizio di destinazione: selezionare il nome fornito nel passo 4.
    4. Descrizione: una descrizione facoltativa della regola.
  10. Fare clic su Aggiungi regole di instradamento.