In diesem Dokument finden Sie eine Referenzarchitektur, die Ihnen beim Erstellen der Infrastruktur für die Ausführung von Oracle E-Business Suite-Anwendungen mit niedriger Latenz-Konnektivität zu Oracle Cloud Infrastructure (OCI)-Exadata-Datenbanken, die in Google Cloudausgeführt werden, hilft. Oracle E-Business Suite ist eine Suite von Unternehmensanwendungen für Geschäftsfunktionen wie Finanzen, Personalwesen, Lieferkette und Kundenbeziehungen.
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 dem Technologie-Stack und der Architektur der Oracle E-Business Suite und dem Oracle Exadata Database Service vertraut ist.
Wenn Sie Oracle Exadata oder Oracle Real Application Clusters (Oracle RAC) zum Ausführen von Oracle-Datenbanken lokal verwenden, können Sie Ihre Anwendungen effizient zu Oracle Database@Google Cloud migrieren und Ihre Datenbanken dort ausführen. Google Cloud Oracle Database@Google Cloud ist ein Google Cloud Marketplace-Angebot, mit dem Sie den Oracle Exadata Database Service und die Oracle Autonomous Database direkt in Google Cloudausführen können.
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. Die Anwendung verwendet Oracle Exadata-Datenbanken in derselben Google Cloud Region.
Alle Komponenten in der Architektur befinden sich in einer einzigen Google Cloud Region. Diese Architektur ist auf den Archetyp für regionale Bereitstellungen ausgerichtet. Sie können diese Architektur anpassen, um eine Topologie zu erstellen, die gegen regionale Ausfälle resistent ist. Verwenden Sie dazu den Archetyp für multiregionale Bereitstellungen. Weitere Informationen finden Sie unter Multiregionale Bereitstellung in Compute Engine und im Abschnitt Zuverlässigkeit weiter unten in diesem Dokument.
Die Architektur im vorherigen Diagramm umfasst die folgenden Komponenten:
Komponente | Zweck |
---|---|
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 Ihren Anwendungs-Stack 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 der Oracle E-Business Suite (Oracle HTTP-Server, Oracle WebLogic-Server und ein Server für die parallele 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 Balanced-Volume. Sie stellen für Oracle E-Business Suite Ihre eigenen Lizenzen bereit (Bring Your Own License, BYOL) und verwalten die VMs und Anwendungen. |
Binärdateien und Daten von Anwendungen | Eine regionale Filestore-Instanz enthält die Binärdateien und Daten der Anwendung. Die Filestore-Instanz wird auf allen Compute Engine-VMs bereitgestellt, auf denen die Komponenten der Anwendungsebene in beiden Zonen gehostet werden. |
Anwendungssicherungen | Sicherungen der Anwendung werden mit Sicherung und Notfallwiederherstellung erstellt, gespeichert und verwaltet. |
VPC-Netzwerk (Virtual Private Cloud) | Alle Google Cloud Ressourcen in der Architektur verwenden ein einziges VPC-Netzwerk. Je nach Ihren Anforderungen können Sie eine Architektur erstellen, die mehrere Netzwerke verwendet. Weitere Informationen finden Sie unter Entscheiden, ob mehrere VPC-Netzwerke erstellt werden sollen. |
Oracle Database@Google Cloud | Die Anwendungen lesen Daten aus und schreiben sie in Oracle-Datenbanken im Oracle Exadata Database Service. Sie stellen den Oracle Exadata Database Service mit Oracle Database@Google Cloud bereit, einem Cloud Marketplace-Angebot, mit dem Sie Oracle-Datenbanken auf von Oracle verwalteter Hardware in einem Google Cloud Rechenzentrum ausführen können. Sie verwenden Google Cloud Oberflächen wie die Google Cloud Console, die Google Cloud CLI und APIs, um Exadata-Infrastrukturinstanzen zu erstellen. Oracle richtet die erforderliche Rechen-, Speicher- und Netzwerkinfrastruktur in einem Rechenzentrum in einer Google Cloud -Region auf Hardware ein, die speziell für Ihr Projekt vorgesehen ist. |
Exadata-Infrastrukturinstanzen | Jede Exadata Infrastructure-Instanz enthält mindestens zwei physische Datenbankserver und mindestens drei Speicherserver. Diese Server, die im Diagramm nicht dargestellt sind, sind über ein Low-Latency-Netzwerk verbunden. Wenn Sie eine Exadata-Infrastrukturinstanz erstellen, geben Sie die Anzahl der Datenbank- und Speicherserver an, die bereitgestellt werden müssen. |
Exadata-VM-Cluster |
Innerhalb einer Exadata-Infrastrukturinstanz 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 jede Ihrer Geschäftsbereiche erforderlich sind. Jeder Exadata-VM-Cluster enthält eine oder mehrere Oracle Linux-VMs, auf denen Oracle-Datenbankinstanzen gehostet werden. Wenn Sie einen Exadata-VM-Cluster erstellen, geben Sie Folgendes an:
Die VMs in Exadata-VM-Clustern sind keine Compute Engine-VMs. |
Oracle Database-Instanzen | Oracle-Datenbanken werden über die OCI-Konsole und andere OCI-Schnittstellen erstellt und verwaltet. Die Oracle-Datenbanksoftware wird auf den VMs innerhalb des Exadata-VM-Clusters ausgeführt. Beim Erstellen des Exadata-VM-Clusters geben Sie die Oracle Grid Infrastructure-Version an. Sie wählen auch den Lizenztyp aus: entweder „Eigene Lizenz verwenden“ (Bring your own License, BYOL) oder das Modell mit inbegriffener Lizenz. |
OCI-VCN und ‑Subnetze | Wenn Sie einen Exadata-VM-Cluster erstellen, wird automatisch ein OCI-virtuelles Cloud-Netzwerk (VCN) erstellt. Das VCN hat ein Clientsubnetz und ein Sicherungssubnetz mit von Ihnen angegebenen IP-Adressbereichen. Das Client-Subnetz wird für die Verbindung von Ihrem VPC-Netzwerk zu den Oracle-Datenbanken verwendet. Über das Sicherungssubnetz werden Datenbanksicherungen an den OCI Object Storage gesendet. |
Cloud Router, Partner Interconnect und OCI-DRG | Der Traffic zwischen Ihrem VPC-Netzwerk und dem VCN wird von einem Cloud Router weitergeleitet, der mit der VPC verbunden ist, und durch ein dynamisches Routing-Gateway (DRG), das mit dem VCN verbunden ist. Der Traffic fließt über eine Verbindung mit niedriger Latenz, die Google mit Partner Interconnect einrichtet. |
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 | Standardmäßig werden Sicherungen der Oracle Exadata-Datenbanken im OCI Object Storage gespeichert. Datenbanksicherungen werden über ein Service-Gateway an den OCI Object Storage weitergeleitet. |
Öffentliches Cloud NAT-Gateway | Die Architektur umfasst ein öffentliches Cloud NAT-Gateway, um sichere ausgehende Verbindungen von den Compute Engine-VMs zu ermöglichen, 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 inGoogle Cloudzu verbinden. Informationen zu den relativen Vorteilen der einzelnen Ansätze finden Sie unter Produkt für die Netzwerkverbindung auswählen. |
Cloud Monitoring | Mit Cloud Monitoring können Sie das Verhalten, den Zustand und die Leistung Ihrer Anwendung und Ihrer Google Cloud Ressourcen beobachten, einschließlich der Oracle Exadata-Ressourcen. Sie können die Ressourcen in Oracle Exadata-Ressourcen auch mit dem OCI-Monitoringdienst überwachen. |
Verwendete Produkte
In dieser Referenzarchitektur werden die folgenden Google Cloud Produkte verwendet:
- 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 VPCs.
- Cloud NAT: Ein Dienst, der eine von Google Cloudverwaltete, leistungsstarke Netzwerkadressübersetzung bietet.
- Cloud Monitoring: Ein Dienst, der Einblicke in die Leistung, Verfügbarkeit und Integrität Ihrer Anwendungen und Infrastruktur bietet.
- 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 Virtual Private Cloud-Netzwerken 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.
- 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 einen leistungsstarken, vollständig verwalteten Dateispeicher auf Google Cloud bereitstellt, mit dem Sie eine Verbindung zu verschiedenen Clienttypen herstellen können.
- Sicherungs- und Notfallwiederherstellungsdienst: Ein sicherer, zentral verwalteter Sicherungs- und Wiederherstellungsdienst für Google Cloud Arbeitslasten, der Sicherungsdaten vor böswilliger oder versehentlicher Löschung schützt.
- Cloud DNS: Ein Dienst, der eine stabile DNS-Bereitstellung mit niedriger Latenz über das weltweite Google-Netzwerk bietet.
In dieser Referenzarchitektur werden die folgenden Oracle-Produkte verwendet:
- Oracle E-Business Suite: Eine Suite von Anwendungen für Geschäftsabläufe wie Finanzen, Personalwesen und Lieferkette.
- Exadata Database Service auf dedizierter Infrastruktur: Mit diesem Dienst können Sie Oracle Database-Instanzen auf dedizierter Exadata-Hardware ausführen.
- Objektspeicher: Ein Dienst zum Speichern großer Mengen strukturierter und unstrukturierter Daten als Objekte.
- 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.
- Service-Gateway: Ein Gateway, mit dem Ressourcen in einer 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 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 Region für Ihre Bereitstellung 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 Oracle Database@Google Cloud in jeder Region Weitere Informationen finden Sie unter Verfügbare Konfigurationen.
- Verfügbarkeit von Compute Engine-Maschinentypen in jeder Region. Weitere Informationen finden Sie unter Verfügbare Regionen und Zonen.
- Latenzanforderungen für den Endnutzer.
- Kosten für Google Cloud -Ressourcen.
- 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 zum Hosten der Oracle E-Business Suite-Anwendungen verwendet. Je nach den Anforderungen Ihrer Anwendung können Sie containerisierte Anwendungen in Google Kubernetes Engine-Clustern (GKE) ausführen. GKE ist eine Engine zur Containerorchestrierung, die die Bereitstellung, Skalierung und Verwaltung von Containeranwendungen automatisiert. Die Entscheidung, ob VMs oder Container verwendet werden sollen, erfordert einen Kompromiss zwischen Konfigurationsflexibilität und Verwaltungsaufwand. Die Designanleitung für alternative Rechendienste wird in diesem Dokument nicht behandelt. Weitere Informationen zu Dienstoptionen finden Sie unter Optionen für das Anwendungshosting auf Google Cloud.
Datenbankmigration
Wenn Sie lokale Datenbanken zu Oracle Database@Google Cloud migrieren möchten, können Sie mit dem Tool Database Migration Assessment (DMA) Ihre aktuelle Datenbankumgebung bewerten und Empfehlungen zur Konfiguration und Größe erhalten.
Wenn Sie lokale Daten oder plattformübergreifende Daten, einschließlich Unix-Systeme, zu Oracle-Datenbanken in Google Cloudmigrieren möchten, können Sie standardmäßige Oracle-Tools wie Transportable Tablespaces verwenden. Weitere Informationen zu transportablen Tablespaces und ihren Einschränkungen finden Sie unter Daten mithilfe von transportablen Tablespaces migrieren.
Bevor Sie die migrierten Datenbanken in einer Produktionsumgebung verwenden, prüfen Sie die Verbindung Ihrer Anwendungen zu den Datenbanken.
Speicheroptionen
Die in diesem Dokument dargestellte Architektur verwendet Google Cloud Hyperdisk Balanced-Volumes für die Boot-Laufwerke der Compute Engine-VMs, auf denen Oracle E-Business Suite-Anwendungen gehostet werden. Hyperdisk-Volumes bieten eine bessere Leistung, Flexibilität und Effizienz als Persistent Disk. Mit Hyperdisk Balanced können Sie IOPS und Durchsatz getrennt und dynamisch bereitstellen. So können Sie das Volume für eine Vielzahl von Arbeitslasten optimieren. Informationen zu Hyperdisk-Typen und ‑Funktionen finden Sie unter Informationen zu Hyperdisk abgestimmt.
Für Anwendungsdaten und Binärdateien wird in der Architektur in diesem Dokument Filestore verwendet. 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 der in diesem Dokument dargestellten Architektur wird eine 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:
- Entscheiden, ob mehrere VPC-Netzwerke erstellt werden sollen
- Netzwerkdesign für Ihre Google Cloud Landing-Zone festlegen
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 zu importieren. Weitere Informationen finden Sie unter Cortex Framework: Integration mit Oracle E-Business Suite.
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 Oracle E-Business Suite-Anwendungen vor externen Bedrohungen wie DDoS-Angriffen und XSS können Sie geeignete Google Cloud Armor-Sicherheitsrichtlinien basierend auf Ihren Anforderungen definieren. Jede Richtlinie besteht aus Regeln, die die zu prüfenden Bedingungen und die auszuführenden Aktionen festlegen, 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 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 VMs, auf denen die Oracle E-Business Suite-Anwendungen gehostet werden, keinen direkten eingehenden Zugriff aus dem Internet. Weisen Sie diesen 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 privaten Google-Zugriff dennoch auf bestimmte Google APIs und Google-Dienste zugreifen. Weitere Informationen finden Sie unter Optionen für den privaten Zugriff.
Sie können Cloud NAT wie im vorherigen Architekturdiagramm dargestellt oder Secure Web Proxy verwenden, 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.
Oracle empfiehlt, den von den Exadata-VMs verwendeten Subnetzen private IP-Adressbereiche zuzuweisen.
Dienstkontoberechtigungen
Wir empfehlen, anstelle der Standarddienstkonten für die Compute Engine-VMs in der Architektur spezielle Dienstkonten zu erstellen und die Ressourcen anzugeben, auf die das Dienstkonto zugreifen kann. Das Standarddienstkonto umfasst eine breite Palette von Berechtigungen, die in diesem Fall 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 dieser Architektur zu erhöhen, implementieren Sie die Weiterleitung mit Identity-Aware Proxy (IAP) und OS Login. Mit IAP können Sie den Netzwerkzugriff basierend auf der Nutzeridentität und IAM-Richtlinien steuern. Mit OS Login 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.
Datenverschlüsselung
Standardmäßig werden die in Hyperdisk-Volumes und im 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.
Standardmäßig wird in Exadata-Datenbanken die Transparent Data Encryption (TDE) verwendet. Damit können Sie sensible Daten verschlüsseln, die in Tabellen und Tabellenspeichern 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.
Datenbanksicherheit und Compliance
Der Exadata Database-Dienst 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 in der folgenden Dokumentation:
- Blueprints für Unternehmensgrundlagen
- Google Cloud Well-Architected Framework: Säule „Sicherheit, Datenschutz und Compliance“
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 einige (aber nicht alle) der VMs, auf denen die Oracle E-Business Suite-Anwendungen gehostet werden, ausfallen, sind die Anwendungen weiterhin verfügbar, da der Load Balancer Anfragen an andere Anwendungs-VMs weiterleitet.
Manchmal wird eine Anwendungs-VM ausgeführt und ist verfügbar, es können jedoch Probleme mit der Anwendung selbst auftreten. Die Anwendung kann einfrieren, abstürzen oder nicht genügend Arbeitsspeicher haben. In diesem Szenario reagiert die VM nicht auf die Systemdiagnosen des Load Balancers und der Load Balancer leitet den Traffic nicht an die nicht reagierende VM weiter.
Robustheit bei zonalen Ausfällen
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-Volume mit ausgeglichener Hochverfügbarkeit geschrieben werden, werden sie synchron zwischen zwei Zonen in derselben Region repliziert.
Robustheit bei regionalen Ausfällen
Bei einem regionalen Ausfall sind die Anwendungen nicht verfügbar. Sie können Ausfallzeiten durch Ausfälle in Regionen reduzieren, indem Sie Folgendes implementieren:
- Behalten Sie ein passives (Failover-)Replikat der Anwendungsebene in einer anderen Google Cloud Region bei.
- Erstellen Sie eine Exadata-Standby-Infrastrukturinstanz mit den erforderlichen Exadata-VM-Clustern in derselben Region, in der sich das passive Replikat des Anwendungsstacks befindet. Verwenden Sie Oracle Data Guard für die Datenreplikation und das automatische Failover zu den Exadata-Standby-Datenbanken. Wenn für Ihre Anwendung ein niedrigeres Recovery Point Objective (RPO) erforderlich ist, können Sie die Datenbanken mit dem Oracle Autonomous Recovery Service sichern und wiederherstellen.
- Wenn ein Ausfall in der primären Region auftritt, verwenden Sie das Datenbankreplikat oder die Datenbanksicherung, um die Datenbank in der Produktion wiederherzustellen und die Anwendung in der Failover-Region zu aktivieren.
- Verwenden Sie DNS-Routingrichtlinien, um Traffic an einen externen Load Balancer in der Failover-Region weiterzuleiten.
Für geschäftskritische Anwendungen, die auch bei einem regionalen Ausfall verfügbar sein müssen, sollten Sie den Archetyp für die multiregionale Bereitstellung verwenden. Sie können Oracle Active Data Guard verwenden, um eine schreibgeschützte Standby-Datenbank in der Failover-Region bereitzustellen.
Oracle verwaltet die Infrastruktur in Oracle Database@Google Cloud. Informationen zu den Service Level Objectives (SLOs) für den Oracle Exadata Database Service auf einer dedizierten Infrastruktur finden Sie unter Service Level Objectives für Oracle PaaS- und IaaS-Public-Cloud-Dienste.
VM-Kapazitätsplanung
Damit die Kapazität für Compute Engine-VMs verfügbar ist, wenn Sie VMs bereitstellen 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. Für reservierte Ressourcen fallen auch dann Gebühren an, wenn die Ressourcen nicht bereitgestellt oder verwendet werden. Weitere Informationen zu Reservierungen, einschließlich Aspekten der Abrechnung, finden Sie unter Reservierungen von zonalen Compute Engine-Ressourcen.
Datenbankkapazität
Sie können die Exadata-Infrastruktur skalieren, indem Sie nach Bedarf Datenbank- und Speicherserver hinzufügen. Nachdem Sie der Exadata-Infrastruktur die erforderlichen Datenbank- oder Speicherserver hinzugefügt haben, müssen Sie dem zugehörigen Exadata-VM-Cluster die Kapazität hinzufügen, um die zusätzlichen CPU- oder Speicherressourcen nutzen zu können. Weitere Informationen finden Sie unter Exadata-Rechen- und Speicherressourcen skalieren.
Datenhaltbarkeit
In der Architektur in diesem Dokument werden Sicherungen und Notfallwiederherstellungen 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 dass Sie Daten vorbereiten oder verschieben müssen.
Backup and DR unterstützt zwei Methoden zum Erstellen von Sicherungen:
- Speicherung im 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. Außerdem können Sie Daten in mehreren Regionen speichern.
Weitere Informationen erhalten Sie in dieser Dokumentation:
- Backup und DR für Compute Engine-Instanzsicherungen
- Sicherung und Notfallwiederherstellung für Filestore und Dateisysteme
- Backup und DR für Oracle
Um die Zuverlässigkeit der Anwendungs-Binärdateien in Ihrer Filestore-Instanz zu gewährleisten, können Sie Sicherungen und Snapshots der Instanz erstellen.
Standardmäßig werden Sicherungen von Datenbanken im Oracle Exadata Database Service auf einer dedizierten Infrastruktur in OCI Object Storage gespeichert. Um eine niedrigere 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:
- Google Cloud Leitfaden zur Infrastrukturzuverlässigkeit
- Skalierbare und robuste Anwendungen erstellen
- Widerstandsfähige Systeme konzipieren
- Well-Architected Framework: Säule „Zuverlässigkeit“
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 Auslastung Ihrer VM-Ressourcen 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 E-Business Suite-Anwendungen 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.
Datenbankkosten
Wenn Sie einen Exadata-VM-Cluster erstellen, können Sie BYOL auswählen oder lizenzierte Oracle-Datenbanken bereitstellen.
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 unter Well-Architected Framework: Säule „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.
VM-Images
Sie können für Ihre VMs Oracle Linux-Images verwenden, die in der Compute Engine verfügbar sind, oder Oracle Linux-Images importieren, die Sie 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.
Datenbankverwaltung
Oracle verwaltet die physischen Datenbankserver, Speicherserver und Netzwerkhardware im Oracle Exadata Database Service auf einer dedizierten Infrastruktur. Sie können die Exadata-Infrastrukturinstanzen und die Exadata-VM-Cluster über die OCI- oder Google Cloud -Benutzeroberflächen 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 relevanten Seiten in der OCI-Konsole gelangen. Damit Sie sich nicht noch einmal in OCI anmelden müssen, können Sie eine Identitätsföderation zwischen OCI und Google Cloudkonfigurieren.
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 von Oracle bereitgestellten Dokumentation für das entsprechende Produkt.
- 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).
- Eine Zusammenfassung der Oracle-Supportrichtlinien für die Oracle E-Business Suite finden Sie unter EBS-Zertifizierungen.
Beobachtbarkeit
Sie können die Observability für Ihre Oracle E-Business Suite-Bereitstellung aufGoogle Cloudmit den Google Cloud Observability-Diensten oder Oracle Enterprise Manager implementieren. Wählen Sie je nach Ihren Anforderungen und Einschränkungen eine geeignete Überwachungsstrategie aus. Wenn Sie beispielsweise neben Oracle E-Business Suite-Anwendungen auch andere Arbeitslasten ausführen, können Sie mithilfe der Observability-Dienste von Google Cloud ein einheitliches Betriebsdashboard für alle Arbeitslasten erstellen. Google Cloud
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 unter Well-Architected Framework: Säule „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, aus denen Sie abhängig von den Leistungsanforderungen Ihrer Oracle E-Business Suite-Anwendungen auswählen können.
Wählen Sie 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.
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.
Der Netzwerkverkehr zwischen den VMs der Anwendungsebene und dem Oracle Exadata-Netzwerk wird über eine von Google eingerichtete Partner Interconnect-Verbindung mit niedriger Latenz geleitet.
Die Exadata-Infrastruktur verwendet RDMA over Converged Ethernet (RoCE) für eine hohe Bandbreite und niedrige Latenz zwischen den Datenbank- und Speicherservern. Die Server tauschen Daten direkt im Arbeitsspeicher aus, ohne dass der Prozessor, der Cache oder das Betriebssystem beteiligt sind.
Hyperdisk-Speicherleistung
In der in diesem Dokument beschriebenen Architektur werden Hyperdisk-Volumes für alle Bootlaufwerke der VMs verwendet, auf denen die Oracle E-Business Suite-Anwendungen gehostet werden. Mit Hyperdisk können Sie Leistung und Kapazität dynamisch skalieren. Sie können die bereitgestellten IOPS, den Durchsatz und die Größe jedes Volume 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 unter Well-Architected Framework: Leistungsoptimierung bereitgestellt werden.
Nächste Schritte
- Cloud-Transformation mit Google Cloud und Oracle
- Oracle-Dokumentation
- Google-Dokumentation
- Weitere Referenzarchitekturen, Diagramme und Best Practices finden Sie im Cloud-Architekturcenter.
Beitragende
Autoren:
- Kumar Dhanagopal | Cross-Product Solution Developer
- Samantha He | Technical Writer
Weitere Beitragende:
- Andy Colvin | Database Black Belt Engineer, Oracle on Google Cloud
- Balazs Pinter | Partner Solutions Architect
- Celia Antonio | Database Customer Engineer
- Johannes Passing | Cloud Solutions Architect
- Majed Al-Halaseh | Customer Engineer, Infrastrukturmodernisierung
- Marc Fielding | Data Infrastructure Architect
- Mark Schlagenhauf | Technical Writer, Netzwerk
- Michelle Burtoft | Senior Product Manager
- Nelson Gonzalez | Product Manager
- Rajesh Kasanagottu | Engineering Manager
- Sean Derrington | Group Outbound Product Manager, Speicher
- Sekou Page | Outbound Product Manager
- Souji Madhurapantula | Group Product Manager
- Victor Moreno | Product Manager, Cloud Networking