Autonome Exadata-VM-Cluster

Mit autonomen VM-Clustern (AVMCs) kann ein physisches Exadata-Cluster (Maschine) in mehrere virtuelle Cluster partitioniert werden. Sie können verwendet werden, um Umgebungen für verschiedene Datenbank-Workloads durch separate Zugriffsregeln, Netzwerkkonfigurationen sowie anpassbaren Rechenspeicher und Speicherressourcen zu isolieren.

AVMC ist eine der Infrastrukturkomponenten des vierstufigen Datenbankarchitekturmodells, auf dem eine autonome Containerdatenbank erstellt wird. Mindestens ein AVMC wird in einer Exadata-Infrastrukturressource (EI) bereitgestellt und stellt den Link zwischen dem EI und den autonomen Containerdatenbankressourcen in Ihrem Deployment bereit.

AVMCs bieten isolierte Umgebungen für verschiedene Datenbank-Workloads über separate Zugriffsregeln, Netzwerkkonfigurationen sowie anpassbaren Rechenspeicher und Speicherressourcen.

Um einen umfassenden Überblick über die vierschichtige Architektur zu erhalten, die mit Autonomous AI Database on Dedicated Exadata Infrastructure verwendet wird, und die Positionierung von AVMC in dieser Architektur zu verstehen, lesen Sie Komponenten der autonomen KI-Datenbank auf dedizierter Exadata-Infrastruktur.

AVMCs werden von Flottenadministratoren erstellt, überwacht und verwaltet. Weitere Informationen finden Sie unter Benutzerrollen, die mit der autonomen KI-Datenbank auf einer dedizierten Exadata-Infrastruktur verknüpft sind.

Autonomes Exadata-VM-Cluster - Anforderungen

IAM-Policy-Anforderungen

Verschiedene Deployment-Optionen IAM-Policys

Oracle Public Cloud und Multicloud

Verschiedene Deployment-Optionen	IAM-Policys
Oracle Public Cloud und Multicloud	`manage cloud-autonomous-vmclusters` `use cloud-exadata-infrastructures`
Exadata Cloud@Customer	`manage autonomous-vmclusters` `use exadata-infrastructures`

manage cloud-autonomous-vmclusters

use cloud-exadata-infrastructures

Exadata Cloud@Customer

manage autonomous-vmclusters

use exadata-infrastructures

Mindestens erforderliche Ressourcen

Um ein autonomes Exadata-VM-Cluster zu erstellen, benötigen Sie mindestens:

40 ECPUs pro Knoten
120 GB Speicher pro Knoten
338,5 GB lokaler Speicher pro Knoten
6,61 TB Exadata-Speicher

Vor dem Provisioning eines autonomen Exadata-VM-Clusters müssen Netzwerkanforderungen erfüllt werden. Die vollständigen Anforderungen finden Sie unter Autonomes Exadata-VM-Cluster erstellen.

Hinweis: Sie müssen eine Exadata-Infrastrukturressource bereitstellen, bevor Sie einen AVMC erstellen. Anweisungen hierzu finden Sie unter Exadata-Infrastrukturressource erstellen.

Vom autonomen Exadata-VM-Cluster verwaltete Datenbankfeatures

Die folgenden Features der autonomen KI-Datenbank können auf der Ebene des autonomen Exadata-VM-Clusters (AVMC) definiert und verwaltet werden.

Autonome KI-Datenbankfunktion	Hinweise:	Weitere Referenz
Compute-Modell Dies ist die Compute-Abrechnungsmetrik für die autonome KI-Datenbank.	Ab dem 28. Mai 2025 können Sie in der autonomen KI-Datenbank auf dedizierter Exadata-Infrastruktur keine neuen AVMCs mit der OCPU-Abrechnungsmetrik erstellen. Alle neuen AVMCs können nur mit ECPUs bereitgestellt werden. Vorhandene OCPU-AVMCs und autonome KI-Datenbanken werden weiterhin wie gewohnt funktionieren. Sie können Ihre OCPU-AVMCs und die entsprechenden autonomen KI-Datenbanken über Serviceanfragen auf ECPU aktualisieren lassen. Weitere Informationen finden Sie unter Doc ID 2998755.1. Hinweis: Multicloud-Deployments unterstützen nur das ECPU-Compute-Modell.	Compute-Modelle
DB-Serverauswahl AVMCs können über eine beliebige Anzahl von DB-Servern (VMs) bereitgestellt werden. Sie können beim Provisioning eines AVMC eine Liste der verfügbaren VMs anzeigen und auswählen.	Beim Provisioning eines AVMC müssen Sie mindestens 2 DB-Server auswählen, um eine AVMC-Ressource bereitzustellen. Für die High Availability-(HA-)Konfiguration sind mindestens 2 DB-Server erforderlich. Nach dem Provisioning eines AVMC können Sie keine DB-Server hinzufügen oder entfernen.
Wartungsplan Im Allgemeinen plant Oracle die gesamte Flottenwartung und führt sie an verschiedenen Terminen in jedem Quartal durch. Sie können die Wartungsplanung Oracle überlassen oder ein bestimmtes Wartungsfenster festlegen, in dem Oracle mit der Wartung beginnen kann.	Sie können separate Wartungsläufe für jedes autonome VM-Cluster auf derselben Exadata-Infrastruktur terminieren. Sie können die Standardeinstellung des Wartungsplans ändern (keine Voreinstellung, die es Oracle ermöglicht, die Wartung nach Bedarf zu planen), indem Sie die Monate, Wochen, Tage und Stunden für den Zeitplan wählen. Sie können auch eine Vorlaufzeit festlegen, um eine Benachrichtigung über eine bevorstehende Wartung von Oracle zu erhalten.	Angeben, wann Wartung stattfinden kann
Ressourcenverwaltung Compute, Speicher und Arbeitsspeicher der einzelnen autonomen Exadata-VM-Clusterkonfigurationen für die gewünschte Workload können angepasst werden. Sie können diese Ressourcen überwachen, indem Sie Visualisierungen für Ressourcenzuteilung und -nutzung anzeigen.	Optional können Sie beim Provisioning eines AVMC einen geeigneten Wert für die folgenden Ressourcenmanagementattribute definieren, der Ihren Anforderungen entspricht: Maximale Anzahl autonomer Containerdatenbanken: Die angegebene Anzahl von ACDs stellt den oberen Grenzwert von ACDs dar. CPU-Anzahl pro VM oder Knoten: Geben Sie die CPU-Anzahl für jede einzelne VM an. Der Mindestwert beträgt 20 ECPUs pro VM. Datenbankspeicher pro CPU (GB): Der Arbeitsspeicher pro CPU, der für die autonomen KI-Datenbanken im autonomen VM-Cluster zugewiesen ist. Speicher für lokale Backups zuweisen: Bei Exadata Cloud@Customer können Sie diese Option aktivieren, um den Exadata-Speicher so zu konfiguriert, dass lokale Datenbankbackups aktiviert werden. Datenbankspeicher (TB): Datenspeicher, der für die Erstellung einer autonomen KI-Datenbank im autonomen VM-Cluster zugewiesen ist. Die Begriffe "VM" und "Knoten" werden synonym zwischen Oracle Exadata Cloud@Customer- und Oracle Public Cloud-Deployments verwendet.	Visualisierungen für Ressourcennutzung
Netzwerkeinstellungen Bei Oracle Public Cloud- und Multicloud-Deployments definieren Sie die Netzwerkzugriffskontrolle mit Komponenten des Networking-Service. Sie erstellen ein virtuelles Cloud-Netzwerk (VCN), das private Subnetze enthält, in denen Ihre autonome KI-Datenbank über das Netzwerk zugänglich ist.	Gilt nur für: Oracle Public Cloud Die folgenden Einstellungen können beim Provisioning eines AVMC angepasst werden: Virtuelles Cloud-Netzwerk: Das virtuelle Cloud-Netzwerk (VCN), in dem Sie das neue AVMC erstellen möchten. Subnetz: Ein Subnetz innerhalb des oben ausgewählten VCN für das neue autonome Exadata-VM-Cluster.
VM-Clusternetzwerk In Exadata Cloud@Customer definieren Sie Netzwerkzugriffskontrollen, indem sie ein Clientnetzwerk innerhalb Ihres Data Centers angeben und in einer VM-Clusternetzwerkressource innerhalb der Exadata-Infrastrukturressource aufzeichnet.	Gilt nur für: Exadata Cloud@Customer Das VM-Clusternetzwerk, in dem das neue autonome Exadata-VM-Cluster erstellt werden soll, wird beim Provisioning eines AVMC ausgewählt.	Exadata Database Service on Cloud@Customer vorbereiten
Zero Trust Packet Routing (ZPR) Oracle Cloud Infrastructure Zero Trust Packet Routing (ZPR) schützt sensible Daten vor unbefugtem Zugriff durch absichtsbasierte Sicherheits-Policys, die Sie für Ressourcen schreiben, wie z.B. einen AVMC, dem Sie Sicherheitsattribute zuweisen.	Gilt nur für: Oracle Public Cloud Sie können ZPR-Sicherheitsattribute beim Provisioning auf einen AVMC oder später anwenden.	Autonomes Exadata-VM-Cluster erstellen Erste Schritte mit Zero Trust Packet Routing
Lizenztyp Sie können vorhandene Oracle Database-Softwarelizenzen verwenden oder Oracle Database-Softwarelizenzen abonnieren.	Es gibt zwei Optionen für den Lizenztyp: Ihre eigene Lizenz verwenden: Wählen Sie diese Option, wenn Ihre Organisation bereits Oracle Database-Softwarelizenzen besitzt, die Sie in der autonomen KI-Datenbank verwenden möchten. Lizenz inklusive: Wählen Sie diese Option aus, um die Oracle Autonomous AI Database-Softwarelizenz zu abonnieren
Zeitzone Sie können die Zeitzone jedes autonomen Exadata-VM-Clusters festlegen.	Die Standardzeitzone für das autonome Exadata-VM-Cluster ist UTC. Sie können jedoch eine andere Zeitzone angeben.
Listener Sie können einen Single Client Access Name-(SCAN-)Listener-Port für TLS und Nicht-TLS auswählen und zwischen One-Way-TLS und mTLS für Datenbank-TLS-Zertifikate wählen.	Die SCAN-Listener-Ports können nach dem Provisioning der AVMC-Ressource nicht geändert werden. Da ORDS-Zertifikate unidirektionale TLS-Zertifikate sind, ist die Auswahl zwischen unidirektionalen TLS- und gegenseitigen TLS-Zertifikaten (mTLS) nur auf Datenbank-TLS-Zertifikate anwendbar.
Verschlüsselungsschlüssel mit AWS KMS	In der autonomen KI-Datenbank auf Oracle Database@AWS können Sie AWS Key Management Service (AWS KMS) aktivieren, um Masterverschlüsselungsschlüssel zu verwalten.	AWS KMS aktivieren oder deaktivieren
Zertifikate verwalten Sie können das von der CA signierte Zertifikat in das autonome VM-Cluster hochladen und für sichere Verbindungen verwenden.	Standardmäßig werden von Oracle verwaltete selbstsignierte Zertifikate beim Provisioning eines autonomen Exadata-VM-Clusters (AVMC) automatisch generiert und auf alle in diesem AVMC erstellten Datenbanken angewendet. Sie haben auch die Möglichkeit, Ihr eigenes CA-signiertes serverseitiges Zertifikat mit Autonomous AI Database zu verwenden. Sie können beide Zertifikatstypen über die Konsole oder API rotieren.	Verwaltung von Zertifikaten

Autonome KI-Datenbankfunktion

Hinweise:

Weitere Referenz

Compute-Modell

Dies ist die Compute-Abrechnungsmetrik für die autonome KI-Datenbank.

Ab dem 28. Mai 2025 können Sie in der autonomen KI-Datenbank auf dedizierter Exadata-Infrastruktur keine neuen AVMCs mit der OCPU-Abrechnungsmetrik erstellen. Alle neuen AVMCs können nur mit ECPUs bereitgestellt werden.

Vorhandene OCPU-AVMCs und autonome KI-Datenbanken werden weiterhin wie gewohnt funktionieren. Sie können Ihre OCPU-AVMCs und die entsprechenden autonomen KI-Datenbanken über Serviceanfragen auf ECPU aktualisieren lassen. Weitere Informationen finden Sie unter Doc ID 2998755.1.

Hinweis: Multicloud-Deployments unterstützen nur das ECPU-Compute-Modell.

Compute-Modelle

DB-Serverauswahl

AVMCs können über eine beliebige Anzahl von DB-Servern (VMs) bereitgestellt werden. Sie können beim Provisioning eines AVMC eine Liste der verfügbaren VMs anzeigen und auswählen.

Beim Provisioning eines AVMC müssen Sie mindestens 2 DB-Server auswählen, um eine AVMC-Ressource bereitzustellen. Für die High Availability-(HA-)Konfiguration sind mindestens 2 DB-Server erforderlich.

Nach dem Provisioning eines AVMC können Sie keine DB-Server hinzufügen oder entfernen.

Wartungsplan

Im Allgemeinen plant Oracle die gesamte Flottenwartung und führt sie an verschiedenen Terminen in jedem Quartal durch.

Sie können die Wartungsplanung Oracle überlassen oder ein bestimmtes Wartungsfenster festlegen, in dem Oracle mit der Wartung beginnen kann.

Sie können separate Wartungsläufe für jedes autonome VM-Cluster auf derselben Exadata-Infrastruktur terminieren.

Sie können die Standardeinstellung des Wartungsplans ändern (keine Voreinstellung, die es Oracle ermöglicht, die Wartung nach Bedarf zu planen), indem Sie die Monate, Wochen, Tage und Stunden für den Zeitplan wählen. Sie können auch eine Vorlaufzeit festlegen, um eine Benachrichtigung über eine bevorstehende Wartung von Oracle zu erhalten.

Angeben, wann Wartung stattfinden kann

Ressourcenverwaltung

Compute, Speicher und Arbeitsspeicher der einzelnen autonomen Exadata-VM-Clusterkonfigurationen für die gewünschte Workload können angepasst werden. Sie können diese Ressourcen überwachen, indem Sie Visualisierungen für Ressourcenzuteilung und -nutzung anzeigen.

Optional können Sie beim Provisioning eines AVMC einen geeigneten Wert für die folgenden Ressourcenmanagementattribute definieren, der Ihren Anforderungen entspricht:

Maximale Anzahl autonomer Containerdatenbanken: Die angegebene Anzahl von ACDs stellt den oberen Grenzwert von ACDs dar.
CPU-Anzahl pro VM oder Knoten: Geben Sie die CPU-Anzahl für jede einzelne VM an. Der Mindestwert beträgt 20 ECPUs pro VM.
Datenbankspeicher pro CPU (GB): Der Arbeitsspeicher pro CPU, der für die autonomen KI-Datenbanken im autonomen VM-Cluster zugewiesen ist.
Speicher für lokale Backups zuweisen: Bei Exadata Cloud@Customer können Sie diese Option aktivieren, um den Exadata-Speicher so zu konfiguriert, dass lokale Datenbankbackups aktiviert werden.
Datenbankspeicher (TB): Datenspeicher, der für die Erstellung einer autonomen KI-Datenbank im autonomen VM-Cluster zugewiesen ist.

Die Begriffe "VM" und "Knoten" werden synonym zwischen Oracle Exadata Cloud@Customer- und Oracle Public Cloud-Deployments verwendet.

Visualisierungen für Ressourcennutzung

Netzwerkeinstellungen

Bei Oracle Public Cloud- und Multicloud-Deployments definieren Sie die Netzwerkzugriffskontrolle mit Komponenten des Networking-Service. Sie erstellen ein virtuelles Cloud-Netzwerk (VCN), das private Subnetze enthält, in denen Ihre autonome KI-Datenbank über das Netzwerk zugänglich ist.

Gilt nur für: Anwendbar Oracle Public Cloud

Die folgenden Einstellungen können beim Provisioning eines AVMC angepasst werden:

Virtuelles Cloud-Netzwerk: Das virtuelle Cloud-Netzwerk (VCN), in dem Sie das neue AVMC erstellen möchten.
Subnetz: Ein Subnetz innerhalb des oben ausgewählten VCN für das neue autonome Exadata-VM-Cluster.

VM-Clusternetzwerk

In Exadata Cloud@Customer definieren Sie Netzwerkzugriffskontrollen, indem sie ein Clientnetzwerk innerhalb Ihres Data Centers angeben und in einer VM-Clusternetzwerkressource innerhalb der Exadata-Infrastrukturressource aufzeichnet.

Gilt nur für: Anwendbar

Exadata Cloud@Customer

Das VM-Clusternetzwerk, in dem das neue autonome Exadata-VM-Cluster erstellt werden soll, wird beim Provisioning eines AVMC ausgewählt.

Exadata Database Service on Cloud@Customer vorbereiten

Zero Trust Packet Routing (ZPR)

Oracle Cloud Infrastructure Zero Trust Packet Routing (ZPR) schützt sensible Daten vor unbefugtem Zugriff durch absichtsbasierte Sicherheits-Policys, die Sie für Ressourcen schreiben, wie z.B. einen AVMC, dem Sie Sicherheitsattribute zuweisen.

Gilt nur für: Anwendbar Oracle Public Cloud

Sie können ZPR-Sicherheitsattribute beim Provisioning auf einen AVMC oder später anwenden.

Autonomes Exadata-VM-Cluster erstellen

Erste Schritte mit Zero Trust Packet Routing

Lizenztyp

Sie können vorhandene Oracle Database-Softwarelizenzen verwenden oder Oracle Database-Softwarelizenzen abonnieren.

Es gibt zwei Optionen für den Lizenztyp:

Ihre eigene Lizenz verwenden: Wählen Sie diese Option, wenn Ihre Organisation bereits Oracle Database-Softwarelizenzen besitzt, die Sie in der autonomen KI-Datenbank verwenden möchten.
Lizenz inklusive: Wählen Sie diese Option aus, um die Oracle Autonomous AI Database-Softwarelizenz zu abonnieren

Zeitzone

Sie können die Zeitzone jedes autonomen Exadata-VM-Clusters festlegen.

Die Standardzeitzone für das autonome Exadata-VM-Cluster ist UTC. Sie können jedoch eine andere Zeitzone angeben.

Listener

Sie können einen Single Client Access Name-(SCAN-)Listener-Port für TLS und Nicht-TLS auswählen und zwischen One-Way-TLS und mTLS für Datenbank-TLS-Zertifikate wählen.

Die SCAN-Listener-Ports können nach dem Provisioning der AVMC-Ressource nicht geändert werden.

Da ORDS-Zertifikate unidirektionale TLS-Zertifikate sind, ist die Auswahl zwischen unidirektionalen TLS- und gegenseitigen TLS-Zertifikaten (mTLS) nur auf Datenbank-TLS-Zertifikate anwendbar.

Verschlüsselungsschlüssel mit AWS KMS

In der autonomen KI-Datenbank auf Oracle Database@AWS können Sie AWS Key Management Service (AWS KMS) aktivieren, um Masterverschlüsselungsschlüssel zu verwalten.

AWS KMS aktivieren oder deaktivieren

Zertifikate verwalten

Sie können das von der CA signierte Zertifikat in das autonome VM-Cluster hochladen und für sichere Verbindungen verwenden.

Standardmäßig werden von Oracle verwaltete selbstsignierte Zertifikate beim Provisioning eines autonomen Exadata-VM-Clusters (AVMC) automatisch generiert und auf alle in diesem AVMC erstellten Datenbanken angewendet. Sie haben auch die Möglichkeit, Ihr eigenes CA-signiertes serverseitiges Zertifikat mit Autonomous AI Database zu verwenden.

Sie können beide Zertifikatstypen über die Konsole oder API rotieren.

Verwaltung von Zertifikaten