次の方法で共有

OCI で Oracle アプリケーション、Azure Virtual Machines、データベースを組み合わせるためのアーキテクチャ

  • [アーティクル]

適用対象: ✔️ Linux VM

Microsoft と Oracle は、お客様が Oracle E-Business Suite、JD Edwards EnterpriseOne、PeopleSoft などの Oracle アプリケーションをクラウドにデプロイできるように協力しています。 Microsoft Azure と Oracle Cloud Infrastructure (OCI) 間のプライベート ネットワーク相互接続性の導入によって、Oracle アプリケーションを、Azure または OCI 内のバックエンド データベースと共に Azure にデプロイできるようになりました。 Oracle アプリケーションを Microsoft Entra ID と統合することもできるため、ユーザーが Microsoft Entra 資格情報を使用して Oracle アプリケーションにサインインできるように、シングル サインオンを設定できます。

OCI には、DBaaS、Exadata Cloud Service、Oracle RAC、Infrastructure-as-a-Service (IaaS) など、Oracle アプリケーション用の複数の Oracle データベース オプションが用意されています。 現在、Autonomous Database は、Oracle アプリケーション用にサポートされているバックエンドではありません。

可用性が高くセキュリティで保護された方法を含め、Azure には Oracle アプリケーションをデプロイするための複数の選択肢があります。 Azure にも、Oracle アプリケーションを完全に Azure 上で実行することを選択した場合にデプロイできる Oracle データベース VM イメージが用意されています。

以下のセクションでは、Oracle E-Business Suite、JD Edwards EnterpriseOne、および PeopleSoft をクロスクラウド構成または完全に Azure にデプロイする場合の、Microsoft と Oracle の両方によるアーキテクチャの推奨事項について概要を説明します。 Microsoft と Oracle はこれらのアプリケーションをテストし、そのパフォーマンスが、Oracle によってこれらのアプリケーションに対して設定された基準を満たしていることを確認しました。

アーキテクチャの考慮事項

Oracle アプリケーションは複数のサービスで構成されています。これらのサービスは、Azure と必要に応じて OCI で、同じまたは複数の仮想マシン上でホストできます。

アプリケーション インスタンスは、プライベート エンドポイントまたはパブリック エンドポイントで設定できます。 Microsoft と Oracle は、アプリケーションの管理用に別のサブネットにパブリック IP アドレスを持つ "踏み台ホスト VM" を設定することをお勧めします。 次に、データベース層を含め、他のマシンにプライベート IP アドレスのみを割り当てます。

クロスクラウド アーキテクチャでアプリケーションを設定するときは、Azure 仮想ネットワークの IP アドレス空間が OCI 仮想クラウド ネットワークのプライベート IP アドレス空間と重ならないように計画する必要があります。

セキュリティを強化するために、特定のポートと IP アドレスでのトラフィックのみが許可されるように、ネットワーク セキュリティ グループをサブネット レベルで設定します。 たとえば、中間層のマシンは仮想ネットワーク内からのみトラフィックを受信するようにします。 外部トラフィックが中間層マシンに直接到達しないようにします。

高可用性を確保するために、同じ可用性セットまたは異なる可用性ゾーンに異なるサーバーの冗長インスタンスを設定できます。 可用性ゾーンを使用すると、99.99% のアップタイム SLA を達成できます。一方、可用性セットを使用すると、リージョン内で 99.95% のアップタイム SLA を達成できます。 この記事に示すサンプル アーキテクチャは、2 つの可用性ゾーンにまたがってデプロイされます。

クラウド間相互接続を使用してアプリケーションをデプロイする際には、Azure 環境をオンプレミス ネットワークに接続するために、既存の ExpressRoute 回線を使用し続けることができます。 ただし、OCI への相互接続には、オンプレミス ネットワークに接続するものとは別の ExpressRoute 回線が必要です。

E-Business Suite

Oracle E-Business Suite (EBS) は、サプライ チェーン管理 (SCM) および顧客関係管理 (CRM) を含む一連のアプリケーションです。 OCI のマネージド データベース ポートフォリオを利用するために、Microsoft Azure と OCI 間にクロスクラウド相互接続を使用して EBS をデプロイできます。 この構成では、次のアーキテクチャ図 (図 1) に示すように、プレゼンテーション層とアプリケーション層は Azure で実行され、データベース層は OCI で実行されます。

E-Business Suite のクロスクラウド アーキテクチャ

図 1: E-Business Suite のクロスクラウド アーキテクチャ

このアーキテクチャで、Azure の仮想ネットワークは、クロスクラウド相互接続を使用して OCI 内の仮想クラウド ネットワークに接続されています。 アプリケーション層は Azure 内に設定され、データベースは OCI 内に設定されます。 推奨されるのは、特定のポート上の特定のサブネットからのトラフィックのみを許可するネットワーク セキュリティ グループを備えた独自のサブネットに各コンポーネントをデプロイすることです。

このアーキテクチャを調整することで、Oracle Data Guard を使用して構成された、1 つのリージョン内の 2 つの可用性ゾーンを利用する高可用性 Oracle データベースを使用した、Azure だけを使用するデプロイを実現することができます。 次の図 (図 2) は、このアーキテクチャ パターンの例です。

E-Business Suite の Azure のみのアーキテクチャ

図 2: E-Business Suite の Azure のみのアーキテクチャ

以下のセクションでは、さまざまなコンポーネントについて概要を説明します。

要塞層

要塞ホストは、アプリケーションおよびデータベース インスタンスにアクセスするためのジャンプ サーバーとして使用できるオプション コンポーネントです。 要塞ホスト VM には、パブリック IP アドレスを割り当てることができます (ただし推奨されるのは、オンプレミス ネットワークとの間に ExpressRoute 接続またはサイト間 VPN を設定してアクセスの安全性を確保することです)。 加えて、受信トラフィック用に SSH (ポート 22、Linux) または RDP (ポート 3389、Windows Server) のみを開放する必要があります。 高可用性を確保するために、要塞ホストは 2 つの可用性ゾーンまたは 1 つの可用性セットにデプロイしてください。

また、ご利用の VM で SSH エージェント転送を有効にすれば、要塞ホストから資格情報を転送することによって仮想ネットワーク内の他の VM にアクセスすることができます。 または、SSH トンネリングを使用して他のインスタンスにアクセスすることもできます。

エージェント転送の例を次に示します。

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

このコマンドは、要塞に接続した後、すぐに ssh を再実行して、ターゲット インスタンス上のターミナルを取得しています。 実際のクラスターの構成が異なる場合は、ターゲット インスタンスに対して root 以外のユーザーを指定しなければならないことがあります。 -A 引数により、ローカル コンピューター上の秘密キーが自動的に使用されるようにエージェント接続が転送されます。 エージェント転送はチェーンであるため、ターゲット インスタンスから開始された後続の SSH 接続でもローカルの秘密キーが使用されるよう、2 つ目の ssh コマンドにも -A が含まれていることに注意してください。

アプリケーション (中間) 層

アプリケーション層は独自のサブネットに分離されています。 フォールト トレランスと簡単なパッチ管理のために設定された複数の仮想マシンがあります。 これらの VM では、Azure NetApp Files と Ultra SSD が提供する共有ストレージを利用できます。 この構成により、ダウンタイムなしでパッチを簡単に展開できます。 アプリケーション層のマシンの前にはパブリック ロード バランサーを配置し、障害が原因で層内の 1 台のマシンがオフラインになっても、EBS アプリケーション層への要求が処理されるようにする必要があります。

Load Balancer

Azure ロード バランサーを使用すると、ワークロードの複数のインスタンスにトラフィックを分散して高可用性を確保できます。 この場合、ユーザーは Web 経由で EBS アプリケーションにアクセスすることが許可されているため、パブリック ロード バランサーが設定されます。 ロード バランサーによって、中間層の両方のマシンに負荷が分散されます。 セキュリティを強化するために、サイト間 VPN または ExpressRoute とネットワーク セキュリティ グループを使用して企業ネットワークからシステムにアクセスするユーザーからのトラフィックのみを許可します。

データベース層

この層には Oracle データベースがホストされ、独自のサブネットに分割されます。 推奨されるのは、Oracle 固有のデータベース ポート 1521 上でアプリケーション層からデータベース層へのトラフィックのみを許可するネットワーク セキュリティ グループを追加することです。

Microsoft と Oracle は、高可用性の設定を推奨します。 Azure で高可用性を実現するには、Oracle Data Guard を使用して 2 つの可用性ゾーンに 2 つの Oracle データベースを設定するか、OCI で Oracle Database Exadata Cloud Service を使用します。 Oracle Database Exadata Cloud Service を使用すると、データベースは 2 つのサブネットにデプロイされます。 Oracle Data Guard を使用して、OCI の 2 つの可用性ドメイン内の VM に Oracle Database を設定することもできます。

ID 層

ID 層には EBS Asserter VM が含まれています。 EBS Asserter を使用すると、Oracle Identity Cloud Service (IDCS) と Microsoft Entra ID から ID を同期できます。 EBS は SAML 2.0 や OpenID Connect などのシングル サインオン プロトコルをサポートしていないため、EBS Asserter が必要です。 EBS Asserter では、(IDCS によって生成された) OpenID 接続トークンが使用され、それが検証され、EBS でユーザーのセッションが作成されます。

このアーキテクチャは IDCS 統合を示していますが、Microsoft Entra ID 統合アクセスとシングル サインオンは、Oracle インターネット ディレクトリまたは Oracle Unified Directory を使用して Oracle Access Manager で有効にすることもできます。 詳細については、IDCS 統合による Oracle EBS の展開または OAM 統合による Oracle EBS の展開のホワイト ペーパーを参照してください。

高可用性を確保するために推奨されるのは、EBS Asserter の冗長サーバーを複数の可用性ゾーンにデプロイし、その前にロード バランサーを配置することです。

インフラストラクチャを設定したら、Oracle が提供するインストール ガイドに従って E-Business Suite をインストールできます。

JD Edwards EnterpriseOne

Oracle の JD Edwards EnterpriseOne は、包括的なエンタープライズ リソース計画ソフトウェアの統合アプリケーション スイートです。 これは、Oracle または SQL Server データベース バックエンドのいずれかで設定できる多層アプリケーションです。 このセクションでは、OCI または Azure で Oracle データベース バックエンドを使用して JD Edwards EnterpriseOne をデプロイする方法について詳しく説明します。

次の推奨アーキテクチャ (図 3) では、管理層、プレゼンテーション層、および中間層が Azure の仮想ネットワークにデプロイされています。 データベースは OCI の仮想クラウド ネットワークに展開されます。

E-Business Suite と同様に、セキュリティで保護された管理の目的のためにオプションの Bastion 層を設定できます。 踏み台 VM ホストをジャンプ サーバーとして使用して、アプリケーションおよびデータベース インスタンスにアクセスします。

JD Edwards Enterprise One のクロスクラウド アーキテクチャ

図 3: JD Edwards EnterpriseOne のクロスクラウド アーキテクチャ

このアーキテクチャで、Azure の仮想ネットワークは、クロスクラウド相互接続を使用して OCI 内の仮想クラウド ネットワークに接続されています。 アプリケーション層は Azure 内に設定され、データベースは OCI 内に設定されます。 推奨されるのは、特定のポート上の特定のサブネットからのトラフィックのみを許可するネットワーク セキュリティ グループを備えた独自のサブネットに各コンポーネントをデプロイすることです。

このアーキテクチャを調整することで、Oracle Data Guard を使用して構成された、1 つのリージョン内の 2 つの可用性ゾーンを利用する高可用性 Oracle データベースを使用した、Azure だけを使用するデプロイを実現することができます。 次の図 (図 4) は、このアーキテクチャ パターンの例です。

JD Edwards EnterpriseOne Azure のみのアーキテクチャ

図 4: JD Edwards EnterpriseOne Azure のみのアーキテクチャ

以下のセクションでは、さまざまなコンポーネントについて概要を説明します。

要塞層

要塞ホストは、アプリケーションおよびデータベース インスタンスにアクセスするためのジャンプ サーバーとして使用できるオプション コンポーネントです。 要塞ホスト VM には、パブリック IP アドレスを割り当てることができます (ただし推奨されるのは、オンプレミス ネットワークとの間に ExpressRoute 接続またはサイト間 VPN を設定してアクセスの安全性を確保することです)。 加えて、受信トラフィック用に SSH (ポート 22、Linux) または RDP (ポート 3389、Windows Server) のみを開放する必要があります。 高可用性を確保するために、要塞ホストは 2 つの可用性ゾーンまたは 1 つの可用性セットにデプロイしてください。

また、ご利用の VM で SSH エージェント転送を有効にすれば、要塞ホストから資格情報を転送することによって仮想ネットワーク内の他の VM にアクセスすることができます。 または、SSH トンネリングを使用して他のインスタンスにアクセスすることもできます。

エージェント転送の例を次に示します。

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

このコマンドは、要塞に接続した後、すぐに ssh を再実行して、ターゲット インスタンス上のターミナルを取得しています。 実際のクラスターの構成が異なる場合は、ターゲット インスタンスに対して root 以外のユーザーを指定しなければならないことがあります。 -A 引数により、ローカル コンピューター上の秘密キーが自動的に使用されるようにエージェント接続が転送されます。 エージェント転送はチェーンであるため、ターゲット インスタンスから開始された後続の SSH 接続でもローカルの秘密キーが使用されるよう、2 つ目の ssh コマンドにも -A が含まれていることに注意してください。

管理層

名前が示すように、この層は管理タスクに使用されます。 管理層用に別のサブネットを作成できます。 この層のサービスとサーバーは、主にアプリケーションのインストールと管理に使用されます。 そのため、これらのサーバーの 1 つのインスタンスで十分です。 アプリケーションの高可用性を確保するために冗長インスタンスは必要ありません。

この層のコンポーネントは次のとおりです。

  • プロビジョニング サーバー - このサーバーは、アプリケーションのさまざまなコンポーネントをエンドツーエンドでデプロイするために使用されます。 ポート 22 を介して、データベース層のインスタンスを含む他の層のインスタンスと通信されます。 JD Edwards EnterpriseOne 用の Server Manager Console がホストされます。
  • デプロイ サーバー - このサーバーは主に JD Edwards EnterpriseOne のインストールに必要です。 インストール プロセス中、このサーバーは必要なファイルとインストール パッケージの中央リポジトリとして機能します。 このソフトウェアは、このサーバーから他のサーバーおよびクライアントに配布または展開されます。
  • 開発クライアント - このサーバーには、Web ブラウザーとネイティブ アプリケーションで実行されるコンポーネントが含まれています。

プレゼンテーション層

この層には、Application Interface Services (AIS)、Application Development Framework (ADF)、Java Application Servers (JAS) などのさまざまなコンポーネントが含まれています。 この層のサーバーは、トラフィックが受信されたポート番号と URL に基づいて必要なサーバーにトラフィックをルーティングするロード バランサーが前面に配置された中間層のサーバーと通信します。 高可用性を確保するために、各サーバーの種類のインスタンスを複数展開することをお勧めします。

この層のコンポーネントは次のとおりです。

  • Application Interface Services (AIS) - AIS サーバーによって、JD Edwards Enterprise One モバイル エンタープライズ アプリケーションと JD Edwards Enterprise One の間に通信インターフェイスが提供されます。
  • Java Application Server (JAS) - JAS では、ロード バランサーから要求を受け取り、それを中間層に渡して複雑なタスクを実行します。 JAS には単純なビジネス ロジックを実行する機能があります。
  • BI Publisher Server (BIP) - このサーバーでは、JD Edwards EnterpriseOne アプリケーションによって収集されたデータに基づいてレポートが表示されます。 さまざまなテンプレートに基づいてレポートのデータの表示方法を設計および制御できます。
  • Business Services Server (BSS) - BSS により、他の Oracle アプリケーションとの情報交換と相互運用が可能になります。
  • Real-Time Events Server (RTE) - RTE Server を使用すると、JDE EnterpriseOne システムで発生したトランザクションに関する外部システムへの通知を設定できます。 サブスクライバー モデルが使用されており、サードパーティ製システムを使用してイベントにサブスクライブできます。 両方の RTE サーバーに要求の負荷を分散するには、サーバーを 1 つのクラスター内に配置します。
  • Application Development Framework (ADF) Server - ADF サーバーは、Oracle ADF を使用して開発された JD Edwards Enterprise One アプリケーションを実行するために使用されます。 このサーバーは、ADF ランタイムと共に Oracle WebLogic サーバーにデプロイされます。

中間層

中間層には、ロジック サーバーとバッチ サーバーが含まれています。 この場合、両方のサーバーが同じ仮想マシンにインストールされています。 運用環境のシナリオで推奨されるのは、ロジック サーバーとバッチ サーバーを別々のサーバーにデプロイすることです。 複数のサーバーが 2 つの可用性ゾーンにまたがって中間層にデプロイされ、可用性が高くなります。 Azure ロード バランサーを作成し、これらのサーバーをバックエンド プールに配置して、両方のサーバーがアクティブで要求が処理されることを確保するようにします。

中間層のサーバーは、プレゼンテーション層のサーバーとパブリック ロード バランサーからのみ要求を受け取ります。 プレゼンテーション層のサブネットとロード バランサー以外のアドレスからのトラフィックを拒否するようにネットワーク セキュリティ グループ規則を設定する必要があります。 管理目的で踏み台ホストからポート 22 のトラフィックを許可するように NSG 規則を設定することもできます。 パブリック ロード バランサーを使用して、中間層の VM 間で要求の負荷を分散できる場合もあります。

次の 2 つのコンポーネントは中間層にあります。

  • ロジック サーバー - ビジネス ロジックまたはビジネス機能が含まれています。
  • バッチ サーバー - バッチ処理に使用されます

データベース層

データベース層には、アプリケーションのデータベース インスタンスが存在します。 データベースには、Oracle DB、Oracle RAC、Oracle Exadata Database システムのいずれかを選択できます。

Oracle DB を選択した場合、Azure Marketplace で提供されている Oracle DB イメージを使用してデータベース インスタンスを Azure にデプロイできます。 または、Azure と OCI 間の相互接続を使用し、OCI 上に PaaS モデルで Oracle DB をデプロイすることもできます。

Oracle RAC の場合、PaaS モデルで OCI を使用できます。 2 ノードの RAC システムを使用することをお勧めします。 IaaS モデルでは Azure CloudSimple に Oracle RAC をデプロイできますが、Oracle でサポートされている構成ではありません。 「許可を受けたクラウド環境で適格な Oracle プログラム」を参照してください。

最後に、Exadata システムの場合は、OCI 相互接続を使用して、Exadata システムを OCI にデプロイします。 前出のアーキテクチャ図は、2 つのサブネットにまたがって OCI にデプロイされた Exadata システムを示しています。

運用のシナリオでは、2 つの可用性ゾーン (Azure にデプロイする場合) または 2 つの可用性ドメイン (OCI の場合) にまたがってデータベースの複数インスタンスをデプロイします。 プライマリ データベースとスタンバイ データベースの同期には、Oracle Active Data Guard を使用します。

データベース層は、中間層からの要求のみを受け取ります。 中間層からの要求と、管理を目的とした要塞サーバーからの要求のみを、それぞれポート 1521 とポート 22 で許可するネットワーク セキュリティ グループ (OCI にデータベースをデプロイする場合はセキュリティ リスト) を設定するようお勧めします。

OCI にデプロイされたデータベースについては、FastConnect 回線に接続された動的ルーティング ゲートウェイ (DRG) を使用して、別個の仮想クラウド ネットワークを設定する必要があります。

ID 層

Microsoft と Oracle のパートナーシップにより、Azure、OCI、Oracle アプリケーションの垣根を越えて統一された ID の設定が可能となっています。 JD Edwards EnterpriseOne または PeopleSoft アプリケーション スイートの場合、Microsoft Entra ID と Oracle IDCS の間でシングル サインオンを設定するには、Oracle HTTP Server (OHS) のインスタンスが必要です。

OHS は、アプリケーション層へのリバース プロキシとして機能します。つまり、エンド アプリケーションに対するすべての要求が OHS を経由します。 Oracle Access Manager WebGate は、エンド アプリケーションに向かうすべての要求をインターセプトする OHS Web サーバー プラグインです。 アクセスしようとしているリソースが保護されている (認証済みのセッションが必要である) 場合、WebGate がユーザーのブラウザーを介して Identity Cloud Service との OIDC 認証フローを開始します。 OpenID Connect WebGate でサポートされるフローの詳細については、Oracle Access Manager のドキュメントを参照してください。

このセットアップでは、既に Microsoft Entra ID にログインしているユーザーは、Oracle Identity Cloud Service を使用して、再度ログインしなくても JD Edwards EnterpriseOne または PeopleSoft アプリケーションに移動できます。 このソリューションをデプロイすることによって、お客様はシングル サインオンの利点を得ることができます (資格情報が 1 セットで済む、サインオン エクスペリエンスとセキュリティが向上する、ヘルプデスク コストが軽減されるなど)。

Microsoft Entra ID を使用して JD Edwards EnterpriseOne または PeopleSoft のシングル サインオンを設定する方法の詳細については、関連する Oracle ホワイトペーパーを参照してください。

PeopleSoft

Oracle の PeopleSoft アプリケーション スイートには、人事管理と財務管理のためのソフトウェアが含まれています。 このアプリケーション スイートは多層であり、アプリケーションには人事管理システム (HRMS)、顧客関係管理 (CRM)、財務およびサプライ チェーン管理 (FSCM)、および企業業績管理 (EPM) が含まれます。

推奨されるのは、ソフトウェア スイートの各層をそれ独自のサブネットにデプロイすることです。 アプリケーションのバックエンド データベースとして、Oracle データベースまたは Microsoft SQL Server が必要です。 このセクションでは、Oracle データベース バックエンドを使用して PeopleSoft を展開する方法について詳しく説明します。

次の図は、PeopleSoft アプリケーション スイートをクラウド間アーキテクチャでデプロイする場合の標準的なアーキテクチャを示しています (図 5)。

PeopleSoft クロスクラウド アーキテクチャ

図 5: PeopleSoft クロスクラウド アーキテクチャ

このサンプル アーキテクチャで、Azure の仮想ネットワークは、クロスクラウド相互接続を使用して OCI 内の仮想クラウド ネットワークに接続されています。 アプリケーション層は Azure 内に設定され、データベースは OCI 内に設定されます。 推奨されるのは、特定のポート上の特定のサブネットからのトラフィックのみを許可するネットワーク セキュリティ グループを備えた独自のサブネットに各コンポーネントをデプロイすることです。

このアーキテクチャは、リージョン内の 2 つの可用性ゾーンで Oracle Data Guard を使用して構成された高可用 Oracle データベースを使用して、完全に Azure 上にデプロイするように調整することもできます。 次の図 (図 6) は、このアーキテクチャ パターンの例です。

PeopleSoft Azure のみのアーキテクチャ

図 6: PeopleSoft Azure のみのアーキテクチャ

以下のセクションでは、さまざまなコンポーネントについて概要を説明します。

要塞層

要塞ホストは、アプリケーションおよびデータベース インスタンスにアクセスするためのジャンプ サーバーとして使用できるオプション コンポーネントです。 要塞ホスト VM には、パブリック IP アドレスを割り当てることができます (ただし推奨されるのは、オンプレミス ネットワークとの間に ExpressRoute 接続またはサイト間 VPN を設定してアクセスの安全性を確保することです)。 加えて、受信トラフィック用に SSH (ポート 22、Linux) または RDP (ポート 3389、Windows Server) のみを開放する必要があります。 高可用性を確保するために、要塞ホストは 2 つの可用性ゾーンまたは 1 つの可用性セットにデプロイしてください。

また、ご利用の VM で SSH エージェント転送を有効にすれば、要塞ホストから資格情報を転送することによって仮想ネットワーク内の他の VM にアクセスすることができます。 または、SSH トンネリングを使用して他のインスタンスにアクセスすることもできます。

エージェント転送の例を次に示します。

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

このコマンドは、要塞に接続した後、すぐに ssh を再実行して、ターゲット インスタンス上のターミナルを取得しています。 実際のクラスターの構成が異なる場合は、ターゲット インスタンスに対して root 以外のユーザーを指定しなければならないことがあります。 -A 引数により、ローカル コンピューター上の秘密キーが自動的に使用されるようにエージェント接続が転送されます。 エージェント転送はチェーンであるため、ターゲット インスタンスから開始された後続の SSH 接続でもローカルの秘密キーが使用されるよう、2 つ目の ssh コマンドにも -A が含まれていることに注意してください。

アプリケーション層

アプリケーション層には、PeopleSoft アプリケーション サーバー、PeopleSoft Web サーバー、エラスティック検索、および PeopleSoft Process Scheduler のインスタンスが含まれています。 Azure ロード バランサーは、アプリケーション層の適切なサーバーにルーティングされるユーザーからの要求を受け入れるように設定されています。

高可用性を確保するために、異なる可用性ゾーンにまたがってアプリケーション層の各サーバーの冗長インスタンスを設定することを検討します。 Azure ロード バランサーは、各要求を適切なサーバーに転送するように複数のバックエンド プールを使用して設定できます。

PeopleTools クライアント

PeopleTools クライアントは、開発、移行、アップグレードなどの管理作業を実行するために使用されます。 PeopleTools クライアントはアプリケーションの高可用性を実現するために必要ではないため、PeopleTools クライアントの冗長サーバーは必要ありません。

データベース層

データベース層には、アプリケーションのデータベース インスタンスが存在します。 データベースには、Oracle DB、Oracle RAC、Oracle Exadata Database システムのいずれかを選択できます。

Oracle DB を選択した場合、Azure Marketplace で提供されている Oracle DB イメージを使用してデータベース インスタンスを Azure にデプロイできます。 または、Azure と OCI 間の相互接続を使用し、OCI 上に PaaS モデルで Oracle DB をデプロイすることもできます。

Oracle RAC の場合、PaaS モデルで OCI を使用できます。 2 ノードの RAC システムを使用することをお勧めします。 IaaS モデルでは Azure CloudSimple に Oracle RAC をデプロイできますが、Oracle でサポートされている構成ではありません。 「許可を受けたクラウド環境で適格な Oracle プログラム」を参照してください。

最後に、Exadata システムの場合は、OCI 相互接続を使用して、Exadata システムを OCI にデプロイします。 前出のアーキテクチャ図は、2 つのサブネットにまたがって OCI にデプロイされた Exadata システムを示しています。

運用のシナリオでは、2 つの可用性ゾーン (Azure にデプロイする場合) または 2 つの可用性ドメイン (OCI の場合) にまたがってデータベースの複数インスタンスをデプロイします。 プライマリ データベースとスタンバイ データベースの同期には、Oracle Active Data Guard を使用します。

データベース層は、中間層からの要求のみを受け取ります。 中間層からの要求と、管理を目的とした要塞サーバーからの要求のみを、それぞれポート 1521 とポート 22 で許可するネットワーク セキュリティ グループ (OCI にデータベースをデプロイする場合はセキュリティ リスト) を設定するようお勧めします。

OCI にデプロイされたデータベースについては、FastConnect 回線に接続された動的ルーティング ゲートウェイ (DRG) を使用して、別個の仮想クラウド ネットワークを設定する必要があります。

ID 層

Microsoft と Oracle のパートナーシップにより、Azure、OCI、Oracle アプリケーションの垣根を越えて統一された ID の設定が可能となっています。 JD Edwards EnterpriseOne または PeopleSoft アプリケーション スイートの場合、Microsoft Entra ID と Oracle IDCS の間でシングル サインオンを設定するには、Oracle HTTP Server (OHS) のインスタンスが必要です。

OHS は、アプリケーション層へのリバース プロキシとして機能します。つまり、エンド アプリケーションに対するすべての要求が OHS を経由します。 Oracle Access Manager WebGate は、エンド アプリケーションに向かうすべての要求をインターセプトする OHS Web サーバー プラグインです。 アクセスしようとしているリソースが保護されている (認証済みのセッションが必要である) 場合、WebGate がユーザーのブラウザーを介して Identity Cloud Service との OIDC 認証フローを開始します。 OpenID Connect WebGate でサポートされるフローの詳細については、Oracle Access Manager のドキュメントを参照してください。

このセットアップでは、既に Microsoft Entra ID にログインしているユーザーは、Oracle Identity Cloud Service を使用して、再度ログインしなくても JD Edwards EnterpriseOne または PeopleSoft アプリケーションに移動できます。 このソリューションをデプロイすることによって、お客様はシングル サインオンの利点を得ることができます (資格情報が 1 セットで済む、サインオン エクスペリエンスとセキュリティが向上する、ヘルプデスク コストが軽減されるなど)。

Microsoft Entra ID を使用して JD Edwards EnterpriseOne または PeopleSoft のシングル サインオンを設定する方法の詳細については、関連する Oracle ホワイトペーパーを参照してください。

次のステップ

Terraform スクリプトを使用して、Azure で Oracle アプリを設定し、OCI とのクロスクラウド接続を確立します。

OCI の詳細およびホワイトペーパーについては、Oracle Cloud のドキュメントを参照してください。