Oracle Cloud InfrastructureでのOracle E-Business Suiteのデプロイについて学ぶ

Oracle Cloud InfrastructureでOracle E-Business Suiteをプロビジョニングする場合、またはOracle E-Business Suite環境をデータ・センターからOracle Cloud Infrastructureに移行する場合は、マルチホストのセキュアな高可用性トポロジを計画できます。

Oracleは、このドキュメントで説明するベスト・プラクティスに従って、Oracle Cloud InfrastructureでOracle E-Business Suite環境のライフサイクルをプロビジョニング、移行および管理するための自動化を提供します。これにより、手動でのデプロイメントおよび管理の複雑さを解消できます。詳細は、ドキュメント2517025.1『Oracle E-Business SuiteおよびOracle Cloud Infrastructureスタート・ガイド』を参照してください。

Oracle Cloud Infrastructureでのデプロイメントに関する考慮事項

Oracleでは、異なるサブネット間で適切なセキュリティ要件を確実に実装できるように、要塞ホスト、データベース、アプリケーション、ロード・バランサ・インスタンスなど、インスタンスに個別のサブネットを作成することをお薦めします。

プライベートまたはパブリック・サブネット

インターネットからインスタンスへのアクセスを許可するかどうかに基づいて、プライベート・サブネットまたはパブリック・サブネットにインスタンスを作成できます。パブリック・サブネットに作成したインスタンスにはパブリックIPアドレスが割り当てられ、インターネットからこれらのインスタンスにアクセスできます。プライベート・サブネットで作成されたインスタンスにパブリックIPアドレスを割り当てることはできません。したがって、これらのインスタンスにインターネット経由でアクセスすることはできません。

次の図は、パブリックおよびプライベート・サブネットを持つ仮想クラウド・ネットワーク(VCN)を示しています。VCNには2つの可用性ドメインが含まれ、各可用性ドメインにはパブリックおよびプライベート・サブネットが含まれます。Webサーバーはこのイメージのパブリック・サブネットに配置されるため、各Webサーバー・インスタンスにパブリックIPアドレスがアタッチされます。パブリック・サブネット内のこれらのOracle Cloudインスタンスにインターネットからアクセスするには、インターネット・ゲートウェイ(IGW)を介した通信を有効にします。IGWとの間のトラフィックを有効にするには、ルートテーブルを更新する必要があります。インターネットからWebサーバーへのトラフィックを許可するには、パブリック・サブネットにロード・バランサを作成する必要があります。インターネットからインスタンスにアクセスするには、パブリック・サブネットに要塞ホストを作成し、IGWから要塞ホストにアクセスする必要もあります。

データベース・サーバーは、このイメージのプライベート・サブネットに配置されます。データ・センターからプライベート・サブネット内のOracle Cloudインスタンスにアクセスするには、動的ルーティング・ゲートウェイ(DRG)を介して接続します。DRGは、オンプレミス・ネットワークをクラウド・ネットワークに接続します。DRGと顧客のオンプレミス機器間の通信を有効にするには、IPSec VPNまたはOracle Cloud Infrastructure FastConnectを使用します。また、ルート表を更新して、DRGとの間のトラフィックを有効にする必要があります。


public_private_subnets_jde.pngの説明が続きます
図public_private_subnets_jde.pngの説明
シナリオ1:プライベート・サブネットのすべてのインスタンスのデプロイ

Oracleでは、インターネットに面したエンドポイントがない本番環境では、プライベート・サブネットのすべてのインスタンスをデプロイすることをお薦めします。このタイプのデプロイメントは、既存のデータ・センターの拡張としてクラウドを使用するハイブリッド・デプロイメントが必要な場合に便利です。

このデプロイメントでは、アプリケーションおよびデータベース・サーバーを含むすべてのインスタンスがプライベート・サブネットにデプロイされます。パブリックIPアドレスは、プライベート・サブネットで作成されたインスタンスに割り当てることはできないため、インターネットを介してこれらのインスタンスにアクセスすることはできません。この構成でオンプレミス環境からアプリケーション・サーバーにアクセスするには、次の操作を実行します。

  • アプリケーション・サーバーをプロビジョニングする前に、データ・センターとOracle Cloud Infrastructure DRG間のIPSec VPNトンネルを構成します。

  • この構成で要塞ホストを作成し、要塞ホストからプライベート・サブネット内のすべてのサーバーにアクセスします。

シナリオ2:パブリックおよびプライベート・サブネットでのインスタンスのデプロイ

パブリック・サブネット内のいくつかのインスタンスと、プライベート・サブネット内のいくつかのインスタンスをデプロイできます。このタイプのデプロイメントは、インターネットに直接接続しているエンドポイントとインターネットに接続していないエンドポイントがデプロイメントに含まれている場合に便利です。

この構成では、一部のアプリケーション・インスタンスはパブリック・サブネットに配置され、その他はプライベート・サブネットに配置されます。たとえば、内部ユーザーにサービスを提供するアプリケーション・インスタンスと、外部ユーザーにサービスを提供するアプリケーション・インスタンスの別のセットがあるとします。このシナリオでは、内部トラフィックを処理するアプリケーション・インスタンスをプライベート・サブネットに配置し、外部トラフィックを処理するアプリケーション・サーバーをパブリック・サブネットに配置します。また、外部トラフィックを処理するアプリケーション・サーバーをパブリック・サブネットに配置するかわりに、インターネットに面したアプリケーション・インスタンスにパブリック・ロード・バランサを設定することもできます。要塞ホストをパブリック・サブネットに配置すると、要塞ホストにパブリックIPアドレスが割り当てられ、インターネット経由でアクセスできるようになります。プライベート・サブネットのインスタンスには、要塞サーバーを介してアクセスできます。

シナリオ3:パブリック・サブネットのすべてのインスタンスのデプロイ

Oracleでは、このデプロイメントは、迅速なデモのため、または内部エンドポイントのない本番グレードのデプロイメントのためにお薦めします。このデプロイメントは、独自のデータ・センターがない場合、またはVPNを介してインスタンスにアクセスできず、インターネットを介してインフラストラクチャにアクセスする場合にのみ適しています。

このデプロイメントでは、アプリケーションおよびデータベース・インスタンスを含むすべてのインスタンスがパブリック・サブネットにデプロイされます。

パブリック・サブネット内の各インスタンスには、パブリックIPアドレスがアタッチされています。パブリックIPアドレスを持つインスタンスにはインターネット経由でアクセスできますが、セキュリティ・リストおよびセキュリティ・ルールを使用してアクセスを制限できます。管理タスクを実行するために、Oracleでは、この構成に要塞ホストを配置することをお薦めします。このシナリオでは、パブリック・インターネットに対して管理ポートを開くのではなく、要塞ホストに対してのみ管理ポートを開き、要塞ホストからのみインスタンスにアクセスできるようにセキュリティ・リストおよびセキュリティ・ルールを設定します。

アンチアフィニティ

Oracle Cloud Infrastructureの可用性ドメインで高可用性のために複数のインスタンスを作成する際、フォルト・ドメインを使用してインスタンスのアンチアフィニティを実現できます。

フォルト・ドメインは、可用性ドメイン内のハードウェアおよびインフラストラクチャのグループです。可用性ドメインごとに3つのフォルト・ドメインが含まれています。フォルト・ドメインを使用すると、1つの可用性ドメイン内の同じ物理ハードウェア上にインスタンスが存在しないようにインスタンスを配置できます。したがって、あるフォルト・ドメインに影響するハードウェア障害またはOracle Computeハードウェア・メンテナンスは、他のフォルト・ドメインのインスタンスには影響しません。フォルト・ドメインを使用すると、予期しないハードウェア障害や計画済の停止からインスタンスを保護できます。

データベースの高可用性のために、Oracle Real Applications Clusters (Oracle RAC)を提供する2ノードの仮想マシン(VM) DBシステムを作成できます。Oracle RACの2つのノードは、デフォルトでは常に個別のフォルト・ドメインに作成されます。Oracle RACデータベースのプロビジョニング中に、RACノードのフォルト・ドメインを手動で選択することもできます。そのため、データベース・ノードは同じ物理ホストにも同じ物理ラックにもありません。これにより、基礎となる物理ホストおよびトップオブラックスイッチの障害からデータベースインスタンスが保護されます。

アーキテクチャ

Oracle E-Business Suiteデプロイメントは、単一の可用性ドメイン、複数の可用性ドメインまたは複数のリージョンのOracle Cloud Infrastructureで設計できます。さらに、非武装地帯を組み込んで、外部トラフィックを分離し、内部システムを保護できます。

  • 単一の可用性ドメイン: Oracle E-Business Suiteを単一の可用性ドメインにデプロイしても、複数のアプリケーション・インスタンスを設定することで高可用性を確保できます。このアーキテクチャは、アプリケーション・インスタンスが停止した場合でもアプリケーションを使用できるようにする場合に使用します。可用性ドメイン内の他の使用可能なアプリケーション・インスタンスは、引き続きリクエストを処理します。

  • 非武装地帯(DMZ)を含む単一可用性ドメイン:内部システムが外部ネットワークから分離されているときに、外部の信頼できないネットワークからアプリケーションにアクセスできるようにする場合は、このアーキテクチャを使用します。
  • 複数の可用性ドメイン:このアーキテクチャは、ある可用性ドメインが停止した場合でもアプリケーションを使用できるようにする場合に使用します。別の可用性ドメインのアプリケーション・インスタンスには引き続きアクセスできます。

  • 複数のリージョン:このアーキテクチャは、アプリケーションの障害時リカバリ・サイトを別のリージョンに設定する場合に使用します。このアーキテクチャは、基本的には複数の可用性ドメイン・アーキテクチャと同じですが、同じリージョン内の別の可用性ドメインにリソースを作成するのではなく、別のリージョンにリソースを作成します。

ノート:

複数の可用性ドメインおよび複数のリージョンの場合もDMZを構成できます。

単一の可用性ドメインにOracle E-Business Suiteをデプロイするためのアーキテクチャ

このアーキテクチャでは、高可用性を確保しながら、単一の可用性ドメインでのOracle E-Business Suiteアプリケーションのデプロイメントを示します。

アーキテクチャは、要塞、ロード・バランサ、アプリケーションおよびデータベース・ホストが単一の可用性ドメイン内のVCNの個別のサブネットに配置された仮想クラウド・ネットワーク(VCN)で構成されます。次のアーキテクチャ図では、要塞ホストはパブリック・サブネットにデプロイされ、他のすべてのインスタンスはプライベート・サブネットにデプロイされます。ビジネス要件に基づいて、様々なインスタンスをパブリック・サブネットまたはプライベート・サブネットに配置できます。

このアーキテクチャでは、複数のアプリケーション層インスタンスが単一の可用性ドメインにデプロイされますが、個々のアプリケーション層インスタンスは別々のフォルト・ドメインに配置されるため、アプリケーション層の高可用性が実現されます。フォルト・ドメインを使用すると、単一の可用性ドメイン内の同じ物理ハードウェア上にないようにインスタンスを分散できます。その結果、あるフォルト・ドメインに影響するハードウェア障害やハードウェア・メンテナンスは、他のフォルト・ドメインのインスタンスには影響しません。

プライベート・サブネット内のインスタンスでは、オペレーティング・システム(yum)の更新を適用するために、Oracle Services Networkへのアウトバウンド接続が必要です。このためには、VCNでサービス・ゲートウェイを使用します。サービス・ゲートウェイを使用すると、プライベート・サブネットのホストは、サポートされているOracleサービス(yumリポジトリなど)にプライベートにアクセスできます。プライベート・サブネット内のインスタンスでは、オプションで、アプリケーション・パッチのダウンロードおよび外部統合のためにインターネットへのアウトバウンド接続が必要な場合があります。このためには、VCNでネットワーク・アドレス変換(NAT)ゲートウェイを使用します。NATゲートウェイでは、プライベート・サブネット内のホストはインターネットへの接続を開始してレスポンスを受信できますが、インターネットから開始されたインバウンド接続を受信することはできません。

可用性ドメイン内のすべてのアプリケーション・インスタンスがアクティブです。ロード・バランサ・インスタンスは、リクエストを受信してアプリケーション・サーバーに送信します。アプリケーション・サーバーは、これらのリクエストを処理してデータベース・インスタンスに転送します。プライベート・サブネット内のインスタンスには、要塞ホストを介してポート22経由でアクセスするか、データ・センターとOracle Cloud Infrastructure DRGの間にIPSec VPNトンネルを設定している場合は動的ルーティング・ゲートウェイ(DRG)経由でアクセスできます。

Oracleでは、Oracle Cloud Infrastructureにデプロイされたデータベースおよびアプリケーションに堅牢なバックアップおよびリカバリ計画を設定することをお薦めします。データベースおよびアプリケーション・インスタンスのバックアップをOracle Cloud Infrastructure Object Storageに格納することをお薦めします。プライベート・サブネット内のデータベースおよびアプリケーション層インスタンスは、サービス・ゲートウェイを使用してOracle Cloud Infrastructure Object Storageにバックアップできます。サービス・ゲートウェイは、インターネットを経由せずOracle Cloud Infrastructure Object Storageへのアクセスを提供します。

Oracle Cloud Infrastructure Object Storageへの自動およびオンデマンド・データベース・バックアップは、Oracle Cloud Infrastructureコンソールを使用して構成できます。これには、Swiftエンドポイントを使用したOracle Cloud Infrastructure Object Storageへの接続が必要です。Oracle Cloud Infrastructure Object Storage上のすべてのデータベース・バックアップは、透過的データ暗号化(TDE)ウォレット暗号化に使用されるものと同じマスター・キーで暗号化されます。自動データベース・バックアップ・サービスでは、週次増分バックアップ計画を使用して、自動バックアップの構成時にカスタマイズできるカスタム保存方針でデータベースをバックアップします。

アプリケーションのバックアップは、Oracle Cloud Infrastructure Block Volumesのポリシーベースのバックアップ機能を使用して構成できます。Oracle Cloud Infrastructure Block Volumesには、スケジュールに基づいてボリューム・バックアップを自動的に実行し、選択したバックアップ・ポリシーに基づいて保存する機能があります。これにより、データのコンプライアンスおよび規制要件に準拠できます。Bronze、Silver、Goldの3つのバックアップ・ポリシーが事前に定義されています。各バックアップ・ポリシーには、事前定義済のバックアップ頻度および保存期間があります。


single_availability_domain_ha_topology.pngの説明が続きます
図single_availability_domain_ha_topology.pngの説明

このアーキテクチャでは、次のコンポーネントがサポートされます。

  • 要塞ホスト:要塞ホストは、プライベート・サブネット内のインスタンスにアクセスするためのジャンプ・サーバーとして使用できるオプションのコンポーネントです。要塞ホストは、オペレーティング・システムとしてLinuxを使用するOracle Cloud Infrastructure Computeインスタンスです。要塞ホストをパブリック・サブネットに配置し、インターネットからアクセスするためのパブリックIPアドレスを割り当てます。

    追加のセキュリティ・レベルを提供するために、オンプレミス・ネットワークのパブリックIPアドレスからのみ要塞ホストにアクセスするようにセキュリティ・リストを設定できます。プライベート・サブネットのOracle Cloud Infrastructureインスタンスには、要塞ホストを介してアクセスできます。これを行うには、ssh-agent転送を有効にします。これにより、要塞ホストに接続し、コンピュータから資格証明を転送して次のサーバーにアクセスできます。動的SSHトンネリングを使用して、プライベート・サブネット内のインスタンスにアクセスすることもできます。SSHトンネリングは、Webアプリケーションまたは他のリスニング・サービスにアクセスする方法です。動的トンネルはローカルポート上でSOCKSプロキシを提供しますが、接続はリモートホストから発信されます。

  • ロード・バランサ層:この層にはOracle Cloud Infrastructure Load Balancingが含まれます。アプリケーション・ユーザーからのリクエストを受信し、トラフィックをOracle E-Business Suiteアプリケーション・サーバーにロード・バランシングします。Oracle Cloud Infrastructure Load Balancingを使用して、VCN内のアプリケーション・インスタンスにトラフィックを分散します。このサービスは、プライマリ・ロード・バランサが停止した場合に、スタンバイ・ロード・バランサがリクエストを転送するように、ロード・バランサのプライマリおよびスタンバイ・インスタンスを提供します。ロード・バランサは、リクエストが正常なアプリケーション・インスタンスにルーティングされるようにします。アプリケーション・インスタンスに問題がある場合、ロード・バランサはそのインスタンスを構成から削除し、残りの正常なアプリケーション・インスタンスへのリクエストのルーティングを開始します。

  • アプリケーション層:この層には、高可用性を提供するOracle E-Business Suiteアプリケーションの複数のインスタンスが含まれます。アプリケーションの複数のインスタンスを別々のフォルト・ドメインに設定して、アプリケーション・インスタンスが停止した場合でもアプリケーションへのアクセスを続行できるようにします。

    Oracleでは、共有アプリケーション・バイナリを使用してOracle E-Business Suite複数層設定をデプロイすることをお薦めします。Oracle Cloud Infrastructure File Storageを使用して、Oracle E-Business Suiteアプリケーション・バイナリを共有する共有ファイル・システムを作成します。

  • データベース層:この層には、Oracle Cloud Infrastructure Databaseインスタンスが含まれます。高可用性要件のために、Oracleでは、2ノードの仮想マシン(VM) DBシステムまたはExadata DBシステムを使用することをお薦めします。

非武装地帯(DMZ)を使用してOracle E-Business Suiteをデプロイするためのアーキテクチャ

このアーキテクチャでは、DMZを含む単一の可用性ドメインでのOracle E-Business Suiteアプリケーションのデプロイメントを示します。

アーキテクチャは、ベース・ホスト、内部ロード・バランサ、内部アプリケーション層、外部ロード・バランサ、外部アプリケーション層、および単一の可用性ドメイン内のVCNの個別のサブネットに配置されたデータベース・ホストを含む仮想クラウド・ネットワーク(VCN)で構成されます。次のアーキテクチャ図では、外部ロード・バランサはパブリック・サブネットにデプロイされ、他のすべてのインスタンスはプライベート・サブネットにデプロイされます。


ebs-singlead-dmz.pngの説明が続きます図ebs-singlead-dmz.pngの説明

このアーキテクチャでは、複数のアプリケーション層インスタンスが単一の可用性ドメインにデプロイされますが、個々のアプリケーション層インスタンスは別々のフォルト・ドメインに配置されるため、アプリケーション層の高可用性が実現されます。フォルト・ドメインを使用すると、単一の可用性ドメイン内の同じ物理ハードウェア上にないようにインスタンスを分散できます。その結果、あるフォルト・ドメインに影響するハードウェア障害やハードウェア・メンテナンスは、他のフォルト・ドメインのインスタンスには影響しません。

プライベート・サブネット内のインスタンスでは、オペレーティング・システム(yum)の更新を適用するために、Oracle Services Networkへのアウトバウンド接続が必要です。このためには、VCNでサービス・ゲートウェイを使用します。サービス・ゲートウェイを使用すると、プライベート・サブネットのホストは、サポートされているOracleサービス(yumリポジトリなど)にプライベートにアクセスできます。プライベート・サブネット内のインスタンスでは、オプションで、アプリケーション・パッチのダウンロードおよび外部統合のためにインターネットへのアウトバウンド接続が必要な場合があります。このためには、VCNでネットワーク・アドレス変換(NAT)ゲートウェイを使用します。NATゲートウェイでは、プライベート・サブネット内のホストはインターネットへの接続を開始してレスポンスを受信できますが、インターネットから開始されたインバウンド接続を受信することはできません。

可用性ドメイン内のすべてのアプリケーション・インスタンスがアクティブです。ロード・バランサ・インスタンスは、リクエストを受信してアプリケーション・サーバーに送信します。アプリケーション・サーバーは、これらのリクエストを処理してデータベース・インスタンスに転送します。プライベート・サブネット内のインスタンスには、要塞ホストを介してポート22経由でアクセスするか、データ・センターとOracle Cloud Infrastructure DRGの間にIPSec VPNトンネルを設定している場合は動的ルーティング・ゲートウェイ(DRG)経由でアクセスできます。

DMZはパブリック・ロード・バランサ・サブネットを使用して実装され、ビジネス・パートナおよびサプライヤからのリクエストを受信し、内部ロード・バランサはプライベート・ロード・バランサ・サブネットを使用して実装され、内部ユーザーからのリクエストを受信します。専用アプリケーション層は、これら2つの異なるタイプのユーザーからのリクエストを処理します。

Oracleでは、Oracle Cloud Infrastructureにデプロイされたデータベースおよびアプリケーションに堅牢なバックアップおよびリカバリ計画を設定することをお薦めします。データベースおよびアプリケーション層インスタンスのバックアップをOracle Cloud Infrastructure Object Storageに格納することをお薦めします。プライベート・サブネット内のデータベースおよびアプリケーション層インスタンスは、サービス・ゲートウェイを使用してOracle Cloud Infrastructure Object Storageにバックアップできます。サービス・ゲートウェイは、インターネットを経由せずOracle Cloud Infrastructure Object Storageへのアクセスを提供します。

Oracle Cloud Infrastructure Object Storageへの自動およびオンデマンド・データベース・バックアップは、Oracle Cloud Infrastructureコンソールを使用して構成できます。これには、Swiftエンドポイントを使用したOracle Cloud Infrastructure Object Storageへの接続が必要です。Oracle Cloud Infrastructure Object Storage上のすべてのデータベース・バックアップは、透過的データ暗号化(TDE)ウォレット暗号化に使用されるものと同じマスター・キーで暗号化されます。自動データベース・バックアップ・サービスでは、週次増分バックアップ計画を使用して、自動バックアップの構成時にカスタマイズできるカスタム保存方針でデータベースをバックアップします。

アプリケーションのバックアップは、Oracle Cloud Infrastructure Block Volumesのポリシーベースのバックアップ機能を使用して構成できます。Oracle Cloud Infrastructure Block Volumesには、スケジュールに基づいてボリューム・バックアップを自動的に実行し、選択したバックアップ・ポリシーに基づいて保存する機能があります。これにより、データのコンプライアンスおよび規制要件に準拠できます。Bronze、Silver、Goldの3つのバックアップ・ポリシーが事前に定義されています。各バックアップ・ポリシーには、事前定義済のバックアップ頻度および保存期間があります。

このアーキテクチャでは、次のコンポーネントがサポートされます。

  • 要塞ホスト:要塞ホストは、プライベート・サブネット内のインスタンスにアクセスするためのジャンプ・サーバーとして使用できるオプションのコンポーネントです。要塞ホストは、オペレーティング・システムとしてLinuxを使用するOracle Cloud Infrastructure Computeインスタンスです。

    追加のセキュリティ・レベルを提供するために、オンプレミス・ネットワークのパブリックIPアドレスからのみ要塞ホストにアクセスするようにセキュリティ・リストを設定できます。プライベート・サブネットのOracle Cloud Infrastructureインスタンスには、要塞ホストを介してアクセスできます。これを行うには、ssh-agent転送を有効にします。これにより、要塞ホストに接続し、コンピュータから資格証明を転送して次のサーバーにアクセスできます。動的SSHトンネリングを使用して、プライベート・サブネット内のインスタンスにアクセスすることもできます。SSHトンネリングは、Webアプリケーションまたは他のリスニング・サービスにアクセスする方法です。動的トンネルはローカルポート上でSOCKSプロキシを提供しますが、接続はリモートホストから発信されます。

  • 内部ロード・バランサ層この層にはOracle Cloud Infrastructure Load Balancingが含まれています。内部アプリケーション・ユーザーからリクエストを受信し、トラフィックをOracle E-Business Suite内部アプリケーション・サーバーにロード・バランシングします。Oracle Cloud Infrastructure Load Balancingを使用して、VCN内のアプリケーション・インスタンスにトラフィックを分散します。このサービスは、プライマリ・ロード・バランサが停止した場合に、スタンバイ・ロード・バランサがリクエストを転送するように、ロード・バランサのプライマリおよびスタンバイ・インスタンスを提供します。ロード・バランサは、リクエストが正常なアプリケーション・インスタンスにルーティングされるようにします。アプリケーション・インスタンスに問題がある場合、ロード・バランサはそのインスタンスを構成から削除し、残りの正常なアプリケーション・インスタンスへのリクエストのルーティングを開始します。
  • 外部ロード・バランサ層:この層は、内部ロード・バランサ層と同じ目的を果たしますが、外部アプリケーション・ユーザー(サプライヤに関連付けられたユーザーなど)を対象とします。
  • アプリケーション層:この層には、高可用性を提供するOracle E-Business Suiteアプリケーションの複数のインスタンスが含まれます。アプリケーションの複数のインスタンスを別々のフォルト・ドメインに設定して、アプリケーション・インスタンスが停止した場合でもアプリケーションへのアクセスを続行できるようにします。

    このアーキテクチャでは、内部ユーザーと外部ユーザーに別々のアプリケーション層を利用することで、トラフィックを分離し、システムのセキュリティを保護できます。

    Oracleでは、共有アプリケーション・バイナリを使用してOracle E-Business Suite複数層設定をデプロイすることをお薦めします。Oracle Cloud Infrastructure File Storageを使用して、Oracle E-Business Suiteアプリケーション・バイナリを共有する共有ファイル・システムを作成します。

  • データベース層:この層には、Oracle Cloud Infrastructure Databaseインスタンスが含まれます。高可用性要件のために、Oracleでは、2ノードの仮想マシン(VM) DBシステムまたはExadata DBシステムを使用することをお薦めします。

複数の可用性ドメインにOracle E-Business Suiteをデプロイするためのアーキテクチャ

このアーキテクチャは、複数の可用性ドメインにまたがるOracle E-Business Suiteアプリケーションのデプロイメントを示します。ベース、ロード・バランサ、アプリケーションおよびデータベース・インスタンスが2つの可用性ドメイン間で別々のサブネットに配置された仮想クラウド・ネットワーク(VCN)を示しています。

可用性ドメイン内の高可用性を確保するために、各可用性ドメインに複数のアプリケーション・サーバーがデプロイされます。可用性ドメイン内のすべてのアプリケーション・サーバーは、異なるフォルト・ドメインにデプロイされます。異なるフォルト・ドメインを使用することで、アプリケーション・インスタンスは予期しないハードウェア障害およびハードウェア・メンテナンスによる計画済の停止から保護されます。また、プライマリ可用性ドメインが使用できない場合に可用性を確保するために、冗長インスタンスが別の可用性ドメインに作成されます。アーキテクチャ図では、可用性ドメイン1のインスタンスはアクティブで、可用性ドメイン2のインスタンスはスタンバイです。Oracleでは、プライマリ可用性ドメインが使用できない場合にアクティブ・インスタンスがロード全体を処理するように、可用性ドメイン間の対称トポロジでアプリケーションおよびデータベース・インスタンスを設定することをお薦めします。対称トポロジでは、アクティブ・サイトとスタンバイ・サイトの両方に同じ数のアプリケーション・インスタンスとデータベース・インスタンスをデプロイします。可用性ドメイン1のインスタンスがアクティブな場合、ロード・バランサは、これらのアクティブなインスタンスにのみトラフィックを転送するように構成されます。ロード・バランサは、可用性ドメイン2のアプリケーション・サーバー・インスタンスにトラフィックを送信するように構成されていません。これは、可用性ドメイン2のアプリケーション・インスタンスがロード・バランサ・バックエンド・セットに追加されないことを意味します。可用性ドメイン1が使用できない場合は、アプリケーションおよびデータベースを他の可用性ドメインに手動でスイッチオーバーする必要があります。このシナリオでは、可用性ドメイン2のアプリケーションおよびデータベース・サーバー・インスタンスがアクティブになります。この時点で、ロード・バランサのバックエンド・セットを可用性ドメイン2のアプリケーション・インスタンスで更新し、可用性ドメイン1のアプリケーション・インスタンスも削除する必要があります。ロード・バランサはリクエストを受け入れて、可用性ドメイン2のアプリケーション・サーバーに転送します。

可用性ドメイン間でシームレスなフェイルオーバーを行うには、Oracle E-Business Suiteデータベースおよびアプリケーション・インスタンスに論理ホスト名を使用します。プライマリ・サイトとスタンバイ・サイトで同じ論理ホスト名を使用して、スイッチオーバーまたはフェイルオーバー時のインスタンスの再構成作業を軽減します。

Oracle Cloud Infrastructureにデプロイされたデータベースおよびアプリケーションには、リカバリ計画の堅牢なバックアップを設定することをお薦めします。データベースおよびアプリケーション・インスタンスのバックアップをOracle Cloud Infrastructure Object Storageに格納することをお薦めします。プライベート・サブネット内のデータベースおよびアプリケーション・インスタンスは、サービス・ゲートウェイを使用してOracle Cloud Infrastructure Object Storageにバックアップできます。サービス・ゲートウェイは、インターネットを経由せずOracle Cloud Infrastructure Object Storageへのアクセスを提供します。

Oracle Cloud Infrastructure Object Storageへの自動およびオンデマンド・データベース・バックアップは、Oracle Cloud Infrastructureコンソールを使用して構成できます。これには、Swiftエンドポイントを使用したOracle Cloud Infrastructure Object Storageへの接続が必要です。Oracle Cloud Infrastructure Object Storage上のすべてのデータベース・バックアップは、透過的データ暗号化(TDE)ウォレット暗号化に使用されるものと同じマスター・キーで暗号化されます。

自動データベース・バックアップ・サービスでは、週次増分バックアップ計画を使用して、30日間の保存方針でデータベースをバックアップします。非定型要件のために、データベースのオンデマンドの全体バックアップを実行することもできます。

次のアーキテクチャ図では、要塞ホストはパブリック・サブネットにデプロイされ、他のすべてのインスタンスはプライベート・サブネットにデプロイされます。ビジネス要件に基づいて、様々なインスタンスをパブリック・サブネットまたはプライベート・サブネットに配置できます。プライベート・サブネット内のインスタンスには、要塞ホストまたはDRG (データ・センターとOracle Cloud Infrastructure DRGの間にIPSec VPNトンネルを設定している場合)を介してポート22経由でアクセスできます。


multiple_availability_domain_ha_topology.pngの説明が続きます
図multiple_availability_domain_ha_topology.pngの説明

このアーキテクチャでは、次のコンポーネントがサポートされます。

  • 要塞ホスト:要塞ホストは、アプリケーションおよびデータベース・インスタンスにアクセスするためのジャンプ・サーバーとして使用できるオプションのコンポーネントです。高可用性を実現するには、両方の可用性ドメインに要塞ホストをデプロイします。

  • ロード・バランサ層: Oracle Cloud Infrastructure Load Balancingは、可用性ドメイン内のアプリケーション・サーバー間でトラフィックを分散します。ロード・バランサは、パブリック・ロード・バランサまたはプライベート・ロード・バランサとしてプロビジョニングできます。

  • アプリケーション層:高可用性を確保するために、各可用性ドメインに複数のアプリケーション・サーバーが設定されます。可用性ドメイン1のアプリケーション・サーバーはアクティブ状態で、可用性ドメイン2のアプリケーション・サーバーはパッシブ状態です。可用性ドメイン間でアプリケーション・サーバーを同期するには、rsyncを使用します。

    Oracleでは、共有アプリケーション・バイナリを使用してOracle E-Business Suite複数層設定をデプロイすることをお薦めします。Oracle Cloud Infrastructure File Storageを使用して、Oracle E-Business Suiteアプリケーション・バイナリを共有する共有ファイル・システムを作成します。

  • データベース層:両方の可用性ドメインで高可用性データベース・インスタンスを設定します。アーキテクチャの図は、可用性ドメイン1のデータベース・サーバーがアクティブで、可用性ドメイン2のデータベース・サーバーがスタンバイであることを示しています。可用性ドメイン間でデータベースをレプリケートするには、Oracle Active Data GuardまたはOracle Data Guardを使用します。データベースに対してOracle Data Guardを有効にするには、Oracle Cloud InfrastructureコンソールまたはOracle Cloud Infrastructure APIを使用します。

複数のリージョンにOracle E-Business Suiteをデプロイするためのアーキテクチャ

障害時リカバリのために、Oracle E-Business Suiteアプリケーションを複数のリージョンにデプロイできます。このアーキテクチャは、複数の可用性ドメイン間でのOracle E-Business Suiteアプリケーションのデプロイに似ています。このアーキテクチャでは、ロード・バランサ、アプリケーションおよびデータベース・インスタンスは、複数のリージョンにまたがる別々のサブネットに配置されます。

プライマリ・リージョンが使用できない場合に可用性を確保するために、スタンバイ・リージョンに冗長インスタンスが作成されます。プライマリ・リージョンには、可用性ドメイン内のアクティブなインスタンスが含まれます。2番目のリージョンの可用性ドメイン内のインスタンスは障害時リカバリ・リージョンと呼ばれ、スタンバイ状態にあります。Oracleでは、プライマリ・リージョンが使用できない場合にアクティブ・インスタンスがロード全体を処理するように、リージョン間の対称トポロジでアプリケーションおよびデータベース・インスタンスを設定することをお薦めします。対称トポロジでは、プライマリとスタンバイの両方のリージョンに同じ数のアプリケーションおよびデータベース・インスタンスをデプロイします。このアーキテクチャでは、可用性ドメイン内の高可用性を確保するために、各可用性ドメインに複数のアプリケーション・サーバーがデプロイされます。

このアーキテクチャは、リージョン1の可用性ドメインと、障害時リカバリ用のリージョン2の可用性ドメインのいずれかにのみデプロイされるため、リージョン1の可用性ドメインのフォルト・トレランスは提供されません。アプリケーションがデプロイされている唯一の可用性ドメインが使用できない場合は、障害時リカバリを呼び出して、アプリケーションをリージョン2にフェイルオーバーする必要があります。

リージョン1のインスタンスが使用できない場合は、リージョン2のインスタンスに手動でスイッチオーバーする必要があります。リージョン間でシームレスなフェイルオーバーを行うには、Oracle E-Business Suiteデータベースおよびアプリケーション・インスタンスに論理ホスト名を使用します。プライマリおよびスタンバイ・サイトで同じ論理ホスト名を使用すると、インスタンスを再構成せずにフェイルオーバーまたはスイッチバックが容易になります。

複数のリージョンにデータベースをレプリケートするには、非同期モードでOracle Active Data GuardまたはOracle Data Guardを使用します。複数のリージョン間でアプリケーション・サーバーを同期するには、rsyncを使用します。


multiple_region_topology.pngの説明が続きます図multiple_region_topology.pngの説明