Oracle Cloud Infrastructure-Dokumentation

Netzwerksetup für Exadata Cloud Infrastructure-Instanzen

In diesem Thema werden die empfohlene Konfiguration für das VCN sowie verschiedene zugehörige Anforderungen für die Exadata Cloud Infrastructure-Instanz beschrieben.

Bevor Sie eine Exadata Cloud Infrastructure-Instanz einrichten, müssen Sie ein virtuelles Cloud-Netzwerk (VCN) und andere Komponenten des Networking-Service einrichten.

Übergeordnetes Thema: Exadata Cloud Infrastructure vorbereiten

VCN und Subnetze

Um eine Exadata Cloud Infrastructure-Instanz zu starten, benötigen Sie ein virtuelles Cloud-Netzwerk und mindestens zwei Subnetze:

Um eine Exadata Cloud Infrastructure-Instanz zu starten, benötigen Sie ein virtuelles Cloud-Netzwerk und mindestens zwei Subnetze. Außerdem müssen Sie den Typ des zu verwendenden DNS-Resolvers auswählen:

  • Ein VCN in der Region, in der die Exadata Cloud Infrastructure-Instanz verwendet werden soll
  • Mindestens zwei Subnetze im VCN. Die beiden Subnetze sind:
    • Clientsubnetz
    • Backupsubnetz
  • Wählen Sie die Methode der DNS-Namensauflösung aus, die Sie verwenden möchten. Siehe Optionen für DNS im VCN
Hinweis

Für Exadata Cloud Infrastructure-Instanzen, die das neue Exadata Cloud Infrastructure-Ressourcenmodell verwenden, wird die Netzwerkkonfiguration in der Cloud-VM-Clusterressource konfiguriert.

Das Clientsubnetz kann mit dem Dual-Stack-Netzwerk IPv4 oder IPv4/IPv6 konfiguriert werden.

Im Allgemeinen empfiehlt Oracle die Verwendung von regionalen Subnetzen, die alle Availability-Domains in der Region umfassen. Weitere Informationen finden Sie unter VCNs und Subnetze - Überblick.

Sie erstellen benutzerdefinierte Routentabellen für jedes Subnetz. Außerdem erstellen Sie Sicherheitsregeln, um den Traffic zum und vom Clientnetzwerk und Backupnetzwerk der Exadata-Compute Nodes zu kontrollieren (bei der Cloud-VM-Clusterressource werden Knoten als virtuelle Maschinen bezeichnet). Nachfolgend finden Sie weitere Informationen zu diesen Elementen.

Verwandte Themen

Übergeordnetes Thema: Netzwerksetup für Exadata Cloud Infrastructure-Instanzen

Option 1: Öffentliches Clientsubnetz mit Internetgateway

Diese Option kann bei der Durchführung von Proof-of-Concept- oder Entwicklungsarbeiten nützlich sein.

Sie können dieses Setup in der Produktion verwenden, wenn Sie ein Internetgateway mit dem VCN verwenden möchten oder Services nutzen, die nur in einem öffentlichen Netzwerk ausgeführt werden und Zugriff auf die Datenbank erfordern. Weitere Informationen finden Sie im folgenden Diagramm und der folgenden Beschreibung.

Beschreibung von network_exa_public_client.png folgt
Beschreibung der Abbildung network_exa_public_client.png

Sie richten Folgendes ein:

Hinweis

Wichtig In diesem bekannten Problem finden Sie Informationen zur Konfiguration von Routingregeln mit dem Servicegateway als Ziel in Routentabellen, die mit öffentlichen Subnetzen verknüpft sind.

Übergeordnetes Thema: VCN und Subnetze

Option 2: Private Subnetze

Oracle empfiehlt private Subnetze für ein Produktionssystem.

Beide Subnetze sind privat und können nicht über das Internet erreicht werden. Weitere Informationen finden Sie im folgenden Diagramm und der folgenden Beschreibung.

Beschreibung von network_exa_private_client.png folgt
Beschreibung der Abbildung network_exa_private_client.png

Sie richten Folgendes ein:

  • Subnetze:
    • Privates Clientsubnetz.
    • Ein privates Backupsubnetz.
  • Gateways für das VCN:
  • Routentabellen:
    • Eine benutzerdefinierte Routentabelle für das private Clientsubnetz mit den folgenden Regeln:
      • Eine Regel für das CIDR des On-Premise-Netzwerks mit dem target = DRG.
      • Eine Regel für das Service-CIDR-Label mit der Bezeichnung All <region> Services in Oracle Services Network und target = the service gateway. Das Oracle Services Network ist ein konzeptionelles Netzwerk in Oracle Cloud Infrastructure, das für Oracle-Services reserviert ist. Mit dieser Regel kann das Clientsubnetz das regionale Oracle YUM-Repository für BS-Updates erreichen. Siehe auch Option 2: Servicegatewayzugriff auf Object Storage und YUM-Repositorys.
      • Optional eine Regel für 0.0.0.0/0 und target = NAT gateway.
    • Eine separate benutzerdefinierte Routentabelle für das private Backupsubnetz mit einer Regel:
      • Dieselbe Regel wie für das Clientsubnetz für das Service-CIDR-Label mit der Bezeichnung All <region> Services in Oracle Services Network und target = the service gateway. Mit dieser Regel kann das Backupsubnetz den regionalen Objektspeicher für Backups erreichen.
  • Sicherheitsregeln, um den gewünschten Traffic zu und von den Exadata-Knoten zu ermöglichen. Weitere Informationen finden Sie unter Sicherheitsregeln für die Exadata Cloud Service-Instanz.
  • Fügen Sie optional eine statische Route für die Compute Nodes (bzw. für die virtuellen Maschinen bei VM-Clustern) zu anderen OCI-Services hinzu, um den Zugriff zu ermöglichen, wenn die Services nur im Backupsubnetz und nicht über das Clientsubnetz erreicht werden können, beispielsweise wenn ein NAT-Gateway verwendet wird.

Übergeordnetes Thema: VCN und Subnetze

Anforderungen an den IP-Adressbereich

IP-Adressen dürfen sich nicht überschneiden, insbesondere wenn sich Exadata Cloud Infrastructure-VM-Cluster (und somit VCNs) in mehreren Regionen befinden.

Wenn Sie Exadata Cloud Infrastructure-VM-Cluster (und somit VCNs) in mehreren Regionen einrichten, stellen Sie sicher, dass sich die IP-Adressbereiche der VCNs nicht überschneiden. Das ist wichtig, wenn Sie Disaster Recovery mit Oracle Data Guard einrichten möchten.

Bei Exadata X8 und niedriger dürfen sich die beiden Subnetze, die Sie für die Exadata Cloud Infrastructure-VM-Cluster erstellen, nicht mit 192.168.128.0/20 überschneiden.

Für Exadata X8M, X9M und X11M sind die IP-Adressen 100.64.0.0/10 für das Interconnect reserviert und dürfen nicht für die Client- oder Backup-VCNs sowie für Datenbankclients verwendet werden.

In der folgenden Tabelle sind die mindestens erforderlichen Subnetzgrößen aufgeführt, je nach Exadata-VM-Infrastruktur für jede VM-Clustergröße. Für das Clientsubnetz benötigt jeder Knoten vier IP-Adressen, und zusätzlich sind drei Adressen für Single Client Access Names (SCANs) reserviert. Für das Backupsubnetz benötigt jeder Knoten drei Adressen.

Rackgröße Clientsubnetz: Anzahl erforderliche IP-Adressen Clientsubnetz: Mindestgröße Hinweis Backupsubnetz: Anzahl erforderliche IP-Adressen Backupsubnetz: Mindestgröße Hinweis
Base System oder Quarter Rack pro VM-Cluster (4 Adressen * 2 Knoten) + 3 für SCANs = 11 /28 (16 IP-Adressen) 3 Adressen * 2 Knoten = 6 /28 (16 IP-Adressen)
Half Rack pro VM-Cluster (4 * 4 Knoten) + 3 = 19 /27 (32 IP-Adressen) 3 * 4 Knoten = 12 /28 (16 IP-Adressen)
Full Rack pro VM-Cluster (4* 8 Knoten) + 3 = 35 /26 (64 IP-Adressen) 3 * 8 Knoten = 24 /27 (32 IP-Adressen)
Flexible Infrastructure-Systeme (X8M und höher) pro VM-Cluster 4 Adressen pro Datenbankknoten (mindestens 2 Knoten) + 3 für SCANs Mindestgröße, die durch die Gesamtanzahl der für Datenbankknoten erforderlichen IP-Adressen bestimmt wird 3 Adressen pro Datenbankknoten (mindestens 2 Knoten) Mindestgröße, die durch die Gesamtanzahl der für Datenbankknoten erforderlichen IP-Adressen bestimmt wird
Hinweis

Der Networking-Service reserviert drei IP-Adressen in jedem Subnetz. Die Zuweisung eines größeren Bereichs für das Subnetz als das erforderliche Minimum (z.B. /25 anstelle von /28) kann die relative Auswirkung dieser reservierten Adressen auf den verfügbaren Bereich im Subnetz reduzieren.

Übergeordnetes Thema: VCN und Subnetze

Statische Routen für den Zugriff auf den Objektspeicher konfigurieren

Der gesamte Traffic in einer Exadata Cloud Infrastructure-Instanz wird standardmäßig über das Datennetzwerk weitergeleitet. Um Backuptraffic an die Backupschnittstelle (BONDETH1) weiterzuleiten, müssen Sie eine statische Route für jeden Compute Node im Cluster konfigurieren.

Anweisungen finden Sie unter Knotenzugriff auf Object Storage: Statische Route.

Übergeordnetes Thema: VCN und Subnetze

DNS für eine Exadata Cloud Infrastructure-Instanz einrichten

Mit DNS können Sie Hostnamen anstelle von IP-Adressen zur Kommunikation mit einer Exadata Cloud Infrastructure-Instanz verwenden.

Sie können den Internet- und VCN-Resolver (die in das VCN integrierte DNS-Funktion) verwenden, wie unter DNS im virtuellen Cloud-Netzwerk beschrieben. Oracle empfiehlt die Verwendung eines VCN-Resolvers zur DNS-Namensauflösung für das Clientsubnetz. Er löst die für das Backup von Datenbanken sowie für Patching und Update des Cloud-Toolings in einer Exadata-Instanz erforderlichen Swift-Endpunkte automatisch auf.

Übergeordnetes Thema: VCN und Subnetze

DNS: Kurznamen für VCN, Subnetze und Exadata Cloud Infrastructure-Instanz

Damit die Knoten kommunizieren können, muss das VCN den Internet- und VCN-Resolver verwenden. Der Internet- und VCN-Resolver ermöglicht die Hostnamenszuweisung zu den Knoten sowie die DNS-Auflösung dieser Hostnamen durch die Ressourcen im VCN.

Der Internet- und VCN-Resolver ermöglicht die Round-Robin-Auflösung der SCANs der Datenbank. Außerdem ermöglicht er die Auflösung der für das Backup von Datenbanken sowie für Patching und Update des Cloud-Toolings in einer Exadata Cloud Infrastructure-Instanz erforderlichen wichtigen Serviceendpunkte. Der Internet- und VCN-Resolver ist die Standardoption für das DNS im VCN. Weitere Informationen finden Sie unter DNS im virtuellen Cloud-Netzwerk sowie unter DHCP-Optionen.

Wenn Sie VCN, Subnetze und Exadata erstellen, müssen Sie die folgenden IDs in Verbindung mit DNS im VCN sorgfältig festlegen:

  • VCN-Domainlabel
  • Subnetzdomainlabel
  • Hostnamenspräfix für die Cloud-VM-Clusterressource der Exadata Cloud Infrastructure-Instanz

Diese Werte bilden den vollqualifizierten Domainnamen (FQDN) des Knotens:

<hostname_prefix>-######.<subnet_domain_label>.<vcn_domain_label>.oraclevcn.com

Beispiel:

exacs-abcde1.clientpvtad1.acmevcniad.oraclevcn.com

In diesem Beispiel weisen Sie exacs als Hostnamespräfix zu, wenn Sie das Cloud-VM-Cluster erstellen. Der Datenbankservice hängt automatisch einen Bindestrich und eine Zeichenfolge aus fünf Buchstaben und der Knotennummer an das Ende an. Beispiel:

  • Knoten 1: exacs-abcde1.clientpvtad1.acmevcniad.oraclevcn.com
  • Knoten 2:exacs-abcde2.clientpvtad1.acmevcniad.oraclevcn.com
  • Knoten 3: exacs-abcde3.clientpvtad1.acmevcniad.oraclevcn.com
  • Und so weiter

Anforderungen an das Hostnamenspräfix:

  • Empfohlenes Maximum: 12 Zeichen. Weitere Informationen finden Sie im Beispiel unter dem Abschnitt "Anforderungen an die VCN- und Subnetzdomainlabels".
  • Darf nicht der Zeichenfolge localhost entsprechen.

Anforderungen an die VCN- und Subnetzdomainlabels:

  • Empfohlenes Maximum: jeweils 14 Zeichen. Die tatsächliche zugrunde liegende Anforderung beträgt insgesamt 28 Zeichen für beide Domainlabels (ausgenommen den Punkt zwischen den Labels). Beispiel: Die beiden folgenden Werte sind zulässig: subnetad1.verylongvcnphx oder verylongsubnetad1.vcnphx. Der Einfachheit halber lautet die Empfehlung "jeweils 14 Zeichen".
  • Keine Bindestriche oder Unterstriche.

  • Empfohlen: Nehmen Sie den Regionsnamen in das Domainlabel des VCN auf, und nehmen Sie den Namen der Availability-Domain in das Domainlabel des Subnetzes auf.

  • Im Allgemeinen gilt für den FQDN ein maximaler Grenzwert von 63 Zeichen. Hier eine allgemeingültige Regel:

    <12_chars_max>-######.<14_chars_max>.<14_chars_max>.oraclevcn.com

Die vorstehenden Maximalwerte werden nicht durchgesetzt, wenn Sie VCN und Subnetze erstellen. Wenn die Labels jedoch den Höchstwert überschreiten, verläuft das Exadata-Deployment nicht erfolgreich.

Übergeordnetes Thema: VCN und Subnetze

DNS: Zwischen On-Premise-Netzwerk und VCN

Oracle empfiehlt die Verwendung eines privaten DNS-Resolvers, damit bei der Kommunikation zwischen On-Premise-Hosts und VCN-Ressourcen Hostnamen verwendet werden können.

Informationen zum Erstellen und Verwenden privater Resolver finden Sie unter Private DNS-Resolver. Eine Referenzarchitektur finden Sie unter Privates DNS im VCN verwenden im Oracle Architecture Center.

Übergeordnetes Thema: VCN und Subnetze

Privates DNS konfigurieren

Voraussetzungen für die Verwendung des privaten DNS.

  • Bevor das Provisioning des VM-Clusters gestartet wird, müssen die private Ansicht und die private Zone erstellt werden. Einzelheiten dazu finden Sie unter Private DNS-Resolver.
  • Eine Weiterleitung an einen anderen DNS-Server muss zuvor in der DNS-Konsole eingerichtet werden. Gehen Sie dazu zum Resolver des VCN, und erstellen Sie den Endpunkt und dann die Regeln. Details finden Sie unter DNS im virtuellen Cloud-Netzwerk.
  • Der Name der privaten Zone darf nicht mehr als 4 Labels enthalten. Beispiel: a.b.c.d ist zulässig, während a.b.c.d.e nicht zulässig ist.
  • Außerdem muss die private Ansicht dem Resolver des VCN hinzugefügt werden. Weitere Informationen finden Sie unter Private Ansicht zu einem Resolver hinzufügen.
  • Beim Provisioning eines Exadata-VM-Clusters mit dem privaten DNS-Feature muss Exadata Reverse-DNS-Zonen im Compartment des Exadata-VM-Clusters erstellen. Wenn das Compartment über definierte Tags oder Tagstandardwerte verfügt, sind zusätzliche Policys für die Verwaltung von Tags erforderlich. Details finden Sie unter:

Übergeordnetes Thema: VCN und Subnetze

Knotenzugriff auf Object Storage: Statische Route

Um Datenbanken sichern und Cloud-Tools auf einer Exadata Cloud Infrastructure-Instanz patchen und aktualisieren zu können, müssen Sie den Zugriff auf Oracle Cloud Infrastructure Object Storage konfigurieren. Unabhängig davon, wie Sie diesen Zugriff im VCN konfigurieren (z.B. mit einem Servicegateway), müssen Sie möglicherweise auch auf jedem Compute Node im Cluster eine statische Route zu Object Storage konfigurieren. Dies ist nur erforderlich, wenn Sie keine automatischen Backups verwenden. Wenn Sie benutzerdefinierte Backups mit den Backup-APIs verwenden, müssen Sie den für Object Storage bestimmten Traffic über die Backupschnittstelle (BONDETH1) weiterleiten. Dies ist nicht erforderlich, wenn Sie automatische Backups verwenden, die mit der Konsole oder den APIs oder CLIs erstellt wurden.

Achtung:

Sie müssen eine statische Route für den Object Storage-Zugriff auf jedem Compute Node in einer Exadata Cloud Infrastructure-Instanz konfigurieren, wenn Sie keine automatischen Backups mit der Konsole oder den APIs oder CLIs erstellen. Andernfalls verlaufen Backups von Datenbanken sowie Patching-Vorgänge oder Updates von Tools im System möglicherweise nicht erfolgreich.
Hinweis

Wenn Sie das erste automatische Backup für eine Datenbank aktivieren, wird die statische Route im Service automatisch konfiguriert.

Wenn Sie den Service vor dem Erstellen einer Datenbank patchen möchten, ist die manuelle statische Route erforderlich, um die GI oder das DB-Home patchen zu können.

Die statische Route kann auch für den Zugriff auf andere Services (IAM, KMS) erforderlich sein, wenn diese nicht über das Clientsubnetz erreichbar sind und nur das Backupsubnetz die Einstellung für den Zugriff auf alle Services innerhalb einer Region verwendet.

IP-Zuweisungen für Object Storage

Oracle Cloud Infrastructure Object Storage verwendet für alle Regionen den CIDR-Block-IP-Bereich 134.70.0.0/16.

Seit dem 1. Juni 2018 unterstützt Object Storage die folgenden eingestellten IP-Bereiche nicht mehr. Oracle empfiehlt, dass Sie diese älteren IP-Adressen aus den Access-Control-Listen, Firewallregeln und anderen Regeln entfernen, nachdem Sie die neuen IP-Bereiche übernommen haben.

Folgende IP-Bereiche wurden eingestellt:

  • Germany Central (Frankfurt): 130.61.0.0/16
  • UK South (London): 132.145.0.0/16
  • US East (Ashburn): 129.213.0.0/16
  • US West (Phoenix): 129.146.0.0/16

So konfigurieren Sie eine statische Route für den Object Storage-Zugriff

  1. Stellen Sie mit SSH eine Verbindung zu einem Compute Node in der Exadata Cloud Infrastructure-Instanz her. 

    ssh -i <private_key_path> opc@<node_ip_address>

  2. Melden Sie sich als "opc" an, und wechseln Sie mit "sudo" zum Benutzer "root". Verwenden Sie sudo su - mit Bindestrich, um das Profil des Root-Benutzers aufzurufen. 

    
login as: opc
			
[opc@dbsys ~]$ sudo su -

  3. Identifizieren Sie das Gateway, das für die BONDETH1-Schnittstelle konfiguriert wurde. 

    [root@dbsys ~]# grep GATEWAY /etc/sysconfig/network-scripts/ifcfg-bondeth1 |awk -F"=" '{print $2}'


10.0.4.1

  4. Fügen Sie der Datei /etc/sysconfig/network-scripts/route-bondeth1 die folgende statische Regel für BONDETH1 hinzu: 

    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. Starten Sie die Schnittstelle neu. 

    
[root@dbsys ~]# ifdown bondeth1; ifup bondeth1;

    Die Dateiänderungen aus dem vorherigen Schritt treten sofort nach der Ausführung der Befehle "ifdown" und "ifup" in Kraft.

  6. Wiederholen Sie die vorherigen Schritte auf jedem Compute Node in der Exadata Cloud Infrastructure-Instanz.

Servicegateway für das VCN

Stellen Sie sicher, dass Ihr VCN das Oracle Services Network erreichen kann – insbesondere Object Storage für Backups, Oracle YUM-Repositorys für BS-Updates, IAM (Identity and Access Management) und OCI Vault (KMS-Integration).

Hinweis

Wenn das VCN keine Konnektivität zu Oracle Services Network aufweist, verläuft das Provisioning neuer VM-Cluster möglicherweise nicht erfolgreich, und die Verwaltbarkeit vorhandener VM-Cluster kann ebenfalls beeinträchtigt werden.

Je nachdem, ob Sie Option1: Public Client Subnet with Internet Gateway oder Option 2: Private Subnets verwenden, verwenden Sie das Servicegateway auf unterschiedliche Weise. Weitere Einzelheiten finden Sie in den beiden nächsten Abschnitten.

Verwandte Themen

Übergeordnetes Thema: Netzwerksetup für Exadata Cloud Infrastructure-Instanzen

Option 1: Servicegatewayzugriff auf OCI-Service für Backupsubnetz

Sie konfigurieren das Backupsubnetz so, dass das Servicegateway nur für den Zugriff auf Object Storage verwendet wird.

Hier sehen Sie noch einmal das Diagramm für Option 1:

Diese Abbildung zeigt das Netzwerksetup mit einem öffentlichen Clientsubnetz.

Im Allgemeinen müssen Sie folgende Schritte ausführen:

  • Führen Sie die Aufgaben zum Einrichten eines Servicegateways in einem VCN aus, und aktivieren Sie insbesondere das Service-CIDR-Label OCI <region> Object Storage.
  • Fügen Sie beim Aktualisieren des Routings eine Routingregel zur benutzerdefinierten Routentabelle des Backupsubnetzes hinzu. Verwenden Sie als Zielservice OCI <region> Object Storage und target = the service gateway.
  • Aktualisieren Sie die Sicherheitsregeln im Subnetz entweder für die Netzwerksicherheitsgruppe (NSG) oder für die benutzerdefinierte Sicherheitsliste des Backupnetzwerks. Richten Sie eine Sicherheitsregel ein und der Zielservice ist auf OCI <region> Object Storage gesetzt. Siehe Speziell für das Backupnetzwerk benötigte Regel.

Option 2: Servicegatewayzugriff auf OCI-Service für Client- und Backup-Subnetze

Sie konfigurieren das Clientsubnetz und das Backupsubnetz so, dass das Servicegateway für den Zugriff auf das Oracle Services Network verwendet wird, das Objektspeicher für Backups, Oracle YUM-Repositorys für BS-Updates, IAM (Identity and Access Management) und OCI Vault (KMS Integration) umfasst.

Hinweis

Informationen zum Zugriff auf Oracle YUM-Services über das Servicegateway finden Sie in diesen bekannten Problemen.

Hier sehen Sie noch einmal das Diagramm für Option 2:

Diese Abbildung zeigt das Netzwerksetup mit einem privaten Clientsubnetz.

Im Allgemeinen müssen Sie folgende Schritte ausführen:

  • Führen Sie die Aufgaben zum Einrichten eines Servicegateways im VCN aus, und aktivieren Sie insbesondere das Service-CIDR-Label All <region> Services in Oracle Services Network.
  • Fügen Sie beim Aktualisieren des Routings eine Regel zur benutzerdefinierten Routentabelle jedes Subnetzes hinzu. Verwenden Sie für den Zieldienst All <region> Services in Oracle Services Network und target = the service gateway.
  • Aktualisieren Sie die Sicherheitsregeln für das Subnetz entweder für die Netzwerksicherheitsgruppe (NSG) oder für die benutzerdefinierte Sicherheitsliste des Backupnetzwerks. Richten Sie eine Sicherheitsregel ein und der Zielservice ist auf OCI <region> Object Storage gesetzt. Siehe Sicherheitsregeln für Oracle Exadata Cloud Service Sicherheitsregeln für Oracle Exadata Database Service on Dedicated Infrastructure. Beachten Sie, dass das Clientsubnetz bereits eine umfassende Egress-Regel enthält, die den Zugriff auf die YUM-Repositorys abdeckt.

Weitere Details zur Verwendung des Servicegateways für Option 2:

  • Das Clientsubnetz und das Backupsubnetz verwenden beide das Servicegateway, greifen jedoch auf unterschiedliche Services zu. Sie können nicht sowohl das Label OCI <region> Object Storage service CIDR als auch All <region> Services in Oracle Services Network für das Servicegateway aktivieren. Um die Anforderungen beider Subnetze zu decken, müssen Sie All <region> Services in Oracle Services Network für das Servicegateway aktivieren. Das VCN kann nur ein einziges Servicegateway enthalten.
  • Jede Routingregel mit einem bestimmten Servicegateway als Ziel muss ein aktiviertes Service-CIDR-Label als Ziel für die Regel verwenden, keinen CIDR-Block. Das bedeutet, dass für Option 2 die Routentabellen für beide Subnetze All <region> Services in Oracle Services Network für ihre Servicegatewayregeln verwenden müssen.
  • Im Gegensatz zu Routingregeln können Sicherheitsregeln entweder ein beliebiges Service-CIDR-Label (unabhängig davon, ob das VCN ein Servicegateway enthält) oder einen CIDR-Block als Quell- oder Ziel-CIDR für die Regel verwenden. Obwohl das Backupsubnetz eine Routingregel verwendet, die All <region> Services in Oracle Services Network verwendet, kann das Subnetz daher eine Sicherheitsregel enthalten. Diese verwendet OCI <region> Object Storage. Siehe Sicherheitsregeln für die Exadata Cloud Service-Instanz.

Sicherheitsregeln für Oracle Exadata Database Service on Dedicated Infrastructure

In diesem Abschnitt sind die Sicherheitsregeln aufgeführt, die für Exadata Cloud Infrastructure verwendet werden müssen.

Sicherheitsregeln legen die Traffictypen fest, die für das Clientnetzwerk und das Backupnetzwerk der Compute Nodes von Exadata zulässig sind. Die Regeln sind in drei Abschnitte unterteilt.

Es gibt verschiedene Möglichkeiten, diese Regeln zu implementieren. Weitere Informationen finden Sie unter Möglichkeiten zum Implementieren der Sicherheitsregeln.
Hinweis

Bei X8M- und X9M-Systemen empfiehlt Oracle, dass alle Ports im Clientsubnetz für Ingress- und Egress-Traffic geöffnet sind. Dies ist eine Voraussetzung für das Hinzufügen zusätzlicher Datenbankserver zum System.
Hinweis

Wenn Sie Zero-Trust-Paket-Routing verwenden möchten, um die Netzwerke für Ihre Datenbankservices zu steuern, und Sie planen, Data Guard-Peers innerhalb desselben VCN zu konfigurieren, müssen alle VM-Cluster in der VCN- und Data Guard-Konfiguration dasselbe ZPR-Sicherheitsattribut aufweisen. Data Guard-Peers, die sich in einem anderen VCN oder einer anderen Region befinden, müssen von CIDR in der ZPR-Konfiguration angegeben werden.

Für Clientnetzwerk und Backupnetzwerk erforderliche Regeln

Dieser Abschnitt enthält mehrere allgemeine Regeln für die grundlegende Konnektivität für Hosts im VCN.

Wenn Sie Sicherheitslisten zum Implementieren der Sicherheitsregeln verwenden, beachten Sie, dass die folgenden Regeln standardmäßig in der Standardsicherheitsliste enthalten sind. Aktualisieren oder ersetzen Sie die Liste entsprechend Ihren spezifischen Sicherheitsanforderungen. Die beiden ICMP-Regeln (allgemeine Ingress-Regeln 2 und 3) sind für die korrekte Funktion des Netzwerktraffics innerhalb der Oracle Cloud Infrastructure-Umgebung erforderlich. Passen Sie die allgemeine Ingress-Regel 1 (SSH-Regel) und die allgemeine Egress-Regel 1 an, damit nur Traffic zu und von Hosts zulässig ist, die mit Ressourcen im VCN kommunizieren müssen.

Allgemeine Ingress-Regel 1: SSH-Traffic von überall zulassen

  • Zustandslos: Nein (alle Regeln müssen zustandsbehaftet sein)
  • Quelltyp: CIDR
  • Quell-CIDR: 0.0.0.0/0 (IPv4), ::/0 (IPv6)
  • IP-Protokoll: SSH
  • Quellportbereich: Alle
  • Zielportbereich: 22

Allgemeine Ingress-Regel 2: Nachrichten zur Pfad-MTU-Discovery-Fragmentierung zulassen

Mit dieser Regel können Hosts im VCN Nachrichten zur Pfad-MTU-Discovery-Fragmentierung empfangen. Ohne Zugriff auf diese Nachrichten können Hosts im VCN Probleme bei der Kommunikation mit Hosts außerhalb des VCN haben.

  • Zustandslos: Nein (alle Regeln müssen zustandsbehaftet sein)
  • Quelltyp: CIDR
  • Quell-CIDR: 0.0.0.0/0 (IPv4), ::/0 (IPv6)
  • IP-Protokoll: ICMP
  • Typ: 3
  • Code: 4

Allgemeine Ingress-Regel 3: Konnektivitätsfehlermeldungen innerhalb des VCN zulassen

Mit dieser Regel können die Hosts im VCN Konnektivitätsfehlermeldungen voneinander empfangen.

  • Zustandslos: Nein (alle Regeln müssen zustandsbehaftet sein)
  • Quelltyp: CIDR
  • Source CIDR: IPv4: your VCN's IPv4 CIDR, IPv6: your VCN's IPv6 CIDR
  • IP-Protokoll: ICMP
  • Typ: ALL
  • Code: Alle

Allgemeine Egress-Regel 1: Sämtlichen Egress-Traffic zulassen

  • Zustandslos: Nein (alle Regeln müssen zustandsbehaftet sein)
  • Zieltyp: CIDR
  • Ziel-CIDR: 0.0.0.0/0 (IPv4), ::/0 (IPv6)
  • IP-Protokoll: Alle

Speziell für das Clientnetzwerk erforderliche Regeln

Die folgenden Sicherheitsregeln sind für das Clientnetzwerk wichtig.

Hinweis

  • Die Client-Ingress-Regeln 1 und 2 gelten nur für Verbindungen, die innerhalb des Clientsubnetzes initiiert werden. Wenn Sie einen Client außerhalb des VCN verwenden, empfiehlt Oracle, zwei zusätzliche ähnliche Regeln einzurichten, die stattdessen als Quell-CIDR die öffentliche IP-Adresse des Clients verwenden.
  • Die Client-Egress-Regeln 1 und 2 in der Clientnetzwerkkonfiguration ermöglichen TCP- und ICMP-Traffic und ermöglichen eine sichere Knoten-zu-Knoten-Kommunikation im Clientnetzwerk. Diese Regeln sind von entscheidender Bedeutung, da sie wesentliche TCP-Konnektivität über Knoten hinweg ermöglichen. Wenn die TCP-Konnektivität zwischen Knoten nicht erfolgreich verläuft, wird das Provisioning der Exadata Cloud-VM-Clusterressource nicht erfolgreich abgeschlossen.

Client-Ingress-Regel 1: ONS- und FAN-Traffic aus dem Clientsubnetz zulassen

Die erste Regel wird empfohlen und ermöglicht, dass Oracle Notification Services (ONS) über Fast Application Notification-(FAN-)Ereignisse kommunizieren können.

  • Zustandslos: Nein (alle Regeln müssen zustandsbehaftet sein)
  • Quelltyp: CIDR
  • Quell-CIDR: IPv4: IPv4 CIDR des Clientsubnetzes, IPv6: CIDR IPv6 des Clientsubnetzes
  • IP-Protokoll: TCP
  • Quellportbereich: Alle
  • Zielportbereich: 6200
  • Beschreibung: Eine optionale Beschreibung der Regel.

Client-Ingress-Regel 2: SQL*NET-Traffic aus dem Clientsubnetz zulassen

Diese Regel ist für SQL*NET-Traffic vorgesehen und in den folgenden Fällen erforderlich:

  • Wenn Sie Clientverbindungen zur Datenbank aktivieren müssen
  • Wenn Sie Oracle Data Guard verwenden möchten
  • Zustandslos: Nein (alle Regeln müssen zustandsbehaftet sein)
  • Quelltyp: CIDR
  • Quell-CIDR: IPv4: IPv4 CIDR des Clientsubnetzes, IPv6: CIDR IPv6 des Clientsubnetzes
  • IP-Protokoll: TCP
  • Quellportbereich: Alle
  • Zielportbereich: 1521
  • Beschreibung: Eine optionale Beschreibung der Regel.

Client-Egress-Regel 1: SSH-TCP-Traffic innerhalb des Clientsubnetzes zulassen

  • Zustandslos: Nein (alle Regeln müssen zustandsbehaftet sein)
  • Zieltyp: CIDR
  • Ziel-CIDR: 0.0.0.0/0 (IPv4), ::/0 (IPv6)
  • IP-Protokoll: TCP
  • Quellportbereich: Alle
  • Zielportbereich: 22
  • Beschreibung: Eine optionale Beschreibung der Regel.

Client-Egress-Regel 2: Sämtlichen Egress-Traffic zulassen (ermöglicht Verbindungen zu den Oracle YUM-Repositorys)

Client-Egress-Regel 2 ist wichtig, weil sie Verbindungen zu den Oracle YUM-Repositorys zulässt. Die Regel ist mit der allgemeinen Egress-Regel in diesem Thema (und in der Standardsicherheitsliste) redundant. Sie ist optional, wird jedoch für den Fall empfohlen, dass die allgemeine Egress-Regel (oder die Standardsicherheitsliste) versehentlich geändert wurde.

  • Zustandslos: Nein (alle Regeln müssen zustandsbehaftet sein)
  • Zieltyp: CIDR
  • Ziel-CIDR: 0.0.0.0/0 (IPv4), ::/0 (IPv6)
  • IP-Protokoll: Alle
  • Beschreibung: Eine optionale Beschreibung der Regel.

Speziell für das Backupnetzwerk erforderliche Regel

Die folgende Sicherheitsregel ist für das Backupnetzwerk wichtig, da sie die Kommunikation des VM-Clusters mit Object Storage über das Servicegateway ermöglicht (sowie optional mit den Oracle YUM-Repositorys, wenn das Clientnetzwerk keinen Zugriff auf diese Hat). Die Regel ist mit der allgemeinen Egress-Regel in diesem Thema (und in der Standardsicherheitsliste) redundant. Sie ist optional, wird jedoch für den Fall empfohlen, dass die allgemeine Egress-Regel (oder die Standardsicherheitsliste) versehentlich geändert wurde.

Backup-Egress-Regel: Zugriff auf Object Storage zulassen

  • Zustandslos: Nein (alle Regeln müssen zustandsbehaftet sein)
  • Zieltyp: Service

  • Zielservice:

    • Das Service-CIDR-Label mit dem Namen OCI <region> Object Storage
    • Wenn das Clientnetzwerk keinen Zugriff auf die Oracle YUM-Repositorys hat, verwenden Sie das Service-CIDR-Label mit dem Namen All <region> Services in Oracle Services Network.
  • IP-Protokoll: TCP
  • Quellportbereich: Alle
  • Zielportbereich: 443 (HTTPS)
  • Beschreibung: Eine optionale Beschreibung der Regel.

Übergeordnetes Thema: Netzwerksetup für Exadata Cloud Infrastructure-Instanzen

Für Clientnetzwerk und Backupnetzwerk erforderliche Regeln

Dieses Thema enthält mehrere allgemeine Regeln für die grundlegende Konnektivität für Hosts im VCN.

Wenn Sie Sicherheitslisten zum Implementieren der Sicherheitsregeln verwenden, beachten Sie, dass die folgenden Regeln standardmäßig in der Standardsicherheitsliste enthalten sind. Aktualisieren oder ersetzen Sie die Liste entsprechend Ihren spezifischen Sicherheitsanforderungen. Die beiden ICMP-Regeln (allgemeine Ingress-Regeln 2 und 3) sind für die korrekte Funktion des Netzwerktraffics innerhalb der Oracle Cloud Infrastructure-Umgebung erforderlich. Passen Sie die allgemeine Ingress-Regel 1 (SSH-Regel) und die allgemeine Egress-Regel 1 an, damit nur Traffic zu und von Hosts zulässig ist, die mit Ressourcen im VCN kommunizieren müssen.

Allgemeine Ingress-Regel 1: SSH-Traffic von überall zulassen
  • Zustandslos: Nein (alle Regeln müssen zustandsbehaftet sein)
  • Quelltyp: CIDR
  • Quell-CIDR: 0.0.0.0/0 (IPv4), ::/0 (IPv6)
  • IP-Protokoll: SSH
  • Quellportbereich: Alle
  • Zielportbereich: 22
Allgemeine Ingress-Regel 2: Nachrichten zur Pfad-MTU-Discovery-Fragmentierung zulassen

Mit dieser Regel können Hosts im VCN Nachrichten zur Pfad-MTU-Discovery-Fragmentierung empfangen. Ohne Zugriff auf diese Nachrichten können Hosts im VCN Probleme bei der Kommunikation mit Hosts außerhalb des VCN haben.

  • Zustandslos: Nein (alle Regeln müssen zustandsbehaftet sein)
  • Quelltyp: CIDR
  • Quell-CIDR: 0.0.0.0/0 (IPv4), ::/0 (IPv6)
  • IP-Protokoll: ICMP
  • Typ: 3
  • Code: 4
Allgemeine Ingress-Regel 3: Konnektivitätsfehlermeldungen innerhalb des VCN zulassen

Mit dieser Regel können die Hosts im VCN Konnektivitätsfehlermeldungen voneinander empfangen.

  • Zustandslos: Nein (alle Regeln müssen zustandsbehaftet sein)
  • Quelltyp: CIDR
  • Source CIDR: IPv4: your VCN's IPv4 CIDR, IPv6: your VCN's IPv6 CIDR
  • IP-Protokoll: ICMP
  • Typ: Alle
  • Code: Alle
Allgemeine Egress-Regel 1: Sämtlichen Egress-Traffic zulassen
  • Zustandslos: Nein (alle Regeln müssen zustandsbehaftet sein)
  • Zieltyp: CIDR
  • Ziel-CIDR: 0.0.0.0/0 (IPv4), ::/0 (IPv6)
  • IP-Protokoll: Alle

Wenn der Kunde die Benachrichtigung über Data-Plane-Gast-VM-Ereignisse aktiviert, ist die Standard-Egress-Regel ausreichend.

Speziell für das Clientnetzwerk erforderliche Regeln

Die folgenden Sicherheitsregeln sind für das Clientnetzwerk wichtig.

Hinweis

  • Bei X8M-Systemen empfiehlt Oracle, dass alle Ports im Clientsubnetz für Ingress- und Egress-Traffic geöffnet sind. Dies ist eine Voraussetzung für das Hinzufügen zusätzlicher Datenbankserver zum System.
  • Die Client-Ingress-Regeln 1 und 2 gelten nur für Verbindungen, die innerhalb des Clientsubnetzes initiiert werden. Wenn Sie einen Client außerhalb des VCN verwenden, empfiehlt Oracle, zwei zusätzliche ähnliche Regeln einzurichten, die stattdessen als Quell-CID R auf die öffentliche IP-Adresse des Clients gesetzt sind.
  • Die Client-Ingress-Regeln 3 und 4 sowie die Client-Egress-Regeln 1 und 2 ermöglichen TCP- und ICMP-Traffic innerhalb des Clientnetzwerks sowie die Kommunikation der Knoten untereinander. Wenn eine TCP-Konnektivität auf den Knoten ausfällt, kann die Exadata-VM-Clusterressource nicht durch Provisioning bereitgestellt werden.

Übergeordnetes Thema: Sicherheitsregeln für Oracle Exadata Database Service on Dedicated Infrastructure

Client-Ingress-Regel 1: ONS- und FAN-Traffic aus dem Clientsubnetz zulassen

Die erste Regel wird empfohlen und ermöglicht, dass Oracle Notification Services (ONS) über Fast Application Notification-(FAN-)Ereignisse kommunizieren können.

  • Zustandslos: Nein (alle Regeln müssen zustandsbehaftet sein)
  • Quelltyp: CIDR
  • Quell-CIDR: IPv4: IPv4 CIDR des Clientsubnetzes, IPv6: CIDR IPv6 des Clientsubnetzes
  • IP-Protokoll: TCP
  • Quellportbereich: Alle
  • Zielportbereich: 6200
  • Beschreibung: Eine optionale Beschreibung der Regel.
Client-Ingress-Regel 2: SQL*NET-Traffic aus dem Clientsubnetz zulassen

Diese Regel ist für SQL*NET-Traffic vorgesehen und in den folgenden Fällen erforderlich:

  • Wenn Sie Clientverbindungen zur Datenbank aktivieren müssen
  • Wenn Sie Oracle Data Guard verwenden möchten
  • Zustandslos: Nein (alle Regeln müssen zustandsbehaftet sein)
  • Quelltyp: CIDR
  • Quell-CIDR: IPv4: IPv4 CIDR des Clientsubnetzes, IPv6: CIDR IPv6 des Clientsubnetzes
  • IP-Protokoll: TCP
  • Quellportbereich: Alle
  • Zielportbereich: 1521
  • Beschreibung: Eine optionale Beschreibung der Regel.
Client-Egress-Regel 1: Sämtlichen TCP-Traffic innerhalb des Clientsubnetzes zulassen

Diese Regel ist für SQL*NET-Traffic wie angegeben.

  • Zustandslos: Nein (alle Regeln müssen zustandsbehaftet sein)
  • Zieltyp: CIDR
  • Ziel-CIDR: 0.0.0.0/0 (IPv4), ::/0 (IPv6)
  • IP-Protokoll: TCP
  • Quellportbereich: Alle
  • Zielportbereich: 22
  • Beschreibung: Eine optionale Beschreibung der Regel.
Client-Egress-Regel 2: Sämtlichen Egress-Traffic zulassen (ermöglicht Verbindungen zu den Oracle YUM-Repositorys)

Client-Egress-Regel 3 ist wichtig, weil sie Verbindungen zu den Oracle YUM-Repositorys zulässt.

Die Regel ist mit der allgemeinen Egress-Regel 1 redundant: Sämtlichen Egress-Traffic zulassen (und in der Standardsicherheitsliste). Sie ist optional, wird jedoch für den Fall empfohlen, dass die allgemeine Egress-Regel (oder die Standardsicherheitsliste) versehentlich geändert wurde.

  • Zustandslos: Nein (alle Regeln müssen zustandsbehaftet sein)
  • Zieltyp: CIDR
  • Ziel-CIDR: 0.0.0.0/0 (IPv4), ::/0 (IPv6)
  • IP-Protokoll: Alle
  • Beschreibung: Eine optionale Beschreibung der Regel.

Speziell für das Backupnetzwerk erforderliche Regel

Die folgende Sicherheitsregel ist für das Backupnetzwerk wichtig, da sie die Kommunikation des VM-Clusters mit Object Storage über das Servicegateway ermöglicht (sowie optional mit den Oracle YUM-Repositorys, wenn das Clientnetzwerk keinen Zugriff auf diese Hut hat).

Sie ist mit der allgemeinen Egress-Regel 1: Sämtlichen Egress-Traffic zulässig redundant. Sie ist optional, wird jedoch für den Fall empfohlen, dass die allgemeine Egress-Regel (oder die Standardsicherheitsliste) versehentlich geändert wurde.

Backup-Egress-Regel: Zugriff auf Object Storage zulassen
  • Zustandslos: Nein (alle Regeln müssen zustandsbehaftet sein)
  • Zieltyp: Service

  • Zielservice:

    • Das Service-CIDR-Label mit dem Namen OCI <region> Object Storage
    • Wenn das Clientnetzwerk keinen Zugriff auf die Oracle YUM-Repositorys hat, verwenden Sie das Service-CIDR-Label mit dem Namen All <region> Services in Oracle Services Network.
  • IP-Protokoll: TCP
  • Quellportbereich: Alle
  • Zielportbereich: 443 (HTTPS)
  • Beschreibung: Eine optionale Beschreibung der Regel.

Für Events-Service erforderliche Regeln

Die Compute-Instanz muss entweder über eine öffentliche IP-Adresse oder ein Servicegateway verfügen, um Compute-Instanzmetriken an den Events-Service senden zu können.

Die Standard-Egress-Regeln sind ausreichend, damit die Compute-Instanz Compute-Instanzmetriken an den Events-Service senden kann.

Wenn die Instanz keine öffentliche IP-Adresse hat, richten Sie ein Servicegateway im virtuellen Cloud-Netzwerk (VCN) ein. Mit dem Servicegateway kann die Instanz Compute-Instanzmetriken an den Events-Service senden, ohne dass der Traffic über das Internet geleitet wird. Nachfolgend finden Sie besondere Hinweise zur Einrichtung des Servicegateways für den Zugriff auf den Events-Service:

  • Aktivieren Sie beim Erstellen des Servicegateways das Servicelabel Alle <Region>-Services in Oracle Services Network. Dazu gehört auch der Events-Service.

  • Wenn Sie Routing für das Subnetz mit der Instanz einrichten, richten Sie eine Routingregel ein, bei der Zieltyp auf Servicegateway und Zielservice auf Alle <Region>-Services in Oracle Services Network eingestellt ist.

    Ausführliche Anweisungen finden Sie unter Zugriff auf Oracle-Services: Servicegateway.

Für Monitoring-Service erforderliche Regeln

Die Compute-Instanz muss entweder über eine öffentliche IP-Adresse oder ein Servicegateway verfügen, um Compute-Instanzmetriken an den Monitoring-Service senden zu können.

Die Standard-Egress-Regeln sind ausreichend, damit die Compute-Instanz Compute-Instanzmetriken an den Monitoring-Service senden kann.

Wenn die Instanz keine öffentliche IP-Adresse hat, richten Sie ein Servicegateway im virtuellen Cloud-Netzwerk (VCN) ein. Mit dem Servicegateway kann die Instanz Compute-Instanzmetriken an den Monitoring-Service senden, ohne dass der Traffic über das Internet geleitet wird. Hier finden Sie besondere Hinweise zur Einrichtung des Servicegateways für den Zugriff auf den Monitoring-Service:

  • Aktivieren Sie beim Erstellen des Servicegateways das Servicelabel Alle <Region>-Services in Oracle Services Network. Dazu gehört auch der Monitoring-Service.

  • Wenn Sie Routing für das Subnetz mit der Instanz einrichten, richten Sie eine Routingregel ein, bei der Zieltyp auf Servicegateway und Zielservice auf Alle <Region>-Services in Oracle Services Network eingestellt ist.

    Ausführliche Anweisungen finden Sie unter Zugriff auf Oracle-Services: Servicegateway.

Möglichkeiten zum Implementieren der Sicherheitsregeln

Erfahren Sie, wie Sie Sicherheitsregeln mit dem Networking-Service in Ihrem VCN implementieren.

Der Networking-Service bietet zwei Möglichkeiten zum Implementieren von Sicherheitsregeln im VCN:

Einen Vergleich der beiden Methoden finden Sie unter Sicherheitslisten und Netzwerksicherheitsgruppen im Vergleich.

Übergeordnetes Thema: Netzwerksetup für Exadata Cloud Infrastructure-Instanzen

Wenn Sie Netzwerksicherheitsgruppen verwenden

Wenn Sie Netzwerksicherheitsgruppen (NSGs) verwenden, befolgen Sie diesen empfohlenen Prozess:

  1. Erstellen Sie eine NSG für das Clientnetzwerk. Fügen Sie dieser NSG die folgenden Sicherheitsregeln hinzu:

  2. Erstellen Sie eine separate NSG für das Backupnetzwerk. Fügen Sie dieser NSG die folgenden Sicherheitsregeln hinzu:

  3. Wenn der Datenbankadministrator eine Exadata Cloud Infrastructure-Instanz erstellt, muss er verschiedene Netzwerkkomponenten auswählen (z.B. das zu verwendende VCN und die zu verwendenden Subnetze):
    • Beim Auswählen des Clientsubnetzes können auch die zu verwendenden NSGs ausgewählt werden. Stellen Sie sicher, dass dabei die NSG des Clientnetzwerks ausgewählt wird.
    • Beim Auswählen des Backupsubnetzes können auch die zu verwendenden NSGs ausgewählt werden. Stellen Sie sicher, dass dabei die NSG des Backupnetzwerks ausgewählt wird.

Stattdessen können Sie auch eine separate NSG für die allgemeinen Regeln erstellen. Wenn der Datenbankadministrator dann die zu verwendenden NSGs für das Clientnetzwerk auswählt, muss er sowohl die allgemeine NSG als auch die NSG des Clientnetzwerks auswählen. Ebenso muss er für das Backupnetzwerk sowohl die allgemeine NSG als auch die NSG des Backupnetzwerks auswählen.

Wenn Sie Sicherheitslisten verwenden

Wenn Sie Sicherheitslisten verwenden, befolgen Sie diesen empfohlenen Prozess:

Wenn Sie Sicherheitslisten verwenden, befolgen Sie diesen empfohlenen Prozess:

  1. Konfigurieren Sie das Clientsubnetz so, dass die erforderlichen Sicherheitsregeln verwendet werden:

    1. Erstellen Sie eine benutzerdefinierte Sicherheitsliste für das Clientsubnetz, und fügen Sie die unter Speziell für das Clientnetzwerk erforderliche Regeln aufgeführten Regeln hinzu.

    2. Verknüpfen Sie die folgenden beiden Sicherheitslisten mit dem Clientsubnetz:

      • Standardsicherheitsliste des VCN mit allen Standardregeln. Diese ist automatisch im VCN enthalten. Sie enthält standardmäßig die unter Für Clientnetzwerk und Backupnetzwerk erforderliche Regeln aufgeführten Regeln.
      • Die neue benutzerdefinierte Sicherheitsliste, die Sie für das Clientsubnetz erstellt haben.

  2. Konfigurieren Sie das Backupsubnetz so, dass die erforderlichen Sicherheitsregeln verwendet werden:

    1. Erstellen Sie eine benutzerdefinierte Sicherheitsliste für das Backupsubnetz, und fügen Sie die unter Speziell für das Backupnetzwerk erforderliche Regel aufgeführten Regeln hinzu.

    2. Verknüpfen Sie die folgenden beiden Sicherheitslisten mit dem Backupsubnetz:

      • Standardsicherheitsliste des VCN mit allen Standardregeln. Diese ist automatisch im VCN enthalten. Sie enthält standardmäßig die unter Für Clientnetzwerk und Backupnetzwerk erforderliche Regeln aufgeführten Regeln.
      • Die neue benutzerdefinierte Sicherheitsliste, die Sie für das Backupsubnetz erstellt haben.

Wenn der Datenbankadministrator später die Exadata Cloud Service-Instanz erstellt, muss er verschiedene Netzwerkkomponenten auswählen. Wenn er das Clientsubnetz und das Backupsubnetz auswählt, die Sie bereits erstellt und konfiguriert haben, werden die Sicherheitsregeln automatisch für die in diesen Subnetzen erstellten Knoten durchgesetzt.

WARNUNG:

Entfernen Sie die Standard-Egress-Regel nicht aus der Standardsicherheitsliste. Andernfalls müssen Sie stattdessen die folgende Ersatz-Egress-Regel in die Sicherheitsliste des Clientsubnetzes einfügen:

  • Zustandslos: Nein (alle Regeln müssen zustandsbehaftet sein)
  • Zieltyp: CIDR
  • Ziel-CIDR: 0.0.0.0/0
  • IP-Protokoll: Alle

Netzwerkanforderungen für Oracle Database Autonomous Recovery Service

Oracle Database Autonomous Recovery Service erfordert ein registriertes Recovery-Servicesubnetz, das für Backup- und Recovery-Vorgänge in Ihrem virtuellen Datenbank-Cloud-Netzwerk (VCN) dediziert ist.

Um Recovery Service für Backups zu verwenden, führen Sie die unter Recovery Service konfigurieren beschriebenen Schritte aus.

Verwandte Themen

Übergeordnetes Thema: Netzwerksetup für Exadata Cloud Infrastructure-Instanzen

Servicegateway zu Object Storage erstellen

Erstellen Sie in der OCI-Konsole ein Servicegateway zu Object Storage. Das Servicegateway ist für Automatisierungsupdates und Konfigurationsmetadaten erforderlich.

  1. Öffnen Sie das Navigationsmenü. Klicken Sie auf Networking, Virtuelle Cloud-Netzwerke.
  2. Wählen Sie das VCN aus, in dem sich die zu sichernden Datenbankservices befinden.
  3. Klicken Sie auf der daraufhin angezeigten Seite Details zum virtuellen Cloud-Netzwerk unter Ressourcen auf Servicegateways.
  4. Klicken Sie auf Servicegateway erstellen, und geben Sie die folgenden Details an.
    1. Name: Ein beschreibender Name für das Servicegateway. Er muss nicht eindeutig sein. Geben Sie dabei keine vertraulichen Informationen ein.
    2. Compartment: Das Compartment, in dem Sie das Servicegateway erstellen möchten, wenn es sich von dem Compartment unterscheidet, in dem Sie derzeit arbeiten.
    3. Services: Wählen Sie das Service-CIDR-Label All <region> Services in Oracle Services Network aus der Dropdown-Liste aus.
    4. Tags: (erweiterte Option) Wenn Sie berechtigt sind, eine Ressource zu erstellen, sind Sie auch berechtigt, Freiformtags auf diese Ressource anzuwenden. Um ein definiertes Tag zuzuweisen, benötigen Sie die Berechtigungen zum Verwenden des Tag-Namespace. Weitere Informationen zum Tagging finden Sie unter Ressourcentags. Wenn Sie nicht sicher sind, ob Sie Tags anwenden sollten, überspringen Sie diese Option, oder fragen Sie Ihren Administrator. Sie können die Tags auch später noch anwenden.

  5. Klicken Sie auf Servicegateway erstellen.

    Warten Sie, bis das Gateway erstellt wurde, bevor Sie mit dem nächsten Schritt fortfahren.

  6. Klicken Sie unter Ressourcen auf Routentabellen.

    Routentabellenverknüpfung: Sie können eine bestimmte VCN-Routentabelle mit diesem Gateway verknüpfen. Wenn Sie eine Routentabelle verknüpfen, muss das Gateway danach immer mit einer Routentabelle verknüpft sein. Sie können die Regeln in der aktuellen Routentabelle ändern oder sie durch eine andere Routentabelle ersetzen.

  7. Klicken Sie auf den Namen der Routentabelle, der vom Subnetz für Recovery Service verwendet wird.

  8. Klicken Sie auf der daraufhin angezeigten Seite Routentabellendetails im Abschnitt Routingregeln auf Hinzufügen.

    Wenn Sie ein Servicegateway für ein bestimmtes Service-CIDR-Label konfigurieren, müssen Sie auch eine Routingregel erstellen, die dieses Label als Ziel und als Ziel das Servicegateway angibt. Führen Sie diesen Schritt für alle Subnetze aus, die auf das Gateway zugreifen müssen.

  9. Geben Sie im daraufhin angezeigten Dialogfeld Routingregeln hinzufügen die folgenden Details ein:
    1. Zieltyp: Servicegateway.
    2. Zielservice: Das Service-CIDR-Label, das für das Gateway aktiviert ist. All <region> Services in Oracle Services Network
    3. Zielservicegateway: Wählen Sie den Namen aus, den Sie in Schritt 4 angegeben haben.
    4. Beschreibung: Eine optionale Beschreibung der Regel.
  10. Klicken Sie auf Routingregeln hinzufügen.