Informationen zum Deployment von JD Edwards EnterpriseOne in Oracle Cloud Infrastructure

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

Bevor Sie beginnen

Oracle Cloud Infrastructure unterstützt JD Edwards EnterpriseOne-Anwendungsrelease 9.0, 9.1 und 9.2. Bevor Sie mit der Bereitstellung oder Migration Ihrer JD Edwards EnterpriseOne-Anwendung beginnen, geben Sie an, ob Oracle Cloud Infrastructure die Kombination aus JD Edwards EnterpriseOne-Anwendungsrelease, JD Edwards EnterpriseOne-Tools Release und dem Betriebssystem unterstützt, auf dem Sie Ihre Anwendungen ausführen möchten.

• JD Edwards EnterpriseOne-Anwendungsrelease 9.2 mit JD Edwards EnterpriseOne Tools Release 9.2. x. Es unterstützt die manuelle und automatisierte Installation von JD Edwards EnterpriseOne-Komponenten auf Oracle Linux - und Windows-Betriebssystemen.

• JD Edwards EnterpriseOne-Anwendungsrelease 9.1 mit JD Edwards EnterpriseOne Tools Release 9.1. x oder 9.2. x. Es unterstützt nur die manuelle Installation von JD Edwards EnterpriseOne-Komponenten auf Oracle Linux und Windows-Betriebssystemen.

Weitere Informationen zu früheren Versionen der JD Edwards EnterpriseOne-Anwendung erhalten Sie von Oracle Advanced Consulting Services.

Die endgültigen Zertifizierungsinformationen finden Sie in My Oracle Support.

Ü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 in den verschiedenen Subnetzen 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. Sie können daher nicht über das Internet auf diese Instanzen zugreifen.

Die folgende Abbildung 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 den Webserverinstanzen 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 Internet Gateway (IGW) aktivieren. Sie müssen die Routentabelle aktualisieren, um Traffic von und zu IGW zu aktivieren. Um den Datenverkehr zu den Webservern aus dem 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 Bastionshost im öffentlichen Subnetz erstellen und von der IGW auf den Bastionshost zugreifen.

Die Datenbankserver werden in diesem Bild im privaten Subnet 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 aktivieren, verwenden Sie IPSec-VPN oder Oracle Cloud Infrastructure FastConnect. Außerdem müssen Sie die Routentabelle aktualisieren, um Traffic in und von DRG zu aktivieren.

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 der Bereitstellung ist nützlich, wenn Sie ein hybrides Deployment mit der Cloud als Erweiterung Ihrer 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 nicht Instanzen zugewiesen werden, die in einem privaten Subnetz erstellt wurden, 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 Administrations-Ports nicht für das öffentliche Internet, sondern öffnen die Administrations-Ports nur für die Bastion Host- und Setup-Sicherheitslisten und Sicherheitsregeln, um sicherzustellen, dass die Instanz nur vom Bastion Host 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 Antiaffinität für Instanzen mit Faultdomänen erreicht werden.

Eine Faultdomain ist eine Gruppierung aus 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 eine Hardwarewartung von Oracle Compute, 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 Hardwareausfällen und geplanten Ausfällen schützen.

Zur hohen Verfügbarkeit von Datenbanken können Sie 2-Knoten-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 dem oberen Rand des Rack-Switch-Fehlers geschützt.

Architektur für das Deployment von JD Edwards EnterpriseOne in einer einzelnen Region

Sie können JD Edwards EnterpriseOne in einer einzelnen Availability-Domain bereitstellen und gleichzeitig die hohe Verfügbarkeit sicherstellen.

Sie können eine hohe Verfügbarkeit erzielen, indem Sie die Anwendungsinstanzen innerhalb mehrerer Faultdomains platzieren. Verwenden Sie diese Architektur, wenn Sie sicherstellen möchten, dass Ihre Anwendung verfügbar ist, auch wenn eine Anwendungsinstanz in einer Faultdomain heruntergefahren wird. Die anderen verfügbaren Anwendungsinstanzen innerhalb der anderen Faultdomain verarbeiten die Anforderungen weiterhin. Sie können JD Edwards EnterpriseOne manuell oder mit den Automatisierungstools von JD Edwards EnterpriseOne auf Oracle Cloud Infrastructure bereitstellen.

Diese Architektur zeigt, dass redundante Instanzen in der Präsentationsebene und Middle Tier in einer Availability-Domain bereitgestellt werden, um eine hohe Verfügbarkeit innerhalb der Availability-Domain sicherzustellen. Alle Instanzen in der Availability-Domain sind aktiv. Diese hohe Verfügbarkeit einer Anwendung innerhalb einer Availability-Domain kann erreicht werden, indem Anwendungsinstanzen in separaten Faultdomains platziert werden. 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 Cloud Infrastructure Compute, die sich auf eine Faultdomain auswirkt, wirkt sich nicht auf Instanzen in anderen Faultdomains aus. Wenn eine Instanz nicht erfolgreich verläuft, wird der Traffic auf andere Instanzen in der Availability-Domain umgeleitet, die die Anforderungen weiterhin verarbeiten. Wenn Ihre Verbindung zur Availability-Domain jedoch nicht erfolgreich verläuft oder die gesamte Availability-Domain heruntergefahren wird, sind die Instanzen nicht verfügbar, um die Anforderungen zu verarbeiten.

Instanzen im privaten Subnetz erfordern eine ausgehende Verbindung zum Internet zum Herunterladen von Patches sowie zum Einspielen von Betriebssystem- und Anwendungsaktualisierungen. Verwenden Sie dazu ein Network Address Translation (NAT)-Gateway 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.

Oracle empfiehlt, dass die Datenbank und die auf Oracle Cloud Infrastructure bereitgestellten Anwendungen über ein robustes Backup der Recovery-Strategie verfügen. Es wird empfohlen, 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 On-Demand-Datenbankbackups für Oracle Cloud Infrastructure Object Storage können mit der Oracle Cloud Infrastructure-Konsole konfiguriert werden. Dies erfordert eine Konnektivität mit 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 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.

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.

Die Architektur besteht aus einem virtuellen Cloud-Netzwerk (VCN) mit Bastionshost, Load Balancer-Tier, Präsentationsebene, Middle Tier, Administrationsebene und Datenbankebene. Die Ebenen werden in einem einzelnen Subnetz des VCN in einer einzelnen Availability-Domain platziert.

Im folgenden Architekturdiagramm wird der Bastionshost in einem öffentlichen Subnetz bereitgestellt, und alle anderen Instanzen werden in privaten Subnetzen platziert. Je nach Ihren Geschäftsanforderungen können Sie Instanzen in öffentliche oder private Subnetze platzieren. Sie können über den Bastionshost oder das dynamische Routinggateway (DRG) auf die Instanzen zugreifen, die sich in privaten Subnetzen über Port 22 befinden. 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.

Der Server-Manager in der Administrationsebene kommuniziert mit Präsentationsebene, Middle Tier und Datenbankebene, um Code-Deployment, Konfigurationsmanagement, Laufzeitmetrikzugriff und Logzugriff bereitzustellen. Der Deployment-Server in der Administrationsebene kommuniziert mit der Middle Tier und der Datenbankebene, um Code zu erstellen und bereitzustellen. Der Entwicklungsclient kommuniziert mit der Middle Tier und der Database Tier. Application Development Framework (ADF) und Oracle Business Intelligence Publisher kommunizieren mit dem HTML-Server in der Presentation Tier.

Beschreibung der Abbildung single_availability_domain_jd_edwards_deployment.png

Diese Architektur ist in folgende Stufen unterteilt:

• 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 Bastionshost 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 das ssh-agent forwarding, mit dem 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 einen anderen Listening-Service zuzugreifen. Der dynamische Tunnel stellt einen SOCKS-Proxy auf dem lokalen Port bereit, die Verbindungen stammen jedoch vom Remote-Host.

• Load Balancer Tier: Die Load Balancer Tier enthält die Oracle Cloud Infrastructure Load Balancing-Instanzen, die den Traffic auf alle Instanzen in der Präsentationsebene ausgleichen. Der Load Balancer empfängt Anforderungen von Benutzern und leitet diese dann an Instanzen in der Präsentationsebene weiter.

  Verwenden Sie Oracle Cloud Infrastructure Load Balancing, um Traffic an Ihre Anwendungsinstanzen innerhalb eines VCN zu verteilen. Dieser Service stellt eine primäre und eine Standby-Instanz des Load Balancers bereit, um sicherzustellen, dass der Standby-Load Balancer die Anforderungen weiterleitet, wenn der primäre Load Balancer nicht verfügbar ist. Der Load Balancer stellt sicher, dass Anforderungen an die gesunden Anwendungsinstanzen weitergeleitet werden. Wenn innerhalb einer Anwendungsinstanz ein Problem auftritt, leitet der Load Balancer Anforderungen an die verbleibenden gesunden Anwendungsinstanzen weiter.

  Je nach Ihren Anforderungen können Sie Load Balancer in einem öffentlichen oder privaten Subnetz platzieren.

  • Für interne Endpunkte, die nicht über das Internet zugänglich sind, verwenden Sie einen privaten Load Balancer. Ein privater Load Balancer hat eine private IP-Adresse und ist nicht über das Internet zugänglich. Sowohl die primären als auch die Standbyinstanzen eines Load Balancers befinden sich im selben privaten Subnetz. Sie können über ein DRG auf private Load Balancer in VCN oder in Ihrem Rechenzentrum über das IPSec-VPN zugreifen. Der private Load Balancer akzeptiert Traffic aus Ihrem Rechenzentrum und verteilt den Traffic auf zugrunde liegende Anwendungsinstanzen.

  • Verwenden Sie für internetorientierte Endpunkte einen öffentlichen Load Balancer. Ein öffentlicher Load Balancer verfügt über eine öffentliche IP-Adresse und ist über das Internet zugänglich. Über das Internetgateway können Sie über das Internet auf die öffentlichen Load Balancer zugreifen.

  • Um auf interne Endpunkte und internetseitige Endpunkte zuzugreifen, richten Sie private Load Balancer und öffentliche Load Balancer ein. Richten Sie private Load Balancer ein, um den internen Traffic zu bedienen, und richten Sie öffentliche Load Balancer ein, um den Traffic aus dem Internet zu bedienen.

  Registrieren Sie die öffentliche oder private IP-Adresse von Oracle Cloud Infrastructure Load Balancing-Instanzen in Ihrem On-Premise- oder Public Domain Nameserver (DNS) für die Domainauflösung Ihres Anwendungsendpunkts.

  Die im Architekturdiagramm bereitgestellten Ports sind nur ein Beispiel. Sie können jeden Port verwenden, der verfügbar ist.

• Administrationsebene: Die Administrationsebene enthält eine einzelne Instanz der folgenden Server. Sie benötigen keine redundante Instanz dieser Server, um eine hohe Verfügbarkeit zu gewährleisten.

  • Provisioning-Server: Mit diesem Server können Sie das End-to-End-Deployment von JD Edwards EnterpriseOne-Komponenten auf Oracle Cloud Infrastructure automatisieren. Es kommuniziert mit allen Instanzen in den anderen Ebenen, einschließlich der Instanzen in der Datenbankebene, über Port 22. Sie hostet die JD Edwards EnterpriseOne One-Click-Provisioning-Konsole und die JD Edwards EnterpriseOne Server Manager-Konsole.

  • Deployment-Server: Während des Installationsprozesses fungiert dieser Server als zentrales Repository aller erforderlichen Dateien und Installationspakete. Die Software wird von diesem Server an alle anderen Server und Clients verteilt oder bereitgestellt.

  • Entwicklungsclient: Der JD Edwards EnterpriseOne-Entwicklungsclient enthält Komponenten, die als Standard-Microsoft Windows-Anwendungen ausgeführt werden (z. B. Active Console, Forms Design Aid (FDA) und Report Design Aid (RDA)) sowie Komponenten, die in einem Webbrowser ausgeführt werden.

  • Application Development Framework-(ADF-)Server: JD Edwards EnterpriseOne ADF-Server ist eine Webanwendung, die auf einem Oracle WebLogic-Server mit ADF-Laufzeit bereitgestellt wird. Es wird verwendet, um JD Edwards EnterpriseOne-Anwendungen auszuführen, die mit Oracle ADF entwickelt wurden.

  • Oracle Business Intelligence Publisher: Oracle Business Intelligence Publisher stellt die von JD Edwards EnterpriseOne erfassten Daten in Form von Berichten dar. Verwenden Sie Oracle Business Intelligence Publisher, um Berichte mit verschiedenen Vorlagen basierend auf Ihren Geschäftsanforderungen anzuzeigen. Sie können mit Vorlagendateien entwerfen und steuern, wie die Berichtsausgaben angezeigt werden.

• Präsentationsebene: Die Präsentationsebene enthält redundante Instanzen von Application Interface Services und Java Application Servern, um eine hohe Verfügbarkeit bereitzustellen. Diese Server kommunizieren mit Servern in der Middle Tier. Alle Instanzen sind aktiv und erhalten Traffic vom Load Balancer. Jede Instanz ist einem Block Storage-Volume zugeordnet. Diese Ebene enthält auch Komponenten, mit denen Sie die Integration zwischen JD Edwards EnterpriseOne und einem externen System erstellen können. Ihre Implementierung kann eine oder mehrere dieser Komponenten enthalten.

  Diese Ebene enthält die folgenden Server:

  • Application Interface Services (AIS) Server: Application Interface Service Server stellt die Kommunikationsschnittstelle zwischen mobilen JD Edwards EnterpriseOne Enterprise-Anwendungen und JD Edwards EnterpriseOne bereit.

  • Standard-Java-Anwendungsserver (Standard-JAS): Er empfängt Anforderungen vom Load Balancer und führt einfache Geschäftslogik aus. Bei Aufgaben, die komplizierte Geschäftslogik erfordern, übergibt Standard JAS die Anforderungen an den Logikserver. In einigen Fällen übergibt es auch Anfragen an den AIS-Server. Es ist jedoch nicht mit dem AIS-Server für die AIS-Laufzeit konfiguriert.

  • Dedizierte Java-Anwendungsserver (Dedizierte JAS): Sie empfängt Anforderungen vom AIS-Server. Es übergibt Anforderungen an den Logikserver, um Aufgaben auszuführen, die komplizierte Geschäftslogik erfordern. Es ist mit dem AIS-Server für die AIS-Laufzeit konfiguriert.

  Um eine hohe Verfügbarkeit innerhalb einer Availability-Domain sicherzustellen, stellen Sie redundante Instanzen jeder Komponente bereit. Alle Instanzen sind aktiv und erhalten Traffic vom Load Balancer und der Middle Tier.

• Middle Tier: Die Middle Tier enthält logische Server und Batchserver. Sie werden nicht direkt geladen, aber sie haben eine Einzel-zu-Eins-Zuordnung mit Servern in Präsentationsebene. Sie können den Logikserver und den Batchserver auf derselben Enterprise-Serverinstanz hosten. Es wird jedoch empfohlen, den Logikserver und den Batchserver auf separaten Enterprise-Serverinstanzen einzurichten.

  Die Middle Tier empfängt Anforderungen aus der Präsentationsebene. Nach der Verarbeitung der Anforderungen leitet sie die Anforderungen an die Datenbankserver weiter. Alle Instanzen der Server sind aktiv und verarbeiten Anforderungen.

  Diese Ebene enthält die folgenden Server:

  • Logik-Server oder Enterprise-Server: Diese Server enthalten die Geschäftslogik oder Geschäftsfunktionen.

  • Batchserver: Diese Server werden für die Batchverarbeitung verwendet.

• Datenbank-Tier: Die Datenbank-Tier enthält JD Edwards EnterpriseOne-Datenbankserverinstanzen. Für Anforderungen an hohe Verfügbarkeit empfiehlt Oracle, dass Sie zwei Knoten, Oracle Real Application Clusters (Oracle RAC) -Datenbanksysteme oder ein Oracle Database Exadata Cloud Service-System in Oracle Cloud Infrastructure zum Einrichten von JD Edwards EnterpriseOne-Datenbankserverinstanzen verwenden.

  Sie können redundante Datenbankinstanzen einrichten, um eine hohe Verfügbarkeit bereitzustellen. Für Oracle RAC - und Oracle Database Exadata Cloud Service-Datenbanksysteme werden Anforderungen, die aus dem Anwendungssubnetz empfangen werden, über die Datenbankserver hinweg Load Balanciert. Wenn eine Datenbankinstanz nicht verfügbar ist, verarbeitet die andere Datenbankinstanz die Anforderungen. Mit Oracle Cloud Infrastructure Object Storage können Sie die JD Edwards EnterpriseOne-Datenbank mit Oracle Recovery Manager (RMAN) sichern. Um die JD Edwards EnterpriseOne-Datenbank in Oracle Cloud Infrastructure Object Storage zu sichern oder zu patchen, muss VCN des DB-Systems entweder mit einem Servicegateway oder einem Internetgateway konfiguriert sein. Es wird empfohlen, ein Servicegateway anstatt ein Internetgateway für Backup und Patching zu verwenden.

  Verwenden Sie Sicherheitslisten, um den Zugriff auf die Datenbankserver nur über den Bastionshost, die Anwendungsebene und On-Premise-Server einzuschränken. Sie können Sicherheitslisten einrichten, um sicherzustellen, dass die Kommunikation nur über Port 22, über den Bastionshost und über Port 1521 erfolgt. Stellen Sie außerdem sicher, dass auf die Datenbanksysteme nicht über das Internet zugegriffen werden kann.

Mit Oracle Cloud Infrastructure Object Storage können Sie die Instanzen in der Präsentationsebene und der Middle Tier sichern.

Architektur für das Deployment von JD Edwards EnterpriseOne mit Disaster Recovery

Diese Architektur zeigt das Deployment von JD Edwards EnterpriseOne-Anwendungsservern mit Disaster Recovery. Es zeigt ein VCN mit der Bastion in einem öffentlichen Subnetz und allen anderen Servern in einem privaten Subnetz an.

Produktionsserver befinden sich in zwei verschiedenen Regionen. Server in einer Region befinden sich im aktiven Modus und Server in der zweiten Region (Disaster Recovery Region) befinden sich im Standby-Modus.

Im Architekturdiagramm wird der Bastionshost 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 platzieren. Sie können über den Bastionshost oder DRG auf die Instanzen in privaten Subnetzen über Port 22 zugreifen. Verwenden Sie IPSec VPN oder Oracle Cloud Infrastructure FastConnect, um die Kommunikation zwischen DRG und den Geräten für Kundenprämissen zu ermöglichen.

In dieser Architektur werden mehrere Anwendungsinstanzen in mehreren Faultdomains bereitgestellt, um eine hohe Verfügbarkeit zu gewährleisten. Dadurch wird sichergestellt, dass Ihre Anwendung auch dann verfügbar ist, wenn eine der Availability-Domains nicht verfügbar ist. Die verfügbaren Anwendungsinstanzen in einer anderen Availability-Domain verarbeiten die Anforderungen weiterhin.

Die Bastion Hosts in beiden Regionen sind aktiv und können SSH Requests für beide Regionen jederzeit bedienen. Der DNS - oder externe DNS-Service vor Ort erhält eine Anforderung für JD Edwards EnterpriseOne-Anwendung. Bei diesen Anforderungen handelt es sich um einen Round-Robin-Last, der den Load Balancer in der aktiven Region ausgeglichen hat. Anschließend leitet der Load Balancer die Anforderung an Instanzen in der Präsentationsebene und der Middle Tier weiter. Die Instanzen in der Middle Tier leiten die Anforderung zur Verarbeitung an aktive Datenbankinstanzen weiter. Der Entwicklungsclient in der Administrationsebene kommuniziert auch mit der Datenbank. Der Provisioning-Server in der Administrationsebene kommuniziert mit Instanzen in allen Ebenen.

Wenn die primäre Region nicht verfügbar ist, müssen Sie manuell zu dem Datenbankserver wechseln, der im Bereich Disaster Recovery ausgeführt wird, und mit dem Bastionshost oder dem Load Balancer beginnen, der im Bereich Disaster Recovery ausgeführt wird.

Die Datenbanken und Anwendungsinstanzen in privaten Subnetzen können mit einem Servicegateway in Oracle Cloud Infrastructure-Objektspeicher gesichert werden. Ein Servicegateway bietet Zugriff auf den Objektspeicher, ohne das Internet zu durchlaufen.

Beschreibung der Abbildung jde2.png

• Bastionshost: Ein Bastionshost ist eine optionale Komponente, die Sie in jeder Region bereitstellen können, um als Jump-Host auf Anwendungs- und Datenbankinstanzen zuzugreifen. Bastionshosts in beiden Regionen befinden sich im aktiven Status.

• Load Balancer-Instanz: Oracle Cloud Infrastructure Load Balancing-Instanzen verteilen Traffic auf die Anwendungsserver. Die Load Balancer-Instanz im aktiven/primären Bereich ist aktiv. Anforderungen, die bei der JD Edwards EnterpriseOne-URL empfangen werden, werden von einem On-Premise oder einem externen DNS-Service an den Load Balancer in der aktiven Region gesendet.

• Präsentationsebene: Die Präsentationsebene enthält redundante Instanzen von Application Interface Services (AIS) und Java Application Server (JAS), um eine hohe Verfügbarkeit bereitzustellen. Diese Server kommunizieren mit Servern in der Middle Tier. Alle Instanzen sind aktiv und erhalten Traffic vom Load Balancer. Jede Instanz ist einem Block Storage-Volume zugeordnet. Diese Ebene enthält auch Komponenten, mit denen Sie die Integration zwischen JD Edwards EnterpriseOne und einem externen System erstellen können. Ihre Implementierung kann eine oder mehrere dieser Komponenten enthalten.

• Middle Tier: Die Middle Tier enthält logische Server und Batchserver. Sie werden nicht direkt geladen, aber sie haben eine Einzel-zu-Eins-Zuordnung mit Servern in der Präsentationsebene.

• Datenbankebene: Richten Sie hochverfügbare Datenbankinstanzen in beiden Regionen ein. Der Datenbankserver, der im aktiven/primären Bereich ausgeführt wird, befindet sich im aktiven Status. In jeder Region werden mindestens zwei Datenbankinstanzen eingerichtet, um eine hohe Verfügbarkeit innerhalb einer Region sicherzustellen. Wenn eine Datenbankinstanz in der aktiven/primären Region nicht verfügbar ist, wechseln Sie zur Datenbankinstanz im Bereich Disaster Recovery, und starten Sie mit dem Load Balancer im Bereich Disaster Recovery, um auf die Umgebung zuzugreifen.

  Verwenden Sie Oracle Active Data Guard im synchronen Modus, um die Datenbank über Regionen hinweg zu replizieren.

Informationen zu Netzwerksicherheitsgruppen

In Oracle Cloud Infrastructure werden Firewall-Regeln über Netzwerksicherheitsgruppen konfiguriert. Für jede Ebene wird eine separate Netzwerksicherheitsgruppe erstellt.

Verwenden Sie Sicherheitslisten, um den Datenverkehr zwischen verschiedenen Ebenen und zwischen dem Bastionshost und externen Hosts zu ermöglichen. Sicherheitsregeln enthalten Ingress- und Egress-Regeln zum Filtern des Traffics auf Ebene der Ebene. Sie enthalten auch Informationen über Kommunikationsports, über die Datenübertragung zulässig ist. Diese Ports (oder in einigen Fällen die Protokolle, die offene Ports in den Sicherheitsregeln benötigen) werden in jeder Netzwerksicherheitsgruppenzeile in den Architekturdiagrammen angezeigt.

Jede Netzwerksicherheitsgruppe wird auf VNIC-Ebene erzwungen. Die Übertragung eines Datenpakets ist zulässig, wenn eine Regel in einer der Listen Traffic zulässt (oder wenn der Traffic Teil einer vorhandenen Verbindung ist, die verfolgt wird). Verwenden Sie neben der Netzwerksicherheitsgruppe iptables, um eine weitere Sicherheitsebene auf Instanzebene zu implementieren.

Bei Deployments in einem öffentlichen Subnetz können Sie ein zusätzliches Sicherheitsniveau bereitstellen, indem Sie den Zugriff auf die Anwendungs- und Datenbankinstanzen aus dem Internet verhindern. Verwenden Sie eine benutzerdefinierte Netzwerksicherheitsgruppe, um den Zugriff auf die Anwendungs- und Datenbankinstanzen aus dem Internet zu verhindern und den Zugriff auf die Datenbank und Anwendungshosts über Port 22 aus dem Bastionshost zu Administrationszwecken zu ermöglichen. SSH-Zugriff auf die Anwendungs- und Datenbankinstanzen aus dem Internet nicht aktivieren, Sie können SSH-Zugriff auf diese Instanzen jedoch aus dem Subnetz zulassen, das den Bastionshost enthält.

Sie können über den Bastionsserver auf Ihre Instanzen im privaten Subnetz zugreifen.

Netzwerksicherheitsgruppe für Bastionshost

Mit der Bastionsnetzwerksicherheitsgruppe kann auf den Bastionshost über Port 22 über das öffentliche Internet zugegriffen werden.

• So ermöglichen Sie SSH-Traffic vom On-Premise-Netzwerk zum Bastionshost über Internet:

  Stateful ingress: TCP-Traffic von Quell-C0.0.0.0IDR/0 und allen Quell-Ports zum Zielport 22 (SSH) zulassen.

  Quelltyp = CIDR, Quell-CIDR = 0.0.0.0/0, IP-Protokoll = TCP, Quell-Portbereich = Alle, Ziel-Portbereich = 22

  Sie können den Bastionshost auch einschränken, auf den über Internet auf Port 22 nur von Ihrem Rechenzentrum aus zugegriffen werden kann, anstatt auf öffentliches Internet (0.0.0.0/0). Verwenden Sie dazu die Edge-Router-IP anstelle von Quell-CIDR als 0.0.0.0/0 in der zustandsbehafteten Ingress-Regel.

• So erlauben Sie allen Traffic vom Bastionshost zu Oracle Cloud Infrastructure:

  Stateful egress: TCP-Traffic für Ziel CIDR 0.0.0.0/0 von allen Quellports zu allen Zielports zulassen.

  Zieltyp = CIDR, Ziel-CIDR = <CIDR-Block von VCN>, IP-Protokoll = TCP, Quell-Portbereich = Alle, Ziel-Portbereich = Alle

Sie können Regeln basierend auf Ihren Anforderungen aus der Netzwerksicherheitsgruppe hinzufügen oder entfernen. Geben Sie außerdem die Ports an, über die Sie auf Java-Anwendungsserver und Application Interface Services-Server zugreifen möchten.

Netzwerksicherheitsgruppe für Administrationsebene

• Stateful Ingress: TCP-Traffic auf Zielport 22 (SSH) aus Quell-CIDR-Block des VCN und jedem Quellport zulassen.

• Stateful ingress: Quell-CIDR-Block des VCN auf TCP, Quellport = all, Zielport = 445, 5985, 14501-14510, 3000, 8998-8999, 5150

• Stateful Egress: Erlauben Sie allen Verkehr.

Netzwerksicherheitsgruppe für Load Balancer Tier

Die Architektur enthält private Load Balancer, die in private Subnetze platziert sind. Wenn Sie die Load Balancer-Instanzen in ein öffentliches Subnetz platzieren, können Sie Traffic aus dem Internet in Load Balancer-Instanzen zulassen.

• Stateful ingress: Quell-CIDR-Block von VCN und On-Premise-Netzwerk auf TCP, Quellport = all, Zielport = Ports, auf denen Sie Listener in den Load Balancer-Instanzen erstellt haben

• Stateful Egress: Erlauben Sie allen Verkehr.

Netzwerksicherheitsgruppe für Präsentationsebene

• So ermöglichen Sie Traffic aus der On-Premise-Umgebung und dem VCN in das Subnetz der Präsentationsebene:

  Stateful ingress: Quell-CIDR-Block des VCN - und On-Premise-Netzwerks auf TCP, Quellport = alle, Zielport = 14501-14510, 5150, Weblogic Admin-Serverport, Webserverports

• Stateful ingress: Quell-CIDR-Block des VCN auf TCP, Quellport = all, Zielport = 22 (SSH)

• So ermöglichen Sie Traffic aus dem Subnetz der Präsentationsebene in das Subnetz der Middle Tier:

  Stateful egress: Quelle 0.0.0.0/0 auf TCP, Quellport = all, Zielport = all

Geben Sie außerdem die Ports an, über die Sie auf Java Application Server und Application Interface Services-Server zugreifen möchten, und die Ports, über die Sie auf Oracle Business Intelligence Publisher-Server zugreifen möchten.

Netzwerksicherheitsgruppe für die Middle Tier

• So ermöglichen Sie Traffic aus der On-Premise-Umgebung und VCN in das Subnetz der Middle Tier:

  Stateful ingress: Quell-CIDR-Block von VCN und On-Premise-Netzwerk auf TCP, Quellport = alle, Zielport = 6017-6023, 14502 - 14510, 5150

• Stateful ingress: Quell-CIDR-Block des VCN auf TCP, Quellport = all, Zielport = 22 (SSH)

• So ermöglichen Sie Traffic vom Subnetz der mittleren Ebene zum Subnetz der Präsentationsebene:

  Stateful egress: Quelle 0.0.0.0/0 auf TCP, Quellport = all, Zielport = all

Sicherheitsliste für die Datenbankebene

• So ermöglichen Sie Traffic vom Bastionshost zur Datenbankebene:

  Stateful ingress: Quell-CIDR-Block des Bastionshosts auf TCP, Quellport = alle, Zielport = 22

• So erlauben Sie Traffic von der Middle Tier zur Datenbankebene:

  Stateful Ingress: Quell-CIDR-Block der Middle Tiers auf TCP, Quellport = alle, Zielport = 1521

• So ermöglichen Sie Traffic aus der On-Premise-Umgebung und dem VCN in das Subnetz der Präsentationsebene:

  Stateful ingress: Quell-CIDR-Block des VCN auf TCP, Quellport = all, Zielport = 14502-14510, 5150

• So erlauben Sie Traffic von der Datenbankebene zur Middle Tier:

  Stateful egress: Ziel 0.0.0.0/0 auf TCP, Quell-Port = all, Ziel-Port = all