Bereitstellung planen

Oracle Database@Azure verwendet Oracle Exadata-Clusterhardware, RDMA-Netzwerke sowie die neueste Oracle Database und Software, die alle direkt im Microsoft Azure-Data Center installiert sind.

Mit dieser Architektur können Sie denselben Oracle Database-Service verwenden, der nativ auf Oracle Cloud Infrastructure, aber auf Microsoft Azure ausgeführt wird.

In diesem Abschnitt werden die folgenden Implementierungen beschrieben:

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

Netzwerkdesign für Oracle Database@Azure Autonomous Database

Diese Architektur zeigt, wie Oracle Autonomous Database auf Microsoft Azure bereitgestellt wird.

Autonomous Database wird als virtuelle Netzwerkschnittstellenkarte (VNIC) in einem an Oracle.Database/networkAttachments delegierten Azure-Subnetz dargestellt. Beim Provisioning des Service wird ein virtuelles Cloud-Netzwerk (VCN) mit demselben CIDR-Blockbereich wie das delegierte Subnetz erstellt. Das VCN ist ein regionales Konstrukt und erstreckt sich von der untergeordneten Site zur nächsten Oracle Cloud Infrastructure-(OCI-)Region. Mit OCI Object Storage wird die Datenbank gesichert.


Beschreibung von network-adb-azure.png folgt
Beschreibung der Abbildung network-adb-azure.png

network-adb-azure-oracle.zip

Um Oracle Autonomous Database auf Microsoft Azure bereitzustellen, führen Sie die folgenden allgemeinen Schritte aus:

  1. Planen Sie den CIDR-Block (classless inter-domain routing) für das vom Client delegierte Subnetz.

    Reservieren Sie den CIDR-Block für das Subnetz, in dem Autonomous Database bereitgestellt wird. Dieser CIDR-Block darf sich nicht mit denjenigen überschneiden, die bereits On Premise oder im aktuellen Azure-Deployment verwendet werden. Außerdem:

    • 13 IP-Adressen werden für Netzwerkservices im Clientsubnetz reserviert, unabhängig davon, wie viele Autonomous Database-Instanzen im Clientsubnetz vorhanden sind. Die 13 Adressen sind die erste 4, die 9. bis 16. und die letzte IP-Adresse.
    • Die minimale CIDR-Blockgröße ist /27.
    • Die IP-Adressen 100.106.0.0/16 und 100.107.0.0/16 sind für die interne Konnektivität reserviert und können dem Clientsubnetz nicht zugewiesen werden.

    Planen Sie immer eine zukünftige Erweiterung der Umgebung, und weisen Sie einen größeren CIDR-Block zu als den erforderlichen. Nachdem der Service bereitgestellt wurde, kann die Größe des CIDR-Blocks nicht mehr geändert werden.

  2. Erstellen Sie das delegierte Subnetz.

    Erstellen Sie im virtuellen Netzwerk, das Autonomous Database hostet, ein Subnetz, und delegieren Sie es an Oracle.Database/networkAttachments. Im delegierten Subnetz sind nur Oracle Database@Azure-Workloads zulässig, und Sie können keine anderen Azure- oder Compute-Services in diesem Subnetz bereitstellen.

    Wenn Sie Oracle Database@Azure bereitstellen, müssen Sie das virtuelle Netzwerk und das delegierte Subnetz angeben.

  3. DNS (Domain Name Service) verstehen.

    Autonomous Database verfügt über einen vollqualifizierten Domainnamen (FQDN) aus der Domain oraclecloud.com. Diese Zone ist eine private DNS-Zone, die sich in OCI befindet. Die Datensätze aus dieser Zone werden in einer entsprechenden privaten DNS-Zone in Azure repliziert. Die Anwendungen von Azure, die eine Verbindung zu Autonomous Database herstellen, lösen den FQDN mit der privaten DNS-Zone von Azure auf.

    Um den FQDN zu prüfen, navigieren Sie zuerst zum OCI-Mandanten, und prüfen Sie dort die DNS-Zone, und prüfen Sie dann das DNS in der Azure-Konsole:

    1. Navigieren Sie in der Azure-Konsole zur Oracle Autonomous Database-Servicekonsole, und notieren Sie sich die unter "Netzwerk" aufgeführte private Datenbank-IP. Klicken Sie auf Gehe zu OCI.
    2. Melden Sie sich beim OCI-Mandanten an, zeigen Sie die Detailseite für Autonomous Database an, und notieren Sie sich das VCN, in dem die Datenbank bereitgestellt ist, und die Netzwerksicherheitsgruppe (NSG), die zur Genehmigung des Netzwerktraffics an Autonomous Database verwendet wird.
    3. Klicken Sie auf den Link Virtuelles Cloud-Netzwerk.
    4. Klicken Sie auf den Link DNS-Resolver.
    5. Klicken Sie auf den Link Private Standardansicht.
    6. Suchen Sie die von Autonomous Database verwendete DNS-Zone, und prüfen Sie die IP-Adresse des A-Datensatzes. Notieren Sie sich den Domainnamen.
    7. Navigieren Sie in der Azure-Konsole zum Azure-DNS-Service, suchen Sie die private DNS-Zone, die Sie in der OCI-Konsole angegeben haben, und klicken Sie auf Virtuelle Netzwerklinks. Beachten Sie, dass er mit dem Domainnamen der OCI-Konsole identisch ist
  4. Genehmigen Sie den Netzwerktraffic zu Autonomous Database.
    1. Melden Sie sich beim OCI-Mandanten an, zeigen Sie die Detailseite für Autonomous Database an, und klicken Sie auf den Link Netzwerksicherheitsgruppen.
    2. Stellen Sie sicher, dass die Anwendungen, die eine Verbindung zu Autonomous Database herstellen, über die erforderliche Genehmigung verfügen (entweder TCP 1521 oder TCP 1522).

Netzwerkdesign für Oracle Database@Azure Oracle Exadata Database Service

Diese Architektur zeigt, wie Oracle Exadata Database Service auf Microsoft Azure bereitgestellt wird.

Der Service wird als eine Reihe von virtuellen Netzwerkkarten (VNICs) in einem Azure-Subnetz dargestellt, das an Oracle.Database/networkAttachments delegiert wurde. Beim Provisioning des Service wird ein virtuelles Cloud-Netzwerk (VCN) mit demselben CIDR-Blockbereich wie das delegierte Subnetz erstellt. Das VCN ist ein regionales Konstrukt und erstreckt sich von der untergeordneten Site zur nächsten OCI-Region.

Während Oracle Autonomous Database ein regionaler Service ist und automatisch über verschiedene Zonen hinweg gestartet werden kann, verfügt Oracle Exadata Database Service über Affinität für eine bestimmte Zone.


Beschreibung von network-exadata-azure.png folgt
Beschreibung der Abbildung network-exadata-azure.png

network-exadata-azure-oracle.zip

Um Oracle Exadata Database Service auf Microsoft Azure bereitzustellen, führen Sie die folgenden allgemeinen Schritte aus:

  1. Planen Sie den CIDR-Block für das vom Client delegierte Subnetz.

    Für Oracle Exadata Database Service sind zwei CIDR-Blockbereiche erforderlich: ein CIDR-Block für das Clientsubnetz, mit dem ein delegiertes Subnetz in Azure bereitgestellt wird, und ein anderer optionaler CIDR-Block für das Backupsubnetz. Die CIDR-Blöcke dürfen sich nicht mit den bereits On Premise oder im aktuellen Azure-Deployment verwendeten Blöcken überschneiden.

    Für das Clientsubnetz gelten folgende Anforderungen:

    • Jede virtuelle Maschine (VM) benötigt 4 IP-Adressen. VM-Cluster verfügen über mindestens 2 virtuelle Maschinen. Daher benötigt ein VM-Cluster mit 2 virtuellen Maschinen 8 IP-Adressen im Clientsubnetz. Jede zusätzliche virtuelle Maschine, die einem VM-Cluster hinzugefügt wird, erhöht die Anzahl der im Clientsubnetz benötigten IP-Adressen um 4 IPs.
    • Jedes VM-Cluster erfordert 3 IP-Adressen für Single Client Access Names (SCANs), unabhängig davon, wie viele virtuelle Maschinen im VM-Cluster vorhanden sind.
    • 13 IP-Adressen werden für Netzwerkservices im Clientsubnetz reserviert, unabhängig davon, wie viele Autonomous Database-Instanzen im Clientsubnetz vorhanden sind. Die 13 Adressen sind die erste 4, die 9. bis 16. und die letzte IP-Adresse.
    • Die minimale CIDR-Blockgröße ist /27.
    • Die IP-Adressen 100.106.0.0/16 und 100.107.0.0/16 sind für die interne Konnektivität reserviert und können dem Clientsubnetz nicht zugewiesen werden.
    • Ein Clientsubnetz kann VM-Cluster aus verschiedenen Exadata-Infrastrukturen hosten, wenn sie aus derselben Verfügbarkeitszone stammen.

    Das Backupsubnetz hat die folgenden Anforderungen:

    • Für jede virtuelle Maschine (VM) sind 3 IP-Adressen erforderlich. VM-Cluster verfügen über mindestens 2 virtuelle Maschinen. Daher benötigt ein VM-Cluster mit 2 virtuellen Maschinen 6 IP-Adressen im Backupsubnetz. Jede zusätzliche virtuelle Maschine, die einem VM-Cluster hinzugefügt wird, erhöht die Anzahl der IP-Adressen, die im Backupsubnetz benötigt werden, um 3 IPs.
    • Networking-Services erfordern 3 IP-Adressen für das Backupsubnetz, unabhängig davon, wie viele VM-Cluster im Backupsubnetz vorhanden sind.
    • Die minimale CIDR-Blockgröße ist /28.

    Planen Sie immer eine zukünftige Erweiterung der Umgebung, und weisen Sie einen größeren CIDR-Block zu als den erforderlichen. Nachdem der Service bereitgestellt wurde, kann die Größe des CIDR-Blocks nicht mehr geändert werden.

  2. Erstellen Sie das delegierte Subnetz.

    Erstellen Sie im virtuellen Netzwerk, das das Exadata-VM-Cluster hostet, ein Subnetz, und delegieren Sie es an Oracle.Database/networkAttachments. Im delegierten Subnetz sind nur Oracle Database@Azure-Workloads zulässig, und Sie können keine anderen Azure- oder Compute-Services in diesem Subnetz bereitstellen.

    Wenn Sie Oracle Exadata Database Service bereitstellen, müssen Sie das Subnetz des delegierten Clients und das Backupsubnetz angeben.

    Wenn kein CIDR-Block für das Backupsubnetz angegeben ist, wird der Standardbereich 192.168.252.0/22 verwendet. Das Backupsubnetz wird in Azure nicht verwendet, und der CIDR-Block ist nicht Teil des virtuellen Netzwerk-CIDR-Blocks. Wenn Sie ein Disaster-Recovery-Szenario mit mehreren Exadata-Deployments (übergreifende Zone oder regionsübergreifend) in Betracht ziehen, muss der CIDR-Block des Backupsubnetzes angegeben werden und darf sich nicht mit einem anderen verwendeten CIDR-Block überschneiden.

    Richten Sie nach dem Erstellen des VM-Clusters die Datenbank mithilfe der Standardproduktdokumentation ein. Mehr erfahren.

  3. Verstehen Sie das DNS.

    Beim Provisioning von Oracle Exadata Database Service gibt es drei mögliche Szenarios für die DNS-Konfiguration:

    • Vollständig verwaltet

      Dies ist die Standardoption, bei der Oracle die DNS-Konfiguration während des Provisioning-Prozesses verarbeitet. Oracle erstellt A-Datensätze für das VM-Cluster. Der SCAN verwendet den vollqualifizierten Domainnamen *.oraclevcn.com (FQDN). Diese Integration ist unerlässlich, da die Exadata-Control Plane auf OCI ausgeführt wird, die den privaten DNS-Service von OCI für das Provisioning verwendet. Darüber hinaus synchronisiert der Provisioning-Prozess diese A-Datensätze automatisch mit dem privaten DNS von Azure. Wenn Sie das private DNS von Azure verwenden, ist die DNS-Konfiguration vollautomatisch und nahtlos sofort einsatzbereit.

      Nach dem Provisioning von DNS-Einträgen in OCI Private DNS und Azure wird der FQDN *.oraclevcn.com verwendet

    • Benutzerdefinierter FQDN

      Bei verwaltetem DNS entspricht der generierte FQDN dem Format *.oraclevcn.com, das für einige Kunden möglicherweise nicht ideal ist, insbesondere für Kunden, die ihn bereits in OCI verwenden und nicht in Azure implementieren können. Alternativ können Kunden mit Oracle während des Provisioning-Prozesses einen benutzerdefinierten FQDN angeben. Bei diesem Ansatz fehlt jedoch die einseitige Synchronisierung zwischen OCI und Azure, die von verwaltetem DNS bereitgestellt wird. Daher müssen Kunden die A-Datensätze aus ihrer benutzerdefinierten Zone manuell in OCI Private DNS zu Azure Private DNS replizieren.

      Da VM-Cluster OCI Private DNS zur Auflösung verwenden, müssen Benutzer vor dem Provisioning des VM-Clusters einen benutzerdefinierten FQDN erstellen. Navigieren Sie dazu zum DNS-Resolver, der an das VCN angehängt ist, und erstellen Sie eine neue private Zone zusammen mit einer privaten Ansicht, und hängen Sie diesen neuen privaten neuen DNS-Resolver an.

      Nachdem Sie diesen Schritt abgeschlossen haben, zeigt die Azure-UI automatisch die neu erstellte benutzerdefinierte Zone an, wenn die benutzerdefinierte FQDN-Option beim Erstellen des VM-Clusters ausgewählt wird.

      Nach dem Provisioning können Azure-Ressourcen auf verschiedene Arten auf DNS-Einträge zugreifen. Die einfachste Methode besteht darin, die Einträge der privaten OCI-Zone in Azure Private DNS zu replizieren. Alternativ können Sie einen OCI-DNS-Listening-Endpunkt erstellen, um Anforderungen an das private OCI-DNS weiterzuleiten.

    • Benutzerdefiniertes DNS

      Sie können auch ein benutzerdefiniertes DNS konfigurieren. Beispiel: Wenn Sie ein DNS eines Drittanbieters wie Infoblox mit Oracle Exadata Database Service verwenden möchten, können sie denselben Prozess wie bei einem benutzerdefinierten FQDN ausführen. Anschließend sollten Sie die relevanten DNS-Datensätze im benutzerdefinierten DNS duplizieren. Dadurch wird sichergestellt, dass Anwendungen und Benutzer die SCAN-URL mit dem benutzerdefinierten DNS auflösen können.