Autonome KI-Datenbank mit Referenzarchitektur konfigurieren

Dieser Anwendungsfall zeigt, wie Sie Ihre autonomen KI-Datenbankressourcen auf einer dedizierten Exadata-Infrastruktur konfigurieren, um ihre Funktionen besser nutzen zu können. Dies ist eine umfassende und empfohlene Konfiguration, bei der die Referenzarchitektur der Autonomous AI Database on Dedicated Exadata Infrastructure genutzt wird.

Oracle Autonomous AI Database on Dedicated Exadata Infrastructure ist eine hochautomatisierte, vollständig verwaltete Datenbankumgebung, die in Oracle Cloud Infrastructure (OCI) mit festgeschriebenen Hardware- und Softwareressourcen ausgeführt wird. Diese isolierten Ressourcen ermöglichen es Unternehmen, strenge Sicherheits-, Verfügbarkeits- und Performanceanforderungen zu erfüllen und gleichzeitig Kosten und Komplexität zu reduzieren.

Tipp:

Informationen zum schnellen Konfigurieren einer POC-Umgebung für autonome KI-Datenbanken finden Sie unter Autonome KI-Datenbank für Proof of Concept (POC) konfigurieren.

Vorausgesetzte Kenntnisse

Um diesen Anwendungsfall vollständig zu verstehen und zu würdigen, sollten Sie über grundlegende Kenntnisse der Autonomous AI Database on Dedicated Exadata Infrastructure verfügen, einschließlich der Deployment-Optionen, der wichtigsten Infrastrukturkomponenten, der Benutzerrollen und der Hauptfeatures. Weitere Informationen finden Sie unter Info zu Autonomous AI Database on Dedicated Exadata Infrastructure.

Verwandte Themen

Anwendungsfall

Acme Company hat sich für die Verwendung von Autonomous AI Database on Dedicated Exadata Infrastructure für seine internen Projektanwendungen entschieden. Die Acme I.T.-Abteilung übernimmt die Rolle des Flottenadministrators, der für die Erstellung und Verwaltung von Exadata-Infrastruktur-(EI-) und autonomen Exadata-VM-Cluster-(AVMC-)Ressourcen für das Unternehmen verantwortlich ist. Innerhalb jedes Projektteams oder Geschäftsbereichs übernehmen bestimmte Benutzer die Anwendungs-DBA-Rolle, mit der Aufgabe, autonome Containerdatenbanken (ACD) und autonome KI-Datenbanken für ihre Datenbankbenutzer zu erstellen, darunter Anwendungsentwickler, Tester und Deployer.

Hinweis:

Dieses Beispiel zeigt, wie der Anwendungs-DBA die ACD-Ressourcen erstellt und verwaltet. Ihre Organisation könnte es jedoch vorziehen, dass der Flottenadministrator diese Aufgabe selbst ausführt.

Acme I.T. weist den verschiedenen Teams Ressourcen zu und stellt so die Bereitstellung von AVMCs sicher, die den erforderlichen SLAs entsprechen. Darüber hinaus möchte die IT-Abteilung von Acme keinen Projektteams oder Geschäftsbereichen Verwaltungszugriff auf die zugrunde liegende dedizierte Infrastruktur gewähren, um die Zuweisung von Ressourcen gerecht zu steuern. Darüber hinaus soll die IT-Abteilung von Acme unter Einhaltung gesetzlicher Audits nicht in der Lage sein, auf die Daten verschiedener Projektteams oder Geschäftsbereiche zuzugreifen, d.h. auf die Daten, die in ihren Anwendungsdatenbanken gespeichert sind.

AcmeHR, eine interne HR-Anwendung, die von Acme entwickelt und verwendet wird, ist in zwei unterschiedlichen Umgebungen verfügbar: eine für Entwicklung und Tests (Dev) und eine für Produktion (Prod). Acme I.T. ist bestrebt, eine strenge Isolation zwischen diesen Umgebungen aufrechtzuerhalten, um unbefugten Zugriff oder unbefugte Interaktion zwischen Entwicklungs- und Produktionsteams zu verhindern.

Benötigte Ressourcen

OCI-IAM-Komponenten


Beschreibung von configure-adb-d-resource-isolation.png folgt
Beschreibung der Abbildung configure-adb-d-resource-isolation.png

  • Drei Compartments für Ressourcenisolation wie unten beschrieben:
    • FleetComp für die von Acme I.T. erstellten Ressourcen, das Netzwerk und die privaten Subnetze, die von Entwicklungs- und Produktionsdatenbanken verwendet werden.
    • DevComp für die Entwicklungsdatenbank.
    • ProdComp für die Produktionsdatenbank.
  • Drei Gruppen, denen Benutzer zugewiesen werden können, jeweils eine für Acme I.T., Dev-Benutzer und Prod-Benutzer. Diese Gruppen heißen FAGroup, DevGroup und ProdGroup.
  • Erforderliche Policys, um den Benutzerzugriff auf die Ressourcen auf Compartment- und Mandantenebene anzugeben.

Netzwerkressourcen


Beschreibung von configure-adbd-refarch-network.png folgt
Beschreibung der Abbildung configure-adbd-refarch-network.png

Symbol für Sicherheitsliste stellt eine Sicherheitsliste dar.

  • Oracle Public Cloud-Deployments:

    • Ein VCN für Netzwerkkonnektivität zu allen dedizierten Infrastrukturressourcen. Dieses VCN verbindet sich über ein IPSec-VPN mit dem Acme-Unternehmens-VPN und verfügt über eine Internetgatewayressource, die den gesamten eingehenden Internetverkehr blockiert. Der Name lautet AcmeHRVCN.
    • Drei Subnetze für die Isolierung des Netzwerkzugriffs, jeweils eines für die Autonomous AI Database-Ressourcen der Dev- und Prod-Umgebungen und eines für die Client- und Mid-Tier-Ressourcen der Anwendung. Diese Subnetze werden DevVMSubnet, ProdVMSubnet bzw. AppSubnet genannt.

    Hinweis:

    Der Einfachheit halber verwenden wir ein einzelnes VCN und nutzen Subnetze, um die Netzwerkisolation zu gewährleisten. Sie können jedoch auch mehrere VCNs erstellen, um die erforderliche Netzwerkzugriffsisolation bereitzustellen. In diesem Beispiel erstellen wir aus Gründen der Einfachheit alle drei Subnetze: DevVMSubnet, ProdVMSubnet und AppSubnet unter FleetComp. Je nach Ihren Anforderungen können Sie diese Subnetze optional in separaten Compartments platzieren.

  • Exadata Cloud@Customer-Deployments:

    • Richten Sie Netzwerkregeln ein, wie unter Netzwerkanforderungen für Oracle Exadata Database Service on Cloud@Customer in Exadata Database Service on Cloud@Customer vorbereiten aufgeführt.
    • Öffnen Sie außerdem Port 1522, um TCP-Traffic zwischen der Primärdatenbank und der Standbydatenbank in einem Autonomous Data Guard-Setup zuzulassen.

Autonomous AI Database-Ressourcen


Beschreibung von configure-adb-d-resources.eps folgt
Beschreibung der Abbildung configure-adb-d-resources.eps

Autonome KI-Datenbankressourcen gemäß der oben dargestellten Konfiguration.
  • Eine Exadata-Infrastruktur zum Hosten von zwei AVMCs. Der Name lautet AcmeInfrastructure.
  • Zwei AVMCs innerhalb von AcmeInfrastructure für Entwicklungs- und Produktionsumgebungen. Diese AVMCs heißen DevAVMC bzw. ProdAVMC.
  • DevAVMC:
    • hostet die autonomen Containerdatenbanken und die autonomen KI-Datenbanken mit den Namen DevACD bzw. DevADB zum Entwickeln und Testen der AcmeHR-Anwendung.
    • Immer auf das neueste RU gepatcht (Releaseupdate).
    • Bewahrt Backups von sieben (7) Tagen auf.
    • Für jedes Releaseupdate (RU) oder Patchrelease wird AcmeHR, das auf DevADB bereitgestellt wird, mit der neuesten RU getestet.
    • Bei kritischen Problemen wird ein One-off-Patch angefordert. Nach dem Einspielen des One-off-Patches wird AcmeHR erneut validiert, um sicherzustellen, dass der Code stabil und für die Hochstufung in die Produktion geeignet ist. Weitere Informationen zu One-off-Patches finden Sie unter Wartung des Autonomous AI Database-Service.
  • ProdAVMC:
    • hostet die autonome Containerdatenbank und die autonome KI-Datenbank, die für das Produktions-Deployment der Anwendung AcmeHR bereitgestellt wurden. Sie heißen ProdACD und ProdADB.
    • Wird immer mit der N-1-Softwareversion ausgeführt.
    • Bewahrt Backups länger auf. Bei Bedarf sind auch langfristige Backups aktiviert.
    • Gespeicherte alternative Quartale für die validierte Software, d.h. die in DevAVMC validierten RUs werden in dieser Datenbank bereitgestellt.

Allgemeine Schritte

Bevor Acme I.T. mit der Konfiguration von Autonomous AI Database-Ressourcen auf einer dedizierten Exadata-Infrastruktur beginnt, fordert es eine Erhöhung des Servicelimits über die OCI-Konsole an, um Exadata-Infrastrukturressourcen - Datenbankserver und Speicherserver - zum Mandanten hinzuzufügen. Weitere Informationen finden Sie unter Erhöhung des Servicelimits anfordern.

Im Folgenden werden die allgemeinen Schritte zur Implementierung dieses Anwendungsfalls aufgeführt:

  1. Der Sicherheitsadministrator für den Cloud-Mandanten von Acme Company erstellt die folgenden Compartments, Gruppen und Compartment Policys für die Ressourcenisolierung:
    • Die Compartments FleetComp, DevComp und ProdComp.
    • Die Gruppen FAGroup, DevGroup und ProdGroup.
    • Die Policys FleetCompPolicy, DevCompPolicy und ProdCompPolicy.
  2. Für Zugriffsisolation:
    • Bei Oracle Public Cloud-Deployments erstellt Acme I.T. oder der Netzwerkadministrator für Acme die folgenden Netzwerkressourcen im Compartment FleetComp:
      • VCN: AcmeHRVCN
      • Private Subnetze: DevVMSubnet und ProdVMSubnet
      • Öffentliches Subnetz: AppSubnet
    • Bei Exadata Cloud@Customer-Deployments stellt Acme I.T. oder der Netzwerkadministrator von Acme Folgendes sicher:
      • Richten Sie Netzwerkregeln ein, wie unter Netzwerkanforderungen für Oracle Exadata Database Service on Cloud@Customer in Exadata Database Service on Cloud@Customer vorbereiten aufgeführt.
      • Öffnen Sie Port 1522, um TCP-Traffic zwischen der Primärdatenbank und der Standbydatenbank in einem Autonomous Data Guard-Setup zuzulassen.
  3. Nach dem Erstellen von Netzwerkressourcen fügt der Sicherheitsadministrator den Cloud-Benutzer eines angegebenen Acme-IT-Mitglieds zur FAGroup hinzu und autorisiert diesen Benutzer als Flottenadministrator.
  4. Der neu autorisierte Flottenadministrator erstellt die folgenden dedizierten Infrastrukturressourcen:
    • Eine Exadata-Infrastrukturressource AcmeInfrastructure im Compartment FleetComp.
    • Zwei autonome Exadata-VM-Cluster (AVMCs) im Compartment FleetComp mit Angabe der neu erstellten Exadata-Infrastruktur:
      • DevAVMC.

        Geben Sie für Oracle Public Cloud-Deployments AcmeHRVCN und DevVMSubnet als VCN und Subnetz an.

      • ProdAVMC.

        Geben Sie für Oracle Public Cloud-Deployments AcmeHRVCN und ProdVMSubnet als VCN und Subnetz an.

  5. Der Sicherheitsadministrator fügt dann den DevGroup- und ProdGroup-Umgebungen bestimmte Cloud-Benutzer hinzu und autorisiert sie als Anwendungs-DBAs für die Dev- und Prod-Umgebungen.
  6. Die neu autorisierten Anwendungs-DBAs erstellen die folgenden Ressourcen in ihren jeweiligen Arbeitsumgebungen, d.h. Dev und Prod:
    • Zwei autonome Containerdatenbanken (ACDs):
      • DevACD im Compartment DevComp, wobei DevAVMC als zugrunde liegende Ressource angegeben wird
      • ProdACD im Compartment ProdComp, wobei Prod AVMC als zugrunde liegende Ressource angegeben wird.
    • Autonome KI-Datenbank namens DevADB im Compartment DevComp.
    • Autonome KI-Datenbank namens ProdADB im Compartment ProdComp.

Schritt 1: Compartments erstellen

In diesem Schritt erstellt der Sicherheitsadministrator für den Cloud-Mandanten von Acme Company die Compartments FleetComp, DevComp und ProdComp.

Um diesen Schritt auszuführen, befolgt der Sicherheitsadministrator die Anweisungen unter Compartments verwalten in der Oracle Cloud Infrastructure-Dokumentation, um mit der Oracle Cloud-Konsole ein Compartment zu erstellen. Beim Befolgen dieser Anweisungen gibt der Sicherheitsadministrator das Root Compartment des Mandanten als übergeordnetes Compartment jedes der drei Compartments an.

Schritt 2: Gruppen erstellen

In diesem Schritt erstellt der Sicherheitsadministrator die Gruppen FAGroup, DevGroup und ProdGroup.

Um diesen Schritt auszuführen, befolgt der Sicherheitsadministrator die Anweisungen unter Gruppen verwalten in der Oracle Cloud Infrastructure-Dokumentation, um mit der Oracle Cloud-Konsole eine Gruppe zu erstellen.

Schritt 3: Policys erstellen

In diesem Schritt erstellt der Sicherheitsadministrator die Policys FleetCompPolicy, DevCompPolicy und ProdCompPolicy.

Um diesen Schritt auszuführen, befolgt der Sicherheitsadministrator die Anweisungen unter Policys verwalten in der Oracle Cloud Infrastructure-Dokumentation, um mit der Oracle Cloud-Konsole eine Policy zu erstellen.

Hinweis:

Neben dem Erstellen der erforderlichen Policy-Anweisungen erstellt der Sicherheitsadministrator in diesem Beispiel auch Policy-Anweisungen vom Typ "USE tag-namespaces", damit Gruppenmitglieder vorhandene Tags den von ihnen erstellten Ressourcen zuweisen können. Damit Gruppenmitglieder Tags erstellen und vorhandene Tags verwenden können, muss der Sicherheitsadministrator stattdessen Policy-Anweisungen vom Typ "MANAGE tag-namespaces" erstellen.

Beim Befolgen dieser Anweisungen für die Policy FleetCompPolicy führt der Sicherheitsadministrator folgende Schritte aus:

  1. Setzt das Compartment im Seitenmenü auf FleetComp, bevor er auf Policy erstellen klickt.

  2. Fügt je nach Deployment-Plattform eine der folgenden Policy-Anweisungen hinzu:

    • Oracle Public Cloud-Deployments:
      • Verwalten von cloud-exadata-infrastructures in Compartment FleetComp durch Gruppe FAGroup zulassen
      • Verwalten von Cloud-autonomous-vmclustern in Compartment FleetComp durch Gruppe FAGroup zulassen
      • Zulassen, dass die Gruppe FAGroup virtuelles Netzwerk im Compartment FleetComp verwendet
      • Zulassen, dass die Gruppe FAGroup Tag-Namespaces im Compartment FleetComp verwendet
      • Gruppe DevGroup das Lesen von cloud-exadata-infrastructures in Compartment FleetComp erlauben
      • Zulassen, dass Gruppe DevGroup cloud-autonomous-vmclusters in Compartment FleetComp liest
      • Zulassen, dass die Gruppe DevGroup virtuelles Netzwerk im Compartment FleetComp verwendet
      • Gruppe ProdGroup das Lesen von cloud-exadata-infrastructures in Compartment FleetComp erlauben
      • Zulassen, dass Gruppe ProdGroup cloud-autonomous-vmclusters in Compartment FleetComp liest
      • Zulassen, dass die Gruppe ProdGroup virtuelles Netzwerk im Compartment FleetComp verwendet
    • Exadata Cloud@Customer-Deployments:
      • Verwalten von Exadata-Infrastrukturen in Compartment FleetComp durch Gruppe FAGroup zulassen
      • Verwalten autonomer Cluster in Compartment FleetComp durch Gruppe FAGroup zulassen
      • Zulassen, dass die Gruppe FAGroup Tag-Namespaces im Compartment FleetComp verwendet
      • Lesen von Exadata-Infrastrukturen in Compartment FleetComp durch Gruppe DevGroup zulassen
      • Gruppe DevGroup das Lesen autonomer Cluster in Compartment FleetComp erlauben
      • Lesen von Exadata-Infrastrukturen in Compartment FleetComp durch Gruppe ProdGroup zulassen
      • Gruppe ProdGroup das Lesen autonomer Cluster in Compartment FleetComp erlauben

Beim Befolgen dieser Anweisungen für die Policy DevCompPolicy führt der Sicherheitsadministrator folgende Schritte aus:

  1. Setzt das Compartment im Seitenmenü auf DevComp, bevor er auf Policy erstellen klickt.

  2. Fügt die folgenden Policy-Anweisungen hinzu:

    • Zulassen, dass die Gruppe DevGroup autonome Containerdatenbanken im Compartment DevComp verwaltet
    • Gruppe DevGroup das Verwalten autonomer Datenbanken im Compartment DevComp erlauben
    • Verwalten von autonomen Backups in Compartment DevComp durch Gruppe DevGroup zulassen
    • Zulassen, dass die Gruppe DevGroup die Instanzfamilie im Compartment DevComp verwaltet
    • Zulassen, dass die Gruppe DevGroup Tag-Namespaces im Compartment DevComp verwendet
    • Verwalten von Metriken in Compartment DevComp durch Gruppe DevGroup zulassen
    • Zulassen, dass die Gruppe DevGroup Arbeitsanforderungen in Compartment DevComp INSPECT

Beim Befolgen dieser Anweisungen für die Policy ProdCompPolicy führt der Sicherheitsadministrator folgende Schritte aus:

  1. Setzt das Compartment im Seitenmenü auf ProdComp, bevor er auf Policy erstellen klickt.

  2. Fügt die folgenden Policy-Anweisungen hinzu:

    • Zulassen, dass die Gruppe ProdGroup autonome Containerdatenbanken im Compartment ProdComp verwaltet
    • Gruppe ProdGroup das Verwalten autonomer Datenbanken im Compartment ProdComp erlauben
    • Verwalten von autonomen Backups in Compartment ProdComp durch Gruppe ProdGroup zulassen
    • Zulassen, dass die Gruppe ProdGroup die Instanzfamilie im Compartment ProdComp verwaltet
    • Zulassen, dass die Gruppe ProdGroup Tag-Namespaces im Compartment ProdComp verwendet
    • Verwalten von Metriken in Compartment ProdComp durch Gruppe ProdGroup zulassen
    • Zulassen, dass die Gruppe ProdGroup Arbeitsanforderungen in Compartment ProdComp INSPECT

Schritt 4: VCN und Subnetze erstellen

Gilt nur für: Oracle Public Cloud (Anwendbar)

In diesem Schritt erstellt Acme I.T. oder der Netzwerkadministrator von Acme das VCN AcmeHRVCN und die Subnetze DevVMSubnet, ProdVMSubnet und AppSubnet im Compartment FleetComp.

Um diesen Schritt auszuführen, reserviert Acme I.T. zunächst bei der IT-Abteilung von Acme I.T. einen CIDR-IP-Adressenbereich, der nicht mit dem On-Premise-Netzwerk des Unternehmens in Konflikt steht. (Andernfalls würde das VCN mit dem On-Premise-Netzwerk in Konflikt stehen, sodass kein IPsec-VPN eingerichtet werden könnte.) Der reservierte Bereich ist CIDR 10.0.0.0/16.

Anschließend passt Acme I.T. die Anweisungen in Szenario B: Privates Subnetz mit einem VPN in der Oracle Cloud Infrastructure-Dokumentation an, um das VCN, die Subnetze und andere Netzwerkressourcen mit der Oracle Cloud-Konsole zu erstellen.

In diesem Beispiel werden die folgenden CIDR-Blöcke für die drei (3) Subnetze in AcmeHRVCN verwendet:
  • Zwei private Subnetze:
    • 10.0.10.0/24 für DevVMSubnet
    • 10.0.20.0/24 für ProdVMSubnet
  • Ein öffentliches Subnetz:
    • 10.0.100.0/24 für AppSubnet
Bei der Anpassung dieser Anweisungen erstellt Acme I.T. manuell Sicherheitslisten (anstelle der Standardsicherheitslisten), um Sicherheitsregeln zu isolieren und zu trennen und so die Netzwerkverwaltung zu vereinfachen. Dabei handelt es sich um folgende Sicherheitslisten:
  • DevSeclist: Die allgemeine Sicherheitsliste für DevVMSubnet. Wird verwendet, wenn das Subnetz DevVMSubnet erstellt wird.
  • ProdSeclist: Die allgemeine Sicherheitsliste für ProdVMSubnet. Wird verwendet, wenn das Subnetz ProdVMSubnet erstellt wird.
  • AppSeclist: Die allgemeine Sicherheitsliste für AppSubnet. Wird verwendet, wenn das Subnetz AppSubnet erstellt wird.

Weitere Informationen zu den AVMC-Ingress- und -Egress-Anforderungen finden Sie unter Anforderungen zum Provisioning eines autonomen Exadata-VM-Clusters.

Sicherheitsregeln in DevSeclist

Im Folgenden werden die Ingress-Regeln aufgeführt, die in DevSeclist erstellt wurden:

Zustandslos Quelle IP-Protokoll Quellportbereich Zielportbereich Typ und Code Lässt Folgendes zu
Nr. 10.0.10.0/24 ICMP Alle Alle Alle ICMP-Traffic für: alle
Nr. 10.0.10.0/24 TCP Alle Alle   TCP-Traffic für folgende Ports: alle
Nr. 10.0.100.0/24 TCP Alle 1521   TCP-Traffic für Port: 1521 Oracle Net
Nr. 10.0.100.0/24 TCP Alle 2484   TCPS-Traffic für Port: 2484 Oracle Net
Nr. 10.0.100.0/24 TCP Alle 6200   ONS/FAN für Ports: 6200
Nr. 10.0.100.0/24 TCP Alle 443   HTTPS-Datenverkehr für Port: 443

Die folgenden Egress-Regeln werden in DevSeclist erstellt:

Zustandslos Ziel IP-Protokoll Quellportbereich Zielportbereich Typ und Code Lässt Folgendes zu
Nr. 10.0.10.0/24 ICMP Alle Alle Alle Sämtlicher ICMP-Traffic innerhalb von DevVMSubnet
Nr. 10.0.10.0/24 TCP Alle Alle   Alle TCP-Traffic innerhalb von DevVMSubnet

Sicherheitsregeln in ProdSeclist

Hinweis:

Obwohl ProdSeclist über dieselben Sicherheitsregeln wie DevSeclist verfügt, hat der Netzwerkadministrator separate Sicherheitslisten erstellt, anstatt eine einzelne Sicherheitsliste für beide Projektteams zu erstellen, um alle zusätzlichen Sicherheitsregeln zu berücksichtigen, die von einem der Projektteams in Zukunft benötigt werden.

Im Folgenden werden die Ingress-Regeln aufgeführt, die in ProdSeclist erstellt wurden:

Zustandslos Quelle IP-Protokoll Quellportbereich Zielportbereich Typ und Code Lässt Folgendes zu
Nr. 10.0.20.0/24 ICMP Alle Alle Alle ICMP-Traffic für: alle
Nr. 10.0.20.0/24 TCP Alle Alle   TCP-Traffic für folgende Ports: alle
Nr. 10.0.100.0/24 TCP Alle 1521   TCP-Traffic für Port: 1521 Oracle Net
Nr. 10.0.100.0/24 TCP Alle 2484   TCPS-Traffic für Port: 2484 Oracle Net
Nr. 10.0.100.0/24 TCP Alle 6200   ONS/FAN für Ports: 6200
Nr. 10.0.100.0/24 TCP Alle 443   HTTPS-Datenverkehr für Port: 443

Die folgenden Egress-Regeln werden in ProdSeclist erstellt:

Zustandslos Ziel IP-Protokoll Quellportbereich Zielportbereich Typ und Code Lässt Folgendes zu
Nr. 10.0.20.0/24 ICMP Alle Alle Alle Sämtlicher ICMP-Traffic innerhalb von ProdVMSubnet
Nr. 10.0.20.0/24 TCP Alle Alle   Alle TCP-Traffic innerhalb von ProdVMSubnet

Sicherheitsregeln in AppSeclist

Die Ingress-Regel wird in AppSeclist erstellt:

Zustandslos Quelle IP-Protokoll Quellportbereich Zielportbereich Typ und Code Lässt Folgendes zu
Nr. 0.0.0.0/0 TCP Alle 22 Alle SSH-Traffic für Ports: 22

Hinweis:

Es wird empfohlen, 0.0.0.0/0 in den Sicherheitsregeln in die genehmigte Liste der CIDR-Bereichs-/IP-Adressen zu ändern.

Die folgenden Egress-Regeln werden in AppSeclist erstellt:

Zustandslos Ziel IP-Protokoll Quellportbereich Zielportbereich Typ und Code Lässt Folgendes zu
Nr. 10.0.10.0/24 TCP Alle 1521    
Nr. 10.0.10.0/24 TCP Alle 2484  
Nr. 10.0.10.0/24 TCP Alle 443    
Nr. 10.0.10.0/24 TCP Alle 6200    
Nr. 10.0.20.0/24 TCP Alle 1521    
Nr. 10.0.20.0/24 TCP Alle 2484    
Nr. 10.0.20.0/24 TCP Alle 443    
Nr. 10.0.20.0/24 TCP Alle 6200    

Schritt 5: Flottenadministrator zuweisen

In diesem Schritt fügt der Sicherheitsadministrator den Cloud-Benutzer eines angegebenen Mitglieds der IT-Abteilung von Acme I.T. zu FAGroup hinzu.

Um diesen Schritt auszuführen, befolgt der Sicherheitsadministrator die Anweisungen unter Benutzer verwalten in der Oracle Cloud Infrastructure-Dokumentation, um mit der Oracle Cloud-Konsole einer Gruppe einen Benutzer hinzuzufügen.

Schritt 6: Exadata-Infrastrukturressource erstellen

In diesem Schritt befolgt der Flottenadministrator die Anweisungen unter Exadata-Infrastrukturressource erstellen, um eine Exadata-Infrastrukturressource mit dem Namen AcmeInfrastructure im Compartment FleetComp zu erstellen.

Schritt 7: Autonome Exadata-VM-Clusterressourcen erstellen

In diesem Schritt befolgt der Flottenadministrator die Anweisungen unter Autonomes Exadata-VM-Cluster erstellen, um DevAVMC und ProdAVMC im Compartment FleetComp mit den folgenden Spezifikationen zu erstellen. Dabei behalten alle anderen Attribute ihre Standardeinstellungen bei.

Einstellung Entwicklungsumgebung Produktionsumgebung
AVMC-Name DevAVMC ProdAVMC
Zugrunde liegende Exadata-Infrastruktur AcmeInfrastructure AcmeInfrastructure
Virtuelles Cloud-Netzwerk (VCN)

Gilt nur für: Oracle Public Cloud (Anwendbar)

 AcmeHRVCN AcmeHRVCN
Subnetz

Gilt nur für: Oracle Public Cloud (Anwendbar)

 DevVMSubnet ProdVMSubnet

Schritt 8: Anwendungs-DBAs zuweisen

In diesem Schritt fügt der Sicherheitsadministrator bestimmte Cloud-Benutzer zu DevGroup hinzu und autorisiert sie so als Anwendungs-DBAs für die Entwicklungsressourcen. Anschließend wiederholt er den Prozess für ProdGroup.

Um diesen Schritt auszuführen, befolgt der Sicherheitsadministrator für jeden Benutzer die Anweisungen unter Benutzer verwalten in der Oracle Cloud Infrastructure-Dokumentation, um mit der Oracle Cloud-Konsole einer Gruppe einen Benutzer hinzuzufügen.

Schritt 9: Autonome Containerdatenbankressourcen erstellen

In diesem Schritt befolgen die jeweiligen Anwendungs-DBAs die Anweisungen unter Autonome Containerdatenbank erstellen, um die autonomen Containerdatenbanken (ACDs) für die Dev- und Prod-Umgebungen zu erstellen. Diese ACDs werden mit den folgenden Spezifikationen erstellt, sodass alle anderen Attribute in ihren Standardeinstellungen bleiben.

Einstellung Entwicklungsumgebung Produktionsumgebung
Compartment DevComp ProdComp
ACD-Name DevACD ProdACD
Zugrunde liegendes AVMC DevAVMC ProdAVMC
Softwareversion der Containerdatenbank Neueste Softwareversion (N) Sofortiger Vorgänger der Softwareversion (N-1)
Wartungsversion Neuestes RU (Releaseupdate) Nächstes RU (Release-Update)
Backupaufbewahrungszeitraum 7 Tage 30 Tage

Schritt 10. Ressourcen für autonome KI-Datenbank erstellen

In diesem Schritt befolgen die jeweiligen Anwendungs-DBAs die Anweisungen unter Autonome KI-Datenbank erstellen, um die autonomen KI-Datenbank für die Dev- und Prod-Umgebungen zu erstellen. Diese Datenbanken werden mit den folgenden Spezifikationen erstellt, sodass alle anderen Attribute ihren Standardeinstellungen entsprechen.

Einstellung Entwicklungsumgebung Produktionsumgebung
Compartment DevComp ProdComp
Datenbankname DevADB ProdADB
Zugrunde liegender ACD DevACD ProdACD
Datenbankinstanz Kann eine autonome KI-Datenbank oder eine autonome KI-Datenbank für Entwickler erstellen Autonome KI-Datenbank

Die Autonomous AI Database on Dedicated Exadata Infrastructure ist jetzt für die Entwicklung und den Test der AcmeHR-Anwendung mit anschließender Bereitstellung in der Produktionsumgebung konfiguriert.