Pianificazione della distribuzione

Oracle Database@Azure utilizza l'hardware dei cluster Oracle Exadata, le reti RDMA e gli Oracle Database e il software più recenti, tutti installati direttamente all'interno del data center Microsoft Azure.

Questa architettura ti consente di utilizzare lo stesso servizio Oracle Database che viene eseguito in modo nativo su Oracle Cloud Infrastructure, ma su Microsoft Azure.

In questa sezione vengono descritte le implementazioni riportate di seguito.

• Oracle Database@Azure Oracle Autonomous Database
• Oracle Database@Azure Oracle Exadata Database Service

Progettazione della rete per Oracle Database@Azure Autonomous Database

Questa architettura mostra Oracle Autonomous Database distribuito su Microsoft Azure.

Autonomous Database viene presentato come scheda di interfaccia di rete virtuale (VNIC) in una subnet di Azure delegata a Oracle.Database/networkAttachments. Durante il provisioning del servizio, viene creata una rete cloud virtuale (VCN, Virtual Cloud Network), con lo stesso intervallo di blocchi CIDR della subnet delegata. La VCN è un costrutto regionale che si estende dal sito figlio all'area Oracle Cloud Infrastructure (OCI) più vicina. Lo storage degli oggetti OCI viene utilizzato per eseguire il backup del database.

Descrizione dell'immagine network-adb-azure.png

network-adb-azure-oracle.zip

Per distribuire Oracle Autonomous Database su Microsoft Azure, utilizza i seguenti passaggi di alto livello:

1. Pianificare il blocco CIDR (instradamento tra domini senza classi) per la subnet delegata dal client.

   Riservare il blocco CIDR per la subnet in cui verrà distribuito Autonomous Database. Questo blocco CIDR non deve sovrapporsi a quelli già utilizzati in locale o nella distribuzione corrente di Azure. Inoltre:

   • 13 indirizzi IP sono riservati per i servizi di networking nella subnet client, indipendentemente dal numero di istanze di Autonomous Database presenti nella subnet client. I 13 indirizzi sono il primo 4, il 9 ° al 16 °, e l'ultimo indirizzo IP.
   • La dimensione minima del blocco CIDR è /27.
   • Gli indirizzi IP 100.106.0.0/16 e 100.107.0.0/16 sono riservati per la connettività interna e non possono essere allocati alla sottorete del client.

   Pianifica sempre l'espansione futura dell'ambiente e prendi in considerazione l'allocazione di un blocco CIDR più grande di quello necessario. Una volta eseguito il provisioning del servizio, il blocco CIDR non può essere ridimensionato.

2. Creare la subnet delegata.

   Nella rete virtuale che ospiterà Autonomous Database, creare una subnet e delegarla aOracle.Database/networkAttachments. Nella subnet delegata sono consentiti solo carichi di lavoro di Oracle Database@Azure e non è possibile eseguire il provisioning di altri servizi di Azure o di computazione in tale subnet.

   Quando si esegue il provisioning di Oracle Database@Azure, è necessario specificare la rete virtuale e la subnet delegata.

3. Comprendere il DNS (domain name service).

   Autonomous Database avrà un nome dominio completamente qualificato (FQDN) dal dominio oraclecloud.com. Questa zona è una zona DNS privata che risiede in OCI. I record di questa zona vengono replicati in una zona DNS privata corrispondente in Azure. Le applicazioni di Azure che si connettono ad Autonomous Database risolvono il nome FQDN utilizzando la zona DNS privata di Azure.

   Per verificare il nome FQDN, prima accedere alla tenancy OCI e controllare la zona DNS lì, quindi verificare il DNS nella console di Azure:

   1. Nella console di Azure passare alla console del servizio Oracle Autonomous Database e prendere nota dell'IP privato del database elencato in Rete. Fare clic su Vai a OCI.
   2. Eseguire il login alla tenancy OCI, visualizzare la pagina dei dettagli per Autonomous Database e prendere nota della VCN in cui viene distribuito il database e del gruppo di sicurezza di rete (NSG) utilizzato per approvare il traffico di rete in Autonomous Database.
   3. Fare clic sul collegamento Rete cloud virtuale.
   4. Fare clic sul collegamento Resolver DNS.
   5. Fare clic sul collegamento Vista privata predefinita.
   6. Individuare la zona DNS utilizzata da Autonomous Database e controllare l'indirizzo IP del record A. Prendere nota del nome di dominio.
   7. Nella console di Azure, accedere al servizio DNS di Azure, individuare la zona DNS privata identificata nella console OCI e fare clic su Collegamenti di rete virtuali. Si noti che è uguale al nome di dominio della console OCI
4. Approva il traffico di rete verso Autonomous Database.
   1. Accedere alla tenancy OCI, visualizzare la pagina dei dettagli per Autonomous Database e fare clic sul collegamento Gruppi di sicurezza di rete.
   2. Assicurarsi che le applicazioni che si connettono ad Autonomous Database abbiano l'approvazione richiesta (tcp 1521 o tcp 1522).

Progettazione della rete per Oracle Database@Azure Oracle Exadata Database Service

Questa architettura mostra Oracle Exadata Database Service distribuito su Microsoft Azure.

Il servizio viene presentato come una serie di schede di interfaccia di rete virtuale (VNIC) in una subnet di Azure delegata a Oracle.Database/networkAttachments. Durante il provisioning del servizio, viene creata una rete cloud virtuale (VCN, Virtual Cloud Network), con lo stesso intervallo di blocchi CIDR della subnet delegata. La VCN è una costruzione regionale che si estende dal sito figlio all'area OCI più vicina.

Sebbene Oracle Autonomous Database sia un servizio regionale e possa essere avviato automaticamente in varie zone, Oracle Exadata Database Service ha un'affinità per una zona specifica.

Descrizione dell'immagine network-exadata-azure.png

network-exadata-azure-oracle.zip

Per distribuire Oracle Exadata Database Service su Microsoft Azure, utilizza i seguenti passaggi di alto livello:

1. Pianificare il blocco CIDR per la subnet delegata dal client.

   Oracle Exadata Database Service richiede due intervalli di blocchi CIDR: un blocco CIDR per la subnet client utilizzata per eseguire il provisioning di una subnet delegata in Azure e un altro blocco CIDR facoltativo per la subnet di backup. I blocchi CIDR non devono sovrapporsi a quelli già utilizzati in locale o nella distribuzione corrente di Azure.

   La sottorete del client presenta i seguenti requisiti:

   • Ogni virtual machine (VM) richiede 4 indirizzi IP. I cluster VM hanno almeno 2 virtual machine. Pertanto, un cluster VM con 2 virtual machine richiede 8 indirizzi IP nella subnet client. Ogni virtual machine aggiuntiva aggiunta a un cluster VM aumenta il numero di indirizzi IP necessari nella subnet client di 4 IP.
   • Ogni cluster VM richiede 3 indirizzi IP per SCAN (Single Client Access Names), indipendentemente dal numero di virtual machine presenti nel cluster VM.
   • 13 indirizzi IP sono riservati per i servizi di networking nella subnet client, indipendentemente dal numero di istanze di Autonomous Database presenti nella subnet client. I 13 indirizzi sono il primo 4, il 9 ° al 16 °, e l'ultimo indirizzo IP.
   • La dimensione minima del blocco CIDR è /27.
   • Gli indirizzi IP 100.106.0.0/16 e 100.107.0.0/16 sono riservati per la connettività interna e non possono essere allocati alla sottorete del client.
   • Una subnet client può ospitare cluster VM da infrastrutture Exadata diverse se appartengono alla stessa zona di disponibilità.

   La subnet di backup soddisfa i requisiti riportati di seguito.

   • Ogni virtual machine (VM) richiede 3 indirizzi IP. I cluster VM hanno almeno 2 virtual machine. Pertanto, un cluster VM con 2 virtual machine richiede 6 indirizzi IP nella subnet di backup. Ogni virtual machine aggiuntiva aggiunta a un cluster VM aumenta il numero di indirizzi IP necessari nella subnet di backup di 3 IP.
   • I servizi di networking richiedono 3 indirizzi IP per la subnet di backup, indipendentemente dal numero di cluster VM presenti nella subnet di backup.
   • La dimensione minima del blocco CIDR è /28.

   Pianifica sempre l'espansione futura dell'ambiente e prendi in considerazione l'allocazione di un blocco CIDR più grande di quello necessario. Una volta eseguito il provisioning del servizio, il blocco CIDR non può essere ridimensionato.

2. Creare la subnet delegata.

   Nella rete virtuale che ospiterà il cluster VM Exadata, creare una subnet e delegarla a Oracle.Database/networkAttachments. Nella subnet delegata sono consentiti solo carichi di lavoro di Oracle Database@Azure e non è possibile eseguire il provisioning di altri servizi di Azure o di computazione in tale subnet.

   Quando si esegue il provisioning di Oracle Exadata Database Service, è necessario specificare la subnet del client delegato e la subnet di backup.

   Se non viene fornito un blocco CIDR per la subnet di backup, viene utilizzato l'intervallo 192.168.252.0/22 predefinito. La subnet di backup non viene utilizzata in Azure e il blocco CIDR non fa parte del blocco CIDR della rete virtuale. Se si considera uno scenario di recupero da errori irreversibili con più distribuzioni Exadata (zona di disponibilità incrociata o tra più aree), è necessario fornire il blocco CIDR della subnet di backup e non deve sovrapporsi ad altri blocchi CIDR utilizzati.

   Dopo aver creato il cluster VM, impostare il database utilizzando la documentazione di prodotto standard. Scopri di più.

3. Comprendi il DNS.

   Durante il provisioning di Oracle Exadata Database Service sono disponibili tre scenari possibili per la configurazione DNS:

   • Completamente gestito

     Questa è l'opzione predefinita in cui Oracle gestisce la configurazione DNS durante il processo di provisioning. Oracle crea un record A per il cluster VM e l'SCAN utilizzerà il nome dominio completo *.oraclevcn.com (FQDN). Questa integrazione è essenziale perché il piano di controllo Exadata opera su OCI, che utilizza il servizio DNS privato di OCI per il provisioning. Inoltre, il processo di provisioning sincronizza automaticamente questi record A con il DNS privato di Azure. Di conseguenza, se si utilizza il DNS privato di Azure, la configurazione DNS è completamente automatizzata e senza interruzioni.

     Dopo il provisioning delle voci DNS nel DNS privato OCI e in Azure sarà disponibile il nome FQDN *.oraclevcn.com

   • FQDN personalizzato

     Con il DNS gestito, il nome FQDN generato segue il formato *.oraclevcn.com, che potrebbe non essere l'ideale per alcuni clienti, in particolare per quelli che lo utilizzano già in OCI e non sono in grado di implementarlo in Azure. In alternativa, Oracle consente ai clienti di specificare un nome FQDN personalizzato durante il processo di provisioning. Tuttavia, questo approccio non prevede la sincronizzazione unidirezionale tra OCI e Azure che il DNS gestito fornisce. Di conseguenza, i clienti devono replicare manualmente i record A dalla propria zona personalizzata nel DNS privato OCI al DNS privato di Azure.

     Poiché i cluster VM utilizzano il DNS privato OCI per la risoluzione, gli utenti devono creare un FQDN personalizzato prima di eseguire il provisioning del cluster VM. A tale scopo, passare al resolver DNS collegato alla VCN e creare una nuova zona privata insieme a una vista privata e collegare la nuova zona privata al resolver DNS.

     Dopo aver completato questo passo, l'interfaccia utente di Azure visualizza automaticamente la zona personalizzata appena creata quando viene selezionata l'opzione FQDN personalizzata durante il processo di creazione del cluster VM.

     Dopo il provisioning, le risorse di Azure possono accedere alle voci DNS in diversi modi. Il metodo più semplice è quello di replicare le voci della zona privata OCI in DNS privato di Azure. In alternativa, puoi creare un endpoint di ascolto DNS OCI per inoltrare le richieste al DNS privato OCI.

   • DNS personalizzato

     Puoi anche configurare un DNS personalizzato. Ad esempio, se desideri utilizzare un DNS di terze parti, come Infoblox, con Oracle Exadata Database Service, possono seguire lo stesso processo di un FQDN personalizzato. Successivamente, è necessario duplicare i record DNS pertinenti nel DNS personalizzato. Ciò garantisce che le applicazioni e gli utenti possano risolvere l'URL SCAN utilizzando il DNS personalizzato.