Informationen zum Deployment von Oracle E-Business Suite in Oracle Cloud Infrastructure

Wenn Sie Oracle E-Business Suite auf Oracle Cloud Infrastructure bereitstellen oder Oracle E-Business Suite-Umgebungen von Ihrem Rechenzentrum zu Oracle Cloud Infrastructure migrieren möchten, können Sie eine Multihost-Topologie, eine sichere und hochverfügbare Topologie planen.

Oracle stellt Automatisierung zur Verfügung, um den Lebenszyklus von Oracle E-Business Suite-Umgebungen in Oracle Cloud Infrastructure bereitzustellen, zu migrieren und zu verwalten, wie in diesem Dokument beschrieben. Dadurch kann die Komplexität des manuellen Deployments und der manuellen Verwaltung weitgehend eliminiert werden. Weitere Informationen finden Sie in Dokument 2517025.1, Erste Schritte mit Oracle E-Business Suite und Oracle Cloud Infrastructure.

Überlegungen zum Deployment in Oracle Cloud Infrastructure

Oracle empfiehlt, separate Subnetze für Ihre Instanzen wie Bastionshost, Datenbank, Anwendung und Load Balancer-Instanzen zu erstellen, um sicherzustellen, dass geeignete Sicherheitsanforderungen über die verschiedenen Subnetze hinweg implementiert werden können.

Private oder öffentliche Subnetze

Sie können Instanzen in einem privaten oder öffentlichen Subnetz erstellen, je nachdem, ob Sie den Zugriff auf die Instanzen über das Internet zulassen möchten. Instanzen, die Sie in einem öffentlichen Subnetz erstellen, werden eine öffentliche IP-Adresse zugewiesen, und Sie können über das Internet auf diese Instanzen zugreifen. Sie können Instanzen, die in einem privaten Subnetz erstellt wurden, keine öffentliche IP-Adresse zuweisen. Daher können Sie nicht über das Internet auf diese Instanzen zugreifen.

Das folgende Bild zeigt ein virtuelles Cloud-Netzwerk (VCN) mit öffentlichen und privaten Subnetzen. VCN enthält zwei Availability-Domains, und jede Availability-Domain enthält ein öffentliches und privates Subnetz. Die Webserver werden in diesem Bild im öffentlichen Subnetz platziert, sodass jeder Webserverinstanz eine öffentliche IP-Adresse zugeordnet ist. Sie können über das Internet auf diese Oracle Cloud-Instanzen im öffentlichen Subnetz zugreifen, indem Sie die Kommunikation über das Internetgateway (IGW) aktivieren. Sie müssen die Routentabelle aktualisieren, um Traffic von und nach IGW zu aktivieren. Um den Datenverkehr zu den Webservern über das Internet zu ermöglichen, müssen Sie Load Balancer im öffentlichen Subnetz erstellen. Um über das Internet auf Ihre Instanzen zuzugreifen, müssen Sie auch einen Bastionshost im öffentlichen Subnetz erstellen und über die IGW auf den Bastionshost zugreifen.

Die Datenbankserver werden in diesem Bild im privaten Subnetz platziert. Sie können über Ihre Rechenzentren auf Oracle Cloud-Instanzen im privaten Subnetz zugreifen, indem Sie sich über das dynamische Routinggateway (DRG) anmelden. DRG verbindet Ihre On-Premise-Netzwerke mit Ihrem Cloud-Netzwerk. Um die Kommunikation zwischen DRG und den On-Premise-Geräten des Kunden zu ermöglichen, verwenden Sie IPSec VPN oder Oracle Cloud Infrastructure FastConnect. Außerdem müssen Sie die Routentabelle aktualisieren, um Traffic in und aus DRG zu aktivieren.

Beschreibung von public_private_subnets_jde.png folgt

Beschreibung der Abbildung public_private_subnets_jde.png

Szenario 1: Alle Instanzen in privaten Subnetzen bereitstellen

Oracle empfiehlt, alle Instanzen in privaten Subnetzen für Produktionsumgebungen bereitzustellen, in denen keine internetorientierten Endpunkte vorhanden sind. Diese Art des Deployments ist nützlich, wenn Sie ein hybrides Deployment mit der Cloud als Erweiterung zu Ihren vorhandenen Rechenzentren durchführen möchten.

In diesem Deployment werden alle Instanzen einschließlich Anwendungs- und Datenbankserver in einem privaten Subnetz bereitgestellt. Eine öffentliche IP-Adresse kann Instanzen, die in einem privaten Subnetz erstellt wurden, nicht zugewiesen werden, sodass Sie nicht über das Internet auf diese Instanzen zugreifen können. Um von Ihrer On-Premise-Umgebung in dieser Konfiguration auf Ihre Anwendungsserver zuzugreifen, können Sie:

Konfigurieren Sie einen IPSec-VPN-Tunnel zwischen Ihrem Rechenzentrum und Oracle Cloud Infrastructure DRG, bevor Sie die Anwendungsserver bereitstellen.
Erstellen Sie in dieser Konfiguration einen Bastionshost, und greifen Sie dann vom Bastionshost auf alle Server im privaten Subnetz zu.

Szenario 2: Instanzen in öffentlichen und privaten Subnetzen bereitstellen

Sie können einige Instanzen in einem öffentlichen Subnetz und einige Instanzen in einem privaten Subnetz bereitstellen. Diese Art des Deployments ist nützlich, wenn das Deployment internetkonfrontierte und nicht internetkonfrontierte Endpunkte enthält.

In dieser Konfiguration werden einige Anwendungsinstanzen in einem öffentlichen Subnetz platziert, andere werden in einem privaten Subnetz platziert. Beispiel: Anwendungsinstanzen dienen internen Benutzern und anderen Anwendungsinstanzen, die externen Benutzern dienen. Platzieren Sie in diesem Szenario die Anwendungsinstanzen, die internen Traffic in einem privaten Subnetz bereitstellen, und platzieren Sie die Anwendungsserver, die externen Traffic in einem öffentlichen Subnetz bedienen. Sie können auch einen öffentlichen Load Balancer auf internetorientierten Anwendungsinstanzen einrichten, anstatt die Anwendungsserver zu platzieren, die externen Traffic in einem öffentlichen Subnetz bereitstellen. Wenn Sie den Bastionshost in ein öffentliches Subnetz setzen, wird dem Bastionshost eine öffentliche IP-Adresse zugewiesen, und Sie können darauf über das Internet zugreifen. Sie können über den Bastionsserver auf Ihre Instanzen im privaten Subnetz zugreifen.

Szenario 3: Alle Instanzen in öffentlichen Subnetzen bereitstellen

Oracle empfiehlt dieses Deployment für schnelle Demonstrationen oder für produktionsbasierte Deployments ohne interne Endpunkte. Dieses Deployment eignet sich nur, wenn Sie kein eigenes Rechenzentrum haben oder nicht auf Instanzen über VPN zugreifen können und Sie über das Internet auf die Infrastruktur zugreifen möchten.

In diesem Deployment werden alle Instanzen einschließlich der Anwendungs- und Datenbankinstanzen in öffentlichen Subnetzen bereitgestellt.

Jeder Instanz im öffentlichen Subnetz ist eine öffentliche IP-Adresse zugeordnet. Obwohl über das Internet auf Instanzen mit öffentlichen IP-Adressen zugegriffen werden kann, können Sie den Zugriff mit Sicherheitslisten und Sicherheitsregeln einschränken. Um Administrationsaufgaben auszuführen, empfiehlt Oracle, dass Sie einen Bastionshost in dieser Konfiguration platzieren. In diesem Szenario öffnen Sie Administrationsports nicht für das öffentliche Internet, sondern öffnen die Administrationsports nur für den Bastionshost und richten Sicherheitslisten und Sicherheitsregeln ein, um sicherzustellen, dass die Instanz nur vom Bastionshost aus aufgerufen werden kann.

Anti-Affinität

Beim Erstellen mehrerer Instanzen für hohe Verfügbarkeit in einer Availability-Domain in Oracle Cloud Infrastructure kann die Anti-Affinität für Instanzen mit Faultdomains erreicht werden.

Eine Faultdomain ist eine Gruppierung von Hardware und Infrastruktur innerhalb einer Availability-Domain. Jede Availability-Domain umfasst drei Faultdomains. Mit Faultdomains können Sie Ihre Instanzen so verteilen, dass sie sich nicht auf derselben physischen Hardware innerhalb einer Availability-Domain befinden. Ein Hardwarefehler oder die Hardwarewartung von Oracle Compute, die sich auf eine Faultdomain auswirkt, wirkt sich also nicht auf Instanzen in anderen Faultdomains aus. Durch die Verwendung von Faultdomains können Sie Ihre Instanzen vor unerwarteten Hardwareausfällen und geplanten Ausfällen schützen.

Zur hohen Verfügbarkeit von Datenbanken können Sie ein 2-Knoten Virtual Machine (VM)-DB-System erstellen, das Oracle Real Applications Clusters (Oracle RAC) bereitstellt. Die beiden Knoten von Oracle RAC werden standardmäßig immer in separaten Faultdomains erstellt. Es ist auch möglich, während des Oracle RAC-Datenbank-Provisionings manuell eine Faultdomain für die RAC-Knoten auszuwählen. Die Datenbankknoten befinden sich also weder auf demselben physischen Host noch auf demselben physischen Rack. Dadurch werden die Datenbankinstanzen vor den zugrunde liegenden physischen Hosts und Top-of-the-Rack-Switch-Fehlern geschützt.

Architektur

Sie können Ihr Oracle E-Business Suite-Deployment in Oracle Cloud Infrastructure in einer einzelnen Availability-Domain, in mehreren Availability-Domains oder in mehreren Regionen entwerfen. Darüber hinaus können Sie eine entmilitarisierte Zone integrieren, um den externen Verkehr zu isolieren und interne Systeme zu schützen.

Single Availability-Domain: Sie können Oracle E-Business Suite in einer einzelnen Availability-Domain bereitstellen und dennoch eine hohe Verfügbarkeit sicherstellen, indem Sie mehrere Anwendungsinstanzen einrichten. Verwenden Sie diese Architektur, wenn Sie sicherstellen möchten, dass Ihre Anwendung auch dann verfügbar ist, wenn eine Anwendungsinstanz heruntergefahren wird. Die anderen verfügbaren Anwendungsinstanzen in der Availability-Domain verarbeiten die Anforderungen weiterhin.
Single Availability-Domain mit einer entmilitarisierten Zone (DMZ): Verwenden Sie diese Architektur, wenn Sie möchten, dass Ihre Anwendung von externen, nicht vertrauenswürdigen Netzwerken aus zugänglich ist, während die internen Systeme vom externen Netzwerk isoliert sind.
Mehrere Availability-Domains: Verwenden Sie diese Architektur, wenn Sie sicherstellen möchten, dass Ihre Anwendung verfügbar ist, selbst wenn eine Availability-Domain heruntergefahren wird. Sie können immer noch auf die Anwendungsinstanzen in einer anderen Availability-Domain zugreifen.
Mehrere Regionen: Verwenden Sie diese Architektur, wenn Sie eine Disaster Recovery-Site für Ihre Anwendung in einer anderen Region einrichten möchten. Diese Architektur ist im Wesentlichen die gleiche wie die Mehrfachverfügbarkeitsdomänenarchitektur, aber anstatt Ressourcen in einer zweiten Availability-Domain in derselben Region zu erstellen, erstellen Sie Ressourcen in einer anderen Region.

Hinweis:

Sie können ein DMZ auch bei mehreren Availability-Domains und mehreren Regionen konfigurieren.

Architektur zum Bereitstellen von Oracle E-Business Suite in einer einzelnen Availability-Domain

Diese Architektur zeigt das Deployment einer Oracle E-Business Suite-Anwendung in einer einzelnen Availability-Domain und stellt gleichzeitig eine hohe Verfügbarkeit sicher.

Die Architektur besteht aus einem virtuellen Cloud-Netzwerk (VCN) mit Bastion, Load Balancer, Anwendung und Datenbankhosts, die in separaten Subnetzen von VCN in einer einzelnen Availability-Domain platziert sind. Im folgenden Architekturdiagramm wird der Bastionshost in einem öffentlichen Subnetz bereitgestellt, und alle anderen Instanzen werden in privaten Subnetzen bereitgestellt. Je nach Ihren Geschäftsanforderungen können Sie die verschiedenen Instanzen in öffentliche oder private Subnetze platzieren.

In dieser Architektur werden mehrere Anwendungs-Tier-Instanzen in einer einzelnen Availability-Domain bereitgestellt, jedoch werden die einzelnen Anwendungs-Tier-Instanzen in separaten Faultdomains platziert, wodurch eine hohe Verfügbarkeit der Anwendungs-Tier möglich ist. Fault-Domains ermöglichen es Ihnen, Ihre Instanzen so zu verteilen, dass sie nicht auf derselben physischen Hardware in einer einzelnen Availability-Domain sind. Infolgedessen hat ein Hardwarefehler oder eine Hardwarewartung, die sich auf eine Faultdomain auswirkt, keine Auswirkungen auf Instanzen in anderen Faultdomains.

Instanzen im privaten Subnetz erfordern eine ausgehende Verbindung zu Oracle Services Network, um Betriebssystemaktualisierungen (yum) anzuwenden. Verwenden Sie dazu ein Servicegateway in Ihrem VCN. Mit einem Servicegateway können die Hosts im privaten Subnetz auf unterstützte Oracle-Services (wie das yum-Repository) privat zugreifen. Instanzen im privaten Subnetz können optional eine ausgehende Verbindung zum Internet erfordern, um Anwendungspatches und externe Integrationen herunterzuladen. Verwenden Sie dazu ein NAT-Gateway (Network Address Translation) in Ihrem VCN. Mit einem NAT-Gateway können die Hosts im privaten Subnetz Verbindungen zum Internet initiieren und Antworten empfangen, erhalten aber keine eingehenden Verbindungen, die aus dem Internet initiiert wurden.

Alle Anwendungsinstanzen in der Availability-Domain sind aktiv. Die Load Balancer-Instanzen empfangen Anforderungen und senden sie an die Anwendungsserver. Die Anwendungsserver verarbeiten diese Anforderungen und leiten sie an die Datenbankinstanzen weiter. Sie können über den Bastionshost oder das Dynamic Routing Gateway (DRG) auf die Instanzen in privaten Subnetzen über Port 22 zugreifen, wenn Sie einen IPSec-VPN-Tunnel zwischen Ihrem Rechenzentrum und Oracle Cloud Infrastructure DRG eingerichtet haben.

Oracle empfiehlt, dass die Datenbank und die auf Oracle Cloud Infrastructure bereitgestellten Anwendungen eine robuste Backup- und Recovery-Strategie haben sollten. Es wird empfohlen, Backups von Datenbanken und Anwendungsinstanzen in Oracle Cloud Infrastructure Object Storage zu speichern. Die Datenbanken und Anwendungsebeneninstanzen in privaten Subnetzen können mit einem Servicegateway in Oracle Cloud Infrastructure Object Storage gesichert werden. Ein Servicegateway bietet Zugriff auf Oracle Cloud Infrastructure Object Storage, ohne das Internet zu durchlaufen.

Die automatischen und On-Demand-Datenbankbackups für Oracle Cloud Infrastructure Object Storage können mit der Oracle Cloud Infrastructure-Konsole konfiguriert werden. Dies erfordert eine Verbindung zu Oracle Cloud Infrastructure Object Storage mit einem Swift-Endpunkt. Alle Datenbankbackups in Oracle Cloud Infrastructure Object Storage werden mit demselben Masterschlüssel verschlüsselt, der für die Transparente Data Encryption (TDE) Wallet-Verschlüsselung verwendet wird. Der automatische Datenbankbackup-Service verwendet wöchentliche inkrementelle Backup-Strategie, um Datenbanken mit einer benutzerdefinierten Aufbewahrungs-Policy zu sichern, die Sie bei der Konfiguration automatischer Backups anpassen können.

Das Backup der Anwendung kann mit dem Policy-basierten Backup-Feature von Oracle Cloud Infrastructure Block Volumes konfiguriert werden. Oracle Cloud Infrastructure Block Volumes bietet Ihnen die Möglichkeit, Volume-Backups automatisch basierend auf einem Zeitplan durchzuführen und basierend auf der ausgewählten Backup-Policy beizubehalten. Auf diese Weise können Sie Ihre Datenkonformität und regulatorischen Anforderungen einhalten. Es gibt drei vordefinierte Backup-Richtlinien: Bronze, Silber und Gold. Jede Backup-Policy hat eine vordefinierte Backuphäufigkeit und Aufbewahrungsfrist.

Beschreibung von single_availability_domain_ha_topology.png folgt

Beschreibung der Abbildung single_availability_domain_ha_topology.png

Diese Architektur unterstützt die folgenden Komponenten:

Bastionshost: Der Bastionshost ist eine optionale Komponente, die als Jump-Server für den Zugriff auf Instanzen im privaten Subnetz verwendet werden kann. Ein Bastionshost ist eine Oracle Cloud Infrastructure Compute-Instanz, die Linux als Betriebssystem verwendet. Platzieren Sie den Bastion-Host in ein öffentliches Subnetz, und weisen Sie ihm eine öffentliche IP-Adresse zu, um über das Internet darauf zuzugreifen.

Um ein zusätzliches Sicherheitsniveau zu bieten, können Sie Sicherheitslisten einrichten, um nur über die öffentliche IP-Adresse Ihres On-Premise-Netzwerks auf den Bastionshost zuzugreifen. Sie können über den Bastionshost auf Oracle Cloud Infrastructure-Instanzen im privaten Subnetz zugreifen. Aktivieren Sie dazu die Weiterleitung von ssh-agent, mit der Sie eine Verbindung zum Bastionshost herstellen können, und greifen Sie dann auf den nächsten Server zu, indem Sie die Zugangsdaten von Ihrem Computer weiterleiten. Sie können auch über dynamisches SSH-Tunneling auf die Instanzen im privaten Subnetz zugreifen. SSH-Tunneling ist eine Möglichkeit, auf eine Webanwendung oder andere Listening-Services zuzugreifen. Der dynamische Tunnel stellt einen SOCKS-Proxy auf dem lokalen Port bereit, die Verbindungen stammen jedoch vom Remote-Host.
Load Balancer Tier: Diese Ebene enthält Oracle Cloud Infrastructure Load Balancing. Er empfängt Anforderungen von Anwendungsbenutzern und belastet dann den Traffic auf Oracle E-Business Suite-Anwendungsserver. Verwenden Sie Oracle Cloud Infrastructure Load Balancing, um Traffic an Ihre Anwendungsinstanzen innerhalb eines VCN zu verteilen. Dieser Service stellt eine primäre und Standby-Instanz des Load Balancers bereit, um sicherzustellen, dass der Standby-Load Balancer die Anforderungen weiterleitet, wenn der primäre Load Balancer heruntergefahren ist. Der Load Balancer stellt sicher, dass Anforderungen an die gesunden Anwendungsinstanzen weitergeleitet werden. Wenn ein Problem mit einer Anwendungsinstanz auftritt, entfernt der Load Balancer diese Instanz aus der Konfiguration und leitet Anforderungen an die verbleibenden gesunden Anwendungsinstanzen weiter.
Anwendungsebene: Diese Ebene enthält mehr als eine Instanz einer Oracle E-Business Suite-Anwendung, um eine hohe Verfügbarkeit bereitzustellen. Richten Sie mehrere Instanzen einer Anwendung in einer separaten Faultdomain ein, um sicherzustellen, dass Sie weiterhin auf die Anwendung zugreifen können, selbst wenn eine Anwendungsinstanz heruntergefahren ist.

Oracle empfiehlt, das Oracle E-Business Suite Multi-Tier-Setup mit Shared Application Binärdateien bereitzustellen. Erstellen Sie mit Oracle Cloud Infrastructure File Storage ein gemeinsam verwendetes Dateisystem, um Oracle E-Business Suite-Anwendungs-Binärdateien gemeinsam zu verwenden.
Datenbankebene: Diese Ebene enthält Oracle Cloud Infrastructure Database-Instanzen. Für Anforderungen an hohe Verfügbarkeit empfiehlt Oracle, ein 2-Knoten Virtual Machine (VM)-DB-System oder Exadata-DB-System zu verwenden.

Architektur für das Deployment von Oracle E-Business Suite mit einer entmilitarisierten Zone (DMZ)

Diese Architektur zeigt das Deployment einer Oracle E-Business Suite-Anwendung in einer einzelnen Availability-Domain mit DMZ.

Die Architektur besteht aus einem virtuellen Cloud-Netzwerk (VCN) mit Bastionshost, einem internen Load Balancer, einer internen Anwendungsebene, einem externen Load Balancer, einer externen Anwendungsebene und Datenbankhosts, die in separaten Subnetzen von VCN in einer einzelnen Availability-Domain platziert sind. Im folgenden Architekturdiagramm wird der externe Load Balancer in einem öffentlichen Subnetz bereitgestellt, und alle anderen Instanzen werden in privaten Subnetzen bereitgestellt.

Beschreibung von ebs-singlead-dmz.png folgt
Beschreibung der Abbildung ebs-singlead-dmz.png

Das DMZ, das mit einem öffentlichen Load Balancer-Subnetz implementiert wird, empfängt Anforderungen von Geschäftspartnern und Lieferanten, während der interne Load Balancer, der mit einem privaten Load Balancer-Subnetz implementiert wird, Anforderungen von internen Benutzern empfängt. Dedizierte Anwendungsebenen verarbeiten die Anforderungen dieser beiden verschiedenen Benutzertypen.

Oracle empfiehlt, dass die Datenbank und die auf Oracle Cloud Infrastructure bereitgestellten Anwendungen eine robuste Backup- und Recovery-Strategie haben sollten. Es wird empfohlen, Backups von Datenbanken und Anwendungsebeneninstanzen in Oracle Cloud Infrastructure Object Storage zu speichern. Die Datenbanken und Anwendungsebeneninstanzen in privaten Subnetzen können mit einem Servicegateway in Oracle Cloud Infrastructure Object Storage gesichert werden. Ein Servicegateway bietet Zugriff auf Oracle Cloud Infrastructure Object Storage, ohne das Internet zu durchlaufen.

Diese Architektur unterstützt die folgenden Komponenten:

Bastionshost: Der Bastionshost ist eine optionale Komponente, die als Jump-Server für den Zugriff auf Instanzen im privaten Subnetz verwendet werden kann. Ein Bastionshost ist eine Oracle Cloud Infrastructure Compute-Instanz, die Linux als Betriebssystem verwendet.

Um ein zusätzliches Sicherheitsniveau zu bieten, können Sie Sicherheitslisten einrichten, um nur über die öffentliche IP-Adresse Ihres On-Premise-Netzwerks auf den Bastionshost zuzugreifen. Sie können über den Bastionshost auf Oracle Cloud Infrastructure-Instanzen im privaten Subnetz zugreifen. Aktivieren Sie dazu die Weiterleitung von ssh-agent, mit der Sie eine Verbindung zum Bastionshost herstellen können, und greifen Sie dann auf den nächsten Server zu, indem Sie die Zugangsdaten von Ihrem Computer weiterleiten. Sie können auch über dynamisches SSH-Tunneling auf die Instanzen im privaten Subnetz zugreifen. SSH-Tunneling ist eine Möglichkeit, auf eine Webanwendung oder andere Listening-Services zuzugreifen. Der dynamische Tunnel stellt einen SOCKS-Proxy auf dem lokalen Port bereit, die Verbindungen stammen jedoch vom Remote-Host.
Interne Load Balancer-Ebene Diese Ebene enthält Oracle Cloud Infrastructure Load Balancing. Er empfängt Anforderungen von internen Anwendungsbenutzern und belastet dann den Traffic auf interne Oracle E-Business Suite-Anwendungsserver. Verwenden Sie Oracle Cloud Infrastructure Load Balancing, um Traffic an Ihre Anwendungsinstanzen innerhalb eines VCN zu verteilen. Dieser Service stellt eine primäre und Standby-Instanz des Load Balancers bereit, um sicherzustellen, dass der Standby-Load Balancer die Anforderungen weiterleitet, wenn der primäre Load Balancer heruntergefahren ist. Der Load Balancer stellt sicher, dass Anforderungen an die gesunden Anwendungsinstanzen weitergeleitet werden. Wenn ein Problem mit einer Anwendungsinstanz auftritt, entfernt der Load Balancer diese Instanz aus der Konfiguration und leitet Anforderungen an die verbleibenden gesunden Anwendungsinstanzen weiter.
Externe Load Balancer-Ebene: Diese Ebene dient demselben Zweck wie die interne Load Balancer-Ebene, jedoch für externe Anwendungsbenutzer, wie sie Lieferanten zugeordnet sind.
Anwendungsebene: Diese Ebene enthält mehr als eine Instanz einer Oracle E-Business Suite-Anwendung, um eine hohe Verfügbarkeit bereitzustellen. Richten Sie mehrere Instanzen einer Anwendung in einer separaten Faultdomain ein, um sicherzustellen, dass Sie weiterhin auf die Anwendung zugreifen können, selbst wenn eine Anwendungsinstanz heruntergefahren ist.

Mit separaten Anwendungsebenen für interne und externe Benutzer können Sie in dieser Architektur den Datenverkehr isolieren und die Sicherheit Ihres Systems schützen.

Oracle empfiehlt, das Oracle E-Business Suite Multi-Tier-Setup mit Shared Application Binärdateien bereitzustellen. Erstellen Sie mit Oracle Cloud Infrastructure File Storage ein gemeinsam verwendetes Dateisystem, um Oracle E-Business Suite-Anwendungs-Binärdateien gemeinsam zu verwenden.
Datenbankebene: Diese Ebene enthält Oracle Cloud Infrastructure Database-Instanzen. Für Anforderungen an hohe Verfügbarkeit empfiehlt Oracle, ein 2-Knoten Virtual Machine (VM)-DB-System oder Exadata-DB-System zu verwenden.

Architektur für das Deployment von Oracle E-Business Suite in mehreren Availability-Domains

Diese Architektur zeigt das Deployment einer Oracle E-Business Suite-Anwendung über mehrere Availability-Domains hinweg. Es zeigt ein virtuelles Cloud-Netzwerk (VCN) mit Bastion, Load Balancer, Anwendung und Datenbankinstanzen, die in separaten Subnetzen in zwei Availability-Domains platziert sind.

Mehrere Anwendungsserver werden in jeder Availability-Domain bereitgestellt, um eine hohe Verfügbarkeit innerhalb einer Availability-Domain sicherzustellen. Alle Anwendungsserver innerhalb einer Availability-Domain werden über verschiedene Faultdomains bereitgestellt. Durch die Verwendung verschiedener Faultdomains sind Anwendungsinstanzen durch Hardwarewartung vor unerwarteten Hardwareausfällen und geplanten Ausfällen geschützt. Darüber hinaus werden redundante Instanzen in einer anderen Availability-Domain erstellt, um die Verfügbarkeit zu gewährleisten, falls die primäre Availability-Domain nicht verfügbar ist. Im Architekturdiagramm sind die Instanzen in Availability-Domain 1 aktiv und die Instanzen in Availability-Domain 2 befinden sich im Standby. Oracle empfiehlt, Anwendungs- und Datenbankinstanzen in symmetrischer Topologie über Availability-Domains hinweg einzurichten, um sicherzustellen, dass Ihre aktiven Instanzen die gesamte Ladung bereitstellen, wenn die primäre Availability-Domain nicht verfügbar ist. In der symmetrischen Topologie stellen Sie dieselbe Anzahl von Anwendungs- und Datenbankinstanzen sowohl auf aktiven als auch auf Standby-Rechnern bereit. Wenn die Instanzen in Availability-Domain 1 aktiv sind, wird der Load Balancer so konfiguriert, dass der Traffic nur auf diese aktiven Instanzen geleitet wird. Load Balancer ist nicht so konfiguriert, dass Traffic zu den Anwendungsserverinstanzen in Availability-Domain 2 weitergeleitet wird. Dies bedeutet, dass die Anwendungsinstanzen in Availability-Domain 2 nicht zum Load Balancer-Backend-Set hinzugefügt werden. Wenn Availability-Domain 1 nicht verfügbar ist, müssen Sie die Anwendung und Datenbank manuell auf die andere Availability-Domain umschalten. In diesem Szenario werden die Anwendungs- und Datenbankserverinstanzen in Availability-Domain 2 aktiv. Zu diesem Zeitpunkt müssen Sie das Backend-Set des Load Balancers mit Anwendungsinstanzen in Availability-Domain 2 aktualisieren und auch die Anwendungsinstanzen der Availability-Domain 1 entfernen. Der Load Balancer akzeptiert dann Anforderungen und leitet sie an Anwendungsserver in Availability-Domain 2 weiter.

Verwenden Sie für ein nahtloses Failover über Availability-Domains hinweg logische Hostnamen für die Oracle E-Business Suite-Datenbank und Anwendungsinstanzen. Verwenden Sie dieselben logischen Hostnamen auf den Primär- und Standby-Rechnern, um den Aufwand für die Neukonfiguration von Instanzen während des Switchover oder Failovers zu reduzieren.

Die auf Oracle Cloud Infrastructure bereitgestellte Datenbank und Anwendung wird empfohlen, ein robustes Backup der Recovery-Strategie zu haben. Es wird empfohlen, das Backup von Datenbanken und Anwendungsinstanzen in Oracle Cloud Infrastructure Object Storage zu speichern. Die Datenbanken und Anwendungsinstanzen in privaten Subnetzen können mit einem Servicegateway in Oracle Cloud Infrastructure Object Storage gesichert werden. Ein Servicegateway bietet Zugriff auf Oracle Cloud Infrastructure Object Storage, ohne das Internet zu durchlaufen.

Der automatische Datenbankbackup-Service verwendet wöchentliche inkrementelle Backup-Strategie, um Datenbanken mit einer 30-Tage-Aufbewahrungs-Policy zu sichern. Es ist auch möglich, ein on-Demand vollständiges Backup von Datenbanken für Ad-hoc-Anforderungen durchzuführen.

Im folgenden Architekturdiagramm wird der Bastionshost in einem öffentlichen Subnetz bereitgestellt und alle anderen Instanzen werden in privaten Subnetzen bereitgestellt. Je nach Ihren Geschäftsanforderungen können Sie die verschiedenen Instanzen in öffentliche oder private Subnetze platzieren. Sie können über den Bastionshost oder DRG auf die Instanzen in privaten Subnetzen über Port 22 zugreifen, wenn Sie einen IPSec-VPN-Tunnel zwischen Ihrem Rechenzentrum und Oracle Cloud Infrastructure DRG eingerichtet haben.

Beschreibung von multiple_availability_domain_ha_topology.png folgt

Beschreibung der Abbildung multiple_availability_domain_ha_topology.png

Diese Architektur unterstützt die folgenden Komponenten:

Bastionshost: Der Bastionshost ist eine optionale Komponente, mit der Sie als Jump-Server auf die Anwendungs- und Datenbankinstanzen zugreifen können. Stellen Sie für hohe Verfügbarkeit einen Bastionshost in beiden Availability-Domains bereit.
Load Balancer Tier: Oracle Cloud Infrastructure Load Balancing verteilt Traffic auf die Anwendungsserver in einer Availability-Domain. Der Load Balancer kann als öffentlicher oder privater Load Balancer bereitgestellt werden.
Anwendungsebene: In jeder Availability-Domain werden mehrere Anwendungsserver eingerichtet, um eine hohe Verfügbarkeit zu gewährleisten. Die Anwendungsserver in Availability-Domain 1 befinden sich im aktiven Status, und die Anwendungsserver in der Availability-Domain 2 befinden sich im passiven Status. Verwenden Sie rsync, um Anwendungsserver über Availability-Domains hinweg zu synchronisieren.

Oracle empfiehlt, das Oracle E-Business Suite Multi-Tier-Setup mit Shared Application Binärdateien bereitzustellen. Erstellen Sie mit Oracle Cloud Infrastructure File Storage ein gemeinsam verwendetes Dateisystem, um Oracle E-Business Suite-Anwendungs-Binärdateien gemeinsam zu verwenden.
Datenbankebene: Richten Sie hochverfügbare Datenbankinstanzen in beiden Availability-Domains ein. Das Architekturdiagramm zeigt, dass die Datenbankserver in Availability-Domain 1 aktiv sind und die Datenbankserver in Availability-Domain 2 auf Standby sind. Um die Datenbank über Availability-Domains hinweg zu replizieren, verwenden Sie Oracle Active Data Guard oder Oracle Data Guard. Sie können Oracle Data Guard für eine Datenbank aus der Oracle Cloud Infrastructure-Konsole oder mit Oracle Cloud Infrastructure-APIs aktivieren.

Architektur für das Deployment von Oracle E-Business Suite in mehreren Regionen

Sie können die Oracle E-Business Suite-Anwendung in mehreren Regionen für das Disaster Recovery bereitstellen. Diese Architektur ähnelt dem Deployment der Oracle E-Business Suite-Anwendung über mehrere Verfügbarkeitsdomains hinweg. In dieser Architektur werden Load Balancer-, Anwendungs- und Datenbankinstanzen in separaten Subnetzen über mehrere Regionen hinweg platziert.

Um die Verfügbarkeit zu gewährleisten, falls die primäre Region nicht verfügbar ist, werden redundante Instanzen in der Standbyregion erstellt. Die primäre Region enthält aktive Instanzen in einer Availability-Domain. Die Instanzen in einer Availability-Domain in der zweiten Region, der Disaster Recovery-Region, befinden sich im Standby. Oracle empfiehlt, Anwendungs- und Datenbankinstanzen in der symmetrischen Topologie über Regionen hinweg einzurichten, um sicherzustellen, dass Ihre aktiven Instanzen die gesamte Ladung bereitstellen, wenn die primäre Region nicht verfügbar ist. In der symmetrischen Topologie stellen Sie dieselbe Anzahl von Anwendungs- und Datenbankinstanzen sowohl in den primären als auch in den Standbyregionen bereit. In dieser Architektur werden in jeder Availability-Domain mehrere Anwendungsserver bereitgestellt, um eine hohe Verfügbarkeit innerhalb einer Availability-Domain sicherzustellen.

Da diese Architektur in nur einer Availability-Domain in Region 1 und einer Availability-Domain in Region 2 für das Disaster Recovery bereitgestellt wird, bietet sie keine Fehlertoleranz für die Availability-Domain in Region 1. Wenn die einzige Availability-Domain, in der die Anwendung bereitgestellt wurde, nicht verfügbar ist, müssen Sie Disaster Recovery aufrufen, um über Ihre Anwendung in Region 2 zu scheitern.

Wenn die Instanzen in Region 1 nicht verfügbar sind, müssen Sie manuell zu den Instanzen in Region 2 wechseln. Verwenden Sie für ein nahtloses Failover über Regionen hinweg logische Hostnamen für die Oracle E-Business Suite-Datenbank und Anwendungsinstanzen. Verwenden Sie dieselben logischen Hostnamen auf den primären und Standby-Rechnern, um das Failover zu erleichtern oder zurückzuschalten, ohne Instanzen neu zu konfigurieren.

Um die Datenbank über mehrere Regionen hinweg zu replizieren, verwenden Sie Oracle Active Data Guard oder Oracle Data Guard im asynchronen Modus. Verwenden Sie rsync, um Anwendungsserver in mehreren Regionen zu synchronisieren.

Beschreibung von multiple_region_topology.png folgt
Beschreibung der Abbildung multiple_region_topology.png