Architekturen für Oracle-Anwendungen mit Azure Virtual Machines mit Datenbank in OCI

Gilt für: ✔️ Linux-VMs

Microsoft und Oracle kooperieren, um Kunden die Bereitstellung von Oracle-Anwendungen, z. B. Oracle E-Business Suite, JD Edwards EnterpriseOne und PeopleSoft, in der Cloud zu ermöglichen. Mit der Einführung der privaten Netzwerkverbindung zwischen Microsoft Azure und der Oracle Cloud Infrastructure (OCI) können Oracle-Anwendungen in Azure bereitgestellt werden, während die Back-End-Datenbanken in Azure oder in der OCI angeordnet sind. Oracle-Anwendungen können auch in Microsoft Entra ID integriert werden. Sie können einmaliges Anmelden einrichten, damit sich Benutzer mit ihren Microsoft Entra-Anmeldeinformationen bei der Oracle-Anwendung anmelden können.

Die OCI verfügt über mehrere Oracle-Datenbankoptionen für Oracle-Anwendungen, z. B. DBaaS, Exadata Cloud Service, Oracle RAC und Infrastructure-as-a-Service (IaaS). Derzeit ist Autonomous Database kein unterstütztes Back-End für Oracle-Anwendungen.

Es gibt mehrere Optionen für die Bereitstellung von Oracle-Anwendungen in Azure, z. B. auch mit hoher Verfügbarkeit und Sicherheit. Darüber hinaus verfügt Azure über Oracle-Datenbank-VM-Images, die Sie bereitstellen können, wenn Sie sich für die vollständige Ausführung Ihrer Oracle-Anwendungen in Azure entscheiden.

Die folgenden Abschnitte enthalten Architekturempfehlungen von Microsoft und Oracle zur Bereitstellung von Oracle E-Business Suite, JD Edwards EnterpriseOne und PeopleSoft in einer cloudübergreifenden Konfiguration oder vollständig in Azure. Microsoft und Oracle haben diese Anwendungen getestet und sichergestellt, dass die Leistung dem Standard entspricht, der von Oracle für diese Anwendungen festgelegt wurde.

Überlegungen zur Architektur

Oracle-Anwendungen bestehen aus mehreren Diensten, die auf einem oder mehreren virtuellen Computern in Azure oder optional in der OCI gehostet werden können.

Anwendungsinstanzen können mit privaten oder öffentlichen Endpunkten eingerichtet werden. Microsoft und Oracle empfehlen, eine Bastionhost-VM mit einer öffentlichen IP-Adresse in einem separaten Subnetz für die Verwaltung der Anwendung einzurichten. Weisen Sie den anderen Computern dann nur private IP-Adressen zu (einschließlich Datenbankschicht).

Beim Einrichten einer Anwendung in einer cloudübergreifenden Architektur sind entsprechende Planungen erforderlich, um sicherzustellen, dass sich der IP-Adressraum im virtuellen Azure-Netzwerk nicht mit dem privaten IP-Adressraum im virtuellen Cloudnetzwerk der OCI überschneidet.

Richten Sie zur Steigerung der Sicherheit Netzwerksicherheitsgruppen auf Subnetzebene ein, um sicherzustellen, dass nur Datenverkehr über bestimmte Ports und IP-Adressen zulässig ist. Computer auf der mittleren Ebene sollten nur Datenverkehr aus dem virtuellen Netzwerk empfangen. Kein externer Datenverkehr sollte direkt auf die Computer der mittleren Ebene gelangen.

Zur Sicherstellung von Hochverfügbarkeit können Sie redundante Instanzen der unterschiedlichen Server in derselben Verfügbarkeitsgruppe oder in unterschiedlichen Verfügbarkeitszonen einrichten. Mit Verfügbarkeitszonen können Sie eine SLA mit einer Verfügbarkeit von 99,99 % erzielen, und mit Verfügbarkeitsgruppen ist innerhalb einer Region eine SLA mit einer Verfügbarkeit von 99,95 % möglich. Die in diesem Artikel beschriebenen Beispielarchitekturen werden übergreifend in zwei Verfügbarkeitszonen bereitgestellt.

Beim Bereitstellen einer Anwendung per cloudübergreifender Verbindung können Sie weiterhin eine vorhandene ExpressRoute-Leitung nutzen, um Ihre Azure-Umgebung mit Ihrem lokalen Netzwerk zu verbinden. Sie benötigen für die Verbindung mit der OCI zusätzlich zu der Leitung, über die die Verbindung mit Ihrem lokalen Netzwerk hergestellt wird, aber eine weitere ExpressRoute-Leitung.

E-Business Suite

Bei Oracle E-Business Suite (EBS) handelt es sich um eine Suite mit Anwendungen, z. B. für Lieferkettenverwaltung (Supply Chain Management, SCM) und Customer Relationship Management (CRM). Zur Nutzung des OCI-Portfolios für verwaltete Datenbanken kann EBS bereitgestellt werden, indem die cloudübergreifende Verbindung zwischen Microsoft Azure und der OCI verwendet wird. Bei dieser Konfiguration werden die Darstellungs- und die Logikschicht in Azure und die Datenbankschicht in der OCI ausgeführt. Dies ist im folgenden Architekturdiagramm dargestellt (Abbildung 1).

Abbildung 1: E-Business Suite – cloudübergreifende Architektur

In dieser Architektur ist das virtuelle Netzwerk in Azure über die cloudübergreifende Verbindung mit einem virtuellen Cloudnetzwerk in der OCI verbunden. Die Anwendungsebene wird in Azure eingerichtet, und die Datenbank in der OCI. Wir empfehlen Ihnen, jede Komponente in einem eigenen Subnetz mit Netzwerksicherheitsgruppen bereitzustellen, damit es möglich ist, Datenverkehr nur aus bestimmten Subnetzen über bestimmte Ports zuzulassen.

Die Architektur kann so angepasst werden, dass die gesamte Bereitstellung in Azure erfolgt und hoch verfügbare Oracle-Datenbanken mit Verwendung von Oracle Data Guard in zwei Verfügbarkeitszonen einer Region genutzt werden. Das folgende Diagramm (Abbildung 2) zeigt ein Beispiel für dieses Architekturmuster:

Abbildung 2: E-Business Suite – reine Azure-Architektur

Die folgenden Abschnitte enthalten allgemeine Beschreibungen der verschiedenen Komponenten.

Bastionschicht

Der Bastionhost ist eine optionale Komponente, die Sie als Sprungserver verwenden können, um auf die Anwendungs- und Datenbankinstanzen zuzugreifen. Der Bastionhost-VM kann eine öffentliche IP-Adresse zugewiesen sein. Wir empfehlen Ihnen aber, eine ExpressRoute-Leitung oder Site-to-Site-VPN-Verbindung mit Ihrem lokalen Netzwerk einzurichten, um für sicheren Zugriff zu sorgen. Darüber hinaus sollten nur Ports für SSH (Port 22, Linux) oder RDP (Port 3389, Windows Server) für eingehenden Datenverkehr geöffnet werden. Stellen Sie zur Erzielung von Hochverfügbarkeit einen Bastionhost in zwei Verfügbarkeitszonen oder in einer einzelnen Verfügbarkeitsgruppe bereit.

Sie können auf Ihren VMs auch die SSH-Agent-Weiterleitung aktivieren, damit Sie auf andere VMs im virtuellen Netzwerk zugreifen können, indem Sie die Anmeldeinformationen von Ihrem Bastionhost weiterleiten. Sie können auch das SSH-Tunneling nutzen, um auf andere Instanzen zuzugreifen.

Hier ist ein Beispiel für die Agent-Weiterleitung angegeben:

ssh -A -t user@BASTION_SERVER_IP ssh -A root@TARGET_SERVER_IP`

Mit diesem Befehl wird für den Bastionhost eine Verbindung hergestellt, und anschließend wird ssh sofort erneut ausgeführt, damit Sie auf der Zielinstanz ein Terminal erhalten. Unter Umständen müssen Sie einen anderen Benutzer als „root“ auf der Zielinstanz angeben, wenn Ihr Cluster anders konfiguriert ist. Mit dem Argument -A wird die Agent-Verbindung weitergeleitet, damit Ihr privater Schlüssel automatisch auf dem lokalen Computer verwendet wird. Beachten Sie, dass es sich bei der Agent-Weiterleitung um eine Kette handelt. Der zweite ssh-Befehl enthält also auch -A, sodass für alle nachfolgenden SSH-Verbindungen, die über die Zielinstanz initiiert werden, ebenfalls Ihr lokaler privater Schlüssel verwendet wird.

Logikschicht (mittlere Ebene)

Die Logikschicht ist in einem eigenen Subnetz isoliert. Für die Fehlertoleranz und die einfache Patchverwaltung werden mehrere virtuelle Computer eingerichtet. Diese VMs können mit gemeinsam genutztem Speicher unterstützt werden, der von Azure NetApp Files und SSD Ultra-Einheiten bereitgestellt wird. Diese Konfiguration ermöglicht eine einfachere Bereitstellung von Patches ohne Ausfallzeiten. Die Computer auf der Logikschicht sollten über ein vorgeschaltetes Lastenausgleichsmodul verfügen, damit an die EBS-Logikschicht gesendete Anforderungen auch dann verarbeitet werden, wenn ein Computer der Schicht aufgrund eines Fehlers offline ist.

Load Balancer

Mit einem Azure Load Balancer können Sie Datenverkehr auf mehrere Instanzen Ihrer Workload verteilen, um die Hochverfügbarkeit sicherzustellen. In diesem Fall wird ein öffentliches Lastenausgleichsmodul eingerichtet, weil es für Benutzer zulässig ist, über das Web auf die EBS-Anwendung zuzugreifen. Das Lastenausgleichsmodul verteilt die Last auf beide Computer der mittleren Ebene. Um die Sicherheit weiter zu erhöhen, sollten Sie nur Datenverkehr von Benutzern zulassen, die aus Ihrem Unternehmensnetzwerk auf das System zugreifen, indem sie eine Site-to-Site-VPN-Verbindung oder eine ExpressRoute-Leitung und Netzwerksicherheitsgruppen verwenden.

Datenbankschicht

Auf dieser Schicht wird die Oracle-Datenbank gehostet, und zwar separat in einem eigenen Subnetz. Wir empfehlen Ihnen das Hinzufügen von Netzwerksicherheitsgruppen, die nur Datenverkehr von der Logikschicht zur Datenbankschicht über den Oracle-spezifischen Datenbankport 1521 zulassen.

Microsoft und Oracle empfehlen die Einrichtung für Hochverfügbarkeit. Sie können in Azure Hochverfügbarkeit erzielen, indem Sie zwei Oracle-Datenbanken in zwei Verfügbarkeitszonen mit Oracle Data Guard einrichten oder Oracle Database Exadata Cloud Service in der OCI verwenden. Wenn Sie Oracle Database Exadata Cloud Service verwenden, wird Ihre Datenbank in zwei Subnetzen bereitgestellt. Sie können Oracle Database auf virtuellen Computern auch in zwei Verfügbarkeitsdomänen der OCI mit Oracle Data Guard einrichten.

Identitätsschicht

Die Identitätsschicht enthält die EBS Asserter-VM. Mit EBS Asserter können Sie Identitäten für Oracle Identity Cloud Service (IDCS) und Microsoft Entra ID synchronisieren. EBS Asserter wird benötigt, weil für EBS keine Protokolle für einmaliges Anmelden (z. B. SAML 2.0 oder OpenID Connect) unterstützt werden. EBS Asserter nutzt das OpenID Connect-Token (von IDCS generiert), überprüft es und erstellt dann eine Sitzung für den Benutzer in EBS.

In dieser Architektur wird die IDCS-Integration angezeigt, aber der einheitliche Zugriff über Microsoft Entra ID und einmaliges Anmelden kann auch mit Oracle Access Manager per Oracle Internet Directory oder Oracle Unified Directory ermöglicht werden. Weitere Informationen finden Sie in den Whitepapers Deploying Oracle EBS with IDCS Integration (Bereitstellen von Oracle EBS mit IDCS-Integration) und Deploying Oracle EBS with OAM Integration (Bereitstellen von Oracle EBS mit OAM-Integration).

Wir empfehlen Ihnen, zum Erzielen von Hochverfügbarkeit redundante Server von EBS Asserter in mehreren Verfügbarkeitszonen mit einem vorgeschalteten Lastenausgleichsmodul bereitzustellen.

Nachdem Sie die Infrastruktur eingerichtet haben, können Sie die E-Business-Suite installieren, indem Sie die Anleitung im von Oracle bereitgestellten Installationshandbuch befolgen.

JD Edwards EnterpriseOne

JD Edwards EnterpriseOne von Oracle ist eine integrierte Suite mit Anwendungen für umfassendes Enterprise Resource Planning. Es handelt sich um eine Anwendung mit mehreren Ebenen, die entweder mit einem Oracle- oder mit einem SQL Server-Datenbank-Back-End eingerichtet werden kann. In diesem Abschnitt werden die Details der Bereitstellung von JD Edwards EnterpriseOne mit einem Oracle-Datenbank-Back-End in der OCI bzw. in Azure beschrieben.

In der folgenden empfohlenen Architektur (Abbildung 3) werden die Verwaltungsschicht, Darstellungsschicht und mittlere Ebene im virtuellen Netzwerk in Azure bereitgestellt. Die Datenbank wird in einem virtuellen Cloudnetzwerk in der OCI bereitgestellt.

Wie auch bei der E-Business Suite, können Sie eine optionale Bastionschicht für die sichere Verwaltung einrichten. Verwenden Sie die Bastionhost-VM als Sprungserver für den Zugriff auf die Anwendungs- und Datenbankinstanzen.

Abbildung 3: JD Edwards EnterpriseOne – cloudübergreifende Architektur

In dieser Architektur ist das virtuelle Netzwerk in Azure über die cloudübergreifende Verbindung mit dem virtuellen Cloudnetzwerk in der OCI verbunden. Die Anwendungsebene wird in Azure eingerichtet, und die Datenbank in der OCI. Wir empfehlen Ihnen, jede Komponente in einem eigenen Subnetz mit Netzwerksicherheitsgruppen bereitzustellen, damit es möglich ist, Datenverkehr nur aus bestimmten Subnetzen über bestimmte Ports zuzulassen.

Die Architektur kann so angepasst werden, dass die gesamte Bereitstellung in Azure erfolgt und hoch verfügbare Oracle-Datenbanken mit Verwendung von Oracle Data Guard in zwei Verfügbarkeitszonen einer Region genutzt werden. Das folgende Diagramm (Abbildung 4) zeigt ein Beispiel für dieses Architekturmuster:

Abbildung 4: JD Edwards EnterpriseOne – reine Azure-Architektur

Die folgenden Abschnitte enthalten allgemeine Beschreibungen der verschiedenen Komponenten.

Bastionschicht

Der Bastionhost ist eine optionale Komponente, die Sie als Sprungserver verwenden können, um auf die Anwendungs- und Datenbankinstanzen zuzugreifen. Der Bastionhost-VM kann eine öffentliche IP-Adresse zugewiesen sein. Wir empfehlen Ihnen aber, eine ExpressRoute-Leitung oder Site-to-Site-VPN-Verbindung mit Ihrem lokalen Netzwerk einzurichten, um für sicheren Zugriff zu sorgen. Darüber hinaus sollten nur Ports für SSH (Port 22, Linux) oder RDP (Port 3389, Windows Server) für eingehenden Datenverkehr geöffnet werden. Stellen Sie zur Erzielung von Hochverfügbarkeit einen Bastionhost in zwei Verfügbarkeitszonen oder in einer einzelnen Verfügbarkeitsgruppe bereit.

Sie können auf Ihren VMs auch die SSH-Agent-Weiterleitung aktivieren, damit Sie auf andere VMs im virtuellen Netzwerk zugreifen können, indem Sie die Anmeldeinformationen von Ihrem Bastionhost weiterleiten. Sie können auch das SSH-Tunneling nutzen, um auf andere Instanzen zuzugreifen.

Hier ist ein Beispiel für die Agent-Weiterleitung angegeben:

ssh -A -t user@BASTION_SERVER_IP ssh -A root@TARGET_SERVER_IP`

Mit diesem Befehl wird für den Bastionhost eine Verbindung hergestellt, und anschließend wird ssh sofort erneut ausgeführt, damit Sie auf der Zielinstanz ein Terminal erhalten. Unter Umständen müssen Sie einen anderen Benutzer als „root“ auf der Zielinstanz angeben, wenn Ihr Cluster anders konfiguriert ist. Mit dem Argument -A wird die Agent-Verbindung weitergeleitet, damit Ihr privater Schlüssel automatisch auf dem lokalen Computer verwendet wird. Beachten Sie, dass es sich bei der Agent-Weiterleitung um eine Kette handelt. Der zweite ssh-Befehl enthält also auch -A, sodass für alle nachfolgenden SSH-Verbindungen, die über die Zielinstanz initiiert werden, ebenfalls Ihr lokaler privater Schlüssel verwendet wird.

Verwaltungsschicht

Wie der Name bereits vermuten lässt, wird diese Schicht für Verwaltungsaufgaben genutzt. Sie können ein separates Subnetz für die Verwaltungsschicht verwenden. Die Dienste und Server auf dieser Schicht werden hauptsächlich für die Installation und Verwaltung der Anwendung verwendet. Daher sind einzelne Instanzen dieser Server ausreichend. Redundante Instanzen sind nicht erforderlich, um Hochverfügbarkeit für Ihre Anwendung zu erzielen.

Die Komponenten dieser Schicht lauten wie folgt:

• Bereitstellungsserver: Dieser Server wird für die End-to-End-Bereitstellung der unterschiedlichen Komponenten einer Anwendung verwendet. Er kommuniziert mit den Instanzen der anderen Schichten, einschließlich der Instanzen auf der Datenbankschicht, über Port 22. Er hostet die Server Manager Console für JD Edwards EnterpriseOne.
• Bereitstellungsserver: Dieser Server ist hauptsächlich für die Installation von JD Edwards EnterpriseOne erforderlich. Während des Installationsprozesses fungiert dieser Server als zentrales Repository für die erforderlichen Dateien und Installationspakete. Die Software wird von diesem Server aus auf andere Server und Clients verteilt bzw. darauf bereitgestellt.
• Entwicklungsclient: Dieser Server enthält Komponenten, die in einem Webbrowser und in nativen Anwendungen ausgeführt werden.

Präsentationsschicht

Diese Schicht enthält verschiedene Komponenten, z. B. Application Interface Services (AIS), Application Development Framework (ADF) und Java Application Servers (JAS). Die Server in dieser Ebene kommunizieren mit den Servern auf der mittleren Ebene, denen ein Lastenausgleichsmodul vorgeschaltet ist, das den Datenverkehr basierend auf der Portnummer und der URL, auf welcher der Datenverkehr empfangen wird, an den erforderlichen Server weiterleitet. Es empfiehlt sich, mehrere Instanzen jedes Servertyps bereitzustellen, um Hochverfügbarkeit zu erzielen.

Hier sind die Komponenten dieser Schicht aufgeführt:

• Application Interface Services (AIS): Der AIS-Server stellt die Kommunikationsschnittstelle zwischen mobilen JD Edwards EnterpriseOne-Unternehmensanwendungen und JD Edwards EnterpriseOne bereit.
• Java Application Server (JAS): Mit JAS werden Anforderungen vom Lastenausgleichsmodul empfangen und an die mittlere Ebene übergeben, um komplizierte Aufgaben durchzuführen. Mit JAS kann einfache Geschäftslogik ausgeführt werden.
• BI Publisher Server (BIP): Mit diesem Server werden Berichte basierend auf den Daten bereitgestellt, die von der JD Edwards EnterpriseOne-Anwendung erfasst werden. Sie können anhand von unterschiedlichen Vorlagen festlegen und steuern, wie die Daten im Bericht dargestellt werden.
• Business Services Server (BSS): BSS ermöglicht den Informationsaustausch und die Interoperabilität mit anderen Oracle-Anwendungen.
• Real-Time Events Server (RTE): Mit RTE Server können Sie Benachrichtigungen für externe Systeme zu Transaktionen einrichten, die im JDE EnterpriseOne-System durchgeführt werden. Es wird ein Abonnentenmodell verwendet, und Drittanbietersysteme können Ereignisse abonnieren. Stellen Sie sicher, dass sich die Server in einem Cluster befinden, um für Anforderungen an beide RTE Server-Einheiten einen Lastenausgleich durchzuführen.
• Application Development Framework (ADF) Server: ADF Server wird zum Ausführen von JD Edwards EnterpriseOne-Anwendungen verwendet, die mit Oracle ADF entwickelt wurden. Die Bereitstellung des Servers erfolgt auf einem Oracle WebLogic-Server mit ADF-Runtime.

Mittlere Ebene

Die mittlere Ebene enthält den Logikserver und den Batchserver. In diesem Fall sind beide Server auf demselben virtuellen Computer installiert. Für Produktionsszenarien empfiehlt es sich, Logikserver und Batchserver auf separaten Servern bereitzustellen. Mehrere Server werden auf der mittleren Ebene in zwei Verfügbarkeitszonen bereitgestellt, um eine bessere Hochverfügbarkeit zu erzielen. Es sollte ein Azure Load Balancer erstellt werden. Außerdem sollten diese Server im zugehörigen Back-End-Pool angeordnet werden, um sicherzustellen, dass beide Server aktiv sind und Anforderungen verarbeiten.

Die Server der mittleren Ebene empfangen nur Anforderungen von den Servern der Darstellungsschicht und vom öffentlichen Lastenausgleich. Es müssen Netzwerksicherheitsgruppen-Regeln eingerichtet werden, um Datenverkehr von allen Adressen abzulehnen, die nicht aus dem Subnetz der Darstellungsschicht und vom Lastenausgleich stammen. Eine NSG-Regel kann auch so eingerichtet werden, dass Datenverkehr über Port 22 vom Bastionhost zu Verwaltungszwecken zugelassen wird. Unter Umständen können Sie den öffentlichen Lastenausgleich auch nutzen, um die Last zwischen den VMs der mittleren Ebene auszugleichen.

Die beiden folgenden Komponenten befinden sich auf der mittleren Ebene:

• Logikserver: Enthält die Geschäftslogik oder Geschäftsfunktionen.
• Batchserver: Wird für die Batchverarbeitung verwendet.

Datenbankschicht

Die Datenbankschicht enthält die Datenbankinstanzen für die Anwendung. Bei der Datenbank kann es sich um ein Oracle DB-, Oracle RAC- oder Oracle Exadata Database-System handeln.

Wenn die Wahl auf Oracle DB fällt, kann die Datenbankinstanz in Azure über die Oracle DB-Images bereitgestellt werden, die auf dem Azure Marketplace verfügbar sind. Alternativ können Sie auch die Verbindung zwischen Azure und der OCI verwenden, um Oracle DB in einem PaaS-Modell in der OCI bereitzustellen.

Für Oracle RAC können Sie OCI in einem PaaS-Modell verwenden. Wir empfehlen Ihnen, ein RAC-System mit zwei Knoten zu verwenden. Oracle RAC kann zwar in einem IaaS-Modell in Azure CloudSimple bereitgestellt werden, dies ist jedoch keine von Oracle unterstützte Konfiguration. Weitere Informationen finden Sie unter Oracle-Programme, die für autorisierte Cloudumgebungen zulässig sind.

Verwenden Sie für Exadata-Systeme die OCI-Verbindung, und stellen Sie das Exadata-System in der OCI bereit. Im obigen Architekturdiagramm ist ein Exadata-System dargestellt, das in der OCI in zwei Subnetzen bereitgestellt wurde.

Stellen Sie für Produktionsszenarien mehrere Instanzen der Datenbank in zwei Verfügbarkeitszonen (bei Bereitstellung in Azure) bzw. zwei Verfügbarkeitsdomänen (in der OCI) bereit. Nutzen Sie Oracle Active Data Guard, um die primäre Datenbank und die Standbydatenbank zu synchronisieren.

Die Datenbankebene empfängt nur Anforderungen von der mittleren Ebene. Wir empfehlen Ihnen, eine Netzwerksicherheitsgruppe einzurichten (Sicherheitsliste bei Bereitstellung der Datenbank in der OCI), um nur Anforderungen über Port 1521 von der mittleren Ebene und Port 22 vom Bastionsserver zu Verwaltungszwecken zuzulassen.

Für in der OCI bereitgestellte Datenbanken muss ein separates virtuelles Cloudnetzwerk mit einem Gateway für dynamisches Routing (Dynamic Routing Gateway, DRG) eingerichtet werden, das mit Ihrer FastConnect-Leitung verbunden ist.

Identitätsschicht

Die Partnerschaft zwischen Microsoft und Oracle ermöglicht die Einrichtung einer einheitlichen Identität in Azure, OCI und Ihrer Oracle-Anwendung. Für die JD Edwards EnterpriseOne- und die PeopleSoft-Anwendungssuite wird eine OHS-Instanz (Oracle-HTTP-Server) benötigt, um das einmalige Anmelden zwischen Microsoft Entra ID und Oracle IDCS einzurichten.

OHS fungiert als Reverseproxy für die Logikschicht. Das bedeutet, dass alle an die Endanwendungen gerichteten Anforderungen OHS durchlaufen. Oracle Access Manager WebGate ist ein OHS-Webserver-Plug-In, das jede an die Endanwendung gerichtete Anforderung abfängt. Handelt es sich bei einer Ressource, auf die zugegriffen wird, um eine geschützte Ressource, für die eine authentifizierte Sitzung erforderlich ist, initiiert WebGate den OIDC-Authentifizierungsablauf mit Identity Cloud Service über den Browser des Benutzers. Weitere Informationen zu den Abläufen, die von OpenID Connect WebGate unterstützt werden, finden Sie in der Oracle Access Manager-Dokumentation.

Mit diesem Setup kann ein bereits bei Microsoft Entra ID angemeldeter Benutzer zur JD Edwards EnterpriseOne- oder PeopleSoft-Anwendung navigieren, ohne sich erneut über Oracle Identity Cloud Service anzumelden. Kunden, die diese Lösung bereitstellen, profitieren von den Vorteilen des einmaligen Anmeldens. Hierzu zählen etwa ein einzelner Satz von Anmeldeinformationen, ein verbessertes Anmeldeverfahren, höhere Sicherheit und geringere Helpdeskkosten.

Weitere Informationen zur Einrichtung des einmaligen Anmeldens für JD Edwards EnterpriseOne oder PeopleSoft mit Microsoft Entra ID finden Sie im entsprechenden Oracle-Whitepaper.

PeopleSoft

Die PeopleSoft-Anwendungssuite von Oracle enthält Software für das Personalwesen und das Finanzmanagement. Die Anwendungssuite hat mehrere Schichten und verfügt über Anwendungen für die Bereiche Personalwesen (Human Resource Management Systems, HRMS), Customer Relationship Management (CRM), Finanzen und Lieferkettenverwaltung (Financials and Supply Chain Management, FSCM) und Enterprise Performance Management (EPM).

Es empfiehlt sich, jede Ebene der Softwaresuite in einem eigenen Subnetz bereitzustellen. Eine Oracle-Datenbank oder eine Microsoft SQL Server-Instanz wird als Back-End-Datenbank für die Anwendung benötigt. In diesem Abschnitt werden Details zur Bereitstellung von PeopleSoft mit einem Oracle-Datenbank-Back-End beschrieben.

Das folgende Diagramm zeigt eine kanonische Architektur für die Bereitstellung der PeopleSoft-Anwendungssuite in einer cloudübergreifenden Architektur dargestellt (Abbildung 5).

Abbildung 5: PeopleSoft – cloudübergreifende Architektur

In dieser Beispielarchitektur ist das virtuelle Netzwerk in Azure über die cloudübergreifende Verbindung mit dem virtuellen Cloudnetzwerk in der OCI verbunden. Die Anwendungsebene wird in Azure eingerichtet, und die Datenbank in der OCI. Wir empfehlen Ihnen, jede Komponente in einem eigenen Subnetz mit Netzwerksicherheitsgruppen bereitzustellen, damit es möglich ist, Datenverkehr nur aus bestimmten Subnetzen über bestimmte Ports zuzulassen.

Die Architektur kann auch so angepasst werden, dass die gesamte Bereitstellung in Azure erfolgt und hoch verfügbare Oracle-Datenbanken mit Verwendung von Oracle Data Guard in zwei Verfügbarkeitszonen einer Region genutzt werden. Das folgende Diagramm (Abbildung 6) zeigt ein Beispiel für dieses Architekturmuster:

Abbildung 6: PeopleSoft – reine Azure-Architektur

Die folgenden Abschnitte enthalten allgemeine Beschreibungen der verschiedenen Komponenten.

Bastionschicht

Der Bastionhost ist eine optionale Komponente, die Sie als Sprungserver verwenden können, um auf die Anwendungs- und Datenbankinstanzen zuzugreifen. Der Bastionhost-VM kann eine öffentliche IP-Adresse zugewiesen sein. Wir empfehlen Ihnen aber, eine ExpressRoute-Leitung oder Site-to-Site-VPN-Verbindung mit Ihrem lokalen Netzwerk einzurichten, um für sicheren Zugriff zu sorgen. Darüber hinaus sollten nur Ports für SSH (Port 22, Linux) oder RDP (Port 3389, Windows Server) für eingehenden Datenverkehr geöffnet werden. Stellen Sie zur Erzielung von Hochverfügbarkeit einen Bastionhost in zwei Verfügbarkeitszonen oder in einer einzelnen Verfügbarkeitsgruppe bereit.

Sie können auf Ihren VMs auch die SSH-Agent-Weiterleitung aktivieren, damit Sie auf andere VMs im virtuellen Netzwerk zugreifen können, indem Sie die Anmeldeinformationen von Ihrem Bastionhost weiterleiten. Sie können auch das SSH-Tunneling nutzen, um auf andere Instanzen zuzugreifen.

Hier ist ein Beispiel für die Agent-Weiterleitung angegeben:

ssh -A -t user@BASTION_SERVER_IP ssh -A root@TARGET_SERVER_IP`

Mit diesem Befehl wird für den Bastionhost eine Verbindung hergestellt, und anschließend wird ssh sofort erneut ausgeführt, damit Sie auf der Zielinstanz ein Terminal erhalten. Unter Umständen müssen Sie einen anderen Benutzer als „root“ auf der Zielinstanz angeben, wenn Ihr Cluster anders konfiguriert ist. Mit dem Argument -A wird die Agent-Verbindung weitergeleitet, damit Ihr privater Schlüssel automatisch auf dem lokalen Computer verwendet wird. Beachten Sie, dass es sich bei der Agent-Weiterleitung um eine Kette handelt. Der zweite ssh-Befehl enthält also auch -A, sodass für alle nachfolgenden SSH-Verbindungen, die über die Zielinstanz initiiert werden, ebenfalls Ihr lokaler privater Schlüssel verwendet wird.

Logikschicht

Die Logikschicht enthält Instanzen der PeopleSoft-Anwendungsserver, PeopleSoft-Webserver, von Elasticsearch und des PeopleSoft Process Scheduler. Ein Azure Load Balancer wird so eingerichtet, dass Anforderungen von Benutzer*innen akzeptiert werden, die an den entsprechenden Server in der Logikschicht geleitet werden.

Erwägen Sie zur Erzielung von Hochverfügbarkeit die Einrichtung von redundanten Instanzen jedes Servers auf der Logikschicht über unterschiedliche Verfügbarkeitszonen hinweg. Der Azure Load Balancer kann mit mehreren Back-End-Pools eingerichtet werden, um jede Anforderung an den richtigen Server leiten zu können.

PeopleTools-Client

Der People Tools-Client wird verwendet, um Verwaltungsaktivitäten durchzuführen, z. B. Entwicklung, Migration und Upgrade. Da der PeopleTools-Client nicht erforderlich ist, um für Ihre Anwendung Hochverfügbarkeit zu erzielen, werden für den PeopleTools-Client keine redundanten Server benötigt.

Datenbankschicht

Die Datenbankschicht enthält die Datenbankinstanzen für die Anwendung. Bei der Datenbank kann es sich um ein Oracle DB-, Oracle RAC- oder Oracle Exadata Database-System handeln.

Wenn die Wahl auf Oracle DB fällt, kann die Datenbankinstanz in Azure über die Oracle DB-Images bereitgestellt werden, die auf dem Azure Marketplace verfügbar sind. Alternativ können Sie auch die Verbindung zwischen Azure und der OCI verwenden, um Oracle DB in einem PaaS-Modell in der OCI bereitzustellen.

Für Oracle RAC können Sie OCI in einem PaaS-Modell verwenden. Wir empfehlen Ihnen, ein RAC-System mit zwei Knoten zu verwenden. Oracle RAC kann zwar in einem IaaS-Modell in Azure CloudSimple bereitgestellt werden, dies ist jedoch keine von Oracle unterstützte Konfiguration. Weitere Informationen finden Sie unter Oracle-Programme, die für autorisierte Cloudumgebungen zulässig sind.

Verwenden Sie für Exadata-Systeme die OCI-Verbindung, und stellen Sie das Exadata-System in der OCI bereit. Im obigen Architekturdiagramm ist ein Exadata-System dargestellt, das in der OCI in zwei Subnetzen bereitgestellt wurde.

Stellen Sie für Produktionsszenarien mehrere Instanzen der Datenbank in zwei Verfügbarkeitszonen (bei Bereitstellung in Azure) bzw. zwei Verfügbarkeitsdomänen (in der OCI) bereit. Nutzen Sie Oracle Active Data Guard, um die primäre Datenbank und die Standbydatenbank zu synchronisieren.

Die Datenbankebene empfängt nur Anforderungen von der mittleren Ebene. Wir empfehlen Ihnen, eine Netzwerksicherheitsgruppe einzurichten (Sicherheitsliste bei Bereitstellung der Datenbank in der OCI), um nur Anforderungen über Port 1521 von der mittleren Ebene und Port 22 vom Bastionsserver zu Verwaltungszwecken zuzulassen.

Für in der OCI bereitgestellte Datenbanken muss ein separates virtuelles Cloudnetzwerk mit einem Gateway für dynamisches Routing (Dynamic Routing Gateway, DRG) eingerichtet werden, das mit Ihrer FastConnect-Leitung verbunden ist.

Identitätsschicht

Die Partnerschaft zwischen Microsoft und Oracle ermöglicht die Einrichtung einer einheitlichen Identität in Azure, OCI und Ihrer Oracle-Anwendung. Für die JD Edwards EnterpriseOne- und die PeopleSoft-Anwendungssuite wird eine OHS-Instanz (Oracle-HTTP-Server) benötigt, um das einmalige Anmelden zwischen Microsoft Entra ID und Oracle IDCS einzurichten.

OHS fungiert als Reverseproxy für die Logikschicht. Das bedeutet, dass alle an die Endanwendungen gerichteten Anforderungen OHS durchlaufen. Oracle Access Manager WebGate ist ein OHS-Webserver-Plug-In, das jede an die Endanwendung gerichtete Anforderung abfängt. Handelt es sich bei einer Ressource, auf die zugegriffen wird, um eine geschützte Ressource, für die eine authentifizierte Sitzung erforderlich ist, initiiert WebGate den OIDC-Authentifizierungsablauf mit Identity Cloud Service über den Browser des Benutzers. Weitere Informationen zu den Abläufen, die von OpenID Connect WebGate unterstützt werden, finden Sie in der Oracle Access Manager-Dokumentation.

Mit diesem Setup kann ein bereits bei Microsoft Entra ID angemeldeter Benutzer zur JD Edwards EnterpriseOne- oder PeopleSoft-Anwendung navigieren, ohne sich erneut über Oracle Identity Cloud Service anzumelden. Kunden, die diese Lösung bereitstellen, profitieren von den Vorteilen des einmaligen Anmeldens. Hierzu zählen etwa ein einzelner Satz von Anmeldeinformationen, ein verbessertes Anmeldeverfahren, höhere Sicherheit und geringere Helpdeskkosten.

Weitere Informationen zur Einrichtung des einmaligen Anmeldens für JD Edwards EnterpriseOne oder PeopleSoft mit Microsoft Entra ID finden Sie im entsprechenden Oracle-Whitepaper.

Nächste Schritte

Verwenden Sie Terraform-Skripts, um Oracle-Apps in Azure einzurichten und die cloudübergreifende Konnektivität mit der OCI herzustellen.

Weitere Informationen und Whitepaper zu OCI finden Sie in der Dokumentation zu Oracle Cloud Infrastructure.