Oracle Cloud Infrastructure-Dokumentation

Oracle Exadata Database Service auf Exascale-Infrastruktur vorbereiten

Prüfen Sie die OCI- sowie die Standort-, Netzwerk- und Speicheranforderungen, um Oracle Exadata Database Service auf Exascale-Infrastruktur in Ihrem Data Center vorzubereiten und bereitzustellen.

Oracle Cloud Infrastructure-(OCI-)Anforderungen für Oracle Exadata Database Service auf Exascale-Infrastruktur

Hier lernen Sie die Grundkonzepte für die ersten Schritte mit Oracle Cloud Infrastructure kennen.

Oracle Exadata Database Service auf Exascale-Infrastruktur wird von der Control Plane von Oracle Cloud Infrastructure (OCI) verwaltet. Die Oracle Exadata Database Service on Exascale-Infrastrukturressourcen werden im OCI-Mandanten bereitgestellt.

Bevor Sie Oracle Exadata Database Service auf Exascale-Infrastrukturinfrastruktur bereitstellen können, muss Ihr Oracle Cloud Infrastructure-Mandant für die Verwendung von Oracle Exadata Database Service auf Exascale-Infrastruktur aktiviert werden. Weitere Einzelheiten finden Sie in den entsprechenden Abschnitten dieser Dokumentation.

Die folgenden Aufgaben werden für alle OCI-Deployments häufig verwendet. In den Links zu den zugehörigen Themen ist die zugehörige Oracle Cloud Infrastructure-Dokumentation aufgeführt.

  • Erste Schritte mit OCI

    Wenn Sie noch nie mit OCI gearbeitet haben, machen Sie sich mit den unter Erste Schritte mit OCI beschriebenen Grundkonzepten vertraut.

  • Mandanten einrichten

    Nachdem Oracle Ihren Mandanten in OCI erstellt hat, muss ein Administrator in Ihrem Unternehmen einige Setupaufgaben ausführen und einen Organisationsplan für Ihre Cloud-Ressourcen und Benutzer einrichten. Die Informationen in diesem Thema erleichtern Ihnen den Einstieg.

  • Regionen verwalten

    In diesem Thema werden die Grundlagen der Verwaltung von Regionsabonnements beschrieben.

  • Compartments verwalten

    In diesem Thema werden die Grundlagen der Arbeit mit Compartments beschrieben.

  • Benutzer verwalten

    In diesem Thema werden die Grundlagen der Arbeit mit Benutzern beschrieben.

  • Gruppen verwalten

    In diesem Thema werden die Grundlagen der Arbeit mit Gruppen beschrieben.

Verwandte Themen

Übergeordnetes Thema: Oracle Exadata Database Service auf Exascale-Infrastruktur vorbereiten

Erforderliche IAM-Policy für Oracle Exadata Database Service auf Exascale-Infrastruktur

Prüfen Sie die IAM}-Policy zum Provisioning von Oracle Exadata Database Service on Exascale-Infrastruktursystemen.

Eine Policy ist ein IAM-Dokument, das angibt, wer welchen Zugriff auf Ihre Ressourcen hat. Der Begriff wird mit unterschiedlichen Bedeutungen verwendet:
  • Eine einzelne in der Policy-Sprache geschriebene Anweisung
  • Eine Sammlung von Anweisungen in einem benannten "Policy"-Dokument, dem eine Oracle Cloud-ID (OCID) zugewiesen ist
  • Der gesamte Policy-Text, mit dem Ihre Organisation den Zugriff auf Ressourcen steuert

Ein Compartment ist eine Sammlung aus zusammengehörigen Ressourcen, auf die nur bestimmte Gruppen zugreifen können, denen ein Administrator in Ihrer Organisation eine Berechtigung erteilt hat.

Damit Sie Oracle Cloud Infrastructure verwenden können, müssen Sie den erforderlichen Zugriffstyp in einer von einem Administrator geschriebenen Policy erhalten, unabhängig davon, ob Sie die Konsole, die REST-API mit einem Software Development Kit (SDK), eine Befehlszeilenschnittstelle (CLI) oder ein anderes Tool verwenden. Wenn Sie beim Versuch, eine Aktion auszuführen, eine Meldung erhalten, dass Sie keine Berechtigung haben oder nicht autorisiert sind, fragen Sie den Mandantenadministrator, welche Art von Zugriff Ihnen erteilt wurde und in welchem Compartment Sie arbeiten sollten.

Für Administratoren: Mit der Policy in "Verwalten von DB-Systemen durch Datenbankadministratoren zulassen" kann die angegebene Gruppe alle Vorgänge mit Datenbanken und zugehörigen Datenbankressourcen durchführen.

Wenn Sie mit Policys nicht vertraut sind, finden Sie weitere Informationen unter "Erste Schritte mit Policys" und "Allgemeine Policys". Wenn Sie mehr über das Verfassen von Policys für Datenbanken erfahren möchten, lesen Sie "Details zum Database-Service".

Weitere Einzelheiten zum Schreiben von Policys, die für Exadata Cloud@Customer-Ressourcen spezifisch sind, finden Sie unter "Policy-Details für Oracle Exadata Database Service on Exascale-Infrastruktur".

Netzwerksetup für Oracle Exadata Database Service auf Exascale-Infrastrukturinstanzen

In diesem Thema werden die empfohlene Konfiguration für das VCN sowie verschiedene zugehörige Anforderungen für die Oracle Exadata Database Service on Exascale-Infrastrukturinstanz beschrieben.

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

Übergeordnetes Thema: Oracle Exadata Database Service auf Exascale-Infrastruktur vorbereiten

VCN und Subnetze

Um ein Oracle Exadata Database Service on Exascale-Infrastruktur-VM-Cluster zu starten, benötigen Sie ein virtuelles Cloud-Netzwerk und mindestens zwei Subnetze.

Um ein Oracle Exadata Database Service-On-Exascale-Infrastruktur-VM-Cluster zu starten, benötigen Sie ein virtuelles Cloud-Netzwerk und mindestens zwei Subnetze. Wählen Sie dann den Typ des zu verwendenden DNS-Resolvers aus:

  • Ein VCN in der Region, in der das Oracle Exadata Database Service auf dem VM-Cluster der Exascale-Infrastruktur angezeigt werden soll

  • Mindestens zwei Subnetze im VCN. Die beiden Subnetze sind:

    • Clientsystem
    • Backupsystem
  • Wählen Sie die Methode der DNS-Namensauflösung aus, die Sie verwenden möchten. Siehe Optionen für DNS im VCN

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 (für die Cloud-VM-Clusterressource werden Knoten als virtuelle Maschinen bezeichnet). Nachfolgend finden Sie weitere Informationen zu diesen Elementen.

Verwandte Themen

Übergeordnetes Thema: Netzwerksetup für Oracle Exadata Database Service auf Exascale-Infrastrukturinstanzen

Option 1: Öffentliches Clientsubnetz mit Internetgateway

Diese Option kann bei einem Proof of Concept oder Entwicklungsarbeit 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 einrichten:

  • Subnetze:

    • Ein öffentliches Clientsubnetz (öffentlich bedeutet, dass die Ressourcen im Subnetz nach Ihrem Ermessen öffentliche IP-Adressen haben können).
    • Ein privates Backupsubnetz (Privat bedeutet, dass die Ressourcen im Subnetz keine öffentlichen IP-Adressen haben und daher keine eingehenden Verbindungen aus dem Internet empfangen können).

  • Gateways für das VCN:

  • Routentabellen:

    • Eine benutzerdefinierte Routentabelle für das öffentliche Clientsubnetz mit einer Route für 0.0.0.0/0 und dem Internetgateway als Ziel.
    • Eine separate benutzerdefinierte Routentabelle für das private Backupsubnetz mit einer Routingregel für die Service-CIDR-Labels (Informationen zu CIDR-Labels finden Sie unter Servicegateways - Überblick und "Verfügbare Service-CIDR-Labels") und dem Servicegateway als Ziel.
  • Sicherheitsregeln, um den gewünschten Traffic zu und von den Compute Nodes der virtuellen Exadata-Maschinen zu ermöglichen.
  • Knotenzugriff auf Object Storage: Statische Route auf den Compute Nodes der Exadata Cloud Service-Instanz (um den Zugriff auf OCI-Services über das Backupsubnetz zu ermöglichen).
Hinweis

Dieses bekannte Problem enthält Informationen zur Konfiguration von Routingregeln mit 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 einrichten:

  • 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 DRG als Ziel.
      • Eine Regel für das Service-CIDR-Label mit dem Namen All <region> Services in Oracle Services Network mit dem Servicegateway als Ziel. 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 mit dem NAT-Gateway als Ziel.
    • Eine separate benutzerdefinierte Routentabelle für das private Backupsubnetz mit einer Regel:
      • Identische Regel wie für das Clientsubnetz: für das Service-CIDR-Label mit dem Namen All <region> Services in Oracle Services Network mit dem Servicegateway als Ziel. 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

Sie müssen ein VCN mit zwei Subnetzen erstellen und sicherstellen, dass genügend Adressen für die Größe Ihres VM-Clusters vorhanden sind.

Hinweis

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

Wenn Sie 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.

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. Der Networking-Service reserviert drei IP-Adressen in jedem Subnetz.

Verwenden Sie die folgende Formel, um die Mindestanzahl von IP-Adressen zu berechnen, wobei die Variable n der Anzahl der VMs im VM-Cluster entspricht:

Die Mindestanzahl an Clientadressen = 4*n+6

Die Mindestanzahl von Backupadressen = 3*n+3

Hinweis

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 Speicherplatz im Subnetz reduzieren. Um zukünftiges Wachstum zu planen, fügen Sie Adressen hinzu, die Sie beim vertikalen Skalieren Ihres VM-Clusters benötigen, und nicht nur die Anzahl der VMs, die Sie für sofortige Anforderungen bereitstellen möchten.

Übergeordnetes Thema: VCN und Subnetze

Statische Routen für den Zugriff auf den Objektspeicher konfigurieren
Der gesamte Traffic in einer Oracle Exadata Database Service on Exascale-Infrastrukturinstanz 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 Oracle Exadata Database Service on Exascale-Infrastrukturinstanz 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 Oracle Exadata Database Service auf Exascale-Infrastrukturinstanz
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 erforderlichen wichtigen Serviceendpunkte sowie das Patching und Update des Cloud-Toolings in einer Oracle Exadata Database Service on Exascale-Infrastrukturinstanz. 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
  • Hostnamenpräfix für das Cloud-VM-Cluster oder die DB-Systemressource der Oracle Exadata Database Service on Exascale-Infrastrukturinstanz

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 Hostnamenspräfix zu, wenn Sie das Cloud-VM-Cluster oder DB-System 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
  • usw.

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.

  • 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.

Ü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.

Privates DNS konfigurieren

Prüfen Sie die Voraussetzungen für die Verwendung von Private DNS.

  • Bevor das Provisioning des DB-Systems gestartet wird, müssen eine private Ansicht und eine private Zone erstellt werden. Details 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 Oracle Exadata Database Service on Exascale Infrastructure-Instanz patchen und aktualisieren zu können, empfiehlt Oracle, dass Sie Autonomous Recovery Service konfigurieren. Unabhängig davon, wie Sie das VCN mit diesem Zugriff konfigurieren (z.B. mit einem Servicegateway), müssen Sie bei Verwendung von Object Storage möglicherweise auch eine statische Route zu Object Storage auf jedem Compute Node im Cluster 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.
Hinweis

Ab dem 06. August 2025 ist Autonomous Recovery Service für Mandanten, die in den FRA-, PHX- oder NRT-Regionen erstellt wurden, das einzige Backupziel, wenn Sie das automatische Backup in Datenbanken aktivieren.

Achtung:

Sie müssen eine statische Route für den Object Storage-Zugriff auf jedem Compute Node in einer Oracle Exadata Database Service on Exascale-Infrastrukturinstanz 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 eine SSH-Verbindung zu einem Compute Node in der Oracle Exadata Database Service on Exascale-Infrastrukturinstanz 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 Oracle Exadata Database Service on Exascale-Infrastrukturinstanz.

Servicegateway für das VCN

Das VCN erfordert Zugriff auf Object Storage für Backups und auf Oracle YUM-Repositorys für BS-Updates.

Übergeordnetes Thema: Netzwerksetup für Oracle Exadata Database Service auf Exascale-Infrastrukturinstanzen

Option 1: Servicegatewayzugriff auf OCI-Services

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, das Netzwerksetup mit einem öffentlichen Clientsubnetz:

Diese Abbildung zeigt das Netzwerksetup mit einem öffentlichen Clientsubnetz, wie zuvor beschrieben.

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 das Servicegateway als Ziel.
  • 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, bei der der Zielservice auf OCI <region> Object Storage gesetzt ist. Siehe "Speziell für das Backupnetzwerk erforderliche Regel.
Option 2: Servicegatewayzugriff auf Object Storage und YUM-Repositorys

Sie konfigurieren sowohl das Clientsubnetz als aber auch das Backupsubnetz so, dass das Servicegateway für den Zugriff auf das Oracle Services Network verwendet wird, einschließlich Object Storage und den Oracle YUM-Repositorys.

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, ein Netzwerksetup mit privaten Subnetzen:

Diese Abbildung zeigt das Netzwerksetup mit privaten Clientsubnetzen, wie zuvor beschrieben.

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 All <region> Services in Oracle Services Network.
  • Fügen Sie beim Aktualisieren des Routings eine Regel zur benutzerdefinierten Routentabelle jedes Subnetzes hinzu. Verwenden Sie als Zielservice All <region> Services in Oracle Services Network und das Servicegateway als Ziel.
  • 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, bei der der Zielservice auf OCI <region> Object Storage gesetzt ist. Siehe Sicherheitsregeln. 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:

Hinweis

Ab dem 06. August 2025 ist Autonomous Recovery Service für Mandanten, die in den FRA-, PHX- oder NRT-Regionen erstellt wurden, das einzige Backupziel, wenn Sie das automatische Backup in Datenbanken aktivieren.
  • Das Clientsubnetz und das Backupsubnetz verwenden beide das Servicegateway, greifen jedoch auf unterschiedliche Services zu. Sie können die Service-CIDR-Labels OCI <region> Object Storage und All <region> Services in Oracle Services Network nicht beide für das Servicegateway aktivieren. Um die Anforderungen beider Subnetze zu erfüllen, 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. Für Option 2 bedeutet dies, dass 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 enthält, die All <region> Services in Oracle Services Network verwendet, kann das Subnetz daher eine Sicherheitsregel enthalten, die OCI <region> Object Storage verwendet. Siehe Sicherheitsregeln für die Exadata Cloud Service-Instanz.

Sicherheitsregeln für Oracle Exadata Database Service auf Exascale-Infrastruktur

In diesem Abschnitt werden die Sicherheitsregeln aufgeführt, die mit Oracle Exadata Database Service on Exascale Infrastructure verwendet werden sollen.

Sicherheitsregeln kontrollieren die Traffictypen, die für das Clientnetzwerk und das Backupnetzwerk der virtuellen Maschinen 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.

Für Clientnetzwerk und Backupnetzwerk erforderliche Regeln

Es gibt 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
  • 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
  • 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
  • Quell-CIDR: Das CIDR Ihres VCN
  • IP-Protokoll: ICMP
  • Typ: 3
  • 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
  • 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-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 die TCP-Konnektivität auf allen Knoten ausfällt, kann das Exadata Cloud-VM-Cluster oder die DB-Systemressource nicht durch Provisioning bereitgestellt werden.

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: CIDR 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: CIDR des Clientsubnetzes
  • IP-Protokoll: TCP
  • Quellportbereich: Alle
  • Zielportbereich: 1521
  • Beschreibung: Eine optionale Beschreibung der Regel.

Client-Ingress-Regel 3: Patching von Traffic aus dem Clientsubnetz zulassen

  • Zustandslos: Nein (alle Regeln müssen zustandsbehaftet sein)
  • Quelltyp: CIDR
  • Quell-CIDR: CIDR des Clientsubnetzes
  • IP-Protokoll: TCP
  • Quellportbereich: Alle
  • Zielportbereich: 7085
  • Beschreibung: Fügen Sie optional eine aussagekräftige Beschreibung der Regel hinzu. Beispiel: "Zugriff auf den privaten Endpunkt für Exadata-Flottenaktualisierung im Subnetz zulassen".

Client-Egress-Regel 1: Sämtlichen TCP-Traffic innerhalb des Clientsubnetzes zulassen

  • Zustandslos: Nein (alle Regeln müssen zustandsbehaftet sein)
  • Zieltyp: CIDR
  • Ziel-CIDR:0.0.0.0/0
  • 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 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
  • IP-Protokoll: Alle
  • Beschreibung: Eine optionale Beschreibung der Regel.

Erforderliche IAM-Policys für Oracle Database- und Oracle Grid Infrastructure-Patching

Erteilen Sie den Benutzern oder Gruppen, die die Datenbank und Oracle Grid Infrastructure verwalten, Identity and Management-(IAM-)Policys für den Zugriff auf Subnetze, virtuelle Netzwerkkarten (vNICs) und private IP-Adressen (Private-IPs). Beispiel: Die Gruppe admin-group verwaltet Compartment ABC. In diesem Fall richten Sie die folgenden Policys ein:

  • Verwendung von Subnetzen in Compartment ABC durch Gruppe admin-group zulassen
  • Zulassen, dass die Gruppe admin-group vNICs in Compartment ABC verwendet
  • Verwendung von Private-IPs in Compartment "ABC" durch Gruppe admin-group zulassen

Speziell für das Backupnetzwerk erforderliche Regel

Die folgende Sicherheitsregel ist für das Backupnetzwerk wichtig, da sie die Kommunikation des DB-Systems 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 Oracle Exadata Database Service auf Exascale-Infrastrukturinstanzen

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-CIDR die öffentliche IP-Adresse des Clients verwenden.
  • 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 die TCP-Konnektivität auf allen Knoten ausfällt, kann das Exadata Cloud-VM-Cluster oder die DB-Systemressource nicht durch Provisioning bereitgestellt werden.

Übergeordnetes Thema: Sicherheitsregeln für Oracle Exadata Database Service on Exascale 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: IPv6-CIDR 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: IPv6-CIDR 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 DB-Systems 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 1: Sämtlichen Egress-Traffic zulassen (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.

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 Oracle Exadata Database Service auf Exascale-Infrastrukturinstanzen

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:

    • Die Regeln, die unter "Für Clientnetzwerk und Backupnetzwerk erforderliche Regeln aufgeführt sind"
    • Die Regeln, die unter "Spezifisch für das Clientnetzwerk erforderliche Regeln aufgeführt sind"

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

    • Die Regeln, die unter "Für Clientnetzwerk und Backupnetzwerk erforderliche Regeln aufgeführt sind"
    • Die Regeln, die unter "Spezifisch für das Clientnetzwerk erforderliche Regeln aufgeführt sind"
  3. Wenn Sie als Datenbankadministrator eine Exadata-Instanz in Exadata Database Service on Exascale Infrastructure erstellen, müssen Sie verschiedene Netzwerkkomponenten auswählen (z.B. das zu verwendende VCN und die zu verwendenden Subnetze):
    • Wenn Sie das Clientsubnetz auswählen, können Sie auch die zu verwendenden NSGs auswählen. Wählen Sie die NSG des Clientnetzwerks aus.
    • Wenn Sie das Backupsubnetz auswählen, können Sie auch die zu verwendenden NSGs auswählen. Wählen Sie die NSG des Backupnetzwerks aus.

Stattdessen können Sie auch eine separate NSG für die allgemeinen Regeln erstellen. Wenn Datenbankadministratoren dann die zu verwendenden NSGs für das Clientnetzwerk auswählen, wählen sie sowohl die allgemeine NSG als auch die NSG des Clientnetzwerks aus. 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 Oracle Exadata Database Service auf Exascale-Infrastrukturinstanzen

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.

Hinweis

Ab dem 06. August 2025 ist Autonomous Recovery Service für Mandanten, die in den FRA-, PHX- oder NRT-Regionen erstellt wurden, das einzige Backupziel, wenn Sie das automatische Backup in Datenbanken aktivieren.
  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.

Serviceübergreifende Interoperabilität zwischen ExaDB-D und ExaDB-XS: Data Guard, Backup und Restore

Sie können jetzt eine serviceübergreifende Oracle Data Guard-Gruppe für alle Datenbankservices erstellen.

Mit dieser Funktion können Sie serviceübergreifende Backup- und Restore-Funktionen für die folgenden Konfigurationen einrichten:  

  • Primärdatenbank auf ExaDB-D mit einer oder mehreren Standbydatenbanken auf ExaDB-XS oder ExaDB-D.
  • Primärdatenbank auf ExaDB-XS mit einer oder mehreren Standbydatenbanken auf ExaDB-D oder ExaDB-XS.
Hinweis

Zum Zeitpunkt dieses Release kann Oracle Data Guard zwischen Exadata Database Service on Dedicated Infrastructure und Exadata Database Service on Exascale Infrastructure nur mit dem Oracle Database 23ai-Release konfiguriert werden.

Mit dieser Funktion können Sie das Potenzial Ihrer Datenbankservices in Ihrem Mandanten nutzen.

Hinweis

Um maximale Verfügbarkeit sicherzustellen, empfiehlt Oracle, dass Sie Ihre Peer-VM-Cluster in einer anderen Exadata-Infrastruktur als das primäre VM-Cluster platzieren.

Konfigurationsoptionen für Standbydatenbank

Beim Hinzufügen einer Standbydatenbank können Sie die folgenden Details angeben:

  • Peer-VM-Clusterdetails: Wenn das Ziel ExaDB-D lautet, können Sie die Exadata-Infrastruktur auswählen.
  • Zielserviceauswahl: Wählen Sie entweder ExaDB-D oder ExaDB-XS aus. Standardmäßig ist der Service, der die Data Guard-Gruppe initiiert, ausgewählt. Wenn ein Service in der ausgewählten Region nicht verfügbar ist, wird er mit der Meldung "Service ist in dieser Region nicht verfügbar" deaktiviert.
  • Data Guard-Typ: Die Gruppe kann mit Data Guard oder Active Data Guard konfiguriert werden, und jede Standbydatenbank kann einen anderen Typ aufweisen.
  • Einschränkung der Data Guard-Gruppe: Eine Primärdatenbank ist auf eine Data Guard-Gruppe beschränkt.
  • Standbydatenbank erstellen: Es kann jeweils nur eine Standbydatenbank hinzugefügt werden. Standbydatenbanken können jedoch in einer der folgenden Kategorien ohne Einschränkung ihrer Anzahl erstellt werden:
    • Innerhalb desselben Service
    • Servicesübergreifend
    • Innerhalb derselben Availability-Domain (AD)
    • In allen Availability-Domains innerhalb derselben Region
    • Regionenübergreifend

Wichtige Überlegungen für serviceübergreifende Primär- und Standbydatenbanken

  • Sowohl die Primär- als auch die Standbydatenbank müssen dieselbe Schlüsselverwaltungslösung verwenden.
  • Data Guard kann im Schutzmodus "Max. Performance" oder "Max. Verfügbarkeit" mit dem Transporttyp "Sync" oder "Async" konfiguriert werden. Dabei gelten folgende Regeln:
    • Für die erste Standby-Datenbank:
      • Standard ist der Modus "Max. Performance" mit asynchronem Transport.
      • Schutzart und Transportart können nicht geändert werden.
    • Für die zweite und nachfolgende Standby-Datenbank:
      • Erbt den Schutzmodus aus der ersten Standbydatenbank.
      • Standard ist asynchroner Transport.
      • Schutzart und Transportart können nicht geändert werden.

Data Guard-Konfigurationen anzeigen und bearbeiten

  • Zeigen Sie alle Datenbanken an, die Teil der Data Guard-Gruppe in der Data Guard-Gruppentabelle sind, unabhängig davon, ob Sie sich auf den Seiten der Primär- oder der Standbydatenbank befinden.
  • Bearbeiten Sie die Data Guard-Konfiguration, um sie zu aktualisieren:
    • Data Guard-Typ: Kann für jede Standbydatenbank unterschiedlich sein. Dies kann nur aus einer Standbydatenbank geändert werden.
    • Datenbankadministratorkennwort: Kann von jeder Datenbank aus bearbeitet werden.
    • Schutzmodus: Kann von der Primär- oder einer Standbydatenbank zwischen "Max. Performance" und "Max. Verfügbarkeit" umgeschaltet werden.
    • Transporttyp: Kann nur von einer Standbydatenbank zwischen "Async" und "Sync" umgeschaltet werden.
Hinweis

Wenn der Schutzmodus auf "Max. Verfügbarkeit" gesetzt ist, prüft das System, ob mindestens eine Standbydatenbank den Sync-Transport verwendet. Wenn diese Option nicht gefunden wurde, wird eine Fehlermeldung angezeigt:

"Um keinen Datenverlust zu erzielen, benötigen Sie mindestens eine Standbydatenbank mit Sync-Transport. Es wird empfohlen, eine Standbydatenbank mit Sync-Transport im selben Service wie die Primärdatenbank zu haben."

Switchover und Failover von Datenbanken

  • Switchover (auf jeder Standbydatenbank)
    • Switchover wird ausgeführt, ohne dass eine Prüfung der Hauptversion oder des Releaseupdates (RU) durchgesetzt wird. Eine Warnung wird jedoch angezeigt, wenn die Standbydatenbank asymmetrisch konfiguriert ist, wie z.B. unterschiedliche Knotenanzahl, Arbeitsspeicher oder Servicetyp.
  • Failover (auf jeder Standbydatenbank)
    • Failover wird ausgeführt, ohne dass eine Prüfung der Hauptversion oder des Releaseupdates (RU) durchgesetzt wird. Eine Warnung wird jedoch angezeigt, wenn die Standbydatenbank eine asymmetrische Konfiguration aufweist, wie z.B. unterschiedliche Knotenanzahl, Arbeitsspeicher oder Servicetyp.

Backup- und Wiederherstellungsoptionen für Datenbanken

Hinweis

Ab dem 06. August 2025 ist Autonomous Recovery Service für Mandanten, die in den FRA-, PHX- oder NRT-Regionen erstellt wurden, das einzige Backupziel, wenn Sie das automatische Backup in Datenbanken aktivieren.

  • Geplante und automatische Backups
    • Sie können automatische Backups für die Primärdatenbank, die Standbydatenbank oder beides planen.
    • Sowohl Object Storage- als auch Recovery Service-Backups werden unterstützt.
    • Wenn Backups sowohl in der Primär- als auch in der Standbydatenbank konfiguriert sind, müssen sie denselben Backupzieltyp verwenden.
  • In-Place-Wiederherstellung derselben Datenbank in ExaDB-XS
    Stellen Sie eine Datenbank mit einem Backup wieder her, das aus derselben Datenbank in ExaDB-XS erstellt wurde:
    • Stellen Sie die Primärdatenbank mit einem Backup wieder her, das in der Primärdatenbank erstellt wurde.
    • Stellen Sie die Standbydatenbank mit einem Backup wieder her, das in der Standbydatenbank erstellt wurde.
  • In-Place-Wiederherstellung einer Peerdatenbank in ExaDB-XS
    Wiederherstellen und Wiederherstellen einer Peerdatenbank (für die keine Backups konfiguriert sind) mit einem Backup aus der Quelldatenbank mit Recovery Service:
    • Szenario 1: Stellen Sie die Primärdatenbank mit dem Standbybackup wieder her.
      • Primäre Datenbank: ExaDB-XS (keine Backups konfiguriert)
      • Standbydatenbank: ExaDB-XS (für Recovery Service konfigurierte Backups)
    • Szenario 2: Stellen Sie die Standbydatenbank mit dem primären Backup wieder her.
      • Primäre Datenbank: ExaDB-XS (für Recovery Service konfigurierte Backups)
      • Standbydatenbank: ExaDB-XS (keine Backups konfiguriert)
  • In-Place-Wiederherstellung einer Peerdatenbank über Services hinweg
    Stellen Sie eine Datenbank in ExaDB-XS oder ExaDB-D mit einem Backup aus der Quelldatenbank im anderen Service (ExaDB-D oder ExaDB-XS) mit Recovery Service wieder her, und stellen Sie sie wieder her:
    • Szenario 1: Stellen Sie eine Peerdatenbank in ExaDB-XS mit einem Backup aus ExaDB-D wieder her
      • Anwendungsfall 1: Stellen Sie die Primärdatenbank mit dem Standbybackup wieder her.
      • Anwendungsfall 2: Stellen Sie die Standbydatenbank mit dem primären Backup wieder her.
    • Szenario 2: Stellen Sie eine Peerdatenbank in ExaDB-D mit einem Backup aus ExaDB-XS wieder her.
      • Anwendungsfall 1: Stellen Sie die Primärdatenbank mit dem Standbybackup wieder her.
      • Anwendungsfall 2: Stellen Sie die Standbydatenbank mit dem primären Backup wieder her.

Out-of-Place-Restore (Neue Datenbank erstellen)

  • Innerhalb von ExaDB-XSSie können eine neue Datenbank in ExaDB-XS mit einem Backup aus demselben Service erstellen.
    • Wiederherstellen innerhalb:
      • Dieselbe Availability-Domain (AD)
      • Eine andere AD innerhalb derselben Region
      • Eine andere Region
    • Unterstützt Object Storage oder Recovery Service als Backupziel.
  • Serviceübergreifend
    • Szenario 1: Neue Datenbank in ExaDB-D mit einem Backup aus ExaDB-XS erstellen
      • Quelle: ExaDB-XS (Datenbank und Backups)
      • Ziel: ExaDB-D (jede Region oder AD)
      • Backupziel: Object Storage oder Recovery Service
    • Szenario 2: Neue Datenbank in ExaDB-XS mit einem Backup aus ExaDB-D erstellen
      • Quelle: ExaDB-D (Datenbank und Backups)
      • Ziel: ExaDB-XS (jede Region oder AD)
      • Backupziel: Object Storage oder Recovery Service