Interconnect für Azure
Mit Oracle Interconnect for Azure können Sie in bestimmten Regionen eine cloudübergreifende Verbindung zwischen Oracle Cloud Infrastructure und Microsoft Azure erstellen. Mit dieser Verbindung können Sie cloud-übergreifende Workloads einrichten, ohne dass der Traffic zwischen den Clouds über das Internet geleitet wird. In diesem Thema wird beschrieben, wie virtuelle Netzwerkinfrastrukturressourcen eingerichtet werden, um diese Art von cloud-übergreifendem Deployment zu ermöglichen.
Informationen zu Multicloud-Oracle Database-Deployments, die Oracle Cloud Infrastructure und Microsoft Azure verwenden, finden Sie unter Oracle Database@Azure. Dieser Service hostet Oracle Exadata-Datenbanken in Azure-Data Centern für eine möglichst geringe Latenz.
Highlights
- Sie können ein Oracle Cloud Infrastructure (OCI) Virtual Cloud Network (VCN) mit einem virtuellen Microsoft Azure-Netzwerk (VNet) verbinden und eine cloudübergreifende Workload ausführen. Im typischen Anwendungsfall stellen Sie eine Oracle Database auf OCI bereit und stellen eine Oracle-, .NET- oder benutzerdefinierte Anwendung in Microsoft Azure bereit.
- Die beiden virtuellen Netzwerke müssen zu demselben Unternehmen gehören und dürfen keine sich überschneidenden CIDRs aufweisen. Für Oracle Interconnect for Azure müssen Sie einen Azure ExpressRoute-Chip und einen OCI FastConnect-Virtual Circuit erstellen.
Verfügbarkeit
Oracle Interconnect for Azure ist nur in den angezeigten OCI-Regionen und ExpressRoute-Speicherorten verfügbar. Weitere Informationen zu Azure-Regionsstandorten und Azure ExpressRoute finden Sie unter ExpressRoute peering locations and connection partners in der Azure-Dokumentation.
Die folgende Abbildung zeigt Regionen mit Oracle Interconnect for Azure, in denen alle OCI-Regionen und Notierungsregionen mit Interconnect zu Azure und GCP angezeigt werden. Die teilnehmenden Azure-Regionen sind ebenfalls in den folgenden Tabellen aufgeführt.
Asien-Pazifik (APAC)
| OCI-Standort - Schlüssel | Azure ExpressRoute-Standort  |
|---|---|
| Japan East (Tokyo) NRT | Tokyo |
| Singapore (Singapore) - SIN | Singapur |
| South Korea Central (Seoul) - ICN | Seoul |
Europa, Naher Osten und Afrika (EMEA)
| OCI-Standort | Azure ExpressRoute-Standort |
|---|---|
| Germany Central (Frankfurt) - FRA | Frankfurt und Frankfurt2 |
| Netherlands Northwest (Amsterdam) - AMS | Amsterdam2 |
| UK South (London) - LHR | London |
| South Africa Central (Johannesburg) - JNB | Johannesburg |
Lateinamerika (LATAM)
| OCI-Standort | Azure ExpressRoute-Standort |
|---|---|
| Brazil Southeast (Vinhedo) - VCP | Campinas |
Nordamerika (NA)
| OCI-Standort | Azure ExpressRoute-Standort |
|---|---|
| Kanada Südosten (Toronto) - YYZ | Toronto und Toronto2 |
| US East (Ashburn) - IAD | Washington DC und Washington DC2 |
| US West (Phoenix) - PHX | Phoenix |
| US West (San Jose) - SJC | Silicon Valley |
Überblick über unterstützten Traffic
Hier finden Sie weitere Einzelheiten zu den unterstützten Traffictypen.
VCN-to-VNet-Verbindung: Erweiterung von einer Cloud zu einer anderen
Sie können ein VCN und VNet verbinden, damit Traffic mit privaten IP-Adressen über die cloud-übergreifende Verbindung geführt wird.
Beispiel: Das folgende Diagramm zeigt ein VCN, das mit einer VNet verbunden ist. Ressourcen in der VNet führen eine .NET-Anwendung aus, die auf eine Oracle-Datenbank zugreifen, die auf Datenbankserviceressourcen im VCN ausgeführt wird. Der Traffic zwischen der Anwendung und der Datenbank verwendet einen logischen Circuit, der auf der cloud-übergreifenden Verbindung zwischen Azure und Oracle Cloud Infrastructure ausgeführt wird.
Um die Verbindung zwischen dem VCN und VNet zu aktivieren, richten Sie sowohl einen Oracle Cloud Infrastructure FastConnect-Virtual Circuit als auch einen Azure ExpressRoute- Circuit ein. Die Verbindung hat eine integrierte Redundanz, sodass Sie nur einen einzelnen FastConnect-Virtual Circuit und einen einzelnen ExpressRoute- Circuit einrichten müssen. Die Bandbreite für die Verbindung ist der Bandbreite-Wert, den Sie für den Circuit ExpressRoute auswählen.
Weitere Anweisungen finden Sie unter Verbindung einrichten.
Peer-VCNs
Mit dieser Verbindung kann der Traffic von der VNet über das verbundene VCN in ein gleichgestelltes VCN in derselben Oracle Cloud Infrastructure-Region oder einer anderen Region fließen.
Traffictypen, die nicht von der Verbindung unterstützt werden
Diese cloud-übergreifende Verbindung ermöglicht keinen Traffic zwischen dem On-Premise-Netzwerk über das VCN zum VNet oder vom On-Premise-Netzwerk über das VNet zum VCN.
Wichtige Auswirkungen von Cloud-Verbindungen
In diesem Abschnitt werden einige Auswirkungen von Oracle Interconnect for Azure auf die Zugriffskontrolle, Sicherheit und Performance zusammengefasst. Im Allgemeinen können Sie den Zugriff und Traffic mit IAM-Policys, Routentabellen im VCN und mit Sicherheitsregeln im VCN steuern.
In den folgenden Abschnitten werden die Auswirkungen aus Sicht des VCN beschrieben. Ähnliche Auswirkungen wirken sich auf VNet aus. Wie beim VCN können Sie Azure-Ressourcen verwenden, wie Routentabellen und Netzwerksicherheitsgruppen, um VNet zu sichern.
Aufbau einer Verbindung steuern
Mit den IAM-Policys von Oracle Cloud Infrastructure können Sie:
- Wer in der Organisation die Berechtigung hat, einen FastConnect-Virtual Circuit zu erstellen (siehe Verbindung einrichten). Das Löschen der relevanten IAM-Policy hat keine Auswirkungen auf vorhandene Verbindungen zu einer VNet, sondern nur auf die Möglichkeit, eine zukünftige Verbindung zu erstellen.
- Wer Routentabellen, Netzwerksicherheitsgruppen und Sicherheitslisten verwalten kann.
Trafficfluss über die Verbindung steuern
Selbst wenn eine Verbindung zwischen dem VCN und VNet hergestellt wurde, können Sie den Paketfluss über die Verbindung mit den Routentabellen im VCN steuern. Beispiel: Sie können den Traffic nur auf bestimmte Subnetze im VNet beschränken.
Sie können den Trafficfluss zur VNet ohne zu löschen, indem Sie Routingregeln entfernen, die den Traffic vom VCN zur VNet leiten. Sie können den Traffic auch wirksam stoppen, indem Sie alle Sicherheitsregeln entfernen, die den Ingress- oder Egress-Traffic mit dem VNet ermöglichen. Dadurch wird nicht der Trafficfluss über die Verbindung, aber auf VNIC-Ebene gestoppt.
Bestimmte zulässige Traffictypen steuern
Stellen Sie sicher, dass der gesamte ausgehende und eingehende Traffic mit VNet beabsichtigt oder erwartet und wie definiert ist. Implementieren Sie Azure-Netzwerksicherheitsgruppenregeln und Oracle-Sicherheitsregeln, die explizit angeben, welche Traffictypen die Clouds untereinander versenden und akzeptieren können.
Oracle Cloud Infrastructure-Instanzen mit Linux- oder Windows-Plattformimages verfügen auch über Firewallregeln, die den Zugriff auf die Instanz steuern. Stellen Sie bei der Behebung von Fehlern beim Zugriff auf eine Instanz sicher, dass die folgenden Elemente korrekt festgelegt sind: die Netzwerksicherheitsgruppen, in denen sich die Instanz befindet, die mit dem Subnetz der Instanz verknüpften Sicherheitslisten und die Firewallregeln der Instanz.
Wenn auf einer Instanz Oracle Autonomous Linux 8.x, Oracle Autonomous Linux 7, Oracle Linux 8, Oracle Linux 7 oder Oracle Linux Cloud Developer 8 ausgeführt wird, müssen Sie firewalld für die Interaktion mit den iptables-Regeln verwenden. Zu Referenzzwecken sind hier Befehle zum Öffnen eines Ports (in diesem Beispiel 1521) aufgeführt:
sudo firewall-cmd --zone=public --permanent --add-port=1521/tcp
sudo firewall-cmd --reloadBei Instanzen mit einem iSCSI-Boot-Volume kann der vorherige --reload-Befehl Probleme verursachen. Weitere Einzelheiten und einen Workaround finden Sie unter Bei den Instanzen hängt das System, nachdem "firewall-cmd --reload" ausgeführt wurde.
Bewerten Sie neben Sicherheitsregeln und Firewalls andere BS-basierte Konfigurationen für die Instanzen im VCN. Es können Standardkonfigurationen vorhanden sein, die nicht für das CIDR des VCN gelten, sondern versehentlich für das VNet-CIDR.
Standardsicherheitslistenregeln mit VCN verwenden
Wenn die Subnetze des VCN die Standardsicherheitsliste mit den Standardregeln verwenden, erlauben zwei Regeln in dieser Liste Ingress-Traffic von überall (0.0.0.0/0 und somit VNet):
- Regel für zustandsbehafteten Ingress, die (SSH-)Traffic über den TCP-Port 22 von 0.0.0.0/0 und allen Quellports zulässt
- Regel für zustandsbehafteten Ingress, die ICMP-Typ-3-Code-4-Traffic von 0.0.0.0/0 und allen Quellports zulässt
Prüfen Sie diese Regeln, und entscheiden Sie, ob Sie sie beibehalten oder aktualisieren möchten. Wie bereits erwähnt, stellen Sie sicher, dass der gesamte zulässige eingehende oder ausgehende Traffic beabsichtigt oder erwartet und wie definiert ist.
Performanceauswirkungen und Sicherheitsrisiken antizipieren
Richten Sie das VCN generell so ein, wie es von der VNet betroffen sein könnte. Beispiel: Die Auslastung des VCN oder seiner Instanzen könnte sich erhöhen. Oder das VCN könnte direkt von oder über die VNet schädlich angegriffen werden.
Zur Performance: Wenn das VCN einen Service für die VNet bereitstellt, müssen Sie den Service entsprechend den Anforderungen der VNet vertikal skalieren. Dies kann bedeuten, dass gegebenenfalls weitere Instanzen erstellt werden müssen. Wenn Sie über hohen Traffic im VCN besorgt sind, sollten Sie die Verwendung von zustandslosen Sicherheitsregeln in Betracht ziehen, um das Ausmaß des Verbindungstrackings zu begrenzen, das das VCN ausführen muss. Außerdem können Sicherheitsregeln für zustandslosen Traffic die Auswirkungen eines Denial-of-Service-(DoS-)Angriffs eindämmen.
Zu Sicherheitsrisiken: Wenn die VNet mit dem Internet verbunden ist, kann das VCN Bounce-Angriffen ausgesetzt sein. Bei einem Bounce-Angriff sendet ein böswilliger Host im Internet Traffic an das VCN, der von VNet zu kommen scheint. Um dies zu vermeiden, verwenden Sie Sicherheitsregeln, um den eingehenden Traffic von VNet sorgfältig auf erwarteten und wie definierten Traffic zu begrenzen.
Verbindungen einrichten
In diesem Abschnitt wird beschrieben, wie die logische Verbindung zwischen einem VCN und VNet eingerichtet wird (Hintergrundinformationen finden Sie unter Überblick über unterstützten Traffic).
Voraussetzungen: Erforderliche Ressourcen
Folgendes muss bereits vorhanden sein:
- Azure-VNet mit Subnetzen und virtuellem Netzwerkgateway
- Ein Oracle Cloud Infrastructure-VCN mit Subnetzen und einem angehängten dynamischen Routinggateway (DRG). Denken Sie daran, das DRG an das VCN anzuhängen, nachdem Sie es erstellt haben. Wenn Sie bereits ein Site-to-Site-VPN oder FastConnect zwischen dem On-Premise-Netzwerk und dem VCN verwenden, verfügt das VCN bereits über ein angehängtes DRG. Verwenden Sie dasselbe DRG beim Einrichten der Verbindung zu Azure.
In der folgenden Tabelle werden die vergleichbaren Netzwerkkomponenten auf beiden Seiten der Verbindung aufgeführt.
| Komponente | Azure | Oracle Cloud Infrastructure |
|---|---|---|
| Virtuelles Netzwerk | VNet | VCN |
| Virtual Circuit | ExpressRoute-Circuit | FastConnect privater Virtual Circuit |
| Gateway | Virtuelles Netzwerkgateway | Dynamisches Routinggateway (DRG) |
| Routing | Routentabellen | Routentabellen |
| Sicherheitsregeln | Netzwerksicherheitsgruppen (NSGs) | Netzwerksicherheitsgruppen (NSGs), Sicherheitslisten |
Voraussetzungen: Erforderliche BGP-Informationen
Für die Verbindung zwischen VCN und VNet wird dynamisches BGP-Routing verwendet. Wenn Sie den Virtual Circuit von Oracle einrichten, geben Sie die BGP-IP-Adressen an, die für die beiden redundanten BGP-Sessions zwischen Oracle und Azure verwendet werden:
- Ein primäres Paar von BGP-Adressen (eine IP-Adresse für die Oracle-Seite, eine IP-Adresse für die Azure-Seite)
- Ein separates, sekundäres Paar von BGP-Adressen (eine IP-Adresse für die Oracle-Seite, eine IP-Adresse für die Azure-Seite)
Für jedes Paar müssen Sie einen separaten Adressblock mit einer Subnetzmaske von /28 bis /31 angeben.
Die zweite und dritte Adresse in jedem Adressblock werden für das BGP-IP-Adresspaar verwendet:
- Die zweite Adresse im Block bezieht sich auf die Oracle-Seite der BGP-Session.
- Die dritte Adresse im Block bezieht sich auf die Azure-Seite der BGP-Session.
Die erste und letzte Adresse im Block werden für andere interne Zwecke verwendet.
Beispiel: Wenn der CIDR-Block 10.0.0.20/30 ist, lauten die Adressen im Block:
- 10.0.0.20
- 10.0.0.21: Verwenden Sie diese für die Oracle-Seite (geben Sie in der Oracle-Konsole die Adresse als 10.0.0.21/30 ein)
- 10.0.0.22: Verwenden Sie diese für die Azure-Seite (geben Sie in der Oracle-Konsole die Adresse als 10.0.0.22/30 ein, und beachten Sie, dass diese Adresse in der Konsole als "Kunden"-Seite bezeichnet wird)
- 10.0.0.23
Beachten Sie, dass Sie auch einen zweiten Block derselben Größe für die sekundären BGP-Adressen angeben müssen. Beispiel: 10.0.0.24/30. In diesem Fall ist 10.0.0.25 für die Oracle-Seite und 10.0.0.26 für die Azure-Seite vorgesehen. In der Oracle-Konsole müssen Sie diese als 10.0.0.25/30 und 10.0.0.26/30 eingeben.
Voraussetzungen: Erforderliche IAM-Policy
Sie haben wahrscheinlich den erforderlichen Azure Active Directory-Zugriff und den IAM-Zugriff in Oracle Cloud Infrastructure, um die relevanten Azure- und Oracle-Netzwerkressourcen zu erstellen und mit diesen zu arbeiten. Für IAM: Wenn Ihr Benutzeraccount Mitglied der Administratorgruppe ist, haben Sie die erforderliche Berechtigung. Andernfalls deckt diese Policy alle Netzwerkressourcen ab:
Allow group NetworkAdmins to manage virtual-network-family in tenancyUm einen Virtual Circuit nur zu erstellen und zu verwalten, benötigen Sie eine Policy wie die Folgende:
Allow group VirtualCircuitAdmins to manage drgs in tenancy
Allow group VirtualCircuitAdmins to manage virtual-circuits in tenancyWeitere Informationen finden Sie unter IAM-Policys für Networking.
Gesamtprozess
Das folgende Diagramm zeigt den allgemeinen Prozess für die Verbindung des VCN und VNet.
In der ersten Aufgabe wird bestimmt, welcher Traffic zwischen den relevanten Subnetzen im VCN und VNet fließen muss. Konfigurieren Sie dann die Sicherheitsregeln für den Abgleich. Im Folgenden werden die allgemeinen Regeltypen aufgeführt, die hinzugefügt werden sollen:
- Ingress-Regeln für die Traffictypen, die Sie aus den relevanten Subnetzen der anderen Cloud zulassen möchten.
- Egress-Regel, mit der ausgehender Traffic von einer Cloud in die andere übertragen werden kann. Wenn das VCN-Subnetz bereits eine umfassende Egress-Regel für alle Protokolltypen an alle Ziele (0.0.0.0/0) hat, müssen Sie für den Traffic zum VNet keine spezielle Regel hinzufügen. Die Standardsicherheitsliste des VCN enthält eine umfassende Standardausgaberegel.
Im Folgenden sind die empfohlenen Traffictypen aufgeführt, die zwischen VNet und VCN zulässig sind:
- Ping-Traffic in beiden Richtungen zum Testen der Verbindung von jeder Seite
- SSH (TCP-Port 22)
- Clientverbindungen zu einer Oracle-Datenbank (SQL*NET auf TCP-Port 1521)
Lassen Sie nur Traffic zwischen bestimmten relevanten Adressbereichen zu (z.B. von und an relevante Subnetze der anderen Cloud).
Für das VCN:
Im Folgenden werden Sicherheitslisten verwendet. Sie könnten jedoch stattdessen die Sicherheitsregeln in mindestens einer Netzwerksicherheitsgruppe implementieren und die relevanten Ressourcen des VCN in NSGs platzieren.
Für VNet: Wählen Sie aus, welche Subnetze in der VNet mit dem VCN kommunizieren müssen. Danach konfigurieren Sie die Netzwerksicherheitsgruppen für diese Subnetze für Traffic.
- Entscheiden Sie, welche Subnetze im VCN mit der VNet kommunizieren müssen.
-
Aktualisieren Sie die Sicherheitsliste für jedes dieser Subnetze mit Regeln, die Egress- oder Ingress-Traffic mit dem CIDR-Block des VNets oder einem Subnetz der VNet zulassen:
- Wählen Sie in der Konsole Sicherheitslisten aus, während Sie das gewünschte VCN anzeigen.
- Wählen Sie die gewünschte Sicherheitsliste aus.
-
Wählen Sie Alle Regeln bearbeiten aus, und erstellen Sie mindestens eine Regel für jeden zulässigen Traffictyp. Sehen Sie sich die folgenden Beispielregeln an.
-
Wählen Sie Sicherheitslistenregeln speichern unten im Dialogfeld.
Weitere Informationen zum Einrichten von Sicherheitsregeln finden Sie unter Sicherheitsregeln.
Mit der folgenden Egress-Sicherheitsregel kann eine Instanz eine Ping-Anforderung an einen Host außerhalb des VCN erstellen (Echoanforderung ICMP-Typ 8). Dies ist eine Regel für zustandsbehafteten Egress, die die Antwort automatisch zulässt. Eine separate Ingress-Regel für Echoantwort ICMP-Typ 0 ist nicht erforderlich.
- Wählen Sie im Abschnitt Regeln für Egress zulassen die Option +Add-Regel aus.
- Lassen Sie das Kontrollkästchen zustandslos deaktiviert.
- Ziel-CIDR: Das relevante Subnetz im VNet (10.0.0.0/16 im vorherigen Diagramm)
- IP-Protokoll: ICMP
- Typ und Code: 8
- Beschreibung: Eine optionale Beschreibung der Regel.
Mit der folgenden Ingress-Sicherheitsregel kann eine Instanz eine Ping-Anforderung von einem Host im VNet empfangen (Echoanforderung ICMP-Typ 8). Dies ist eine Regel für zustandsbehafteten Egress, die die Antwort automatisch zulässt. Eine separate Egress-Regel für Echoantwort ICMP-Typ 0 ist nicht erforderlich.
- Wählen Sie im Abschnitt Regeln für Ingress zulassen die Option +Add-Regel aus.
- Lassen Sie das Kontrollkästchen zustandslos deaktiviert.
- Quell-CIDR: Das relevante Subnetz im VNet (10.0.0.0/16 im vorherigen Diagramm)
- IP-Protokoll: ICMP
- Typ und Code: 8
- Beschreibung: Eine optionale Beschreibung der Regel.
Mit der folgenden Ingress-Sicherheitsregel kann eine Instanz eine SSH-Verbindung (TCP-Port 22) von einem Host im VNet empfangen.
- Wählen Sie im Abschnitt Regeln für Ingress zulassen die Option +Add-Regel aus.
- Lassen Sie das Kontrollkästchen zustandslos deaktiviert.
- Quell-CIDR: Das relevante Subnetz im VNet (10.0.0.0/16 im vorherigen Diagramm)
- IP-Protokoll: TCP
- Quellportbereich: Alle
- Zielportbereich: 22
- Beschreibung: Eine optionale Beschreibung der Regel.
Die folgende Ingress-Sicherheitsregel lässt SQL*Net-Verbindungen (TCP-Port 1521) von Hosts im VNet zu.
- Wählen Sie im Abschnitt Regeln für Ingress zulassen die Option +Add-Regel aus.
- Lassen Sie das Kontrollkästchen zustandslos deaktiviert.
- Quell-CIDR: Das relevante Subnetz im VNet (10.0.0.0/16 im vorherigen Diagramm)
- IP-Protokoll: TCP
- Quellportbereich: Alle
- Zielportbereich: 1521
- Beschreibung: Eine optionale Beschreibung der Regel.
Richten Sie einen ExpressRoute-Chip zu Oracle Cloud Infrastructure FastConnect ein. Während der Einrichtung des Circuits erhalten Sie einen Serviceschlüssel von Microsoft. Notieren Sie diesen Serviceschlüssel, denn Sie müssen ihn in der nächsten Aufgabe bei Oracle angeben.
In der nächsten Aufgabe richten Sie einen FastConnect-Private Virtual Circuit zu Microsoft Azure: ExpressRoute ein. Wenn das Provisioning dieses Virtual Circuits beendet ist, wird der ExpressRoute- Circuit aktualisiert, um anzuzeigen, dass Private Peering aktiviert ist.
- Bestätigen Sie in der Konsole, dass Sie das Compartment anzeigen, in dem Sie arbeiten möchten. Wenn Sie nicht sicher sind, welches Compartment das DRG enthält, verwenden Sie es. Diese Compartment-Auswahl bestimmt zusammen mit einer entsprechenden IAM-Policy, wer Zugriff auf den Virtual Circuit hat, den Sie gerade erstellen.
- Öffnen Sie das Navigationsmenü , und wählen Sie Networking aus. Wählen Sie unter Kundenkonnektivität die Option FastConnect aus.
Auf der daraufhin angezeigten FastConnect-Seite erstellen Sie einen neuen Virtual Circuit und kehren später dorthin zurück, wenn Sie den Virtual Circuit verwalten müssen.
- Wählen Sie Verbindung erstellen aus.
- Wählen Sie den FastConnect-Partner aus, und wählen Sie in der Liste Microsoft Azure: ExpressRoute aus.
-
Gehen Sie wie folgt vor:
- Name: Ein freundlicher Name. Der Wert muss nicht in allen Virtual Circuits eindeutig sein, und Sie können ihn später ändern. Geben Sie keine vertraulichen Informationen ein.
- Erstellen in Compartment: Übernehmen Sie die Vorgabe (das Compartment, in dem Sie arbeiten).
- Virtual Circuit-Typ: Wählen Sie Privater Virtual Circuit.
- Compartment dynamisches Routinggateway: Wählen Sie das Compartment aus, in dem sich das DRG befindet (bereits ausgewählt).
- Dynamisches Routinggateway: Wählen Sie das DRG.
- Bereitgestellte Bandbreite: Wählen Sie dieselbe Bandbreite, die Sie für den Circuit ExpressRoute gewählt haben (oder den nächsten verfügbaren Wert).
- Partner Service-Schlüssel: Geben Sie den Serviceschlüssel ein, den Sie bei der Einrichtung des ExpressRoute-Circuit von Microsoft erhalten haben.
- Primäre BGP-IP-Adresse des Kunden: Dies ist die primäre BGP-IP-Adresse von Azure. Geben Sie die dritte Adresse im von Ihnen angegebenen primären CIDR-Block (mit einer Subnetzmaske von /28 bis /31) ein, und schließen Sie die Subnetzmaske am Ende ein. Beispiel: 10.0.0.22/30. Weitere Informationen zu diesem und den nächsten Feldern finden Sie unter Verbindungen einrichten.
- Primäre BGP-IP-Adresse von Oracle (optional): Sie können dieses Feld leer lassen, und Oracle ruft die Adresse basierend auf dem CIDR-Block ab, den Sie für die BGP-IP-Adresse von Azure angegeben haben. In diesem Beispiel wäre der korrekte Wert 10.0.0.21/30.
- Zweite BGP-IP-Adresse des Kunden: Dieses Feld enthält die sekundäre BGP-IP-Adresse von Azure. Geben Sie die dritte Adresse im von Ihnen angegebenen sekundären CIDR-Block (mit einer Subnetzmaske von /28 bis /31) ein, und schließen Sie die Subnetzmaske am Ende ein. Beispiel: 10.0.0.26/30.
- Primäre BGP-IP-Adresse von Oracle (optional): Sie können dieses Feld leer lassen, und Oracle ruft die Adresse basierend auf dem CIDR-Block ab, den Sie für die BGP-IP-Adresse von Azure angegeben haben. In diesem Beispiel wäre der korrekte Wert 10.0.0.25/30.
-
Wählen Sie Fortfahren.
Der Virtual Circuit wird erstellt.
- Wählen Sie Schließen.
Nachdem Sie den Virtual Circuit von Oracle erstellt haben, müssen Sie sich nicht an Azure wenden, um das Provisioning des Circuits zu anfordern. Es erfolgt automatisch.
Beide Schaltungen werden innerhalb weniger Minuten bereitgestellt. Überprüfen Sie:
- Bestätigen Sie für den ExpressRoute-Circuit, dass Private Peering bereitgestellt ist.
- Bestätigen Sie für den FastConnect-VMC, dass der Status hochgefahren ist. Siehe So rufen Sie den Status des FastConnect-VMCs ab.
Für das VCN:
- Entscheiden Sie, welche Subnetze im VCN mit der VNet kommunizieren müssen.
-
Aktualisieren Sie die Routentabelle für jedes dieser Subnetze, um eine neue Regel aufzunehmen, die den Traffic, der für das CIDR des Netzes bestimmt ist, an das DRG weiterleitet:
- Wenn Sie das gewünschte VCN anzeigen, wählen Sie in der Konsole die Option Tabellen weiterleiten aus.
- Wählen Sie die gewünschte Routentabelle aus.
- Wählen Sie Routingregeln bearbeiten aus.
-
Wählen Sie + Weitere Routingregel aus, und geben Sie Folgendes ein:
- Zieltyp: Dynamisches Routinggateway. Das angehängte DRG des VCN wird automatisch als Ziel ausgewählt, sodass Sie es nicht selbst angeben müssen.
- Ziel-CIDR-Block: Das relevante Subnetz im VNet (10.0.0.0/16 im vorherigen Diagramm).
- Beschreibung: Eine optionale Beschreibung der Regel.
- Klicken Sie auf Speichern.
Für VNet: Wählen Sie aus, welche Subnetze in der VNet mit dem VCN kommunizieren müssen. Danach konfigurieren Sie die Routentabellen für diese Subnetze so, dass der Traffic zum VNet-Gateway weitergeleitet wird.
Jeder Subnetztraffic mit einem Ziel, das der Regel entspricht, wird an das DRG weitergeleitet. Das DRG weiß dann, dass der Traffic basierend auf den BGP-Sessioninformationen des Virtual Circuits an das VNet weiterzuleiten ist.
Wenn Sie später keine Verbindung mehr benötigen und das DRG löschen möchten, müssen Sie zuerst alle Routingregeln im VCN löschen, die das DRG als Ziel angeben.
Weitere Informationen zum Einrichten von Routingregeln finden Sie unter VCN-Routentabellen.
Wenn die VNet-Sicherheitsgruppen und VCN-Sicherheitsregeln korrekt eingerichtet sind, können Sie eine Instanz im VCN erstellen und von einem Host in der VNet darauf zugreifen oder eine Verbindung von der Instanz zu einem Host in der VNet herstellen. Wenn Sie können, ist die Verbindung betriebsbereit.
Wenn Sie sich entscheiden, die Verbindung zu beenden, müssen Sie einem bestimmten Prozess folgen. Siehe So beenden Sie die Verbindung mit Azure.
Verwalten von Oracle Interconnect for Azure
- Öffnen Sie das Navigationsmenü , und wählen Sie Networking aus. Wählen Sie unter Kundenkonnektivität die Option FastConnect aus.
- Wählen Sie das Compartment aus, in dem sich die Verbindung befindet, und wählen Sie die gewünschte Verbindung aus. Wenn das Symbol für den Virtual Circuit grün ist und "UP" angibt, wird der Virtual Circuit bereitgestellt und das BGP wurde ordnungsgemäß konfiguriert. Der Virtual Circuit ist einsatzbereit.
Sie können die folgenden Elemente für den Virtual Circuit ändern:
- Den Namen
- Welches DRG verwendet wird
Wenn der Virtual Circuit den Status PROVISIONED aufweist, wird bei Änderung des verwendeten DRG der Status in PROVISIONING geändert. Dies kann möglicherweise dazu führen, dass die Verbindung heruntergefahren wird. Sobald Oracle den Virtual Circuit erneut durch Provisioning bereitstellt, wird der Status wieder auf PROVISIONED gesetzt. Vergewissern Sie sich, dass die Verbindung wieder hergestellt ist und ordnungsgemäß funktioniert.
- Öffnen Sie das Navigationsmenü , und wählen Sie Networking aus. Wählen Sie unter Kundenkonnektivität die Option FastConnect aus.
- Wählen Sie das Compartment aus, in dem sich die Verbindung befindet, und wählen Sie die Verbindung aus.
- Wählen Sie den Virtual Circuit aus.
- Wählen Sie Bearbeiten, und nehmen Sie Änderungen vor. Geben Sie keine vertraulichen Informationen ein.
- Klicken Sie auf Speichern.
Das folgende Diagramm zeigt den allgemeinen Prozess zum Beenden einer VCN-zu-VNet-Verbindung.
- Zeigen Sie im Azure-Portal den ExpressRoute-Circuit und dann seine Verbindungen an. Stellen Sie sicher, dass noch keine Verbindungen für den Circuit ExpressRoute vorhanden sind. Löschen Sie alle Verbindungen, bevor Sie fortfahren.
-
Löschen Sie im Oracle-Portal den Virtual Circuit FastConnect:
- Öffnen Sie das Navigationsmenü , und wählen Sie Networking aus. Wählen Sie unter Kundenkonnektivität die Option FastConnect aus.
- Wählen Sie das Compartment aus, in dem sich die Verbindung befindet, und wählen Sie die Verbindung aus.
- Wählen Sie den Virtual Circuit aus.
- Klicken Sie auf Löschen.
-
Bestätigen Sie den Vorgang, wenn Sie dazu aufgefordert werden.
Der Lebenszyklusstatus des Virtual Circuits ändert sich in TERMINATING.
- Bestätigen Sie im Azure-Portal, dass das Private Peering für den ExpressRoute-Circuit gelöscht wurde. Bestätigen Sie außerdem, dass der Status des ExpressRoute-Circuits in "Nicht durch Provisioning bereitgestellt" geändert wurde.
- Löschen Sie im Azure-Portal den ExpressRoute-Circuit.
Die Verbindung zwischen Azure und Oracle Cloud Infrastructure wird beendet.