Interconnessione per Azure
Oracle Interconnect for Azure consente di creare una connessione cross-cloud tra Oracle Cloud Infrastructure e Microsoft Azure in alcune aree. Questa connessione ti consente di impostare carichi di lavoro cross-cloud senza che il traffico tra i cloud passi su Internet. Questo argomento descrive come impostare le risorse dell'infrastruttura di rete virtuale per abilitare questo tipo di distribuzione cross-cloud.
Per informazioni sulle implementazioni multicloud di Oracle Database che utilizzano Oracle Cloud Infrastructure e Microsoft Azure, consulta Oracle Database@Azure. Questo servizio ospita i database Oracle Exadata nei data center di Azure per la latenza più bassa possibile.
Evidenziazioni
- Puoi connettere una rete cloud virtuale (VCN) Oracle Cloud Infrastructure (OCI) con una rete virtuale Microsoft Azure (VNet) ed eseguire un carico di lavoro cross-cloud. Nel caso d'uso tipico, distribuisci un Oracle Database su OCI e distribuisci un'applicazione Oracle, .NET o personalizzata in Microsoft Azure.
- Le due reti virtuali devono appartenere alla stessa azienda e non avere CIDR sovrapposti. Oracle Interconnect for Azure richiede di creare un circuito ExpressRoute di Azure e un circuito virtuale FastConnect OCI.
disponibilità
Oracle Interconnect for Azure è disponibile solo nelle aree OCI e nelle posizioni ExpressRoute visualizzate. Per ulteriori informazioni sulle posizioni delle aree di Azure e Azure ExpressRoute, vedere ExpressRoute Posizioni di peering e partner di connettività nella documentazione di Azure.
L'immagine seguente mostra le aree con Oracle Interconnect for Azure, che mostrano tutte le aree OCI e annotano le aree con interconnessione sia con Azure che con GCP. Nelle tabelle seguenti sono elencate anche le aree di Azure partecipanti.
Asia Pacifico (APAC)
| Posizione OCI - Chiave | Posizione ExpressRoute di Azure  |
|---|---|
| NRT del Giappone orientale (Tokyo) | Tokyo |
| Singapore (Singapore) - SIN | Singapore |
| Corea del Sud centrale (Seul) - ICN | Seul |
Europa, Medio Oriente e Africa (EMEA)
| Posizione OCI | Posizione ExpressRoute di Azure |
|---|---|
| Germania centrale (Francoforte) - FRA | Francoforte e Frankfurt2 |
| Paesi Bassi nord-occidentali (Amsterdam) - AMS | Amersterdam2 |
| Regno Unito (Sud) - LHR | Londra |
| Sudafrica centrale - Johannesburg - JNB | Johannesburg |
America Latina (LATAM)
| Posizione OCI | Posizione ExpressRoute di Azure |
|---|---|
| Brasile sud-est (Vinhedo) - VCP | Campinas |
America settentrionale (NA)
| Posizione OCI | Posizione ExpressRoute di Azure |
|---|---|
| Canada sudorientale (Toronto) - YYZ | Toronto e Toronto2 |
| Stati Uniti orientali (Ashburn) - IAD | Washington DC e Washington DC2 |
| Stati Uniti occidentali (Phoenix) - PHX | Phoenix |
| Stati Uniti (ovest) - SJC | Silicon Valley |
Panoramica del traffico supportato
Di seguito sono riportati ulteriori dettagli sui tipi di traffico supportati.
Connessione da VCN a VNet: estensione da un cloud all'altro
Puoi connettere una VCN e VNet in modo che il traffico che utilizza gli indirizzi IP privati passi attraverso la connessione cross-cloud.
Ad esempio, il diagramma riportato di seguito mostra una VCN connessa a una VNet. Le risorse in VNet eseguono un'applicazione .NET che accede a un database Oracle eseguito sulle risorse del servizio di database nella VCN. Il traffico tra l'applicazione e il database utilizza un circuito logico eseguito sulla connessione cross-cloud tra Azure e Oracle Cloud Infrastructure.
Per abilitare la connessione tra la VCN e VNet, è necessario impostare sia un circuito virtuale Oracle Cloud Infrastructure FastConnect che un circuito ExpressRoute di Azure. La connessione dispone di ridondanza integrata, il che significa che è necessario impostare solo un singolo circuito virtuale FastConnect e un singolo circuito ExpressRoute. La larghezza di banda per la connessione è il valore della larghezza di banda selezionato per il circuito ExpressRoute.
Per istruzioni, vedere Impostazione di una connessione.
VCN in peer
La connessione consente il flusso di traffico da VNet attraverso la VCN connessa a una VCN in peer nella stessa area geografica Oracle Cloud Infrastructure o in un'area diversa.
Tipi di traffico non supportati dalla connessione
Questa connessione cross-cloud non abilita il traffico tra la rete in locale tramite la VCN e VNet o dalla rete in locale tramite VNet e la VCN.
Importanti implicazioni della connessione dei cloud
Questa sezione contiene un riepilogo di alcune implicazioni relative a controllo dell'accesso, sicurezza e prestazioni di Oracle Interconnect for Azure. In generale, puoi controllare l'accesso e il traffico utilizzando i criteri IAM, le tabelle di instradamento nella VCN e le regole di sicurezza nella VCN.
Le sezioni che seguono illustrano le implicazioni dal punto di vista della VCN. Implicazioni simili interessano il VNet. Come con la rete VCN, è possibile utilizzare le risorse Azure come le tabelle di instradamento e i gruppi di sicurezza di rete per proteggere VNet.
Controllo dell'istituzione di una connessione
Con i criteri IAM di Oracle Cloud Infrastructure, puoi controllare:
- Chi nell'organizzazione ha l'autorità di creare un circuito virtuale FastConnect (vedere Impostazione di una connessione). L'eliminazione del criterio IAM pertinente non influisce sulle connessioni esistenti a un VNet, ma solo sulla possibilità di creare una connessione futura.
- Chi può gestire tabelle di instradamento, gruppi di sicurezza di rete ed elenchi di sicurezza.
Controllo del flusso di traffico sulla connessione
Anche se è stata stabilita una connessione tra la VCN e VNet, è possibile controllare il flusso di pacchetti sulla connessione con le tabelle di instradamento nella VCN. Ad esempio, è possibile limitare il traffico solo a subnet specifiche in VNet.
Senza eliminare la connessione, è possibile arrestare il flusso di traffico verso VNet rimuovendo le regole di instradamento che indirizzano il traffico dalla VCN alla VNet. Puoi anche interrompere il traffico in modo efficace rimuovendo qualsiasi regola di sicurezza che abilita il traffico in entrata o in uscita con VNet. In questo modo il traffico non viene interrotto tramite la connessione, ma viene arrestato a livello di VNIC.
Controllo dei tipi specifici di traffico consentiti
Assicurarsi che tutto il traffico in uscita e in entrata con VNet sia previsto o previsto e come definito. Implementare il gruppo di sicurezza di rete Azure e le regole di sicurezza Oracle che specificano in modo esplicito i tipi di traffico che un cloud può inviare all'altro e accettare dall'altro.
Anche le istanze di Oracle Cloud Infrastructure che eseguono Linux o immagini della piattaforma Windows dispongono di regole firewall che controllano l'accesso all'istanza. Durante la risoluzione dei problemi di accesso a un'istanza, assicurarsi che gli elementi riportati di seguito siano impostati correttamente: i gruppi di sicurezza di rete in cui si trova l'istanza, le liste di sicurezza associate alla subnet dell'istanza e le regole firewall dell'istanza.
Se un'istanza esegue Oracle Autonomous Linux 8.x, Oracle Autonomous Linux 7, Oracle Linux 8, Oracle Linux 7 o Oracle Linux Cloud Developer 8, devi utilizzare firewalld per interagire con le regole iptables. Per riferimento, ecco i comandi per l'apertura di una porta (1521 in questo esempio):
sudo firewall-cmd --zone=public --permanent --add-port=1521/tcp
sudo firewall-cmd --reloadPer le istanze con un volume di avvio iSCSI, il comando --reload precedente può causare problemi. Per informazioni dettagliate e una soluzione alternativa, vedere Instances experience system hang after running firewall-cmd --reload.
Oltre alle regole di sicurezza e ai firewall, valuta altre configurazioni basate sul sistema operativo nelle istanze nella VCN. Potrebbero essere disponibili configurazioni predefinite che non si applicano al CIDR della VCN, ma che si applicano inavvertitamente al CIDR della VNet.
Utilizzo delle regole predefinite della lista di sicurezza con la VCN
Se le subnet della VCN utilizzano la lista di sicurezza predefinita con le regole predefinite, due regole in tale lista consentono il traffico in entrata da qualsiasi posizione (0.0.0.0/0, quindi VNet):
- Regola di entrata con conservazione dello stato che consente il traffico della porta TCP 22 (SSH) da 0.0.0.0/0 e da qualsiasi porta di origine
- Regola di entrata con conservazione dello stato che consente il traffico ICMP di tipo 3, codice 4 da 0.0.0.0/0 e da qualsiasi porta di origine
Valutare queste regole e se si desidera mantenerle o aggiornarle. Come indicato in precedenza, assicurarsi che tutto il traffico in entrata o in uscita consentito sia previsto o previsto e come definito.
Prepararsi all'impatto sulle prestazioni e ai rischi per la sicurezza
In generale, prepara la VCN per le modalità in cui potrebbe essere interessata da VNet. Ad esempio, il carico sulla VCN o sulle relative istanze potrebbe aumentare. In alternativa, la VCN potrebbe subire un attacco dannoso direttamente da o tramite VNet.
Per quanto riguarda le prestazioni: se la VCN fornisce un servizio a VNet, prepararsi a eseguire lo scale-up del servizio per soddisfare le richieste del sito VNet. Ciò potrebbe significare essere pronti a creare più istanze, se necessario. In alternativa, se sei preoccupato per gli elevati livelli di traffico di rete che arrivano alla rete VCN, prendi in considerazione l'utilizzo di regole di sicurezza senza conservazione dello stato per limitare il livello di monitoraggio della connessione che la VCN deve eseguire. Le regole di sicurezza senza conservazione dello stato possono anche contribuire a rallentare l'impatto di un attacco di tipo Denial of Service (DoS).
Per quanto riguarda i rischi per la sicurezza: se VNet è connesso a Internet, la VCN può essere esposta ad attacchi di mancato recapito. Un attacco di mancato recapito coinvolge un host dannoso su Internet che invia traffico alla VCN che sembra provenire da VNet. Per evitare questo problema, come accennato in precedenza, utilizzare le regole di sicurezza per limitare attentamente il traffico in entrata da VNet al traffico previsto e definito.
Impostazione di una connessione
In questa sezione viene descritto come impostare la connessione logica tra una VCN e VNet (per informazioni generali, vedere Panoramica sul traffico supportato).
Prerequisiti: risorse necessarie
Devi già avere:
- Un Azure VNet con subnet e gateway di rete virtuale
- Una VCN Oracle Cloud Infrastructure con subnet e un gateway di instradamento dinamico (DRG) collegato. Ricordarsi di collegare il DRG alla VCN dopo averla creata. Se si dispone già di una VPN da sito a sito o FastConnect tra la rete in locale e la VCN, la VCN dispone già di un DRG collegato. Lo stesso DRG viene utilizzato qui durante l'impostazione della connessione ad Azure.
Come promemoria, ecco una tabella che elenca i componenti di rete comparabili coinvolti in ciascun lato della connessione.
| Componente | Azure | Oracle Cloud Infrastructure |
|---|---|---|
| Rete virtuale | VNet | VCN |
| Circuito virtuale | circuito ExpressRoute | FastConnect circuito virtuale privato |
| Gateway | gateway della rete virtuale | Gateway di instradamento dinamico (DRG) |
| Instradamento | tabelle di instradamento | tabelle di instradamento |
| Regole di sicurezza | gruppi di sicurezza di rete (NSG) | gruppi di sicurezza di rete (NSG), liste di sicurezza |
Prerequisiti: Informazioni BGP necessarie
La connessione tra la VCN e VNet utilizza l'instradamento dinamico BGP. Quando imposti il circuito virtuale Oracle, fornisci gli indirizzi IP BGP utilizzati per le due sessioni BGP ridondanti tra Oracle e Azure:
- Una coppia primaria di indirizzi BGP (un indirizzo IP per il lato Oracle, un indirizzo IP per il lato Azure)
- Una coppia separata e secondaria di indirizzi BGP (un indirizzo IP per il lato Oracle, un indirizzo IP per il lato Azure)
Per ciascuna coppia, è necessario fornire un blocco separato di indirizzi con una maschera di sottorete da /28 a /31.
Il secondo e il terzo indirizzo in ogni blocco di indirizzi vengono utilizzati per la coppia di indirizzi IP BGP:
- Il secondo indirizzo nel blocco è per il lato Oracle della sessione BGP
- Il terzo indirizzo del blocco è per il lato Azure della sessione BGP
Il primo e l'ultimo indirizzo del blocco vengono utilizzati per altri scopi interni.
Ad esempio, se il CIDR è 10.0.0.20/30, gli indirizzi nel blocco sono i seguenti:
- 10.0.0.20
- 10.0.0.21: utilizzare questa opzione per il lato Oracle (nella console Oracle, immettere l'indirizzo come 10.0.0.21/30)
- 10.0.0.22: utilizzare questa opzione per il lato Azure (nella console di Oracle, immettere l'indirizzo come 10.0.0.22/30 e notare che questo indirizzo viene indicato come il lato "Cliente" nella console)
- 10.0.0.23
Ricorda che devi anche fornire un secondo blocco con le stesse dimensioni per gli indirizzi BGP secondari. Ad esempio: 10.0.0.24/30. In questo caso, 10.0.0.25 è per il lato Oracle e 10.0.0.26 è per il lato Azure. Nella console Oracle è necessario immettere i valori seguenti: 10.0.0.25/30 e 10.0.0.26/30.
Prerequisiti: criterio IAM necessario
Probabilmente hai l'accesso ad Azure Active Directory e l'accesso a Oracle Cloud Infrastructure IAM necessari per creare e lavorare con le risorse di rete di Azure e Oracle pertinenti. Per IAM: se il proprio account utente si trova nel gruppo Amministratori, si dispone dell'autorità necessaria. In caso contrario, questa politica copre tutte le risorse di rete:
Allow group NetworkAdmins to manage virtual-network-family in tenancyPer creare e gestire solo un circuito virtuale, è necessario disporre di un criterio simile al seguente:
Allow group VirtualCircuitAdmins to manage drgs in tenancy
Allow group VirtualCircuitAdmins to manage virtual-circuits in tenancyPer ulteriori informazioni vedere Criteri IAM per il networking.
Processo generale
Il diagramma riportato di seguito mostra il processo generale di connessione della VCN e di VNet.
Il primo task consiste nel decidere quale traffico deve fluire tra le subnet pertinenti all'interno della VCN e VNet, quindi configurare le regole di sicurezza in modo che corrispondano. Di seguito sono riportati i tipi generali di regole da aggiungere.
- Regole di entrata per i tipi di traffico che si desidera consentire dalle altre subnet pertinenti del cloud.
- Regola di uscita per consentire il traffico in uscita da un cloud all'altro. Se la subnet della VCN dispone già di un'ampia regola di uscita per tutti i tipi di protocolli in tutte le destinazioni (0.0.0.0/0), non è necessario aggiungerne una speciale per il traffico in VNet. La lista di sicurezza predefinita della VCN include un'ampia regola di uscita predefinita.
Di seguito sono riportati i tipi di traffico consigliati da consentire tra VNet e VCN.
- Ping del traffico in entrambe le direzioni per il test della connessione da ciascun lato
- SSH (porta TCP 22)
- Connessioni client a un database Oracle (SQL*NET sulla porta TCP 1521)
Consenti solo il traffico da e verso specifici intervalli di indirizzi di interesse (ad esempio, le altre subnet pertinenti del cloud).
Per la VCN:
La procedura riportata di seguito utilizza gli elenchi di sicurezza, ma è possibile implementare le regole di sicurezza in uno o più gruppi di sicurezza di rete, quindi inserire le risorse pertinenti della VCN nei gruppi NSG.
Per VNet: decidere quali subnet nel file VNet devono comunicare con la VCN. Quindi configurare i gruppi di sicurezza di rete per tali subnet in modo da consentire il traffico.
- Decidere quali subnet nella VCN devono comunicare con VNet.
-
Aggiornare la lista di sicurezza per ciascuna subnet in modo da includere regole per consentire il traffico in uscita o in entrata con il blocco CIDR della VNet o una subnet del file VNet:
- Nella console, durante la visualizzazione della VCN di interesse, selezionare Elenchi di sicurezza.
- Selezionare la lista di sicurezza a cui si è interessati.
-
Selezionare Modifica tutte le regole e creare una o più regole, ognuna per il tipo specifico di traffico che si desidera consentire. Vedere le regole di esempio riportate di seguito.
-
Selezionare Salva regole lista di sicurezza nella parte inferiore della finestra di dialogo.
Per ulteriori informazioni sull'impostazione delle regole di sicurezza, vedere Regole di sicurezza.
La seguente regola di sicurezza di uscita consente a un'istanza di creare una richiesta di ping a un host esterno alla VCN (richiesta ecologica ICMP di tipo 8). Questa è una regola con conservazione dello stato che consente automaticamente la risposta. Non è richiesta alcuna regola di entrata separata per la risposta all'eco ICMP di tipo 0.
- Nella sezione Consenti regole per uscita, selezionare +Add Regola.
- Lasciare deselezionata la casella di controllo senza conservazione dello stato.
- CIDR di destinazione: la subnet pertinente nel VNet (10.0.0.0/16 nel diagramma precedente)
- Protocollo IP: ICMP
- Tipo e codice: 8
- Descrizione: una descrizione facoltativa della regola.
La seguente regola di sicurezza in entrata consente a un'istanza di ricevere una richiesta di ping da un host in VNet (richiesta ecologica ICMP di tipo 8). Questa è una regola con conservazione dello stato che consente automaticamente la risposta. Non è richiesta alcuna regola di uscita separata per ICMP di risposta all'eco di tipo 0.
- Nella sezione Consenti regole per entrata, selezionare +Add Regola.
- Lasciare deselezionata la casella di controllo senza conservazione dello stato.
- CIDR di origine: la subnet rilevante nel VNet (10.0.0.0/16 nel diagramma precedente)
- Protocollo IP: ICMP
- Tipo e codice: 8
- Descrizione: una descrizione facoltativa della regola.
La regola di sicurezza in entrata riportata di seguito consente a un'istanza di ricevere una connessione SSH (porta TCP 22) da un host in VNet.
- Nella sezione Consenti regole per entrata, selezionare +Add Regola.
- Lasciare deselezionata la casella di controllo senza conservazione dello stato.
- CIDR di origine: la subnet rilevante nel VNet (10.0.0.0/16 nel diagramma precedente)
- Protocollo IP: TCP
- Intervallo porte di origine: tutte
- Intervallo di porte di destinazione: 22
- Descrizione: una descrizione facoltativa della regola.
La regola di sicurezza in entrata riportata di seguito consente le connessioni SQL*Net (porta TCP 1521) dagli host in VNet.
- Nella sezione Consenti regole per entrata, selezionare +Add Regola.
- Lasciare deselezionata la casella di controllo senza conservazione dello stato.
- CIDR di origine: la subnet rilevante nel VNet (10.0.0.0/16 nel diagramma precedente)
- Protocollo IP: TCP
- Intervallo porte di origine: tutte
- Intervallo di porte di destinazione: 1521
- Descrizione: una descrizione facoltativa della regola.
Configura un circuito ExpressRoute per Oracle Cloud Infrastructure FastConnect. Durante l'impostazione del circuito, si riceve una chiave di servizio da Microsoft. Registrare la chiave di servizio perché è necessario fornirla a Oracle nel task successivo.
Nel task successivo, è necessario impostare un circuito virtuale privato FastConnect su Microsoft Azure: ExpressRoute. Al termine del provisioning del circuito virtuale, il circuito ExpressRoute viene aggiornato per mostrare che il peering privato è abilitato.
- Nella console confermare che si sta visualizzando il compartimento in cui si desidera lavorare. Se non si è certi di quale, utilizzare il compartimento che contiene il DRG. Questa scelta di compartimento, insieme a un criterio IAM corrispondente, controlla chi può accedere al circuito virtuale che si sta per creare.
- Aprire il menu di navigazione e selezionare Networking. In Connettività cliente, selezionare FastConnect.
La pagina FastConnect risultante consente di creare un nuovo circuito virtuale e di tornare a quando è necessario gestire il circuito virtuale.
- Selezionare Crea connessione.
- Selezionare Partner FastConnect e selezionare Microsoft Azure: ExpressRoute dall'elenco.
-
Immettere quanto riportato di seguito per il circuito virtuale.
- Nome: un nome descrittivo. Il valore non deve essere univoco tra i circuiti virtuali ed è possibile modificarlo in un secondo momento. Evitare di fornire informazioni riservate.
- Crea nel compartimento: lasciare invariato (il compartimento in cui si sta lavorando).
- Tipo di circuito virtuale: selezionare Circuito virtuale privato.
- Compartimento gateway di instradamento dinamico: selezionare il compartimento in cui risiede il DRG (già selezionato).
- Gateway di instradamento dinamico: selezionare il DRG.
- Larghezza di banda con provisioning eseguito: selezionare lo stesso livello di larghezza di banda scelto per il circuito ExpressRoute o il valore più vicino disponibile.
- Chiave Partner Service: immettere la chiave di servizio ricevuta da Microsoft quando si imposta il circuito ExpressRoute.
- Indirizzo IP BGP primario del cliente: questo campo è l'indirizzo IP BGP primario di Azure. Immettere il terzo indirizzo nel blocco CIDR primario (con una subnet mask da /28 a /31) fornito e includere la subnet mask alla fine. Ad esempio: 10.0.0.22/30. Per ulteriori informazioni su questo campo e sui campi successivi, vedere Impostazione di una connessione.
- Indirizzo IP BGP primario Oracle (facoltativo): è possibile lasciare vuoto questo campo e Oracle fornisce l'indirizzo in base al blocco CIDR fornito per l'indirizzo IP BGP di Azure. In questo esempio, il valore corretto sarebbe 10.0.0.21/30.
- Indirizzo IP BGP secondario cliente: questo campo è l'indirizzo IP BGP secondario Azure. Immettere il terzo indirizzo nel blocco CIDR secondario (con una subnet mask da /28 a /31) fornito e includere la subnet mask alla fine. Ad esempio: 10.0.0.26/30.
- Indirizzo IP BGP primario Oracle (facoltativo): è possibile lasciare vuoto questo campo e Oracle fornisce l'indirizzo in base al blocco CIDR fornito per l'indirizzo IP BGP di Azure. In questo esempio, il valore corretto sarebbe 10.0.0.25/30.
-
Selezionare Continua.
Il circuito virtuale viene creato.
- Selezionare Chiudi.
Dopo aver creato il circuito virtuale Oracle, non è necessario contattare Azure per richiedere il provisioning del circuito. Succede automaticamente.
Entrambi i circuiti vengono forniti in pochi minuti. Per verificare:
- Per il circuito ExpressRoute, confermare che è stato eseguito il provisioning del peering privato.
- Per il circuito virtuale FastConnect, confermare che lo stato è UP. Vedere Per ottenere lo stato del circuito virtuale FastConnect.
Per la VCN:
- Decidere quali subnet nella VCN devono comunicare con VNet.
-
Aggiornare la tabella di instradamento per ciascuna subnet in modo da includere una nuova regola che indirizza il traffico destinato al CIDR della rete VNet al DRG:
- Nella console, durante la visualizzazione della VCN di interesse, selezionare Tabelle di instradamento.
- Selezionare la tabella di instradamento a cui si è interessati.
- Selezionare Modifica regole di instradamento.
-
Selezionare + Altra regola di instradamento e immettere quanto segue:
- Tipo di destinazione: gateway di instradamento dinamico. Il gateway DRG collegato della VCN viene selezionato automaticamente come destinazione e non è necessario specificare manualmente la destinazione.
- Blocco CIDR di destinazione: la subnet pertinente nel VNet (10.0.0.0/16 nel diagramma precedente).
- Descrizione: una descrizione facoltativa della regola.
- Selezionare Salva.
Per VNet: decidere quali subnet nel file VNet devono comunicare con la VCN. Quindi, configurare le tabelle di instradamento per tali subnet in modo da instradare il traffico al gateway VNet.
Qualsiasi traffico della subnet con una destinazione che corrisponde alla regola viene instradato al DRG. Il gateway DRG sa quindi instradare il traffico a VNet in base alle informazioni sulla sessione BGP del circuito virtuale.
In seguito, se non è più necessaria la connessione e si desidera eliminare il gateway DRG, è necessario eliminare prima tutte le regole di instradamento nella VCN che specificano il gateway DRG come destinazione.
Per ulteriori informazioni sull'impostazione delle regole di instradamento, consulta le tabelle di instradamento VCN.
Se i gruppi di sicurezza VNet e le regole di sicurezza VCN sono impostati correttamente, è possibile creare un'istanza nella VCN e accedervi da un host nella VNet oppure connettersi dall'istanza a un host nella VNet. Se possibile, la connessione è pronta per l'uso.
Se si decide di interrompere la connessione, è necessario seguire un determinato processo. Vedere Per interrompere la connessione ad Azure.
Gestione di Oracle Interconnect per Azure
- Aprire il menu di navigazione e selezionare Networking. In Connettività cliente, selezionare FastConnect.
- Selezionare il compartimento in cui risiede la connessione, quindi selezionare la connessione a cui si è interessati. Se l'icona per il circuito virtuale è verde e indica UP, il provisioning del circuito virtuale è stato eseguito e il BGP è stato configurato correttamente. Il circuito virtuale è pronto per l'uso.
È possibile modificare questi elementi per il circuito virtuale:
- Nome
- Quale DRG utilizza
Se lo stato del circuito virtuale è PROVISIONED, la modifica del DRG utilizzato cambia lo stato in PROVISIONING e potrebbe causare l'interruzione della connessione. Dopo che Oracle ha eseguito il provisioning del circuito virtuale, lo stato torna a PROVISIONED. Verificare che la connessione sia attiva e funzionante.
- Aprire il menu di navigazione e selezionare Networking. In Connettività cliente, selezionare FastConnect.
- Selezionare il compartimento in cui risiede la connessione, quindi selezionare la connessione.
- Selezionare il circuito virtuale.
- Selezionare Modifica e apportare le modifiche desiderate. Evitare di fornire informazioni riservate.
- Selezionare Salva.
Il diagramma riportato di seguito mostra il processo generale di interruzione di una connessione da VCN a VNet.
- Nel portale Azure, visualizzare il circuito ExpressRoute, quindi visualizzare le relative connessioni. Verificare che non esistano ancora connessioni per il circuito ExpressRoute. Eliminare tutte le connessioni prima di continuare.
-
Nel portale Oracle, eliminare il circuito virtuale FastConnect:
- Aprire il menu di navigazione e selezionare Networking. In Connettività cliente, selezionare FastConnect.
- Selezionare il compartimento in cui risiede la connessione, quindi selezionare la connessione.
- Selezionare il circuito virtuale.
- Selezionare Elimina.
-
Confermare quando richiesto.
Lo stato del ciclo di vita del circuito virtuale passa a TERMINATING.
- Nel portale Azure, confermare che il peering privato per il circuito ExpressRoute è stato eliminato. Confermare inoltre che lo stato del circuito ExpressRoute è stato modificato in "Non fornito".
- Nel portale di Azure, eliminare il circuito ExpressRoute.
La connessione tra Azure e Oracle Cloud Infrastructure viene interrotta.