Learn About Deploying PeopleSoft on Oracle Cloud Infrastructure (2024)

Wenn Sie die PeopleSoft-Anwendungen von Oracle auf Oracle Cloud Infrastructure bereitstellen oder PeopleSoft-Umgebungen aus Ihrem Data Center in Oracle Cloud Infrastructure migrieren möchten, können Sie eine Multihost-, sichere, Hochverfügbarkeitstopologie planen.

Überlegungen zum Deployment von Oracle Cloud Infrastructure

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

Private oder öffentliche Subnetze

Sie können Instanzen in einem privaten oder öffentlichen Subnet erstellen, je nachdem, ob Sie den Zugriff auf die Instanzen aus dem 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. Deshalb können Sie nicht über das Internet auf diese Instanzen zugreifen.

Das folgende Bild zeigt ein virtuelles Cloud-Netzwerk (Virtual Cloud Network, VCN) mit öffentlichen und privaten Subnetzen. Das VCN enthält zwei Availability-Domains, und jede Availability-Domain enthält eine öffentliche und private Untergruppe. Die Webserver werden in diesem Bild im öffentlichen Subnetz platziert. Daher ist den Webserverinstanzen eine öffentliche IP-Adresse zugeordnet. Sie können über das Internetgateway (IGW) auf diese Oracle Cloud-Instanzen im öffentlichen Subnetz zugreifen. Sie müssen die Routingtabelle aktualisieren, um den Datenverkehr von der IGW zu ermöglichen. Um den Datenverkehr zu den Webservern im Internet zu ermöglichen, müssen Sie Load Balancer im öffentlichen Subnetz erstellen. Um im Internet auf Ihre Instanzen zuzugreifen, müssen Sie auch einen Bastion-Host im öffentlichen Subnetz erstellen und über IGW auf den Bastion-Host zugreifen.

Die Datenbankserver werden in diesem Bild im privaten Subnetz platziert. Sie können über das dynamische Routinggateway (DRG) auf Oracle Cloud-Instanzen im privaten Subnetz zugreifen. DRG ist das Gateway, das Ihr On-Premise-Netzwerk mit Ihrem Cloud-Netzwerk verbindet. Verwenden Sie IPSec VPN oder Oracle Cloud Infrastructure FastConnect, um die Kommunikation zwischen dem DRG und dem Customer Premise zu ermöglichen. Sie müssen außerdem die Routingtabelle aktualisieren, um den Datenverkehr zu und von DRG zu ermöglichen.

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. Dieser Deployment-Typ ist nützlich, wenn Sie über ein Hybrid-Deployment mit der Cloud als Erweiterung für die vorhandenen Data Center verfügen möchten.

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

Konfigurieren Sie einen IPSec-VPN-Tunnel zwischen Ihrem Data Center und Oracle Cloud Infrastructure DRG, bevor Sie die Application Server durch Provisioning bereitstellen.
Erstellen Sie in dieser Konfiguration einen Bastion-Host, und greifen Sie dann vom Bastion-Host 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. Dieser Deployment-Typ ist nützlich, wenn das Deployment über interne und nicht interaktive Endpunkte verfügt.

In dieser Konfiguration werden einige Anwendungsinstanzen in einem öffentlichen Subnetz platziert, und andere werden in einem privaten Subnetz platziert. Beispiel: Es gibt Anwendungsinstanzen, die interne Benutzer und andere Anwendungsinstanzen bedienen, die externe Benutzer bedienen. Platzieren Sie In diesem Szenario die Anwendungsinstanzen, die internen Datenverkehr In einem privaten Subnetz bedienen, und platzieren Sie die Anwendungsserver, die externen Datenverkehr In einem öffentlichen Subnet bedienen. Sie können auch einen öffentlichen Load Balancer für die internetorientierten Anwendungsinstanzen einrichten, anstatt die Anwendungsserver, die externen Verkehr in einem öffentlichen Subnetz bedienen, zu platzieren. Wenn Sie den Bastion-Host in einem öffentlichen Subnetz ablegen, wird dem Bastion-Host eine öffentliche IP-Adresse zugewiesen, und Sie können über das Internet darauf zugreifen. Sie können über den Bastion-Server auf Ihre Instanzen im privaten Subnetz zugreifen.

Szenario 3: Alle Instanzen in öffentlichen Subnetzen bereitstellen

Oracle empfiehlt dieses Deployment für schnelle Demos oder Deployments der Production-Gehaltsgruppe ohne interne Endpunkte. Dieses Deployment eignet sich nur, wenn Sie nicht über Ihr eigenes Data Center verfügen, oder wenn Sie nicht auf Instanzen über VPN zugreifen und auf die Infrastruktur über das Internet 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. Auch wenn auf Instanzen mit öffentlichen IP-Adressen über das Internet zugegriffen werden kann, können Sie den Zugriff mit Sicherheitslisten und Sicherheitsregeln einschränken. Zur Ausführung von Administrationsaufgaben empfiehlt Oracle, dass Sie einen Bastion-Host in dieser Konfiguration speichern. In diesem Szenario öffnen Sie keine Administrationsports für das öffentliche Internet, sondern öffnen nur die Administrationsports für den Bastion-Host und richten Sicherheitslisten und Sicherheitsregeln ein, um sicherzustellen, dass nur der Bastion-Host auf die Instanz zugreifen kann.

Anti-Affinität

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

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

Für hohe Verfügbarkeit von Datenbanken können Sie 2-node Oracle Real Application Clusters - (Oracle RAC-) Datenbanksysteme erstellen. Die beiden Knoten von Oracle RAC werden standardmäßig immer in separaten Faultdomains erstellt. Die Datenbankknoten befinden sich also weder auf demselben physischen Host noch auf demselben physischen Rack. Dadurch werden die Datenbankinstanzen vor dem zugrunde liegenden physischen Host und der Anfang des Rack-Switch geschützt.

Architektur

Informationen zu den wichtigsten Konzepten, mit denen Sie diese Deployment-Optionen für PeopleSoft planen können:

Architektur für das Deployment von PeopleSoft in einer einzelnen Availability-Domain, während hohe Verfügbarkeit sichergestellt wird. Verwenden Sie diese Architektur, um sicherzustellen, dass die Anwendung verfügbar ist, selbst wenn eine Anwendungsinstanz heruntergefahren wird. Die anderen verfügbaren Anwendungsinstanzen in der Availability-Domain werden weiter verarbeitet.
Architektur für das Deployment von PeopleSoft in mehreren Availability-Domains, während hohe Verfügbarkeit sichergestellt wird. 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 weiterhin auf die Anwendungsinstanzen in einer anderen Availability-Domain zugreifen.
Architektur, mit der PeopleSoft bereitgestellt wird, während High Availability und Disaster Recovery sichergestellt wird. Verwenden Sie diese Architektur, wenn Sie eine Disaster Recovery-Site für Ihre Anwendung in einer anderen Region einrichten möchten.

Die Architektur ist für PeopleSoft-Deployments gültig, die manuell oder mit PeopleSoft-Automatisierungstools in Oracle Cloud Infrastructure ausgeführt werden.

Alle Architekturdiagramme werden empfohlen, wenn Sie nicht über das Internet auf die Datenbank und die Anwendungshosts zugreifen möchten.

Architektur für das Deployment von PeopleSoft in einer einzelnen Availability-Domain

Diese Architektur zeigt das Deployment einer PeopleSoft-Anwendung in einer einzelnen Availability-Domain, während hohe Verfügbarkeit sichergestellt wird.

Die Architektur besteht aus einem VCN, in dem die Bastion, Load Balancer, Anwendung und Datenbankhosts in separaten Subnets des VCNs in einer einzelnen Availability-Domain gespeichert sind. Der Bastion-Host wird in einem öffentlichen Subnetz bereitgestellt, und alle anderen Instanzen werden in privaten Subnetzen bereitgestellt. Sie können die verschiedenen Instanzen entsprechend Ihren Geschäftsanforderungen in öffentliche oder private Subnetze setzen. Sie können über den Basishost oder DRG auf die Instanzen in privaten Subnetzen über Port 22 zugreifen, wenn Sie einen IPSec-VPN-Tunnel zwischen Ihrem Data Center und Oracle Cloud Infrastructure DRG eingerichtet haben.

In dieser Architektur werden redundante Instanzen in der Application Tier und Database Tier bereitgestellt, um High Availability innerhalb der Availability-Domain sicherzustellen. Dadurch wird sichergestellt, dass die Anwendung auch dann verfügbar ist, wenn eine Anwendungsinstanz heruntergefahren wird. Die anderen verfügbaren Anwendungsinstanzen in der Availability-Domain werden weiter verarbeitet. Alle Anwendungsinstanzen in der Availability-Domain sind aktiv. Die Load Balancer-Instanzen empfangen Anforderungen und senden sie an die Anwendungsserver. Diese High Availability einer Anwendung innerhalb einer Availability-Domain kann erreicht werden, indem Anwendungsinstanzen in separaten Faultdomains abgelegt werden. Mit Faultdomains können Sie Ihre Instanzen so verteilen, dass sie sich nicht auf derselben physischen Hardware innerhalb einer einzelnen Availability-Domain befinden. Deshalb wirkt sich ein Hardwarefehler oder eine Hardwarewartung, die sich auf eine Faultdomain auswirkt, nicht auf Instanzen in anderen Faultdomains aus.

Instanzen im privaten Subnetz erfordern eine ausgehende Verbindung zum Internet, um Patches herunterzuladen und Betriebssystemupdates und Anwendungsupdates einzuspielen. Verwenden Sie zu diesem Zweck ein Network Address Translation (NAT) Gateway in Ihrem VCN. Mit einem NAT-Gateway können Hosts in einem privaten Subnetz Verbindungen mit dem Internet initiieren und Antworten empfangen, vom Internet ausgelöste eingehende Verbindungen werden jedoch nicht empfangen.

Oracle empfiehlt, dass die Datenbank und die Anwendungen, die in Oracle Cloud Infrastructure bereitgestellt werden, ein robustes Backup der Recovery-Strategie haben. Es wird empfohlen, ein 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.

Die automatischen und bedarfsgesteuerten Datenbankbackups in Oracle Cloud Infrastructure Object Storage können mit der Oracle Cloud Infrastructure-Konsole konfiguriert werden. Dies erfordert Verbindungen 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 Datenverschlüsselung (TDE)-Wallet-Verschlüsselung verwendet wird. Der automatische Datenbankbackup-Service verwendet eine wöchentliche inkrementelle Backup-Strategie für das Backup von Datenbanken mit einer 30-day Aufbewahrungs-Policy. Sie können außerdem ein vollständiges On-Demand-Backup von Datenbanken für Ad-hoc-Anforderungen ausführen.

Das Backup der Anwendung kann mit der Policy-basierten Backupfunktion von Oracle Cloud Infrastructure Block Volumes konfiguriert werden. Mit Oracle Cloud Infrastructure Block Volumes können Sie Volume-Backups automatisch basierend auf einem Ausführungsplan ausführen und basierend auf der gewählten Backup-Policy beibehalten. Auf diese Weise können Sie die Datencompliance und die gesetzlichen Bestimmungen einhalten. Es gibt drei vordefinierte Backup-Policys: Bronze, Silver und Gold. Jede Backup-Policy hat eine vordefinierte Backuphäufigkeit und einen Aufbewahrungszeitraum.

Beschreibung der Abbildung peoplesoft_single_availability_domain_ha_topology.png

Diese Architektur ist in folgende Ebenen unterteilt:

Bastion-Host: Der Bastion-Host ist eine optionale Komponente, die Sie als Jump-Server für den Zugriff auf die Instanzen im privaten Subnetz verwenden können.
Load Balancer-Tier: Diese Tier enthält die Oracle Cloud Infrastructure Load Balancing-Instanzen, die den Datenverkehr auf PeopleSoft-Webserver verteilen. Der Load Balancer empfängt Anforderungen von Benutzern und leitet diese Anforderungen dann an die Application Tier weiter.
Application Tier: Diese Tier enthält redundante Instanzen der PeopleSoft-Anwendungsserver, PeopleSoft-Webserver, ElasticSearch-Server und PeopleSoft Process Scheduler, um High Availability zu gewährleisten. Richten Sie redundante Instanzen aller Server in der Application Tier ein, um sicherzustellen, dass Sie selbst dann auf die Anwendung zugreifen können, wenn eine Instanz heruntergefahren wird.
PeopleTools-Client: Verwenden Sie den PeopleTools-Client, um Administrationsaktivitäten wie Entwicklung, Migration und Upgrade durchzuführen.
Database Tier: Diese Tier enthält Oracle Cloud Infrastructure-Datenbanksysteminstanzen. Für High Availability-Anforderungen empfiehlt Oracle, dass Sie zwei Oracle Real Application Clusters - (Oracle RAC-) Datenbanksysteme oder ein Oracle Database Exadata Cloud Service-System von Oracle Cloud Infrastructure verwenden.

Architektur für das Deployment von PeopleSoft in mehreren Availability-Domains

Diese Architektur zeigt das Deployment von PeopleSoft-Anwendungsservern in mehreren Availability-Domains. Hier wird ein VCN mit Basis, Load Balancer, Anwendung und Datenbankhosts dargestellt, die in zwei Availability-Domains in separaten Subnetzen platziert werden.

Im Architekturdiagramm wird der Bastion-Host In einem öffentlichen Subnetz bereitgestellt, und alle anderen Instanzen werden In privaten Subnetzen bereitgestellt. Sie können die Instanzen basierend auf Ihren Geschäftsanforderungen in öffentliche oder private Subnetze setzen. Sie können über den Basishost oder DRG auf die Instanzen in privaten Subnetzen über Port 22 zugreifen, wenn Sie einen IPSec-VPN-Tunnel zwischen Ihrem Data Center und Oracle Cloud Infrastructure DRG eingerichtet haben. Alle Instanzen sind in den beiden Availability-Domains aktiv. Die einzigen passiven Komponenten in der Architektur sind die Datenbankhosts in Availability-Domain 2.

Die Bastion-Hosts in Availability-Domain 1 und Availability-Domain 2 sind aktiv und können SSH-Anforderungen an Instanzen in beiden Availability-Domains jederzeit verarbeiten. Der On-Premise-DNS- oder externe DNS-Service empfängt eine Anforderung für die PeopleSoft-Anwendung. Bei diesen Anforderungen handelt es sich um einen Round-Robin-Load, der auf einen der Load Balancer in Availability-Domain 1 oder 2 verteilt ist. Der Load Balancer leitet die Anforderung dann an einen der zugrunde liegenden PeopleSoft-Webserver in Availability-Domain 1 oder 2 weiter. Der PeopleSoft-Webserver leitet die Anforderung dann an einen der PeopleSoft-Anwendungsserver weiter und leitet abschließend Anforderungen an die aktiven Datenbankinstanzen in Availability-Domain 1 zur Verarbeitung weiter.

Wenn Availability-Domain 1 nicht verfügbar ist, müssen Sie den Eintrag von Availability-Domain 1 Load Balancer manuell aus dem DNS-Service entfernen und zu den Datenbankinstanzen in Availability-Domain 2 wechseln. Anforderungen, die vom DNS-Service empfangen werden, werden jetzt an den Load Balancer in Availability-Domain 2 weitergeleitet und schließlich an die Datenbank in Availability-Domain 2 zur Verarbeitung.

Beschreibung der Abbildung peoplesoft_multiple_availability_domain_ha_topology.png

Bastion-Host: Ein Bastion-Host ist eine optionale Komponente, die Sie in jeder Availability-Domain bereitstellen können, damit sie als Jump-Host für den Zugriff auf Anwendungs- und Datenbankinstanzen fungiert. Bastion-Hosts in Availability-Domain 1 und Availability-Domain 2 befinden sich im aktiven Status.
Load Balancer-Instanzen: Oracle Cloud Infrastructure Load Balancing-Instanzen verteilen Datenverkehr über die Anwendungsserver in beiden Availability-Domains. Load Balancer-Instanzen in Availability-Domain 1 und 2 sind aktiv. Anforderungen, die an der PeopleSoft-URL empfangen werden, sind eine Round-Robin-Belastung, die einem Load Balancer in Availability-Domain 1 oder 2 von einer On-Premise- oder externen DNS-Service ausgeglichen ist.
Application Tier: Sowohl Availability-Domain 1 als auch Availability-Domain 2 enthalten redundante Instanzen von PeopleSoft-Anwendungsserver, PeopleSoft-Webserver, ElasticSearch-Server und PeopleSoft Process Scheduler. Alle Instanzen in der Application Tier in den beiden Availability-Domains befinden sich im aktiven Status.
PeopleTools-Client: Verwenden Sie den PeopleTools-Client, um Administrationsaktivitäten wie Entwicklung, Migration und Upgrade durchzuführen.
Database Tier: hochverfügbare Datenbankinstanzen in beiden Availability-Domains einrichten. Availability-Domain 1 hostet die Primärdatenbankinstanzen. Availability-Domain 2 hostet die Standby-Datenbankinstanzen. In jeder Availability-Domain sind mindestens zwei Datenbankinstanzen eingerichtet, um High Availability zu gewährleisten. Wenn eine Datenbankinstanz in Availability-Domain 1 nicht verfügbar ist, verarbeitet die zweite Datenbankinstanz in Availability-Domain 1 mit der Verarbeitung von Anforderungen.

Verwenden Sie Oracle Active Data Guard im synchronen Modus, um die Datenbank über Availability-Domains in einer Region hinweg zu replizieren.

Architektur für das Deployment von PeopleSoft über mehrere Regionen

Diese Architektur zeigt das Deployment von PeopleSoft-Anwendungsservern für mehrere Regionen, während High Availability und Disaster Recovery sichergestellt werden. Hier wird ein VCN mit Basis, Load Balancer, Anwendung und Datenbankinstanzen dargestellt, die in zwei Regionen in separaten Subnetzen platziert werden. Um sicherzustellen, dass Sie auf PeopleSoft-Anwendungsinstanzen zugreifen können, selbst wenn alle Availability-Domains in einer Region heruntergefahren sind, stellen Sie PeopleSoft für mehrere Regionen bereit.

Das Architekturdiagramm zeigt zwei Bereiche an. In Region 1 wird PeopleSoft in mehreren Availability-Domains bereitgestellt, um High Availability über Availability-Domains in einer Region zu gewährleisten. Region 2 ist der Disaster Recovery-Bereich. Alle Instanzen sind in den beiden Availability-Domains in Region 1 aktiv. Die passiven Komponenten in der Architektur sind die Datenbankhosts in Availability-Domain 2 und alle Instanzen in Region 2. Oracle empfiehlt, dass die Anzahl von Instanzen, die Sie für jede Tier in der Availability-Domain in Region 2 bereitstellen, identisch mit der Anzahl von Instanzen ist, die in einer Availability-Domain in Region 1 bereitgestellt werden. Dadurch wird sichergestellt, dass die Anwendungsinstanzen nach dem Aufruf von Disaster Recovery die gesamte Belastung übernehmen können.

Diese Architektur kann auch in nur einer Availability-Domain in Region 1 und einer Availability-Domain in Region 2 für Disaster Recovery bereitgestellt werden. Diese Architektur bietet jedoch keine Fehlertoleranz für Availability-Domain in Region 1. Wenn die einzige Availability-Domain, in der die Anwendung bereitgestellt wurde, nicht verfügbar ist, müssen Sie das Disaster Recovery aufrufen, damit die Anwendung in Region 2 übergehen kann.

In Region 1 sind die Bastion-Hosts in Availability-Domain 1 und Availability-Domain 2 aktiv und können SSH-Anforderungen an Instanzen in beiden Availability-Domains jederzeit verarbeiten. Der On-Premise-DNS- oder externe DNS-Service empfängt eine Anforderung für die PeopleSoft-Anwendung. Bei diesen Anforderungen handelt es sich um einen Round-Robin-Load, der auf einen der Load Balancer in Availability-Domain 1 oder 2 verteilt ist. Der Load Balancer leitet die Anforderung dann an einen der zugrunde liegenden PeopleSoft-Webserver in Availability-Domain 1 oder 2 weiter. Der PeopleSoft-Webserver leitet die Anforderung dann an einen der PeopleSoft-Anwendungsserver weiter und leitet abschließend Anforderungen an die aktiven Datenbankinstanzen in Availability-Domain 1 zur Verarbeitung weiter.

Wenn die Instanzen in Region 1 nicht verfügbar sind, müssen Sie manuell zu den Instanzen in Region 2 wechseln. In diesem Szenario fungieren der Load Balancer und die Datenbankinstanzen in Region 2 als primärer Load Balancer und als Datenbankinstanzen. Anforderungen, die unter der PeopleSoft-URL eingehen, werden an den Load Balancer in Region 2 weitergeleitet, der dann den Datenverkehr an den zugrunde liegenden PeopleSoft-Webserver in Region 2 weiterleitet. Die PeopleSoft-Webserver leiten die Anforderung an PeopleSoft-Anwendungsinstanzen weiter, und die PeopleSoft-Anwendungsserver leiten die Anforderungen zur Verarbeitung an die Datenbankinstanzen in Region 2 weiter.

Im Architekturdiagramm werden der Bastion-Host und Load Balancer In öffentlichen Subnetzen bereitgestellt, und alle anderen Instanzen werden In privaten Subnetzen bereitgestellt. Sie können die Instanzen basierend auf Ihren Geschäftsanforderungen in öffentliche oder private Subnetze setzen. Sie können über den Basishost oder DRG auf die Instanzen in privaten Subnetzen über Port 22 zugreifen, wenn Sie einen IPSec-VPN-Tunnel zwischen Ihrem Data Center und Oracle Cloud Infrastructure DRG eingerichtet haben.

Beschreibung der Abbildung peoplesoft_multiple_regions_ha_topology.png

Diese Architektur unterstützt die folgenden Komponenten:

Bastion-Host: Ein Bastion-Host ist eine optionale Komponente, die Sie in jeder Availability-Domain bereitstellen können, damit sie als Jump-Host für den Zugriff auf Anwendungs- und Datenbankinstanzen fungiert. Bastion-Hosts in Availability-Domain 1 und Availability-Domain 2 befinden sich im aktiven Status.
Load Balancer-Instanzen: Oracle Cloud Infrastructure Load Balancing-Instanzen verteilen Datenverkehr über die Anwendungsserver in beiden Availability-Domains. Availability-Domain 1 und 2 in Region 1 hostet die primären Load Balancer-Instanzen.
Application Tier: "Availability Domain 1" und "Availability-Domain 2" in Region 1 enthalten mindestens eine Instanz von PeopleSoft-Anwendungsserver, PeopleSoft-Webserver, ElasticSearch-Server und PeopleSoft Process Scheduler. Alle Instanzen in den beiden Availability-Domains in Region 1 befinden sich im aktiven Status. Die Application Tier-Instanzen in Region 2 befinden sich im passiven Status. Um Anwendungsserver über Availability-Domains und Regionen hinweg zu synchronisieren, verwenden Sie rsync.
PeopleTools-Client: Verwenden Sie den PeopleTools-Client, um Administrationsaktivitäten wie Entwicklung, Migration und Upgrade durchzuführen.
Database Tier: Availability-Domain 1 in Region 1 hostet die Primärdatenbankinstanzen. Availability-Domain 2 in Region 1 und Region 2 hostet die Standbydatenbankinstanzen. In jeder Availability-Domain sind mindestens zwei Datenbankinstanzen eingerichtet, um High Availability zu gewährleisten. Wenn eine Datenbankinstanz in Availability-Domain 1 heruntergefahren wird, verarbeitet die zweite Datenbankinstanz in Availability-Domain 1 mit der Verarbeitung von Anforderungen. Wenn Region 1 nicht verfügbar ist, verarbeiten die Datenbankinstanzen in Region 2 die Anforderungen.

Oracle empfiehlt, dass Sie Oracle Active Data Guard im synchronen Modus verwenden, um die Datenbank über Availability-Domains in einer Region zu replizieren. Um die Datenbank über Bereiche hinweg zu replizieren, verwenden Sie Oracle Active Data Guard im asynchronen Modus.