Oracle E-Business Suite mit Oracle Database auf Compute Engine-VMs

Last reviewed 2025-05-27 UTC

Dieses Dokument enthält Referenzarchitekturen, die Ihnen beim Erstellen der Infrastruktur für die Ausführung von Oracle E‑Business Suite-Anwendungen mit Oracle Database auf Compute Engine-VMs in Google Cloudhelfen. Die Oracle E‑Business Suite ist eine Suite von Unternehmensanwendungen für Geschäftsfunktionen wie Finanzen, Personalwesen, Lieferkette und Kundenbeziehung.

Dieses Dokument richtet sich an Cloud-Architekten und Administratoren von Oracle-Datenbanken und Oracle E‑Business Suite-Anwendungen. In diesem Dokument wird davon ausgegangen, dass Ihr Team mit Oracle Database und dem Technologiestack und der Architektur der Oracle E‑Business Suite vertraut ist.

Wenn Sie Oracle Exadata oder Oracle Real Application Clusters (Oracle RAC) verwenden müssen, können Sie Ihre Anwendungen zu Google Cloud migrieren und Ihre Datenbanken in Oracle Database@Google Cloud ausführen. Weitere Informationen finden Sie unter Oracle E‑Business Suite with Oracle Exadata in Google Cloud.

Architektur

Je nach Anwendungsfall und Anforderungen an Verfügbarkeit und Notfallwiederherstellung (Disaster Recovery, DR) können Sie einen der folgenden Google Cloud Bereitstellungsarchetypen auswählen, um Oracle E‑Business Suite-Anwendungen auf Google Cloudauszuführen:

  • Zonal: Ihre Anwendungen werden in einer einzigen Google CloudZone ausgeführt. Dieser Bereitstellungs-Archetyp eignet sich gut für Entwicklungs- und Testumgebungen sowie für nicht kritische Anwendungen, die keine hohe Verfügbarkeit erfordern.
  • Regional: Ihre Anwendungen werden unabhängig voneinander in zwei oder mehr Zonen innerhalb einer einzelnen Google Cloud-Region ausgeführt. Wir empfehlen diesen Bereitstellungs-Archetyp für Anwendungen, die nicht geschäftskritisch sind, aber vor Zonenausfällen geschützt sein müssen.
  • Multiregional: Ihre Anwendungen werden unabhängig in mehreren Zonen in zwei oder mehr Google Cloud Regionen ausgeführt, entweder im Aktiv-Aktiv- oder im Aktiv-Passiv-Modus. Dieser Bereitstellungsarchetyp ist ideal für Notfallwiederherstellungsszenarien. Wir empfehlen diesen Archetyp für geschäftskritische Anwendungen, die vor regionalen Ausfällen und Katastrophen geschützt sein müssen.

Die Auswahl eines Bereitstellungs-Archetyps vereinfacht nachfolgende Entscheidungen in Bezug auf die Google Cloud -Produkte und -Features, die Sie für Ihre Architektur benötigen.

In den folgenden Abschnitten werden vier Architekturoptionen vorgestellt. Jede Option basiert auf einem der Deployment-Archetypen:

Zonale Architektur

Das folgende Diagramm zeigt eine Architektur für Oracle E‑Business Suite-Anwendungen mit Oracle Database, die in einer einzelnen Zone in einerGoogle Cloud -Region ausgeführt werden. Diese Architektur ist am Archetyp für zonale Bereitstellungen ausgerichtet.

Eine Architektur für Oracle E‑Business Suite-Anwendungen wird in einer einzelnen Zone in einer Google Cloud -Region ausgeführt.

Die Architektur im vorherigen Diagramm umfasst die folgenden Komponenten:

Komponente Beschreibung
Regionaler externer Application Load Balancer Der Load Balancer empfängt und verteilt Nutzeranfragen an die Oracle E‑Business Suite-Anwendungen.
Google Cloud Armor-Sicherheitsrichtlinie Mit der Google Cloud Armor-Sicherheitsrichtlinie können Sie Ihre Anwendungen vor Bedrohungen wie DDoS-Angriffen und XSS schützen.
Oracle E‑Business Suite (BYOL)

Die Komponenten der Anwendungsebene der Oracle E‑Business Suite (Oracle HTTP Server, Oracle WebLogic Server und ein Server für die gleichzeitige Verarbeitung) werden auf Compute Engine-VMs ausgeführt. Jede VM hostet eine unabhängige Instanz der Anwendungsebene. Das Bootlaufwerk für jede VM ist ein Google Cloud Hyperdisk-Volume.

Sie stellen für Oracle E‑Business Suite Ihre eigenen Lizenzen bereit (Bring Your Own License, BYOL) und verwalten die VMs und die Anwendungen.
Binärdateien und Daten von Anwendungen Eine zonale Filestore-Instanz enthält die Anwendungsbinärdateien und -daten. Die Filestore-Instanz wird auf den Compute Engine-VMs bereitgestellt, auf denen die Komponenten der Anwendungsebene gehostet werden.
Oracle-Datenbank (BYOL)

Die Oracle E‑Business Suite-Anwendungen verwenden eine Oracle Database-Instanz, die auf einer Compute Engine-VM bereitgestellt wird. Das Boot- und das Datenlaufwerk für die VM sind Hyperdisk-Volumes.

Sie stellen für die Oracle Database-Instanz Ihre eigene Lizenz bereit (Bring Your Own License, BYOL) und verwalten die VM und die Datenbank.
Anwendungs- und Datenbanksicherungen Sicherungen der Anwendungsdaten und der Datenbank werden mit dem Backup- und DR-Dienst erstellt, gespeichert und verwaltet.
VPC-Netzwerk (Virtual Private Cloud) und Subnetze

Alle Google Cloud Ressourcen in der Architektur verwenden ein einzelnes VPC-Netzwerk. Die VMs, auf denen die Anwendungsebene und die Datenbank gehostet werden, verwenden separate Subnetze.

Je nach Ihren Anforderungen können Sie eine Architektur erstellen, die mehrere VPC-Netzwerke verwendet. Weitere Informationen finden Sie unter Entscheiden, ob mehrere VPC-Netzwerke erstellt werden sollen.
Öffentliches NAT-Gateway Die Architektur umfasst ein öffentliches Cloud NAT-Gateway für sichere ausgehende Verbindungen von den Compute Engine-VMs, die nur interne IP-Adressen haben. Die VMs können beispielsweise auf den Oracle Linux Yum-Server zugreifen, um Betriebssystempakete herunterzuladen.
Cloud Interconnect und Cloud VPN Sie können Cloud Interconnect oder Cloud VPN verwenden, um Ihr lokales Netzwerk mit dem VPC-Netzwerk inGoogle Cloudzu verbinden. Informationen zu den relativen Vorteilen der einzelnen Ansätze finden Sie unter Produkt für Network Connectivity auswählen.

Zonale Architektur mit einer DMZ

Das folgende Diagramm zeigt eine Architektur mit zwei unabhängigen Oracle E‑Business Suite-Anwendungsebenen, die auf Compute Engine-VMs ausgeführt werden. Eine der Anwendungsebenen ist eine demilitarisierte Zone (DMZ), die externe Nutzer der Oracle E‑Business Suite-Anwendungen bedient. Die andere Ebene ist für interne Nutzer vorgesehen. Beide Anwendungsebenen werden in einer einzelnen Zone in einer Google Cloud -Region ausgeführt und verwenden eine einzelne Oracle Database-Instanz. Wie die Architektur im vorherigen Abschnitt ist diese Architektur am Archetyp für zonale Bereitstellungen ausgerichtet.

Eine Architektur für Oracle E‑Business Suite-Anwendungen wird in einer einzelnen Zone mit einer DMZ in einer Google Cloud -Region ausgeführt.

Die Architektur im vorherigen Diagramm umfasst die folgenden Komponenten:

Komponente Beschreibung
Regionaler externer Application Load Balancer Der externe Load Balancer empfängt und verteilt Anfragen von externen Nutzern an die externe Anwendungsebene.
Regionaler interner Application Load Balancer Der interne Load Balancer empfängt und verteilt Anfragen von internen Nutzern an eine interne Anwendungsschicht.
Google Cloud Armor-Sicherheitsrichtlinie Mit der Google Cloud Armor-Sicherheitsrichtlinie können Sie Ihre Anwendungen vor externen Bedrohungen wie DDoS-Angriffen und XSS schützen.
Oracle E‑Business Suite (BYOL)

Die Komponenten der Anwendungsebene der Oracle E‑Business Suite (Oracle HTTP Server, Oracle WebLogic Server und ein Server für die gleichzeitige Verarbeitung) werden auf Compute Engine-VMs ausgeführt. Jede VM hostet eine unabhängige Instanz der Anwendungsebene. Die internen und externen Anwendungen werden von unterschiedlichen VM-Gruppen bereitgestellt. Das Bootlaufwerk für jede VM ist ein Hyperdisk-Volume.

Sie stellen für Oracle E‑Business Suite Ihre eigenen Lizenzen bereit (Bring Your Own License, BYOL) und verwalten die VMs und die Anwendungen.
Binärdateien und Daten von Anwendungen Eine zonale Filestore-Instanz enthält die Anwendungsbinärdateien und -daten. Die Filestore-Instanz wird auf den Compute Engine-VMs bereitgestellt, auf denen die Komponenten der Anwendungsebene gehostet werden.
Oracle-Datenbank (BYOL)

Die Oracle E‑Business Suite-Anwendungen verwenden eine Oracle Database-Instanz, die auf einer Compute Engine-VM bereitgestellt wird. Das Boot- und das Datenlaufwerk für die VM sind Hyperdisk-Volumes.

Sie stellen für die Oracle Database-Instanz Ihre eigene Lizenz bereit (Bring Your Own License, BYOL) und verwalten die VM und die Datenbank.
Anwendungs- und Datenbanksicherungen Sicherungen der Anwendungsdaten und der Datenbank werden mit Backup and DR erstellt, gespeichert und verwaltet.
VPC-Netzwerk (Virtual Private Cloud) und Subnetze

Alle Google Cloud Ressourcen in der Architektur verwenden ein einzelnes VPC-Netzwerk. Die VMs, auf denen die Anwendungsebene und die Datenbank gehostet werden, verwenden separate Subnetze.

Je nach Ihren Anforderungen können Sie eine Architektur erstellen, die mehrere VPC-Netzwerke verwendet. Weitere Informationen finden Sie unter Entscheiden, ob mehrere VPC-Netzwerke erstellt werden sollen.
Öffentliches NAT-Gateway Die Architektur umfasst ein öffentliches Cloud NAT-Gateway für sichere ausgehende Verbindungen von den Compute Engine-VMs, die nur interne IP-Adressen haben. Die VMs können beispielsweise auf den Oracle Linux Yum-Server zugreifen, um Betriebssystempakete herunterzuladen.
Cloud Interconnect und Cloud VPN Sie können Cloud Interconnect oder Cloud VPN verwenden, um Ihr lokales Netzwerk mit dem VPC-Netzwerk inGoogle Cloudzu verbinden. Administratoren und interne Anwendungsnutzer verwenden diese Verbindungen, um auf die Ressourcen bzw. Anwendungen zuzugreifen. Informationen zu den relativen Vorteilen der einzelnen Ansätze finden Sie unter Produkt für Network Connectivity auswählen.

Regionale Architektur

Das folgende Diagramm zeigt eine Architektur, in der Oracle E‑Business Suite-Anwendungen im Aktiv/Aktiv-Modus auf Compute Engine-VMs ausgeführt werden, die auf zwei Zonen innerhalb einer Google Cloud -Region verteilt sind. Für beide Anwendungsbereitstellungen wird eine primäre Oracle Database-Instanz verwendet, die auf einer VM in einer der Zonen ausgeführt wird. Oracle Data Guard verwaltet die Replikation und das Failover der Datenbank zu einer Oracle Database-Standby-Instanz in der zweiten Zone. Diese Architektur basiert auf dem Archetyp für regionale Bereitstellungen.

Eine Architektur für Oracle E‑Business Suite-Anwendungen, die in zwei Zonen in einer Google Cloud -Region ausgeführt werden.

Die Architektur im vorherigen Diagramm umfasst die folgenden Komponenten:

Komponente Beschreibung
Regionaler externer Application Load Balancer Der Load Balancer empfängt und verteilt Nutzeranfragen an die Oracle E‑Business Suite-Anwendungen.
Google Cloud Armor-Sicherheitsrichtlinie Mit der Google Cloud Armor-Sicherheitsrichtlinie können Sie Ihre Anwendungen vor Bedrohungen wie DDoS-Angriffen (Distributed Denial of Service) und Cross-Site-Scripting (XSS) schützen.
Oracle E‑Business Suite (BYOL)

Die Komponenten der Anwendungsebene von Oracle E‑Business Suite (Oracle HTTP Server, Oracle WebLogic Server und ein Server für die gleichzeitige Verarbeitung) werden auf Compute Engine-VMs ausgeführt, die auf zwei Zonen verteilt sind. Jede VM hostet eine unabhängige Instanz der Anwendungsebene. Das Bootlaufwerk für jede VM ist ein Hyperdisk-Volume.

Sie stellen für Oracle E‑Business Suite Ihre eigenen Lizenzen bereit (Bring Your Own License, BYOL) und verwalten die VMs und die Anwendungen.
Binärdateien und Daten von Anwendungen Eine regionale Filestore-Instanz enthält die Anwendungsbinärdateien und -daten. Die Filestore-Instanz wird auf allen Compute Engine-VMs bereitgestellt, auf denen die Komponenten der Anwendungsebene in beiden Zonen gehostet werden.
Oracle-Datenbank (BYOL)

Die Oracle E‑Business Suite-Anwendungen verwenden ein Primär/Standby-Paar von Oracle Database-Instanzen, die auf Compute Engine-VMs in separaten Zonen bereitgestellt werden. Die Boot- und Datenlaufwerke für die VM sind Hyperdisk-Volumes.

Oracle Data Guard verwaltet die Replikation und das Failover der Datenbank von der primären Instanz zur Standby-Instanz.

Sie stellen für die Oracle Database-Instanzen Ihre eigenen Lizenzen bereit (Bring Your Own License, BYOL) und verwalten die VMs und Datenbanken.
Anwendungs- und Datenbanksicherungen Sicherungen der Anwendungsdaten und der Datenbank werden mit Backup and DR erstellt, gespeichert und verwaltet.
VPC-Netzwerk (Virtual Private Cloud) und Subnetze

Alle Google Cloud Ressourcen in der Architektur verwenden ein einzelnes VPC-Netzwerk. Die VMs, auf denen die Anwendungsebene und die Datenbank gehostet werden, verwenden separate Subnetze.

Je nach Ihren Anforderungen können Sie eine Architektur erstellen, die mehrere VPC-Netzwerke verwendet. Weitere Informationen finden Sie unter Entscheiden, ob mehrere VPC-Netzwerke erstellt werden sollen.
Öffentliches NAT-Gateway Die Architektur umfasst ein öffentliches Cloud NAT-Gateway für sichere ausgehende Verbindungen von den Compute Engine-VMs, die nur interne IP-Adressen haben. Die VMs können beispielsweise auf den Oracle Linux Yum-Server zugreifen, um Betriebssystempakete herunterzuladen.
Cloud Interconnect und Cloud VPN Sie können Cloud Interconnect oder Cloud VPN verwenden, um Ihr lokales Netzwerk mit dem VPC-Netzwerk inGoogle Cloudzu verbinden. Informationen zu den relativen Vorteilen der einzelnen Ansätze finden Sie unter Produkt für Network Connectivity auswählen.

Multiregionale Aktiv-Passiv-Architektur (DR)

Das folgende Diagramm zeigt eine Architektur, in der Oracle E‑Business Suite-Anwendungen im Aktiv/Aktiv-Modus auf Compute Engine-VMs ausgeführt werden, die auf zwei Zonen innerhalb einer Google Cloud -Region verteilt sind. Für beide Anwendungsbereitstellungen wird eine primäre Oracle Database-Instanz verwendet, die auf einer VM in einer der Zonen ausgeführt wird. Oracle Data Guard verwaltet die Replikation und das Failover der Datenbank zu einer Oracle Database-Standby-Instanz in der zweiten Zone. Die Architektur umfasst eine kleinere Replik des Anwendungsstacks in einer Remote-Region (Failover-Region) für die Notfallwiederherstellung. Wie die Architektur im vorherigen Abschnitt basiert diese Architektur auf dem Archetyp für die regionale Bereitstellung.

Eine Architektur für Oracle E‑Business Suite-Anwendungen wird in zwei Zonen in einer Google Cloud -Region mit einem Replikat in einer Remote-Region für die Notfallwiederherstellung ausgeführt.

Die Architektur im vorherigen Diagramm umfasst die folgenden Komponenten:

Komponente Beschreibung
DNS-Failover-Routingrichtlinie Eine öffentliche Cloud DNS-Zone, die mit einer Failover-Routingrichtlinie konfiguriert ist, leitet Nutzeranfragen an den Load Balancer in der Region weiter, in der Anfragen derzeit verarbeitet werden.
Regionaler externer Application Load Balancer Der Load Balancer empfängt und verteilt Nutzeranfragen an die Oracle E‑Business Suite-Anwendungen.
Google Cloud Armor-Sicherheitsrichtlinie Mit der Google Cloud Armor-Sicherheitsrichtlinie können Sie Ihre Anwendungen vor Bedrohungen wie DDoS-Angriffen (Distributed Denial of Service) und Cross-Site-Scripting (XSS) schützen.
Oracle E‑Business Suite (BYOL)

Die Komponenten der Anwendungsebene von Oracle E‑Business Suite (Oracle HTTP Server, Oracle WebLogic Server und ein Server für die gleichzeitige Verarbeitung) werden auf Compute Engine-VMs ausgeführt, die auf zwei Zonen in der primären Region verteilt sind. Jede VM hostet eine unabhängige Instanz der Anwendungsebene. Das Bootlaufwerk für jede VM ist ein Hyperdisk-Volume.

Sie stellen für Oracle E‑Business Suite Ihre eigenen Lizenzen bereit (Bring Your Own License, BYOL) und verwalten die VMs und die Anwendungen.
Binärdateien und Daten von Anwendungen

Eine regionale Filestore-Instanz in der primären Region enthält die Anwendungsbinärdateien und -daten. Die Filestore-Instanz wird auf allen Compute Engine-VMs bereitgestellt, auf denen die Komponenten der Anwendungsebene in beiden Zonen in der primären Region gehostet werden. Die Filestore-Instanz wird in die Failover-Region repliziert.
Oracle-Datenbank (BYOL)

Die Oracle E‑Business Suite-Anwendungen verwenden ein Primär/Standby-Paar von Oracle Database-Instanzen, die auf Compute Engine-VMs in separaten Zonen in der primären Region bereitgestellt werden. Das Boot- und die Datenlaufwerke für die VM sind Hyperdisk-Volumes.

Oracle Data Guard verwaltet die Replikation und das Failover der Datenbank von der primären Instanz zur Standby-Instanz.

Sie stellen für die Oracle Database-Instanzen Ihre eigenen Lizenzen bereit (Bring Your Own License, BYOL) und verwalten die VMs und Datenbanken.
Anwendungs- und Datenbanksicherungen Sicherungen der Anwendungsdaten und der Datenbank werden mit Backup and DR erstellt, gespeichert und verwaltet.
VPC-Netzwerk (Virtual Private Cloud) und Subnetze

Alle Google Cloud Ressourcen in der Architektur verwenden ein einzelnes VPC-Netzwerk. Die VMs, auf denen die Anwendungsebene und die Datenbank gehostet werden, verwenden separate regionale Subnetze.

Je nach Ihren Anforderungen können Sie eine Architektur erstellen, die mehrere VPC-Netzwerke verwendet. Weitere Informationen finden Sie unter Entscheiden, ob mehrere VPC-Netzwerke erstellt werden sollen.
Öffentliches NAT-Gateway Die Architektur umfasst ein öffentliches Cloud NAT-Gateway in jeder Region für sichere ausgehende Verbindungen von den Compute Engine-VMs, die nur interne IP-Adressen haben. Die VMs können beispielsweise auf den Oracle Linux Yum-Server zugreifen, um Betriebssystempakete herunterzuladen.
Cloud Interconnect und Cloud VPN Sie können Cloud Interconnect oder Cloud VPN verwenden, um Ihr lokales Netzwerk mit dem VPC-Netzwerk inGoogle Cloudzu verbinden. Informationen zu den relativen Vorteilen der einzelnen Ansätze finden Sie unter Produkt für Network Connectivity auswählen.

Verwendete Produkte

In diesen Referenzarchitekturen werden die folgenden Produkte verwendet: Google Cloud

  • Compute Engine: Ein sicherer und anpassbarer Computing-Dienst, mit dem Sie virtuelle Maschinen in der Infrastruktur von Google erstellen und ausführen können.
  • Google Cloud Hyperdisk: Ein Netzwerkspeicherdienst, mit dem Sie Blockspeichervolumes mit konfigurierbarer und vorhersehbarer Leistung bereitstellen und dynamisch skalieren können.
  • Filestore: Ein Dienst, der leistungsstarken, vollständig verwalteten Dateispeicher auf Google Cloud bietet, mit dem Sie eine Verbindung zu verschiedenen Clienttypen herstellen können.
  • 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.
  • 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 NAT: Ein Dienst, der eine von Google Cloudverwaltete, leistungsstarke Netzwerkadressübersetzung bietet.
  • Cloud Interconnect: Ein Dienst, mit dem Ihr externes Netzwerk über eine hochverfügbare Verbindung mit niedriger Latenz auf das Google-Netzwerk erweitert wird.
  • Cloud VPN: Ein Dienst, mit dem Sie Ihr Peer-Netzwerk über einen IPsec-VPN-Tunnel sicher auf das Google-Netzwerk ausdehnen können.

In diesen Referenzarchitekturen werden die folgenden Oracle-Produkte verwendet:

  • Oracle E-Business Suite: Eine Suite von Anwendungen für Geschäftsabläufe wie Finanzen, Personalwesen und Lieferkette.
  • Oracle Database: Ein relationales Datenbankverwaltungssystem (Relational Database Management System, RDBMS), das das relationale Modell auf ein objektrelationales Modell erweitert.
  • Oracle Data Guard: Eine Reihe von Diensten zum Erstellen, Pflegen, Verwalten und Überwachen einer oder mehrerer Standby-Datenbanken.

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 Referenzarchitekturen verwenden, um eine Topologie zu entwickeln, die Ihren spezifischen Anforderungen an Sicherheit, Zuverlässigkeit, operative Effizienz, Kosten und Leistung entspricht.

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.

Computing-Infrastruktur

In der Referenzarchitektur in diesem Dokument werden Compute Engine-VMs für bestimmte Ebenen der Anwendung verwendet. Je nach Anforderungen Ihrer Anwendung können Sie aus anderen Google Cloud Computing-Diensten auswählen:

  • Container: Sie können containerisierte Anwendungen in Google Kubernetes Engine (GKE)-Clustern ausführen. GKE ist eine Engine zur Containerorchestrierung, die die Bereitstellung, Skalierung und Verwaltung von Containeranwendungen automatisiert.
  • Serverlos: Wenn Sie sich bei Ihren IT-Maßnahmen auf Ihre Daten und Anwendungen konzentrieren möchten, anstatt Infrastrukturressourcen einzurichten und zu betreiben, können Sie serverlose Dienste wie Cloud Run verwenden.

Die Entscheidung, ob VMs, Container oder serverlose Dienste verwendet werden sollen, erfordert einen Kompromiss zwischen Konfigurationsflexibilität und Verwaltungsaufwand. VMs und Container bieten mehr Konfigurationsflexibilität, aber Sie sind für die Verwaltung der Ressourcen verantwortlich. In einer serverlosen Architektur stellen Sie Arbeitslasten auf einer vorkonfigurierten Plattform bereit, die minimalen Verwaltungsaufwand erfordern. Weitere Informationen zur Auswahl geeigneter Computing-Dienste für Ihre Arbeitslasten inGoogle Cloudfinden Sie unter Anwendungen in Google Cloudhosten.

Datenbankmigration

Wenn Sie planen, lokale Oracle-Datenbankbereitstellungen zuGoogle Cloudzu migrieren, sollten Sie Ihre aktuelle Datenbankumgebung bewerten und Konfigurations- und Größenempfehlungen mit dem Tool zur Datenbankmigrationsbewertung (Database Migration Assessment, DMA) abrufen.

Wenn Sie lokale Daten in Oracle-Datenbankbereitstellungen inGoogle Cloudmigrieren möchten, können Sie Standard-Oracle-Tools wie Oracle GoldenGate verwenden.

Speicheroptionen

In den in diesem Dokument gezeigten Architekturen werden Hyperdisk-Volumes für die Bootlaufwerke aller Compute Engine-VMs und für die Datenlaufwerke der VMs verwendet, auf denen Oracle Database-Instanzen gehostet werden. Hyperdisk-Volumes bieten eine bessere Leistung, Flexibilität und Effizienz als Persistent Disk. Informationen zu Hyperdisk-Typen und ‑Funktionen finden Sie unter Informationen zu Hyperdisk.

Für Anwendungsdaten und Binärdateien verwenden alle Architekturen in diesem Dokument Filestore. Die Daten, die Sie in einer Filestore-Regionalinstanz speichern, werden synchron über drei Zonen innerhalb der Region repliziert. Die Replikation sorgt für hohe Verfügbarkeit und Robustheit bei zonalen Ausfällen. Sie können auch freigegebene Konfigurationsdateien, gängige Tools und Dienstprogramme sowie zentralisierte Logs in der Filestore-Instanz speichern und die Instanz auf mehreren VMs bereitstellen.

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.

Netzwerkkonzept

Wenn Sie eine Infrastruktur für einen mehrstufigen Anwendungs-Stack erstellen, müssen Sie ein Netzwerkdesign auswählen, das Ihren geschäftlichen und technischen Anforderungen entspricht. In den in diesem Dokument dargestellten Architekturen wird eine einfache Netzwerktopologie mit einem einzelnen VPC-Netzwerk verwendet. Je nach Ihren Anforderungen können Sie mehrere VPC-Netzwerke verwenden. Weitere Informationen erhalten Sie in dieser Dokumentation:

Datenanalyse

Für erweiterte Analysen können Sie das Google Cloud Cortex Framework verwenden, um Daten aus Ihren Oracle E‑Business Suite-Anwendungen in BigQuery aufzunehmen. Weitere Informationen finden Sie unter Cortex Framework: Integration with Oracle E‑Business Suite.

Sicherheit, Datenschutz und Compliance

In diesem Abschnitt werden Faktoren beschrieben, die Sie bei der Verwendung dieser Referenzarchitekturen 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.

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 umfasst eine Vielzahl von Berechtigungen, die in diesem Fall nicht erforderlich sind. Sie können spezielle Dienstkonten jedoch 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 dieser Architektur zu erhöhen, implementieren Sie die Identity-Aware Proxy (IAP)-Weiterleitung mit der 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 basierend auf der Nutzeridentität und IAM-Richtlinien steuern. Weitere Informationen zum Verwalten des Netzwerkzugriffs finden Sie unter Best Practices für die Steuerung des SSH-Anmeldezugriffs.

Laufwerksverschlüsselung

Standardmäßig werden die in Hyperdisk-Volumes und in 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 Laufwerksverschlüsselung für Hyperdisk-Volumes und Daten mit vom Kunden verwalteten Verschlüsselungsschlüsseln verschlüsseln für Filestore.

Netzwerksicherheit

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

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 Referenzarchitekturen zum Erstellen und Betreiben einer zuverlässigen Infrastruktur für Ihre Bereitstellung in Google Cloudberücksichtigen sollten.

Robustheit der Anwendungsschicht bei VM-Fehlern

Bei allen Architekturoptionen in diesem Dokument sind die Anwendungen weiterhin verfügbar, wenn einige (aber nicht alle) der Anwendungs-VMs ausfallen, da der Load Balancer Anfragen an andere Anwendungs-VMs weiterleitet.

Manchmal wird eine Anwendungs-VM ausgeführt und ist verfügbar, es kann jedoch Probleme mit der Anwendung selbst geben. Die Anwendung kann einfrieren, abstürzen oder nicht genügend Arbeitsspeicher haben. In diesem Szenario 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 der Datenbank bei VM-Fehlern

Wenn die Datenbank-VM in einer zonenbasierten Architektur ausfällt, können Sie die Datenbank mithilfe der in Backup and DR gespeicherten Sicherungen auf einer neuen VM wiederherstellen. Nachdem Sie die Datenbank wiederhergestellt haben, müssen Sie die Anwendungen mit der neuen Datenbankinstanz verbinden.

Wenn Datenkonsistenz Priorität hat, richten Sie eine primäre und eine Standby-Datenbankinstanz ein, vorzugsweise auf VMs in verschiedenen Zonen, wie in der regionalen Architektur dargestellt. Verwenden Sie Data Guard für die Replikation und das Failover zur Standby-Datenbankinstanz. Data Guard trägt zur Konsistenz bei, indem Transaktionen auf die Stand-by-Instanz repliziert werden, bevor sie auf der primären Instanz bestätigt werden. Die Architektur mit primärer Datenbank und Stand-by-Datenbank ist mit zusätzlichen Kosten für Infrastruktur und Lizenzen verbunden.

Wenn in einer regionalen oder multiregionalen Architektur die VM, auf der die primäre Datenbank gehostet wird, ausfällt, initiiert Oracle Data Guard einen Failover zur Oracle Database-Standby-Instanz. Während des Failover-Prozesses können die Anwendungen nicht auf die Datenbank zugreifen.

Robustheit bei zonalen Ausfällen

Wenn in einer zonalen Architektur die Zone, in der Ihre Bereitstellung gehostet wird, ausfällt, sind die Anwendungen und die Datenbank nicht verfügbar. Sie können die Anwendungen und die Datenbank in einer anderen Zone oder Region in der Produktion wiederherstellen, indem Sie die Sicherungen verwenden, die in Backup and DR gespeichert sind.

Wenn in einer regionalen Architektur eine der Zonen ausfällt, leitet der Load Balancer Anfragen an Instanzen der Anwendungen weiter, die in der anderen Zone ausgeführt werden. Filestore ist weiterhin verfügbar, da in der Architektur die Dienststufe „Filestore Regional“ verwendet wird.

Um bei einem Ausfall einer einzelnen Zone für eine hohe Verfügbarkeit der Daten in Hyperdisk-Volumes zu sorgen, können Sie Hyperdisk mit ausgeglichener Hochverfügbarkeit verwenden. Wenn Daten in ein Hyperdisk Balanced-Volume mit Hochverfügbarkeit geschrieben werden, werden sie synchron zwischen zwei Zonen in derselben Region repliziert.

Robustheit bei regionalen Ausfällen

Wenn ein regionaler Ausfall auftritt, sind die Anwendungen und die Datenbank nicht verfügbar. Sie können die Anwendungen und die Datenbank mithilfe der in Backup and DR gespeicherten Sicherungen in einer anderen Region in der Produktion wiederherstellen. Um die Ausfallzeit zu verkürzen, verwenden Sie die multiregionale Active-Passive-Architektur (DR). Nachdem Sie die Anwendungen und die Datenbank hochgefahren haben, müssen Sie die DNS-Routingrichtlinie aktualisieren, um Traffic an den Load Balancer in der Failover-Region weiterzuleiten.

Für geschäftskritische Anwendungen, die auch bei einem regionalen Ausfall keine Ausfallzeiten tolerieren können, sollten Sie den Archetyp für die multiregionale Aktiv-Aktiv-Bereitstellung verwenden.

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.

Datenhaltbarkeit

In den Architekturen in diesem Dokument wird Backup and DR verwendet, um Sicherungen von 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 Arbeitslasten in der Produktion wiederherstellen, indem Sie Daten aus dem langfristigen Sicherungsspeicher direkt verwenden, ohne Daten vorbereiten oder verschieben zu müssen.

Backup and DR unterstützt zwei Methoden zum Erstellen von Sicherungen:

  • Speicher für Back-up-Tresor: Die Sicherungsdaten werden in derselben Region wie die Quelldaten gespeichert und können nicht geändert oder gelöscht werden.
  • Selbstverwalteter Speicher: Autorisierte Nutzer können die Sicherungsdaten ändern oder löschen und Sie können Daten in mehreren Regionen speichern.

Weitere Informationen erhalten Sie in dieser Dokumentation:

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 Referenzarchitekturen 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. Berücksichtigen Sie bei der Berechnung der Lizenzkosten die Anzahl der erforderlichen Oracle-Prozessorlizenzen, die sich aus dem Maschinentyp ergeben, den Sie für die Compute Engine-VMs auswählen, auf denen die Oracle-Produkte gehostet werden. Weitere Informationen finden Sie unter Oracle-Software in der Cloud-Computing-Umgebung lizenzieren.

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 Referenzarchitekturen zum Entwerfen einer Google Cloud Topologie berücksichtigen sollten, die Sie effizient betreiben können.

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

Verbindung zwischen Anwendungsserver und Datenbank

Für Verbindungen von Ihren Anwendungen zu Oracle Database empfehlen wir, den zonalen internen DNS-Namen der Datenbank-VM anstelle ihrer IP-Adresse zu verwenden. Google Cloud löst den DNS-Namen automatisch in die primäre interne IP-Adresse der VM auf. Ein weiterer Vorteil dieses Ansatzes besteht darin, dass Sie keine statischen internen IP-Adressen für die Datenbank-VMs reservieren und zuweisen müssen.

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.

Beobachtbarkeit

Um die Observability für Ihre Oracle E‑Business Suite-Bereitstellung aufGoogle Cloudzu implementieren, 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 E‑Business Suite-Anwendungen 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.

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 Referenzarchitekturen 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, aus denen Sie abhängig von den Leistungsanforderungen Ihrer Arbeitslasten auswählen können.

  • Wählen Sie für die VMs, die die Anwendungen und die Datenbank hosten, einen geeigneten Maschinentyp basierend auf Ihren Leistungsanforderungen aus. Eine Liste der verfügbaren Maschinentypen, die Hyperdisk-Volumes unterstützen und Ihre Leistungs- und sonstigen Anforderungen erfüllen, finden Sie in der Tabelle Maschinenserienvergleich.
  • Für die VM, auf der die Oracle Database-Instanzen gehostet werden, empfehlen wir einen Maschinentyp aus der C4-Maschinenreihe der Maschinenfamilie für allgemeine Zwecke. C4-Maschinentypen bieten eine konstant hohe Leistung für Datenbankarbeitslasten.

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 Netzwerkleistung verbessern, indem Sie Tier_1-Netzwerke aktivieren. Dadurch wird die maximale Bandbreite für ausgehenden Traffic erhöht. Weitere Informationen finden Sie unter Netzwerkleistung pro VM-Tier_1 konfigurieren.

Hyperdisk-Speicherleistung

Die in diesem Dokument beschriebenen Architekturen verwenden Hyperdisk-Volumes für alle Bootlaufwerke der VMs und für die Datenlaufwerke der Datenbank-VM. Mit Hyperdisk können Sie Leistung und Kapazität dynamisch skalieren. Sie können die bereitgestellten IOPS, den Durchsatz und die Größe jedes Volumes an die Speicherleistung und Kapazitätsanforderungen Ihrer Arbeitslast anpassen. Die Leistung von Hyperdisk-Volumes hängt vom Hyperdisk-Typ und vom Maschinentyp der VMs ab, an die die Volumes angehängt sind. Weitere Informationen zu den Leistungsgrenzen und zur Optimierung von Hyperdisk finden Sie in der folgenden Dokumentation:

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

Autoren:

Weitere Beitragende: