Documentazione di Oracle Cloud Infrastructure

Preparazione per Oracle Exadata Database Service su infrastruttura Exascale

Rivedi OCI, nonché i requisiti di sito, rete e storage per preparare e distribuire Oracle Exadata Database Service sull'infrastruttura Exascale nel tuo data center.

Requisiti di Oracle Cloud Infrastructure (OCI) per Oracle Exadata Database Service su infrastruttura Exascale

Apprendi i concetti di base per iniziare a utilizzare Oracle Cloud Infrastructure.

Oracle Exadata Database Service su infrastruttura Exascale è gestito dal piano di controllo Oracle Cloud Infrastructure (OCI). Le risorse Oracle Exadata Database Service sull'infrastruttura Exascale vengono distribuite nella tenancy OCI.

Prima di poter eseguire il provisioning di Oracle Exadata Database Service sull'infrastruttura Exascale, la tenancy Oracle Cloud Infrastructure deve essere abilitata per utilizzare Oracle Exadata Database Service sull'infrastruttura Exascale. Rivedere le informazioni contenute in questa pubblicazione per ulteriori dettagli.

I task riportati di seguito sono comuni a tutte le distribuzioni OCI. Fare riferimento ai collegamenti negli argomenti correlati per trovare la documentazione di Oracle Cloud Infrastructure associata.

  • Introduzione a OCI.

    Se non si ha familiarità con OCI, apprendere i concetti di base per iniziare seguendo il manuale OCI Getting Started Guide (in lingua inglese).

  • Impostazione della tenancy.

    Dopo che Oracle avrà creato la tenancy in OCI, un amministratore dell'azienda dovrà eseguire alcuni task di impostazione e stabilire un piano dell'organizzazione per le risorse e gli utenti cloud. Le informazioni contenute in questo argomento consentiranno di iniziare.

  • Gestione delle aree

    Questo argomento descrive le nozioni di base per la gestione delle sottoscrizioni area.

  • Gestione dei compartimenti

    Questo argomento descrive le nozioni di base per l'utilizzo dei compartimenti.

  • Gestione degli utenti

    In questo argomento vengono descritte le nozioni di base per l'utilizzo degli utenti.

  • Gestione dei gruppi

    In questo argomento vengono descritte le nozioni di base per l'utilizzo dei gruppi.

Argomenti correlati

Argomento principale: Preparazione per Oracle Exadata Database Service su infrastruttura Exascale

Criterio IAM richiesto per Oracle Exadata Database Service su infrastruttura Exascale

Rivedere il criterio di gestione dell'accesso alle identità (IAM) per il provisioning di Oracle Exadata Database Service sui sistemi dell'infrastruttura Exascale.

Un criterio è un documento IAM che specifica chi dispone del tipo di accesso alle risorse. Viene utilizzato in modi diversi:
  • Una singola dichiarazione scritta nella lingua del criterio
  • Raccolta di istruzioni in un singolo documento denominato "criterio", a cui è assegnato un ID Oracle Cloud (OCID)
  • Corpo generale dei criteri utilizzati dall'organizzazione per controllare l'accesso alle risorse

Per compartimento si intende una raccolta di risorse correlate alle quali possono accedere solo determinati gruppi autorizzati da un amministratore dell'organizzazione.

Per utilizzare Oracle Cloud Infrastructure, devi ricevere il tipo di accesso richiesto in un criterio scritto da un amministratore, sia che tu stia utilizzando la console, sia che tu stia utilizzando l'API REST con un kit di sviluppo software (SDK), un'interfaccia della riga di comando (CLI) o qualche altro strumento. Se si tenta di eseguire un'azione e si riceve un messaggio che informa che non si dispone dell'autorizzazione o che si è autorizzati, confermare con l'amministratore della tenancy il tipo di accesso concesso e il compartimento in cui si dovrebbe lavorare.

Se non si ha familiarità con i criteri, vedere "Guida introduttiva ai criteri" e "Criteri comuni". Se si desidera approfondire la scrittura dei criteri per i database, vedere "Dettagli per il servizio di database".

Per ulteriori dettagli sulla scrittura di criteri specifici per le risorse Exadata Cloud@Customer, vedere "Dettagli dei criteri per Oracle Exadata Database Service sull'infrastruttura Exascale".

Impostazione di rete per Oracle Exadata Database Service su istanze di infrastruttura Exascale

Questo argomento descrive la configurazione consigliata per la VCN e diversi requisiti correlati per l'istanza di Oracle Exadata Database Service on Exascale Infrastructure.

Prima di impostare un'istanza di Oracle Exadata Database Service sull'infrastruttura Exascale, è necessario impostare una rete cloud virtuale (VCN) e altri componenti del servizio di rete.

Argomento principale: Preparazione per Oracle Exadata Database Service su infrastruttura Exascale

VCN e subnet

Per avviare un cluster VM Oracle Exadata Database Service su infrastruttura Exascale, è necessario disporre di una rete cloud virtuale e di almeno due subnet.

Per avviare un cluster VM Oracle Exadata Database Service su infrastruttura Exascale, è 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 il cluster VM Oracle Exadata Database Service on Exascale Infrastructure

  • 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

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.

Si creeranno tabelle di instradamento personalizzate per ogni subnet. Inoltre, creerai 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 chiamati virtual machine). Ulteriori informazioni su questi elementi.

Argomenti correlati

Argomento padre: Impostazione di rete per Oracle Exadata Database Service sulle istanze dell'infrastruttura Exascale

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:

  • Subnet:

    • Subnet client pubblica (pubblica indica che le risorse della subnet possono avere indirizzi IP pubblici a discrezione dell'utente).
    • Subnet di backup Privata (privata indica che le risorse nella subnet non possono avere indirizzi IP pubblici e pertanto non possono ricevere connessioni in entrata da Internet).

  • Gateway per la VCN:

  • Table di instradamento:

    • Tabella di instradamento personalizzata per la subnet del client pubblico, con un instradamento per 0.0.0.0/0 e destinazione = gateway Internet.
    • Separare la tabella di instradamento personalizzata per la subnet di backup privata, con una regola di instradamento per le etichette CIDR del servizio (vedere le etichette CIDR in Panoramica dei gateway di servizio e le etichette CIDR dei dispositivi disponibili e la destinazione = gateway del servizio).
  • Regole di sicurezza per abilitare il traffico desiderato da e verso i nodi di calcolo delle virtual machine Exadata.
  • Accesso nodo allo storage degli oggetti: instradamento statico sui nodi di calcolo dell'istanza di Exadata Cloud Service (per abilitare l'accesso ai servizi OCI tramite la subnet di backup).
Nota

Per informazioni sulla configurazione delle regole di instradamento con il gateway del servizio come destinazione nelle tabelle di instradamento associate alle 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:

    • Privata subnet client.
    • 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 in locale e destinazione = DRG.
      • Regola per l'etichetta CIDR del servizio denominata Tutti i servizi <region> in Oracle Services Network e target = gateway del servizio. 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 del gateway di servizio sia allo storage degli oggetti che ai repository YUM.
      • Facoltativamente, una regola per 0.0.0.0/0 e la destinazione = gateway NAT.
    • Separa la tabella di instradamento personalizzata per la subnet di backup privata con una regola:
      • La stessa regola della subnet del client: per l'etichetta CIDR del servizio denominata Tutti i servizi <region> in Oracle Services Network e target = gateway del servizio. 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

È necessario creare una VCN con due subnet e assicurarsi che siano presenti indirizzi sufficienti per la dimensione del cluster VM.

Nota

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

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

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. Il servizio di networking riserva tre indirizzi IP in ogni subnet.

Utilizzare la seguente formula per calcolare il numero minimo di indirizzi IP in cui la variabile n rappresenta il numero di VM nel cluster VM:

Numero minimo di indirizzi client = 4*n+6

Il numero minimo di indirizzi di backup = 3*n+3

Nota

L'allocazione di uno spazio più grande 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. Per pianificare una crescita futura, aggiungi gli indirizzi che prevedi di richiedere durante lo scale-up del tuo cluster VM, non solo il numero di VM di cui prevedi di eseguire il provisioning per necessità immediate.

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 di Oracle Exadata Database Service on Exascale Infrastructure 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 dei nodi allo storage degli oggetti: instradamento statico.

Argomento padre: VCN e subnet

Impostazione di DNS per un'istanza di Oracle Exadata Database Service su infrastruttura Exascale

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 VCN, le subnet e Oracle Exadata Database Service sull'infrastruttura Exascale
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 di Oracle Exadata Database Service sull'infrastruttura Exascale. 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 la risorsa cluster VM cloud dell'istanza di Oracle Exadata Database Service on Exascale Infrastructure

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. 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.

  • 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 in locale e le risorse VCN comunicano tra loro.

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.

Configura DNS privato

Prerequisiti necessari per utilizzare il DNS privato.

  • La vista privata e la zona privata devono essere create prima di avviare il provisioning del cluster VM. Per informazioni dettagliate, 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 essere in grado di eseguire il backup dei database e applicare patch e aggiornare gli strumenti cloud su un'istanza di Oracle Exadata Database Service on Exascale Infrastructure, Oracle consiglia di configurare Autonomous Recovery Service. Indipendentemente dalla modalità di configurazione della VCN con tale accesso (ad esempio, con un gateway di servizi), se utilizzi lo storage degli oggetti, potresti anche dover configurare un instradamento statico allo storage degli oggetti su ciascuno dei nodi di calcolo nel cluster. Il valore è obbligatorio solo se non si utilizzano i backup automatici. Se utilizzi backup personalizzati utilizzando le API di backup, devi instradare il traffico destinato allo storage degli oggetti tramite l'interfaccia di backup (BONDETH1). Questa operazione non è necessaria se si utilizzano i backup automatici creati con la console, le API o le interfacce CLI.
Nota

A partire dal 06 agosto 2025, per le tenancy create nelle aree FRA, PHX o NRT, Autonomous Recovery Service sarà l'unica destinazione di backup quando si abilita il backup automatico sui database.

Attenzione:

È necessario configurare un instradamento statico per l'accesso allo storage degli oggetti su ogni nodo di calcolo in un'istanza di Oracle Exadata Database Service sull'infrastruttura Exascale se non si creano backup automatici con la console, le interfacce 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 di Oracle Exadata Database Service sull'infrastruttura Exascale. 

    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 di Oracle Exadata Database Service on Exascale Infrastructure.

Gateway di servizi per la VCN

La VCN deve accedere sia allo storage degli oggetti per i backup che ai repository Oracle YUM per gli aggiornamenti del sistema operativo.

Argomento padre: Impostazione di rete per Oracle Exadata Database Service sulle istanze dell'infrastruttura Exascale

Opzione 1: accesso del gateway del servizio ai servizi OCI

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

A titolo di promemoria, ecco il diagramma per l'opzione 1, configurazione di rete con una subnet client pubblica:

Questa immagine mostra la configurazione di rete con una sottorete client pubblica, come descritto in precedenza.

In generale, è necessario:

  • Eseguire i task per l'impostazione di un gateway di servizi su una VCN e abilitare in modo specifico l'etichetta CIDR del servizio denominata OCI <region> Object Storage.
  • Nel task per l'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 = gateway del servizio.
  • Nel task per l'aggiornamento delle regole di sicurezza nella subnet, eseguire il task nel gruppo di sicurezza di rete (NSG) o nella lista di sicurezza personalizzata della rete del backup. Impostare una regola di sicurezza con il servizio di destinazione impostato su OCI <region> Object Storage. Vedere "Regola richiesta in modo specifico per la rete di backup" Regola richiesta in modo specifico per la rete di backup.
Opzione 2: accesso del gateway di servizio sia allo storage degli oggetti che ai repository YUM

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 sia lo storage degli oggetti che i repository Oracle YUM.

Nota

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

A titolo di promemoria, ecco il diagramma per l'opzione 2, una configurazione di rete con sottoreti private:

Questa immagine mostra l'impostazione della rete con sottoreti del client privato, come descritto in precedenza.

In generale, è necessario:

  • Eseguire i task per l'impostazione di un gateway di servizi su una VCN e abilitare in modo specifico l'etichetta CIDR del servizio denominata Tutti i servizi <region> 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 Tutti i servizi <region> in Oracle Services Network e target = gateway del servizio.
  • Nella procedura per l'aggiornamento delle regole di sicurezza per la sottorete, eseguire l'attività nel gruppo di sicurezza di rete (NSG) o nell'elenco di sicurezza personalizzato backup. Impostare una regola di sicurezza con il servizio di destinazione impostato su OCI <region> Object Storage. Vedere Regole di sicurezza. Si noti 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.

Nota

A partire dal 06 agosto 2025, per le tenancy create nelle aree FRA, PHX o NRT, Autonomous Recovery Service sarà l'unica destinazione di backup quando si abilita il backup automatico sui database.
  • 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 CIDR del servizio OCI <region> Object Storage che l'etichetta Tutti i servizi <region> in Oracle Services Network per il gateway del servizio. Per soddisfare le esigenze di entrambe le subnet, è necessario abilitare Tutti i servizi <region> in Oracle Services Network per il gateway di servizi. La VCN può avere un solo gateway di servizi.
  • Qualsiasi regola di instradamento destinata a un determinato gateway di servizi deve utilizzare un'etichetta CIDR del servizio abilitata e non un blocco CIDR come destinazione per la regola. In altre parole, per l'opzione 2, le tabelle di instradamento di entrambe le subnet devono utilizzare Tutti i servizi <region> in Oracle Services Network per le regole del gateway di servizi.
  • A differenza delle regole di instradamento, le regole di sicurezza possono utilizzare l'etichetta CIDR del servizio qualsiasi (indipendentemente dal fatto che la VCN disponga o meno di un gateway di servizi) 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 Tutti i servizi <region> in Oracle Services Network, la subnet può avere 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 su infrastruttura Exascale

In questa sezione vengono elencate le regole di sicurezza da utilizzare con Oracle Exadata Database Service sull'infrastruttura Exascale.

Le regole di sicurezza controllano i tipi di traffico consentiti per la rete client e la rete di backup delle virtual machine. 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.

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

Esistono diverse regole generali che abilitano la connettività essenziale per gli host nella VCN.

Se si utilizzano le 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
  • 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
  • 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
  • CIDR di origine: il CIDR della VCN
  • Protocollo IP: ICMP
  • Tipo: 3
  • 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
  • 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 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.

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
  • CIDR di origine: CIDR della subnet client
  • 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
  • CIDR di origine: CIDR della subnet client
  • Protocollo IP: TCP
  • Intervallo porte di origine: tutto
  • Intervallo di porte di destinazione: 1521
  • Descrizione: una descrizione facoltativa della regola.

Regola di entrata client 3: consente l'applicazione di patch al traffico dalla subnet client

  • Senza conservazione dello stato: No (tutte le regole devono avere lo stato)
  • Tipo di origine: CIDR
  • CIDR di origine: CIDR della subnet client
  • Protocollo IP: TCP
  • Intervallo porte di origine: tutto
  • Intervallo di porte di destinazione: 7085
  • Descrizione: è possibile aggiungere una descrizione significativa della regola. Ad esempio: "Consenti l'accesso all'endpoint privato di aggiornamento della flotta Exadata all'interno della subnet".

Regola di uscita client 1: consente tutto il traffico TCP 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
  • 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 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
  • Protocollo IP: tutto
  • Descrizione: una descrizione facoltativa della regola.

Criteri IAM obbligatori per Oracle Database e Oracle Grid Infrastructure Patching

Concedere i criteri IAM (Identity and Management) per accedere alle subnet, alle schede di interfaccia di rete virtuale (vNICs) e agli indirizzi IP privati (IP privati) agli utenti o ai gruppi che gestiscono il database e Oracle Grid Infrastructure. Ad esempio, si supponga che il gruppo admin-group gestisca il compartimento ABC. In tal caso, è necessario impostare i seguenti criteri:

  • Consentire al gruppo admin-group di utilizzare le subnet nel compartimento ABC
  • Consentire al gruppo admin-group di utilizzare vNICs nel compartimento ABC
  • Consenti al gruppo admin-group di utilizzare IP privati nel compartimento ABC

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 di rete per Oracle Exadata Database Service sulle istanze dell'infrastruttura Exascale

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 regole simili aggiuntive per le quali 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 nei nodi, il provisioning della risorsa cluster VM Exadata non riesce.

Argomento padre: Regole di sicurezza per Oracle Exadata Database Service su infrastruttura Exascale

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 cluster VM 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).

È ridondante con la regola di uscita generale 1: consente tutto il traffico in uscita. È facoltativo ma consigliato nel caso in cui la regola di uscita generale (o l'elenco di sicurezza predefinito) venga modificata inavvertitamente.

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:

    • Le regole elencate in "Regole richieste sia per la rete client che per la rete di backup"
    • Le regole elencate in "Regole richieste in modo specifico per la rete client"

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

    • Le regole elencate in "Regole richieste sia per la rete client che per la rete di backup"
    • Le regole elencate in "Regole richieste in modo specifico per la rete client"
  3. L'amministratore del database, quando crei un'istanza Exadata su Oracle Exadata Database Service on Exascale Infrastructure, deve scegliere diversi componenti di rete (ad esempio, quali VCN e subnet utilizzare):
    • Quando scegli la subnet client, puoi anche scegliere quale NSG o NSG utilizzare. Scegliere il gruppo NSG della rete client.
    • Quando scegli la subnet di backup, puoi anche scegliere quale NSG o NSG utilizzare. Scegliere il gruppo NSG della rete di backup.

È invece possibile creare un gruppo NSG separato per le regole generali. Quindi, quando gli amministratori di database scelgono quali NSG utilizzare per la rete client, scelgono 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 in Regola richiesta specificamente 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 Recovery Service per i backup, segui i passi descritti in Onboarding di Oracle Database to Recovery Service.

Argomento padre: Impostazione di rete per Oracle Exadata Database Service sulle istanze dell'infrastruttura Exascale

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.

Nota

A partire dal 06 agosto 2025, per le tenancy create nelle aree FRA, PHX o NRT, Autonomous Recovery Service sarà l'unica destinazione di backup quando si abilita il backup automatico sui database.
  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.

Interoperabilità tra i servizi ExaDB-D e ExaDB-XS: Data Guard, backup e ripristino

Ora puoi creare un gruppo Oracle Data Guard multiservizio tra i servizi di database.

Questa funzione consente di stabilire funzionalità di backup e ripristino tra più servizi per le configurazioni riportate di seguito.  

  • Database primario in ExaDB-D con uno o più database in standby in ExaDB-XS o ExaDB-D.
  • Database primario in ExaDB-XS con uno o più database in standby in ExaDB-D o ExaDB-XS.
Nota

Al momento di questa release, Oracle Data Guard tra Exadata Database Service on Dedicated Infrastructure ed Exadata Database Service on Exascale Infrastructure può essere configurato solo con la release Oracle AI Database 26ai.

Questa funzionalità ti consente di sfruttare il potenziale dei tuoi servizi di database nella tua tenancy,

Nota

Per garantire il massimo della disponibilità, Oracle consiglia di posizionare i cluster VM peer in un'infrastruttura Exadata diversa dal cluster VM primario.

Opzioni di configurazione del database in standby

Quando si aggiunge un database in standby, è possibile specificare i dettagli riportati di seguito.

  • Dettagli cluster VM peer: se la destinazione è ExaDB-D, è possibile selezionare l'infrastruttura Exadata.
  • Selezione servizio di destinazione: scegliere ExaDB-D o ExaDB-XS. Per impostazione predefinita, il servizio che avvia il gruppo Data Guard è selezionato. Se un servizio non è disponibile nell'area selezionata, viene disabilitato con il messaggio: 'Il servizio non è disponibile in quest'area'.
  • Tipo Data Guard: il gruppo può essere configurato con Data Guard o Active Data Guard e ogni database in standby può avere un tipo diverso.
  • Limitazione del gruppo Data Guard: un database primario è limitato a un gruppo Data Guard.
  • Creazione di database in standby: è possibile aggiungere un solo database in standby alla volta. Tuttavia, i database in standby possono essere creati in una qualsiasi delle seguenti categorie senza restrizioni sul loro numero:
    • All'interno dello stesso servizio
    • Tra i servizi
    • Nello stesso dominio di disponibilità (AD)
    • In tutti i domini di disponibilità all'interno della stessa area
    • In tutte le regioni

Considerazioni chiave per i database primari e in standby tra più servizi

  • Sia il database primario che quello in standby devono utilizzare la stessa soluzione di gestione delle chiavi.
  • Data Guard può essere configurato in modalità di protezione Max Performance o Max Availability con tipo di trasporto Sync o Async, in base alle seguenti regole:
    • Per il primo database in standby:
      • L'impostazione predefinita è Modalità prestazioni massime con trasporto asincrono.
      • Impossibile modificare la modalità di protezione e il tipo di trasporto.
    • Per il secondo e i database di standby successivi:
      • Eredita la modalità di protezione dal primo standby.
      • Il valore predefinito è Trasporto asincrono.
      • Impossibile modificare la modalità di protezione e il tipo di trasporto.

Visualizzazione e modifica delle configurazioni Data Guard

  • Visualizzare tutti i database che fanno parte del gruppo Data Guard nella tabella Gruppo Data Guard, indipendentemente dal fatto che ci si trovi nelle pagine del database primario o in standby.
  • Modificare la configurazione Data Guard per aggiornare:
    • Tipo Data Guard: può essere diverso per ogni database in standby. Questa operazione può essere modificata solo da un database in standby.
    • Password amministratore del database: può essere modificata da qualsiasi database.
    • Modalità di protezione: è possibile passare da Prestazioni massime a Disponibilità massima dal database primario o da qualsiasi database in standby.
    • Tipo di trasporto: è possibile passare da Async a Sync solo da un database in standby.
Nota

Se la modalità di protezione è impostata su Disponibilità massima, il sistema verifica che almeno un database in standby utilizzi il trasporto Sync. Se non è stato trovato, viene visualizzato un messaggio d'errore:

"Per ottenere una perdita di dati pari a zero, è necessario almeno uno standby con il trasporto Sync. Si consiglia di avere un trasporto in standby con Sync nello stesso servizio del database primario."

Switchover e failover dei database

  • Switchover (su qualsiasi database in standby)
    • Lo switchover viene eseguito senza applicare una versione principale o un controllo Release Update (RU). Tuttavia, viene visualizzata un'avvertenza se il database di standby dispone di una configurazione asimmetrica, ad esempio conteggi di nodi, memoria o tipo di servizio diversi.
  • Failover (su qualsiasi database in standby)
    • Il failover viene eseguito senza applicare una versione principale o il controllo dell'aggiornamento della release (RU). Tuttavia, viene visualizzata un'avvertenza se il database di standby dispone di una configurazione asimmetrica, ad esempio conteggi di nodi, memoria o tipo di servizio diversi.

Opzioni di backup e ripristino del database

Nota

A partire dal 06 agosto 2025, per le tenancy create nelle aree FRA, PHX o NRT, Autonomous Recovery Service sarà l'unica destinazione di backup quando si abilita il backup automatico sui database.

  • Backup pianificati e automatici
    • Puoi pianificare backup automatici sul database primario, sul database in standby o su entrambi.
    • Sono supportati sia i backup dello storage degli oggetti che del servizio di recupero.
    • Se i backup sono configurati su entrambi i database primario e in standby, devono utilizzare lo stesso tipo di destinazione di backup.
  • Ripristino in loco dello stesso database all'interno di ExaDB-XS
    Ripristinare e recuperare un database utilizzando un backup eseguito dallo stesso database in ExaDB-XS:
    • Ripristinare primario utilizzando un backup eseguito sul database primario.
    • Ripristinare lo standby utilizzando un backup eseguito sul database di standby.
  • Ripristino in loco di un database peer all'interno di ExaDB-XS
    Ripristinare e recuperare un database peer (che non dispone di backup configurati) utilizzando un backup dal database di origine con Recovery Service:
    • Scenario 1: ripristinare il database primario utilizzando il backup in standby.
      • Database principale: ExaDB-XS (nessun backup configurato)
      • Database in standby: ExaDB-XS (backup configurati per Recovery Service)
    • Scenario 2: ripristinare lo standby utilizzando il backup primario.
      • Database principale: ExaDB-XS (backup configurati per Recovery Service)
      • Database in standby: ExaDB-XS (nessun backup configurato)
  • Ripristino in loco di un database peer in tutti i servizi
    Ripristinare e recuperare un database in ExaDB-XS o ExaDB-D utilizzando un backup dal database di origine nel servizio opposto (ExaDB-D o ExaDB-XS) con Recovery Service:
    • Scenario 1: ripristinare un database peer in ExaDB-XS utilizzando un backup da ExaDB-D
      • Caso d'uso 1: ripristinare il database primario utilizzando il backup in standby.
      • Caso d'uso 2: ripristinare lo standby utilizzando il backup primario.
    • Scenario 2: ripristinare un database peer in ExaDB-D utilizzando un backup da ExaDB-XS
      • Caso d'uso 1: ripristinare il database primario utilizzando il backup in standby.
      • Caso d'uso 2: ripristinare lo standby utilizzando il backup primario.

Ripristino non in loco (creazione di un nuovo database)

  • In ExaDB-XSÈ possibile creare un nuovo database in ExaDB-XS utilizzando un backup dallo stesso servizio.
    • Ripristina entro:
      • Lo stesso dominio di disponibilità (AD)
      • Un AD diverso all'interno della stessa area
      • Un'altra regione
    • Supporta lo storage degli oggetti o il servizio di recupero come destinazione di backup.
  • Tra servizi
    • Scenario 1: creare un nuovo database in ExaDB-D utilizzando un backup da ExaDB-XS
      • Origine: ExaDB-XS (database e backup)
      • Destinazione: ExaDB-D (qualsiasi area o AD)
      • Destinazione di backup: servizio di storage degli oggetti o recupero
    • Scenario 2: creare un nuovo database in ExaDB-XS utilizzando un backup da ExaDB-D
      • Origine: ExaDB-D (database e backup)
      • Destinazione: ExaDB-XS (qualsiasi area o AD)
      • Destinazione di backup: servizio di storage degli oggetti o recupero