Oracle PeopleSoft in Compute Engine mit Oracle Exadata

Last reviewed 2025-08-21 UTC

In diesem Dokument finden Sie eine Referenzarchitektur, die Ihnen beim Erstellen der Infrastruktur für die Ausführung von Oracle PeopleSoft-Anwendungen auf Compute Engine-VMs mit niedriger Latenz Konnektivität zu Oracle Database@Google Cloud (Oracle Cloud Infrastructure Exadata-Datenbanken, die in Google Cloudausgeführt werden) hilft. Oracle PeopleSoft ist eine Suite von Unternehmensanwendungen für das Personalwesen, Campus-Lösungen und die Unternehmensressourcenplanung.

Dieses Dokument richtet sich an Cloud-Architekten und Administratoren von Oracle-Datenbanken und Oracle PeopleSoft-Anwendungen. In diesem Dokument wird davon ausgegangen, dass Sie mit Oracle PeopleSoft-Anwendungen und Oracle-Datenbanken vertraut sind.

Architektur

Das folgende Diagramm zeigt eine Architektur, in der Oracle PeopleSoft-Anwendungen auf Compute Engine-VMs in einer Google Cloud Region ausgeführt werden und Oracle Exadata-Datenbanken in derselben Google Cloud Region verwendet werden.

Architektur für Oracle PeopleSoft mit Oracle Exadata.

Die Architektur im vorherigen Diagramm umfasst die folgenden Komponenten:

Komponente Zweck
Regionaler externer Application Load Balancer Der Load Balancer empfängt Nutzeranfragen und verteilt sie an die Oracle PeopleSoft-Webserver. Um die Sitzungsaffinität zu gewährleisten, ist der Load-Balancer für die Verwendung von generierten Cookies konfiguriert.
Google Cloud Armor-Sicherheitsrichtlinie Mit der Cloud Armor-Sicherheitsrichtlinie können Sie Ihren Anwendungs-Stack vor Bedrohungen wie DDoS-Angriffen (Distributed Denial of Service) und Cross-Site-Scripting (XSS) schützen.
Oracle PeopleSoft-Web-Tier (BYOL) Die Oracle PeopleSoft-Webschicht besteht aus Webservern, die unabhängig voneinander auf zwei Compute Engine-VMs ausgeführt werden. Sie stellen für Oracle PeopleSoft Ihre eigenen Lizenzen bereit (Bring Your Own License, BYOL) und verwalten die VMs und die Webserversoftware.
Webserver-Binärdateien Eine Filestore-Instanz enthält die Binärdateien des Webservers. Die Filestore-Instanz ist auf allen Compute Engine-VMs bereitgestellt, auf denen die Webserver gehostet werden.
Oracle PeopleSoft-Middletier (BYOL)

Die Oracle PeopleSoft-Mid-Tier-Ebene besteht aus den folgenden Komponenten:

  • OpenSearch
  • Anwendungsserver
  • Prozess-Scheduler

Jede dieser Komponenten wird unabhängig auf zwei Compute Engine-VMs ausgeführt. Sie stellen für die Oracle PeopleSoft-Komponenten Ihre eigenen Lizenzen bereit (Bring Your Own License, BYOL) und verwalten die VMs und die Mid-Tier-Software.
Binärdateien für Geräte der Mittelklasse Eine Filestore-Instanz enthält die Binärdateien der mittleren Ebene. Die Filestore-Instanz wird auf allen Compute Engine-VMs bereitgestellt, auf denen die Mid-Tier-Komponenten gehostet werden.
Anwendungssicherungen Sicherungen der Anwendung werden mit dem Backup- und DR-Dienst erstellt, gespeichert und verwaltet.
VPC-Netzwerk (Virtual Private Cloud) Alle Google Cloud Ressourcen in der Architektur verwenden ein einzelnes VPC-Netzwerk. Die Webserver, die Komponenten der mittleren Ebene und die Datenbanken befinden sich in separaten Subnetzen.
Oracle-Datenbank@Google Cloud

Die Oracle PeopleSoft-Anwendungen lesen Daten aus Oracle-Datenbanken im Oracle Exadata Database Service und schreiben Daten in diese. Sie stellen den Oracle Exadata Database Service mit Oracle Database@Google Cloud bereit. Dieses Cloud Marketplace-Angebot ermöglicht es Ihnen, Oracle-Datenbanken auf von Oracle verwalteter Hardware in einem Google Cloud -Rechenzentrum auszuführen.

Sie verwenden Google Cloud Schnittstellen wie die Google Cloud Console, die Google Cloud CLI und APIs, um Exadata Infrastructure-Instanzen zu erstellen. Oracle richtet die erforderliche Rechen-, Speicher- und Netzwerkinfrastruktur in einem Rechenzentrum in einer Google Cloud -Region auf Hardware ein, die für Ihr Projekt vorgesehen ist, und verwaltet sie.

Um die Latenz zwischen der Anwendung und der Datenbank zu optimieren, stellen Sie die Anwendung in derselben Zone bereit, in der Sie die Exadata-Infrastrukturinstanzen erstellen.
Exadata-Infrastanz Die Exadata-Infrastanzinstanz enthält mindestens zwei physische Datenbankserver und mindestens drei Speicherserver. Diese Server, die im Diagramm nicht dargestellt sind, sind über ein Netzwerk mit niedriger Latenz miteinander verbunden. Wenn Sie die Exadata-Infrastrukturinstanz erstellen, geben Sie die Anzahl der Datenbankserver und Speicherserver an, die bereitgestellt werden müssen.
Exadata-VM-Cluster

In der Exadata-Infrastanzinstanz erstellen Sie einen oder mehrere Exadata-VM-Cluster. Sie können beispielsweise einen separaten Exadata-VM-Cluster erstellen und verwenden, um die Datenbanken zu hosten, die für die einzelnen Geschäftsbereiche erforderlich sind. Jeder Exadata-VM-Cluster enthält eine oder mehrere Oracle Linux-VMs, auf denen Oracle Database-Instanzen gehostet werden.

Wenn Sie einen Exadata-VM-Cluster erstellen, geben Sie Folgendes an:

  • Die Anzahl der Datenbankserver.
  • Die Rechen-, Arbeitsspeicher- und Speicherkapazität, die jeder VM im Cluster zugewiesen werden soll.
  • Das VPC-Netzwerk, mit dem der Cluster verbunden werden muss.
  • Die IP-Adressbereiche der Sicherungs- und Client-Subnetze für den Cluster.

Die VMs in Exadata-VM-Clustern sind keine Compute Engine-VMs.
Oracle Database -Instanzen Sie erstellen und verwalten Oracle Database-Instanzen über die Oracle Cloud Infrastructure (OCI) Console und andere OCI-Schnittstellen. Die Oracle-Datenbanksoftware wird auf den VMs im Exadata-VM-Cluster ausgeführt. Wenn Sie den Exadata-VM-Cluster erstellen, geben Sie die Oracle Grid Infrastructure-Version an und wählen den Lizenztyp aus. Sie können entweder Ihre eigenen Lizenzen verwenden (BYOL) oder sich für das Modell mit Nutzungslizenz entscheiden.
OCI-VCN und Subnetze Wenn Sie einen Exadata-VM-Cluster erstellen, wird automatisch ein virtuelles Cloud-Netzwerk (VCN) von OCI erstellt. Das VCN hat ein Client-Subnetz und ein Backup-Subnetz mit IP-Adressbereichen, die Sie angeben. Das Client-Subnetz wird für die Verbindung von Ihrem VPC-Netzwerk zu den Oracle-Datenbanken verwendet. Das Sicherungs-Subnetz wird verwendet, um Datenbanksicherungen an OCI Object Storage zu senden.
Cloud Router, Partner Interconnect, und OCI DRG Der Traffic zwischen Ihrem VPC-Netzwerk in Google Cloudund dem OCI-VCN wird von einem Cloud Router über ein dynamisches Routing-Gateway (DRG) weitergeleitet, das an das OCI-VCN angehängt ist. Der Traffic fließt über eine Verbindung mit niedriger Latenz, die von Google über Partner Interconnect eingerichtet wird.
Private Cloud DNS-Zone Wenn Sie einen Exadata-VM-Cluster erstellen, wird automatisch eine private Cloud DNS-Zone erstellt. Wenn Ihre Anwendungen Lese- und Schreibanfragen an die Oracle-Datenbanken senden, löst Cloud DNS die Datenbank-Hostnamen in die entsprechenden IP-Adressen auf.
OCI Object Storage und OCI Service Gateway Sicherungen der Oracle Exadata-Datenbanken werden standardmäßig in OCI Object Storage gespeichert. Datenbanksicherungen werden über ein Service Gateway an OCI Object Storage weitergeleitet.
Öffentliches Cloud NAT-Gateway (optional) Die Architektur umfasst ein optionales öffentliches Cloud NAT-Gateway. Das Gateway ermöglicht sichere ausgehende Verbindungen von den Compute Engine-VMs, die nur interne IP-Adressen haben.
Cloud Interconnect oder Cloud VPN Sie können Cloud Interconnect oder Cloud VPN verwenden, um Ihr lokales Netzwerk mit dem VPC-Netzwerk in Google Cloudzu verbinden. Informationen zu den relativen Vorteilen der einzelnen Ansätze finden Sie unter Produkt für Network Connectivity auswählen.
Cloud Monitoring Mit Cloud Monitoring können Sie das Verhalten, den Zustand und die Leistung Ihrer Anwendung und Ihrer Google Cloud Ressourcen, einschließlich der Oracle Exadata-Ressourcen, beobachten. Sie können die Oracle Exadata-Ressourcen auch mit dem OCI Monitoring-Dienst überwachen.

Verwendete Produkte

In dieser Referenzarchitektur werden die folgenden Google Cloud Produkte verwendet:

  • Compute Engine: Ein sicherer und anpassbarer Computing-Dienst, mit dem Sie virtuelle Maschinen in der Infrastruktur von Google erstellen und ausführen können.
  • Cloud Load Balancing: Ein Portfolio von leistungsstarken, skalierbaren, globalen und regionalen Load-Balancern
  • Google Cloud Armor: Ein Netzwerksicherheitsdienst, der WAF-Regeln (Web Application Firewall) bietet und vor DDoS- und Anwendungsangriffen schützt.
  • Virtual Private Cloud (VPC): Ein virtuelles System, das globale, skalierbare Netzwerkfunktionen für Ihre Google Cloud Arbeitslasten bietet. VPC umfasst VPC-Netzwerk-Peering, Private Service Connect, Zugriff auf private Dienste und freigegebene VPC.
  • Cloud Interconnect: Ein Dienst, mit dem Ihr externes Netzwerk über eine hochverfügbare Verbindung mit niedriger Latenz auf das Google-Netzwerk erweitert wird.
  • Partner Interconnect: Ein Dienst, der über einen unterstützten Dienstanbieter eine Verbindung zwischen Ihrem lokalen Netzwerk und Ihren VPC-Netzwerken (Virtual Private Cloud) und anderen Netzwerken herstellt.
  • Cloud VPN: Ein Dienst, mit dem Sie Ihr Peer-Netzwerk über einen IPsec-VPN-Tunnel sicher auf das Google-Netzwerk ausdehnen können.
  • Cloud NAT: Ein Dienst, der eine von Google Cloudverwaltete, leistungsstarke Netzwerkadressübersetzung bietet.
  • Backup and DR Service: Ein sicherer, zentral verwalteter Sicherungs- und Wiederherstellungsdienst für Google Cloud Arbeitslasten, der Sicherungsdaten vor böswilligem oder versehentlichem Löschen schützt.
  • Cloud DNS: Ein Dienst, der stabile DNS-Bereitstellung mit niedriger Latenz über das weltweite Google-Netzwerk bietet.

In dieser Referenzarchitektur werden die folgenden Oracle-Produkte verwendet:

  • Oracle PeopleSoft: Eine Suite von Unternehmensanwendungen für das Personalwesen, Campuslösungen und die Planung von Unternehmensressourcen.
  • Exadata Database Service on Dedicated Infrastructure: Mit diesem Dienst können Sie Oracle Database-Instanzen auf Exadata-Hardware ausführen, die für Sie reserviert ist.
  • VCN und Subnetze: Ein VCN ist ein virtuelles und privates Netzwerk für Ressourcen in einer OCI-Region. Ein Subnetz ist ein zusammenhängender Bereich von IP-Adressen mit einem VCN.
  • Dynamic Routing Gateway: Ein virtueller Router für Traffic zwischen einem VCN und externen Netzwerken.
  • Objektspeicher: Ein Dienst zum Speichern großer Mengen strukturierter und unstrukturierter Daten als Objekte.
  • Servicegateway: Ein Gateway, über das Ressourcen in einem VCN privat auf bestimmte Oracle-Dienste zugreifen können.

Sie sind selbst dafür verantwortlich, die Lizenzen für die Oracle-Produkte zu erwerben, die Sie in Google Cloudbereitstellen, und sind für die Einhaltung der Nutzungsbedingungen der Oracle-Lizenzen verantwortlich.

Designaspekte

In diesem Abschnitt werden Designfaktoren, Best Practices und Designempfehlungen beschrieben, die Sie berücksichtigen sollten, wenn Sie diese Referenzarchitektur verwenden, um eine Topologie zu entwickeln, die Ihren spezifischen Anforderungen an Sicherheit, Zuverlässigkeit, operative Effizienz, Kosten und Leistung entspricht. Berücksichtigen Sie beim Erstellen der Architektur für Ihre Arbeitslast auch die Best Practices und Empfehlungen im Google Cloud Well-Architected Framework.

Systemdesign

Dieser Abschnitt enthält eine Anleitung zur Auswahl von Google Cloud Regionen für Ihre Bereitstellung und zur Auswahl geeigneter Google Cloud Dienste.

Auswahl der Region

Berücksichtigen Sie bei der Auswahl der Google Cloud Regionen, in denen Ihre Anwendungen bereitgestellt werden müssen, die folgenden Faktoren und Anforderungen:

  • Verfügbarkeit von Google Cloud -Diensten in jeder Region. Weitere Informationen finden Sie unter Produktverfügbarkeit nach Standort.
  • Verfügbarkeit von Compute Engine-Maschinentypen in jeder Region. Weitere Informationen finden Sie unter Regionen und Zonen.
  • Latenzanforderungen für den Endnutzer.
  • Kosten für Google Cloud Ressourcen.
  • Kosten für die regionenübergreifende Datenübertragung.
  • Gesetzliche Anforderungen.

Einige dieser Faktoren und Anforderungen können Kompromisse beinhalten. Beispielsweise hat die kostengünstigste Region möglicherweise nicht die niedrigste CO2-Bilanz. Weitere Informationen finden Sie unter Best Practices für die Auswahl der Region in Compute Engine.

Datenbankmigration

Wenn Sie planen, lokale Datenbanken zu Oracle Database@Google Cloud zu migrieren, sollten Sie Ihre aktuelle Datenbankumgebung bewerten und Konfigurations- und Größenempfehlungen mit dem Tool Database Migration Assessment (DMA) abrufen.

Informationen zur Vorgehensweise und zu den Tools, die Sie zum Migrieren von Oracle-Datenbanken zu Google Cloudverwenden können, finden Sie im Oracle Migration Methods Advisor.

Bevor Sie die migrierten Datenbanken in einer Produktionsumgebung verwenden, sollten Sie die Verbindung von Ihren Anwendungen zu den Datenbanken prüfen.

Speicheroptionen

Für die Compute Engine-VMs in der Architektur können Sie Hyperdisk- oder Persistent Disk-Bootlaufwerke verwenden. Hyperdisk-Volumes bieten eine bessere Leistung, Flexibilität und Effizienz als Persistent Disk. Mit Hyperdisk Balanced können Sie IOPS und Durchsatz separat und dynamisch bereitstellen und so das Volume für eine Vielzahl von Arbeitslasten optimieren.

Verwenden Sie Filestore, um Anwendungsbinärdateien zu speichern. Dateien, die Sie in einer Filestore-Regionalinstanz speichern, werden synchron über drei Zonen innerhalb der Region repliziert. Diese Replikation sorgt für hohe Verfügbarkeit und Robustheit bei zonalen Ausfällen. Um die Robustheit bei regionalen Ausfällen zu erhöhen, können Sie eine Filestore-Instanz in eine andere Region replizieren. Weitere Informationen finden Sie unter Instanzreplikation.

Berücksichtigen Sie beim Entwerfen des Speichers für Ihre Arbeitslasten die funktionalen Eigenschaften der Arbeitslasten, Anforderungen an die Ausfallsicherheit, Leistungserwartungen und Kostenziele. Weitere Informationen finden Sie unter Optimale Speicherstrategie für Ihre Cloudarbeitslast entwerfen.

Netzwerkdesign für Oracle Database@Google Cloud

Wählen Sie ein Netzwerkdesign aus, das Ihren geschäftlichen und technischen Anforderungen entspricht. Sie können beispielsweise ein einzelnes VPC-Netzwerk oder mehrere VPC-Netzwerke verwenden. Weitere Informationen finden Sie unter Netzwerktopologien für Oracle Database@Google Cloud auswählen.

Wenn Sie IP-Adressbereiche für die Client- und Sicherungssubnetze zuweisen, die für die Exadata-VM-Cluster verwendet werden sollen, beachten Sie die Mindestanforderungen an die Subnetzgröße. Weitere Informationen finden Sie unter IP-Adressraum in Oracle Database@Google Cloud planen.

Sicherheit, Datenschutz und Compliance

In diesem Abschnitt werden Faktoren beschrieben, die Sie bei der Verwendung dieser Referenzarchitektur berücksichtigen sollten, um eine Topologie in Google Cloud zu entwerfen, die die Sicherheits- und Compliance-Anforderungen Ihrer Arbeitslasten erfüllt.

Schutz vor externen Bedrohungen

Zum Schutz Ihrer Anwendung vor Bedrohungen wie DDoS-Angriffen (Distributed Denial-of-Service) und Cross-Site-Scripting (XSS) können Sie die Sicherheitsrichtlinien von Google Cloud Armor verwenden. Jede Richtlinie besteht aus Regeln, die bestimmte Bedingungen festlegen, die ausgewertet werden sollen, und Aktionen, die ausgeführt werden sollen, wenn die Bedingungen erfüllt sind. Eine Regel könnte beispielsweise festlegen, dass der Traffic abgelehnt werden muss, wenn die Quell-IP-Adresse des eingehenden Traffics mit einer bestimmten IP-Adresse oder einem CIDR-Bereich übereinstimmt. Sie können auch vorkonfigurierte WAF-Regeln (Web Application Firewall) anwenden. Weitere Informationen finden Sie unter Sicherheitsrichtlinien – Übersicht.

Externer Zugriff für VMs

In der Referenzarchitektur, die in diesem Dokument beschrieben wird, benötigen die Compute Engine-VMs keinen eingehenden Zugriff aus dem Internet. Weisen Sie den VMs keine externen IP-Adressen zu. Google Cloud Ressourcen, die nur eine private, interne IP-Adresse haben, können über Private Service Connect oder den privater Google-Zugriff dennoch auf bestimmte Google APIs und Google-Dienste zugreifen. Weitere Informationen finden Sie unter Private Zugriffsoptionen für Dienste.

Um sichere ausgehende Verbindungen von Google Cloud -Ressourcen zu ermöglichen, die nur private IP-Adressen haben, wie die Compute Engine-VMs in dieser Referenzarchitektur, können Sie Secure Web Proxy oder Cloud NAT verwenden.

Für die Subnetze, die von den Exadata-VMs verwendet werden, empfiehlt Oracle, dass Sie private IP-Adressbereiche zuweisen.

Dienstkontoberechtigungen

Für die Compute Engine-VMs in der Architektur empfehlen wir, anstelle der Standarddienstkonten dedizierte Dienstkonten zu erstellen und die Ressourcen anzugeben, auf die das Dienstkonto zugreifen kann. Das Standarddienstkonto hat eine Vielzahl von Berechtigungen, darunter einige, die möglicherweise nicht erforderlich sind. Sie können spezielle Dienstkonten so anpassen, dass sie nur die erforderlichen Berechtigungen haben. Weitere Informationen finden Sie unter Dienstkontoberechtigungen einschränken.

SSH-Sicherheit

Um die Sicherheit von SSH-Verbindungen zu den Compute Engine-VMs in Ihrer Architektur zu erhöhen, implementieren Sie Identity-Aware Proxy (IAP) und die Cloud OS Login API. Mit IAP können Sie den Netzwerkzugriff basierend auf der Nutzeridentität und IAM-Richtlinien (Identity and Access Management) steuern. Mit der Cloud OS Login API können Sie den Linux-SSH-Zugriff anhand von Nutzeridentität und IAM-Richtlinien steuern. Weitere Informationen zum Verwalten des Netzwerkzugriffs finden Sie unter Best Practices für die Steuerung des SSH-Anmeldezugriffs.

Datenverschlüsselung

Standardmäßig werden die in Hyperdisk, nichtflüchtigem Speicher und Filestore gespeicherten Daten mitGoogle-owned and Google-managed encryption keysverschlüsselt. Als zusätzliche Schutzebene können Sie die Google-owned and managed key mithilfe von Schlüsseln verschlüsseln, die Ihnen gehören und die Sie im Cloud Key Management Service (Cloud KMS) verwalten. Weitere Informationen finden Sie unter Datenträgerverschlüsselung für Hyperdisk- und Persistent Disk-Volumes und unter Daten mit vom Kunden verwalteten Verschlüsselungsschlüsseln verschlüsseln für Filestore.

Standardmäßig verwenden Exadata-Datenbanken Transparent Data Encryption (TDE), mit der Sie sensible Daten verschlüsseln können, die in Tabellen und Tablespaces gespeichert sind.

Netzwerksicherheit

Zur Steuerung des Netzwerk-Traffics zwischen den Ressourcen in der Architektur müssen Sie geeignete Cloud Next Generation Firewall-Richtlinien (NGFW) konfigurieren.

Achten Sie bei den Webserver-VMs darauf, dass das Quellfeld der Ingress-Richtlinie Folgendes enthält:

Sicherheit und Compliance von Oracle Exadata

Oracle Exadata Database Service umfasst Oracle Data Safe, mit dem Sie Sicherheits- und Compliance-Anforderungen für Oracle-Datenbanken verwalten können. Mit Oracle Data Safe können Sie Sicherheitskontrollen bewerten, Nutzeraktivitäten überwachen und sensible Daten maskieren. Weitere Informationen finden Sie unter Datenbanksicherheit mit Oracle Data Safe verwalten.

Weitere Sicherheitsaspekte

Beachten Sie beim Erstellen der Architektur für Ihre Arbeitslast die Best Practices und Empfehlungen zur Sicherheit auf Plattformebene, die im Enterprise Foundations Blueprint und im Google Cloud Well-Architected Framework: Sicherheit, Datenschutz und Compliance enthalten sind.

Zuverlässigkeit

In diesem Abschnitt werden Designfaktoren beschrieben, die Sie bei der Verwendung dieser Referenzarchitektur zum Erstellen und Betreiben einer zuverlässigen Infrastruktur für Ihre Bereitstellung inGoogle Cloudberücksichtigen sollten.

Robustheit der Anwendungsschicht bei VM-Fehlern

Wenn eine der beiden VMs, auf denen die einzelnen Oracle PeopleSoft-Komponenten gehostet werden, ausfällt, ist die Anwendung weiterhin verfügbar. Anfragen werden an die andere VM weitergeleitet.

Manchmal wird eine VM ausgeführt und ist verfügbar, es können jedoch Probleme mit der Oracle PeopleSoft-Komponente selbst auftreten. Die Komponente kann einfrieren, abstürzen oder nicht genügend Arbeitsspeicher haben. In diesen Szenarien reagiert die VM nicht auf die Systemdiagnosen des Load Balancer und der Load Balancer leitet den Traffic nicht an die nicht reagierende VM weiter.

Robustheit bei zonalen oder regionalen Ausfällen

Wenn ein zonaler oder regionaler Ausfall auftritt, ist die Anwendung nicht verfügbar. Sie können Ausfallzeiten durch solche Ausfälle reduzieren, indem Sie Folgendes implementieren:

  • Pflegen Sie ein passives (Failover-)Replikat des Anwendungs-Stacks in einer anderenGoogle Cloud Region oder ‑Zone.
  • Erstellen Sie eine Standby-Exadata-Infrastrukturinstanz mit den erforderlichen Exadata-VM-Clustern in derselben Zone, in der sich das passive Replikat des Anwendungsstacks befindet. Verwenden Sie Oracle Active Data Guard für die Datenreplikation und das automatische Failover zu den Exadata-Standby-Datenbanken. Wenn Ihre Anwendung ein niedrigeres Recovery Point Objective (RPO) erfordert, können Sie die Datenbanken mit dem Oracle Autonomous Recovery Service sichern und wiederherstellen.
  • Wenn ein Ausfall in der primären Region oder Zone auftritt, verwenden Sie das Datenbankreplikat oder die Sicherung, um die Datenbank in der Produktion wiederherzustellen und die Anwendung in der Failover-Region oder -Zone zu aktivieren.
  • Wenn sich das passive Replikat in einer anderen Region befindet, verwenden Sie Cloud DNS-Routingrichtlinien, um Traffic an den externen Load Balancer in dieser Region weiterzuleiten.

Weitere Informationen finden Sie unter Oracle Maximum Availability Architecture (MAA) for Oracle Database@Google Cloud.

Oracle verwaltet die Infrastruktur in Oracle Database@Google Cloud. Informationen zu den Service Level Objectives (SLOs) für Oracle Exadata Database Service auf Dedicated Infrastructure finden Sie unter Service Level Objectives for Oracle PaaS and IaaS Public Cloud Services.

VM-Kapazitätsplanung

Damit die Kapazität für Compute Engine-VMs verfügbar ist, wenn VMs bereitgestellt werden müssen, können Sie Reservierungen erstellen. Eine Reservierung bietet zugesicherte Kapazität in einer bestimmten Zone für eine bestimmte Anzahl von VMs eines von Ihnen ausgewählten Maschinentyps. Eine Reservierung kann für ein Projekt spezifisch sein oder für mehrere Projekte freigegeben sein. Weitere Informationen zu Reservierungen finden Sie unter Reservierungstyp auswählen.

Oracle Exadata-Kapazität

Sie können die Exadata-Infrastruktur skalieren, indem Sie nach Bedarf Datenbankserver und Speicherserver hinzufügen. Nachdem Sie die erforderlichen Datenbankserver oder Speicherserver zur Exadata-Infrastruktur hinzugefügt haben, müssen Sie die Kapazität dem zugehörigen Exadata-VM-Cluster hinzufügen, um die zusätzlichen CPU- oder Speicherressourcen nutzen zu können. Weitere Informationen finden Sie unter Exadata-Compute- und ‑Speicher skalieren.

Datenhaltbarkeit

Sie können den Backup- und DR-Dienst verwenden, um Sicherungen der Compute Engine-VMs zu erstellen, zu speichern und zu verwalten. Bei Sicherung und Notfallwiederherstellung werden Sicherungsdaten in ihrem ursprünglichen, für Anwendungen lesbaren Format gespeichert. Bei Bedarf können Sie Ihre Arbeitslasten in der Produktion wiederherstellen, indem Sie Daten aus dem langfristigen Sicherungsspeicher direkt verwenden, ohne zeitaufwendige Datenverschiebungen oder Vorbereitungsaktivitäten zu erledigen. Weitere Informationen finden Sie unter Backup und DR für Compute Engine-Instanzsicherungen.

Um die Langlebigkeit von Daten in Ihren Filestore-Instanzen zu gewährleisten, können Sie Sicherungen und Snapshots der Instanz erstellen oder Backup and DR für Filestore und Dateisysteme verwenden.

Standardmäßig werden Sicherungen von Datenbanken in Oracle Exadata Database Service auf Dedicated Infrastructure in OCI Object Storage gespeichert. Um einen niedrigeren RPO zu erreichen, können Sie die Datenbanken mit dem Oracle Autonomous Recovery Service sichern und wiederherstellen.

Weitere Überlegungen zur Zuverlässigkeit

Lesen Sie beim Erstellen der Cloud-Architektur für Ihre Arbeitslast die zuverlässigsten Best Practices und Empfehlungen in der folgenden Dokumentation:

Kostenoptimierung

Dieser Abschnitt enthält Anleitungen zur Optimierung der Kosten für die Einrichtung und den Betrieb einer Google Cloud Topologie, die Sie mithilfe dieser Referenzarchitektur erstellen.

VM-Maschinentypen

Damit Sie die Ressourcennutzung Ihrer VM-Instanzen optimieren können, bietet Compute Engine Empfehlungen für Maschinentypen. Wählen Sie anhand der Empfehlungen Maschinentypen aus, die den Computing-Anforderungen Ihrer Arbeitslast entsprechen. Bei Arbeitslasten mit vorhersehbaren Ressourcenanforderungen können Sie den Maschinentyp mithilfe von benutzerdefinierten Maschinentypen an Ihre Anforderungen anpassen und Kosten sparen.

Oracle-Produktlizenzen

Sie sind selbst dafür verantwortlich, die Lizenzen für die Oracle-Produkte zu erwerben, die Sie in der Compute Engine bereitstellen, und sind für die Einhaltung der Nutzungsbedingungen der Oracle-Lizenzen verantwortlich. Weitere Informationen finden Sie unter Oracle-Software in der Cloud-Computing-Umgebung lizenzieren.

Lizenzierung von Oracle Exadata-Datenbanken

Wenn Sie einen Exadata-VM-Cluster erstellen, können Sie entweder Ihre eigene Lizenz (Bring Your Own License, BYOL) verwenden oder eine Lizenz, die Sie im Rahmen Ihrer Google Cloud Marketplace-Bestellung für Oracle Database@Google Cloud erworben haben.

Netzwerkgebühren für die Datenübertragung zwischen Ihren Anwendungen und Oracle Exadata-Datenbanken in derselben Region sind im Preis des Oracle Database@Google Cloud-Angebots enthalten.

Weitere Kostengesichtspunkte

Berücksichtigen Sie beim Erstellen der Architektur für Ihre Arbeitslast auch die allgemeinen Best Practices und Empfehlungen, die im Google Cloud Well-Architected Framework: Kostenoptimierung bereitgestellt werden.

Operative Effizienz

In diesem Abschnitt werden die Faktoren beschrieben, die Sie bei der Verwendung dieser Referenzarchitektur zum Entwerfen einer Google Cloud Topologie berücksichtigen sollten, die Sie effizient betreiben können.

Oracle Linux-Images

Für Ihre VMs können Sie Oracle Linux-Images verwenden, die in Compute Engine verfügbar sind, oder Oracle Linux-Images importieren, die Sie selbst erstellen und verwalten. Sie können auch benutzerdefinierte Betriebssystem-Images erstellen und verwenden, die die Konfigurationen und Software enthalten, die Ihre Anwendungen benötigen. Sie können Ihre benutzerdefinierten Images in einer benutzerdefinierten Image-Familie zusammenfassen. Die Image-Familie verweist immer auf das neueste Image in dieser Familie. Ihre Instanzvorlagen und -skripte können dieses Image daher verwenden, ohne dass Verweise auf eine bestimmte Image-Version aktualisiert werden müssen. Sie müssen Ihre benutzerdefinierten Images regelmäßig aktualisieren, um die Sicherheitsupdates und Patches des Betriebssystemanbieters zu berücksichtigen.

Oracle Exadata-Datenbankverwaltung

Oracle verwaltet die physischen Datenbankserver, Speicherserver und Netzwerkhardware in Oracle Exadata Database Service on Dedicated Infrastructure. Sie können die Exadata-Infrastrukturinstanzen und die Exadata-VM-Cluster über die OCI- oder Google Cloud -Schnittstellen verwalten. Sie erstellen und verwalten Datenbanken über die OCI-Schnittstellen. Die Google Cloud Konsolenseiten für Oracle Database@Google Cloud enthalten Links, über die Sie direkt zu den entsprechenden Seiten in der OCI-Konsole gelangen. Damit Sie sich nicht noch einmal bei OCI anmelden müssen, können Sie die Identitätsföderation zwischen OCI und Google Cloudkonfigurieren.

Beobachtbarkeit für Oracle-Anwendungen

Um die Observability für Oracle-Arbeitslasten zu implementieren, die in Google Cloudbereitgestellt werden, können Sie Google Cloud Observability-Dienste oder Oracle Enterprise Manager verwenden. Wählen Sie je nach Ihren Anforderungen und Einschränkungen eine geeignete Monitoringstrategie aus. Wenn Sie beispielsweise neben Oracle-Arbeitslasten auch andere Arbeitslasten in Google Cloud ausführen, können Sie mit Google Cloud Observability-Diensten ein einheitliches Betriebs-Dashboard für alle Arbeitslasten erstellen.

Oracle-Dokumentation und ‑Support

Für Oracle-Produkte, die auf Compute Engine-VMs ausgeführt werden, gelten ähnliche operative Anforderungen wie für Oracle-Produkte, die lokal ausgeführt werden. Sie müssen jedoch die zugrunde liegende Rechen-, Netzwerk- und Speicherinfrastruktur nicht verwalten. Informationen zum Betreiben und Verwalten von Oracle-Produkten finden Sie in der entsprechenden Oracle-Dokumentation.

Informationen zur Supportrichtlinie von Oracle für Oracle Database-Instanzen, die Sie in Google Cloudbereitstellen, finden Sie unter Oracle Database Support for Non-Oracle Public Cloud Environments (Doc ID 2688277.1).

Weitere operative Aspekte

Berücksichtigen Sie beim Erstellen der Architektur für Ihre Arbeitslast die allgemeinen Best Practices und Empfehlungen für die betriebliche Effizienz, die im Google Cloud Well-Architected Framework: Operative Exzellenz beschrieben werden.

Leistungsoptimierung

In diesem Abschnitt werden die Faktoren beschrieben, die Sie berücksichtigen sollten, wenn Sie diese Referenzarchitektur zum Entwerfen einer Topologie in Google Cloud verwenden, die die Leistungsanforderungen Ihrer Arbeitslasten erfüllt.

Rechenleistung

Compute Engine bietet eine breite Palette vordefinierter und anpassbarer Maschinentypen für die Arbeitslasten, die Sie auf VMs ausführen. Wählen Sie einen geeigneten Maschinentyp basierend auf Ihren Leistungsanforderungen aus. Weitere Informationen finden Sie im Leitfaden zu Ressourcen und Vergleichen für Maschinenfamilien.

Netzwerkleistung

Die Compute Engine hat ein pro VM festgelegtes Limit für die Netzwerkbandbreite für ausgehenden Traffic. Dieses Limit hängt vom Maschinentyp der VM und davon ab, ob der Traffic über dasselbe VPC-Netzwerk wie die Quell-VM geleitet wird. Bei VMs mit bestimmten Maschinentypen können Sie die maximale Bandbreite für ausgehenden Traffic erhöhen, indem Sie Tier_1-Netzwerke aktivieren. Weitere Informationen finden Sie unter Netzwerkleistung pro VM-Tier_1 konfigurieren.

Der Netzwerk-Traffic zwischen den Anwendungs-VMs und dem Oracle Exadata-Netzwerk wird über eine Partner Interconnect-Verbindung mit niedriger Latenz weitergeleitet, die von Google eingerichtet wird.

Die Exadata-Infrastruktur verwendet RDMA over Converged Ethernet (RoCE) für die Vernetzung mit hoher Bandbreite und niedriger Latenz zwischen den Datenbank- und Speicherservern. Die Server tauschen Daten direkt im Hauptspeicher aus, ohne dass der Prozessor, der Cache oder das Betriebssystem beteiligt sind.

Um die Latenz zwischen Ihrer Anwendung und der Datenbank zu optimieren, stellen Sie die Anwendung in derselben Zone bereit, in der Sie die Exadata-Infrastrukturinstanz erstellen.

Weitere Hinweise zur Leistung

Berücksichtigen Sie beim Erstellen der Architektur für Ihre Arbeitslast die allgemeinen Best Practices und Empfehlungen, die im Google Cloud Well-Architected Framework: Leistungsoptimierung bereitgestellt werden.

Nächste Schritte

Beitragende

Autor: Kumar Dhanagopal | Cross-product Solution Developer

Weitere Beitragende: