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 autonomen KI-Datenbank auf einer dedizierten Exadata-Infrastruktur verwendet 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 zur schnellen Konfiguration einer POC-Umgebung für eine autonome KI-Datenbank finden Sie unter Autonomous AI Database for Proof of Concept (POC) konfigurieren.
Erforderliches Wissen
Um diesen Anwendungsfall vollständig zu verstehen und zu würdigen, sollten Sie über grundlegende Kenntnisse der autonomen KI-Datenbank auf dedizierter Exadata-Infrastruktur verfügen, einschließlich der Deployment-Optionen, der wichtigsten Infrastrukturkomponenten, der Benutzerrollen und der Hauptfeatures. Weitere Informationen finden Sie unter Autonomous AI Database on Dedicated Exadata Infrastructure.
Anwendungsfall
Acme Company hat sich für die Verwendung der autonomen KI-Datenbank auf dedizierter Exadata-Infrastruktur 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 die angegebenen Benutzer die Rolle des Anwendungs-DBA, mit der Aufgabe, autonome Containerdatenbanken (ACD) und autonome KI-Datenbanken für ihre Datenbankbenutzer zu erstellen, darunter Anwendungsentwickler, Tester und Deployer.
Hinweis: Dieses Beispiel veranschaulicht, wie der Anwendungs-DBA die ACD-Ressourcen erstellt und verwaltet. Ihre Organisation kann es jedoch vorziehen, dass der Flottenadministrator diese Aufgabe selbst übernimmt.
Acme I.T. wird den verschiedenen Teams Ressourcen zuweisen und so die Bereitstellung von AVMCs sicherstellen, die den erforderlichen SLAs entsprechen. Additionally, to control the allocation of resources fairly, Acme I.T. does not want any project team or line of business to have management access to the underlying dedicated infrastructure. Darüber hinaus wird das Acme-Management von Regulierungsbehörden nicht darauf zugreifen, dass Acme I.T. auf die Daten zugreifen kann, die zu verschiedenen Projektteams oder Geschäftsbereichen gehören, d.h. auf die Daten, die in den Anwendungsdatenbanken gespeichert werden.
AcmeHR, eine interne HR-Anwendung, die von Acme entwickelt und verwendet wird, arbeitet in zwei unterschiedlichen Umgebungen: einer für Entwicklung und Tests (Dev) und einer für Produktion (Prod). Acme I.T. verpflichtet sich, die strikte Isolierung zwischen diesen Umgebungen aufrechtzuerhalten, um unbefugten Zugriff oder die Interaktion zwischen den Entwicklungs- und Produktionsteams zu verhindern.
Benötigte Ressourcen
OCI IAM-Komponenten
Beschreibung der Abbildung configure-adb-d-resource-isolation.png
-
Drei Compartments für die Ressourcenisolierung, wie unten beschrieben:
-
FleetComp für die von Acme I.T. erstellten Ressourcen, das Networking 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., Entwicklerbenutzer und Produktbenutzer. Diese Gruppen werden FAGroup, DevGroup und ProdGroup genannt.
-
Erforderliche Policys zur Angabe des Benutzerzugriffs auf die Ressourcen auf Compartment- und Mandantenebene.
Netzwerkressourcen
Beschreibung der Abbildung configure-adbd-refarch-network.png
steht für eine Sicherheitsliste.
-
Oracle Public Cloud-Deployments:
-
Ein VCN für Netzwerkkonnektivität zu allen dedizierten Infrastrukturressourcen. Dieses VCN stellt eine Verbindung zum Acme-Unternehmens-VPN über ein IPSec-VPN her und hat eine Internetgatewayressource, die den gesamten eingehenden Internettraffic blockiert. Der Name lautet AcmeHRVCN.
-
Drei Subnetze für die Isolierung des Netzwerkzugriffs, jeweils eines für die autonomen KI-Datenbankressourcen der Dev- und Prod-Umgebungen und eines für die Client- und Mid-Tier-Ressourcen der Anwendung. Diese Subnetze werden DevVMSubnet, ProdVMSubnet und AppSubnet genannt.
Hinweis: Der Einfachheit halber verwenden wir ein einzelnes VCN und nutzen Subnetze für die Netzwerkisolation. Sie können jedoch auch mehrere VCNs erstellen, um die erforderliche Isolierung für den Netzwerkzugriff bereitzustellen. In diesem Beispiel erstellen wir alle drei Subnetze: DevVMSubnet, ProdVMSubnet und AppSubnet unter FleetComp zur Vereinfachung. Je nach Ihren Anforderungen können Sie diese Subnetze optional in separaten Compartments platzieren.
-
-
Exadata Cloud@Customer-Deployments:
-
Richten Sie Netzwerkregeln wie unter Netzwerkanforderungen für Oracle Exadata Database Service on Cloud@Customer in Exadata Database Service on Cloud@Customer vorbereiten aufgeführt ein.
-
Öffnen Sie außerdem Port 1522, um TCP-Traffic zwischen der Primärdatenbank und der Standbydatenbank in einem Autonomous Data Guard-Setup zuzulassen.
-
Autonome KI-Datenbankressourcen
Beschreibung der Abbildung configure-adb-d-resources.png
Autonome KI-Datenbankressourcen gemäß der oben dargestellten Konfiguration.
-
Eine Exadata-Infrastruktur zum Hosten von zwei AVMCs. Es heißt AcmeInfrastructure.
-
Zwei AVMCs in AcmeInfrastructure für die Entwicklungs- und Produktionsumgebungen. Diese AVMCs heißen DevAVMC und ProdAVMC.
-
DevAVMC:
-
hostet die autonomen Containerdatenbank 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).
-
Behält Backups von sieben (7) Tagen bei.
-
Für jedes Releaseupdate (RU) oder Patchrelease wird AcmeHR, das auf DevADB bereitgestellt wird, mit dem 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 Promotion in die Produktion geeignet ist. Weitere Informationen zu One-off-Patches finden Sie unter Wartung des autonomen KI-Datenbankservice.
-
-
ProdAVMC:
-
hostet die autonome Containerdatenbank und die autonome KI-Datenbank, die für das Produktions-Deployment der AcmeHR-Anwendung bereitgestellt wurden. Sie heißen ProdACD und ProdADB.
-
Wird immer mit der N-1-Softwareversion ausgeführt.
-
Behält Backups länger bei. Bei Bedarf werden auch langfristige Backups aktiviert.
-
Gepatchte alternative Quartale zur validierten Software, d.h. die in DevAVMC validierten RUs werden in dieser Datenbank bereitgestellt.
-
Allgemeine Schritte
Bevor Acme I.T. mit der Konfiguration von autonomen KI-Datenbankressourcen 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.
Nachfolgend sind die allgemeinen Schritte zur Implementierung dieses Anwendungsfalls aufgeführt:
-
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.
-
-
Für die Zugriffsisolierung:
-
Für 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
-
-
Für Exadata Cloud@Customer-Deployments stellt Acme I.T. oder der Netzwerkadministrator von Acme Folgendes sicher:
-
Richten Sie Netzwerkregeln wie unter Netzwerkanforderungen für Oracle Exadata Database Service on Cloud@Customer in Exadata Database Service on Cloud@Customer vorbereiten aufgeführt ein.
-
Öffnen Sie Port 1522, um TCP-Traffic zwischen der Primärdatenbank und der Standbydatenbank in einem Autonomous Data Guard-Setup zuzulassen.
-
-
-
Nach dem Erstellen von Netzwerkressourcen fügt der Sicherheitsadministrator den Cloud-Benutzer eines angegebenen Acme I.T.-Mitglieds zur FAGroup hinzu und autorisiert diesen Benutzer als Flottenadministrator.
-
Der neu autorisierte Flottenadministrator erstellt die folgenden dedizierten Infrastrukturressourcen:
-
Eine Exadata-Infrastrukturressource AcmeInfrastructure im Compartment FleetComp.
-
Zwei autonome Exadata-VM-Cluster (AVMCs) im FleetComp-Compartment mit 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.
-
-
-
Der Sicherheitsadministrator fügt dann bestimmte Cloud-Benutzer zu DevGroup und ProdGroup hinzu und autorisiert sie somit als Anwendungs-DBAs für die Dev- und Prod-Umgebungen.
-
Die neu autorisierten Anwendungs-DBAs erstellen die folgenden Ressourcen in ihren jeweiligen Arbeitsumgebungen, d.h. Dev und Prod:
-
Zwei autonome Containerdatenbanken (ACDs):
-
DevACD im DevComp-Compartment, wobei DevAVMC als zugrunde liegende Ressource angegeben wird
-
ProdACD im ProdComp-Compartment, wobei Sie Prod AVMC als zugrunde liegende Ressource angeben.
-
-
Autonome KI-Datenbank mit dem Namen DevADB im Compartment DevComp.
-
Autonome KI-Datenbank mit dem Namen ProdADB im Compartment ProdComp.
-
Schritt 1: Compartments erstellen
In diesem Schritt erstellt der Sicherheitsadministrator für den Cloud-Mandanten der 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 Art "USE tag-namespaces", um Gruppenmitgliedern die Zuweisen vorhandener Tags zu den von ihnen erstellen Ressourcen. Damit Gruppenmitglieder Tags erstellen und vorhandene Tags verwenden können, muss der Sicherheitsadministrator stattdessen Policy-Anweisungen vom Typs "MANAGE tag-namespaces" erstellen.
Beim BeFolgen dieser Anweisungen für die FleetCompPolicy-Policy führt der Sicherheitsadministrator folgende Schritte durch:
-
Setzt das Compartment im Seitenmenü auf FleetCompbevor er auf Policy erstellen klickt.
-
Fügt je nach Deployment-Plattform eine der folgenden Policy-Anweisungen hinzu:
-
Oracle Public Cloud-Deployments:
-
Gruppen-FAGroup für MANAGE cloud-exadata-infrastructures im Compartment FleetComp zulassen
-
Zulassen, dass Gruppen-FAGroup cloud-autonomous-vmclusters im Compartment FleetComp verwaltet
-
Gruppen-FAGroup für die Verwendung von virtual-network-family im Compartment FleetComp zulassen
-
Gruppen-FAGroup für die Verwendung von Tag-Namespaces im Compartment FleetComp zulassen
-
Zulassen, dass die Gruppe DevGroup cloud-exadata-infrastructures im Compartment FleetComp liest
-
LESEN von cloud-autonomous-vmclusters in Compartment FleetComp durch Gruppe DevGroup zulassen
-
Gruppe DevGroup die Verwendung von virtual-network-family im Compartment FleetComp erlauben
-
Zulassen, dass die Gruppe ProdGroup cloud-exadata-infrastructures im Compartment FleetComp liest
-
Zulassen, dass Gruppe ProdGroup Cloud-autonomous-vmclusters im Compartment FleetComp liest
-
Gruppe ProdGroup die Verwendung von virtual-network-family im Compartment FleetComp erlauben
-
-
Exadata Cloud@Customer-Deployments:
-
Gruppen-FAGroup darf Exadata-Infrastrukturen im Compartment FleetComp verwalten
-
Gruppen-FAGroup zur Verwaltung autonomer VM-Cluster im Compartment FleetComp zulassen
-
Gruppen-FAGroup für die Verwendung von Tag-Namespaces im Compartment FleetComp zulassen
-
Gruppe DevGroup das READ von Exadata-Infrastrukturen im Compartment FleetComp erlauben
-
Gruppe "DevGroup" darf autonome VM-Cluster im Compartment "FleetComp" lesen
-
Gruppe ProdGroup darf Exadata-Infrastrukturen im Compartment FleetComp lesen
-
Gruppe ProdGroup darf autonome VM-Cluster im Compartment FleetComp lesen
-
-
Beim Be Folgen dieser Anweisungen für die DevCompPolicy-Policy führt der Sicherheitsadministrator folgende Schritte:
-
Setzt das Compartment im Seitenmenü auf DevComp, bevor er auf Policy erstellen klickt.
-
Fügt die folgenden Policy-Anweisungen hinzu:
-
Gruppe "DevGroup" darf autonome Containerdatenbanken im Compartment "DevComp" verwalten
-
Gruppe "DevGroup" erlauben, autonome Datenbanken im Compartment "DevComp" zu verwalten
-
Gruppe "DevGroup" erlauben, autonome Backups im Compartment "DevComp" zu verwalten
-
Gruppe "DevGroup" darf Instanzfamilie in Compartment "DevComp" verwalten
-
Gruppe DevGroup das Verwenden von Tag-Namespaces im Compartment DevComp erlauben
-
Gruppe "DevGroup" darf Metriken in Compartment "DevComp" verwalten
-
Gruppenentwicklungsgruppe das INSPECT von Arbeitsanforderungen im Compartment DevComp zulassen
-
Wenn Sie diese Anweisungen für die ProdCompPolicy-Policy befolgen, führt der Sicherheitsadministrator folgende Schritte:
-
Setzt das Compartment im Seitenmenü auf "ProdComp", bevor er auf Policy erstellen klickt.
-
Fügt die folgenden Policy-Anweisungen hinzu:
-
Gruppe "ProdGroup" darf autonome Containerdatenbanken im Compartment "ProdComp" verwalten
-
Gruppe "ProdGroup" erlauben, autonome Datenbanken im Compartment "ProdComp" zu verwalten
-
Gruppe "ProdGroup" erlauben, autonome Backups im Compartment "ProdComp" zu verwalten
-
Gruppe ProdGroup darf Instanzfamilie in Compartment ProdComp verwalten
-
Gruppe "ProdGroup" erlauben, Tag-Namespaces in Compartment "ProdComp" zu verwenden
-
Gruppe "ProdGroup" darf Metriken in Compartment "ProdComp" verwalten
-
Gruppe ProdGroup das INSPECT von Arbeitsanforderungen im Compartment ProdComp zulassen
-
Schritt 4: VCN und Subnetze erstellen
Gilt nur für: 
Oracle Public Cloud
In diesem Schritt erstellt Acme I.T. oder der Netzwerkadministrator von Acme das AcmeHRVCN-VCN und die Subnetze DevVMSubnet, ProdVMSubnet und AppSubnet im Compartment FleetComp.
Um diesen Schritt auszuführen, vertraut Acme I.T. zunächst mit dem Netzwerk der Acme I.T.-Abteilung, um einen CIDR-IP-Adressbereich zu reservieren, 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 derOracle 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
Beim Anpassen dieser Anweisungen erstellt Acme I.T. manuell Sicherheitslisten (anstatt die Standardsicherheitslisten verwenden), um Sicherheitsregeln zu isolieren und so zu trennen und die Netzwerkverwaltung zu vereinfachen. Dabei handelt es sich um folgende Sicherheitslisten:
-
DevSeclist: Die grundlegende Sicherheitsliste für DevVMSubnet. Wird verwendet, wenn das Subnetz DevVMSubnet erstellt wird.
-
ProdSeclist: Die grundlegende Sicherheitsliste für ProdVMSubnet. Wird verwendet, wenn das Subnetz ProdVMSubnet erstellt wird.
-
AppSeclist: Die grundlegende Sicherheitsliste für AppSubnet. Wird verwendet, wenn das Subnetz AppSubnet erstellt wird.
Weitere Informationen zu den Anforderungen an AVMC-Ingress und -Egress finden Sie unter Voraussetzungen für das Provisioning eines autonomen Exadata-VM-Clusters.
Sicherheitsregeln in DevSeclist
In DevSeclist erstellte Ingress-Regeln:
| 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-Traffic für Port: 443 |
In DevSeclist erstellte Egress-Regeln:
| Zustandslos | Ziel | IP-Protokoll | Quellportbereich | Zielportbereich | Typ und Code | Lässt Folgendes zu |
|---|---|---|---|---|---|---|
| Nr. | 10.0.10.0/24 | ICMP | Alle | Alle | Alle | Alle ICMP-Datenverkehr innerhalb von DevVMSubnet |
| Nr. | 10.0.10.0/24 | TCP | Alle | Alle | Alle TCP-Datenverkehr in DevVMSubnet |
Sicherheitsregeln in ProdSeclist
Hinweis: Obwohl ProdSeclist dieselben Sicherheitsregeln wie DevSeclist hat, hat der Netzwerkadministrator separate Sicherheitslisten erstellt, anstatt eine einzige Sicherheitsliste für beide Projektteams zu erstellen, um alle zusätzlichen Sicherheitsregeln zu berücksichtigen, die von einem der Projektteams in der Zukunft benötigt werden.
Ingress-Regeln, 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-Traffic für Port: 443 |
In ProdSeclist erstellte Egress-Regeln:
| Zustandslos | Ziel | IP-Protokoll | Quellportbereich | Zielportbereich | Typ und Code | Lässt Folgendes zu |
|---|---|---|---|---|---|---|
| Nr. | 10.0.20.0/24 | ICMP | Alle | Alle | Alle | Alle ICMP-Datenverkehr innerhalb von ProdVMSubnet |
| Nr. | 10.0.20.0/24 | TCP | Alle | Alle | Alle TCP-Datenverkehr in ProdVMSubnet |
Sicherheitsregeln in AppSeclist
In AppSeclist erstellte Ingress-Regel:
| 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 folgende 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.
In AppSeclist erstellte Egress-Regeln:
| 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: Flottenadministratoren zuweisen
In diesem Schritt fügt der Sicherheitsadministrator den Cloud-Benutzer eines angegebenen Mitglieds der Acme I.T.-Abteilung der 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, wobei alle anderen Attribute die Standardeinstellungen beibehalten.
| Einstellung | Entwicklungsumgebung | Produktionsumgebung |
|---|---|---|
| AVMC-Name | DevAVMC | ProdAVMC |
| Zugrunde liegende Exadata-Infrastruktur | AcmeInfrastruktur | AcmeInfrastruktur |
| Virtuelles Cloud-Netzwerk (VCN) Gilt nur für: Oracle Public Cloud |
AcmeHR-VCN | AcmeHR-VCN |
| Subnetz Gilt nur für: Oracle Public Cloud |
DevVMSubnet | ProdVMSubnet |
Schritt 8: Anwendungs-DBAs zuweisen
In diesem Schritt fügt der Sicherheitsadministrator bestimmte Cloud-Benutzer zu DevGroup hinzu und autorisiert sie somit als Anwendungs-DBAs für die Entwicklungsressourcen und wiederholt dann 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 ihre Standardeinstellungen beibehalten.
| Einstellung | Entwicklungsumgebung | Produktionsumgebung |
|---|---|---|
| Compartment | DevComp | Produktkomp. |
| ACD-Name | DevACD | ProdACD |
| Zugrunde liegendes AVMC | DevAVMC | ProdAVMC |
| Version der Containerdatenbanksoftware | Neueste Softwareversion (N) | Sofortiger Vorgänger der Softwareversion (N-1) |
| Wartungsversion | Neueste RU (Releaseupdate) | Nächstes RU (Releaseupdate) |
| 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-Datenbanken 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 | Produktkomp. |
| Datenbankname | DevADB | ProdADB |
| Zugrunde liegendes ACD | DevACD | ProdACD |
| Datenbankinstanz | Kann eine autonome KI-Datenbank oder eine autonome KI-Datenbank für Entwickler erstellen | Autonome KI-Datenbank |
Die autonome KI-Datenbank auf dedizierter Exadata-Infrastruktur ist jetzt für die Entwicklung und den Test der AcmeHR-Anwendung mit anschließender Bereitstellung in der Produktionsumgebung konfiguriert.
Verwandte Inhalte
Komponenten der autonomen KI-Datenbank auf einer dedizierten Exadata-Infrastruktur