OCIでのWeb層の準備
プライマリ・オンプレミス・サイトと一致するように、Oracle Cloud Infrastructure (OCI)にセカンダリ・サイトをプロビジョニングおよび構成します。
ノート:
この項で説明するリソース(OCI Load Balancer、SSL証明書、バックエンド・セットとバックエンド、ルーティング・ポリシー、リスナーおよびルール・セット)を作成するTerraformコードは、「コードのダウンロード」にあります。
(オプション)Oracle HTTP Serverホストの準備
ノート:
Oracle HTTP Serverの作成および構成はオプションです。OCI Load Balancerのみを使用して(Oracle HTTP Serverを使用せずに)、OCIでWeb層を構成できます。
Oracle HTTP Serverホストのプロビジョニング
OCIで実行されている各Oracle HTTP Serverには、オンプレミスで実行されているOracle HTTP Serverをカバーするために使用されるライセンスおよびサポート契約に加えて、有効なライセンスおよびサポート契約が必要です。Oracle WebLogic Server for OCIイメージを使用して、Oracle CloudでOracle HTTP Serverのコンピュート・インスタンスを作成できます。これらのイメージを使用して作成されたコンピュート・インスタンスには、Oracle HTTP Serverを実行する権限が含まれ、WebLogicソフトウェアが実行中状態の場合に権限がOCPU/時間ごとに請求されます。Oracle WebLogic Server for OCIを使用してコンピュート・インスタンスを作成する場合は、コンピュート・インスタンス・コンソールまたはマーケットプレイスを使用できます。これらのイメージは、Oracle Linux 7.9およびOracle Linux 8.5オペレーティング・システムで使用できます。
この例では、表に示すように、コンパートメント内の1つの可用性ドメインにある2つのコンピュート・インスタンスを使用します。
名前 | コンパートメント | 可用性ドメイン | イメージ | 形状 | VCN | サブネット |
---|---|---|---|---|---|---|
hydrohs1 | HyDRCompmt | AD1 | Oracle WebLogic Enterprise Edition UCMイメージ(Oracle Linux 7.9) | VM.Standard2.2 | Hydrvcn | webTierSubnet |
hydrohs2 | HyDRCompmt | AD1 | Oracle WebLogic Enterprise Edition UCMイメージ(Oracle Linux 7.9) | VM.Standard2.2 | Hydrvcn | webTierSubnet |
コンピュート・インスタンス・コンソールを使用してコンピュート・インスタンスをプロビジョニングするには、次を実行します:
オペレーティング・システム・ユーザーおよびグループの準備
セカンダリ・コンピュート・インスタンスには、プライマリ・オンプレミスのOracleソフトウェアで使用されているものと同じユーザーおよびグループが必要です。
Oracle WebLogic Server for Oracle Cloud Infrastructureイメージには、すでにoracleユーザーおよびグループがあります。ただし、これらの値(ユーザー名、グループ名、uid
およびgid
)はプライマリ・インスタンスにある値と一致しない可能性があるため、プライマリoracleユーザーおよびグループの値と一致するようにセカンダリ・ホストを構成する必要があります。次の例は、プライマリoracleユーザーおよびグループの値と一致するようにこの層のセカンダリ・ホストを構成する方法を示しています。
オペレーティングシステムの要件の準備
runinstaller
を実行する必要はありません。Oracle WebLogic Server for Oracle Cloud InfrastructureイメージはWebLogicソフトウェア用に準備されているため、WebLogicのパッケージを手動で追加する必要はありません。ただし、これらのOracle HTTP ServerホストはOracle HTTP Server製品を実行します。セカンダリ・ホストがOracle HTTP Serverの要件を満たしていることを確認します。Oracle HTTP Serverのホスト名別名の準備
これは、次の2つの方法で実装できます。
- Oracle WebLogic Server for OCIコンピュート・インスタンスの
/etc/hosts
ファイルに別名としてホスト名を追加します。 - セカンダリOCI VCNでプライベートDNSビューを使用します。
/etc/hosts
ファイルの使用
/etc/hosts
ファイルに追加されます。 このモードは、DNSサーバーがプライマリ・オンプレミスとセカンダリOracle Cloud Infrastructure (OCI)サイトで同じである場合、およびプライマリ・サイトとセカンダリ・サイトで分離されたDNSサーバーが使用されている場合、すべてのシナリオで有効です。/etc/hosts
ファイルのエントリは、DNS解決よりも優先されます。これは、/etc/nsswitch.conf
ファイルのディレクティブhostsにあらかじめ定義されている優先順位であるためです。
ただし、この方法では、すべてのOracle HTTP Serverホストにエントリを手動で追加する必要があります:
ドメイン名システム(DNS)の使用
/etc/hosts
ファイルにすべてのエントリを追加するのではなく、プライベートDNSビューにすべてのエントリを追加できることです。
「OCIでの中間層の準備」のステップで、OCIで作成したプライベート・ビューにOracle HTTP Server仮想ホスト名のエントリを追加します:
OCIホストのファイアウォールで必要なポートを開く
ssh
、dhcp
)を除くすべてのポートの接続を拒否します。Oracle HTTP Serverで使用されるポートを開く必要があります。
Oracle HTTP Serverのoracle
ユーザー環境変数の作成
oracle
ユーザーのプロファイルに共通です。たとえば、ORACLE_HOME
、JDK_HOME
、PATH
、WEB_DOMAIN_HOME
などです。
プライマリからのOracle HTTP Server製品および構成のレプリケート
rsync
を使用して、プライマリOracle HTTP ServerノードからバイナリおよびOracle HTTP Server構成をコピーできます。
または、Oracle HTTP Serverソフトウェアをダウンロードし、OCI Oracle HTTP Serverコンピュート・インスタンスでゼロからインストールして構成することもできます。このアプローチは、このドキュメントの範囲外です。ただし、Oracle HTTP Server OCIコンピュート・インスタンスのオペレーティング・システムがプライマリOracle HTTP Serverホストと異なる場合は、このアプローチを使用する必要があります。
Oracle HTTP Serverのバイナリおよび構成ファイルは、通常、プライベート・ストレージに存在します。OCIでは、コンピュート・インスタンスがデフォルトで持っているブロック・ボリュームを使用できます。または、Oracle HTTP Serverコンピュートごとに新しいブロック・ボリュームを作成し(OCIブロック・ボリュームの準備を参照)、それぞれをOracle HTTP Serverコンピュート・インスタンスにマウントできます(OCIブロック・ボリュームのマウントを参照)。
この例では、追加のブロック・ボリュームを作成せずに、Oracle HTTP Serverコンピュート・インスタンスのデフォルトのブロック・ボリュームを使用します。
Oracle HTTP Serverの構成およびバイナリは、頻繁な超過時間は変更されません。この最初のレプリケーションの後、ライフサイクル中に同じレプリケーションを繰り返すことができます。または、両方のサイトでOracle HTTP Server構成の変更を実装することで、Oracle HTTP Serverの構成をプライマリおよびセカンダリで手動で維持できます。
OCI Load Balancerの準備
クラウドでOracle Cloud Infrastructure Load Balancerを作成および構成します。
ノート:
この項で説明するリソース(OCI Load Balancer、SSL証明書、バックエンド・セットとバックエンド、ルーティング・ポリシー、リスナーおよびルール・セット)を作成するTerraformコードは、「コードのダウンロード」にあります。
OCI Load Balancerのプロビジョニング
プライマリ・オンプレミス・サイトと一貫性を持たせるには、システムのエントリ・ポイントとして、Oracle Cloud Infrastructure (OCI)のセカンダリ・サイトにロード・バランサをプロビジョニングします。
バックエンド・セットの作成
バックエンド・セットは、同じアプリケーションを実行するバックエンド・サーバーのリストを含む論理エンティティです。バックエンド・セットを定義する場合、ロード・バランシング・ポリシーとヘルス・チェック・テストを指定する必要があります。その後、バックエンド・サーバーのリストを追加できます。
バックエンド・セットの構成は、WebLogicサーバー・ホストの前でOracle HTTP Serverを使用しているかどうかによって異なります。
Oracle HTTP Serverを使用している場合、Oracle Cloud Infrastructure (OCI) Load BalancerはHTTPSサーバーにリクエストを送信します。HTTPSサーバーによって公開されているポートごとにバックエンド・セットを作成します。たとえば、アプリケーションへのアクセスを提供するOracle HTTP Serverリスナー用に1つのバックエンド・セットを作成し、各Oracle WebLogic Server管理コンソールへのアクセスを提供するOracle HTTP Serverリスナー用に別のバックエンド・セットを作成します。
Oracle HTTP Serverを使用していない場合、OCI Load BalancerはWebLogicサーバーにリクエストを直接送信します。Oracle WebLogic Serverクラスタごとにバックエンド・セットを作成し、管理サーバー用に別のバックエンド・セットを作成します。
- OCIコンソールにログインします。
- 適切なリージョンおよびコンパートメントを選択します。
- ナビゲーション・メニューで、「ネットワーキング」をクリックし、「ロード・バランサ」をクリックします。
- バックエンドを追加するロード・バランサをクリックします。
- 「リソース」メニューで「バックエンド・セット」をクリックし、「バックエンド・セットの作成」をクリックします。
- 「バックエンド・セットの作成」ダイアログ・ボックスに次を入力します:
- 「Create」をクリックします。
追加のWebLogicサーバー・クラスタがある場合、同様の方法で各クラスタのバックエンド・セットを作成します。
Oracle HTTPS ServerをOracle WebLogic Serverとともに使用する場合のバックエンド・セットの例を次に示します。
コンポーネント | バックエンド・セット名 | トラフィック分散ポリシー | セッション永続性 | Cookie名(例) | 属性: secure | ヘルス・チェック |
---|---|---|---|---|---|---|
管理サーバー | OHS_Admin_backendset |
重み付けラウンド・ロビン | ロード・バランサCookieの永続性を有効化 | X-Oracle-LBR-ADMIN-Backendset |
チェックなし | TCPまたはHTTP |
WebLogicクラスタ | OHS_HTTP_backendset |
重み付けラウンド・ロビン | ロード・バランサCookieの永続性を有効化 | X-Oracle-LBR-OHS-HTTP-Backendset |
チェック済 | TCPまたはHTTP |
Oracle HTTP Serverを使用しない場合のバックエンド・セットの例を次に示します。
コンポーネント | バックエンド・セット名 | トラフィック分散ポリシー | セッション永続性 | Cookie名(例) | 属性: secure | ヘルス・チェック |
---|---|---|---|---|---|---|
管理サーバー | Admin_backendset |
重み付けラウンド・ロビン | ロード・バランサCookieの永続性を有効化 | X-Oracle-LBR-ADMIN-Backendset |
チェックなし | TCPまたはHTTP |
Weblogicクラスタ 1 | WLS_Cluster1_backendset |
重み付けラウンド・ロビン | ロード・バランサCookieの永続性を有効化 | X-Oracle-LBR-WLSCluster1-Backendset |
チェック済 | TCPまたはHTTP |
Weblogicクラスタ 2 | WLS_Cluster2_backendset |
重み付けラウンド・ロビン | ロード・バランサCookieの永続性を有効化 | X-Oracle-LBR-WLSCluster2-Backendset |
チェック済 | TCPまたはHTTP |
追加のWebLogicクラスタがある場合は、同様の方法で各クラスタのバックエンド・セットを作成します。
各バックエンド・セットのバックエンドの定義
Oracle Cloud Infrastructure (OCI) Load Balancerで、各バックエンド・セットのバックエンドを定義します。
Oracle HTTP Serverを使用している場合は、各バックエンド・セットのバックエンドとしてOracle HTTP Serverノードおよび適切なポートを追加します。
Oracle HTTP Serverを使用していない場合は、各バックエンド・セットのバックエンドとしてOracle WebLogic Serverノードおよび適切なポートを追加します。
- コンソールで、「バックエンド・セット」を選択します。「バックエンド」をクリックし、「バックエンドの追加」をクリックします。
- バックエンドであるサーバーのIPアドレスおよびポートを入力します。
バックエンド・セット名 | バックエンド |
---|---|
OHS_Admin_backendset |
コンピュート・インスタンス:
|
OHS_HTTP_backendset |
コンピュート・インスタンス:
|
この表は、Oracle HTTP Serverを使用しない場合にこのドキュメントの例で作成されるバックエンド・セットを示しています:
バックエンド・セット名 | バックエンド |
---|---|
Admin_backendset |
IPアドレス:
|
WLSCluster1_backendset |
コンピュート・インスタンス:
|
WLSCluster2_backendset |
コンピュート・インスタンス:
|
ルーティング・ポリシーの定義およびルールの構成
ルーティング・ポリシーは、受信リクエストを正しいバックエンド・セットに送信するために使用されます。たとえば、/console
へのリクエストは管理バックエンド・セットにディスパッチされ、/app1
へのリクエストは、app1
が実行されているクラスタのバックエンド・セットにディスパッチされます。
Oracle HTTP Serverを使用している場合は、通常、Oracle HTTP Server構成でルート(/app1
、/app2
、/console
など)を定義します。この場合、Oracle Cloud Infrastructure (OCI) Load Balancerでルーティング・ポリシーおよびルールを定義する必要はありません。
Oracle HTTP Serverを使用していない場合は、OCI Load Balancerでルーティング・ポリシーおよびルールを定義して、リクエストを適切なバックエンド・セットにディスパッチする必要があります。
コンポーネント | ルーティング・ポリシー名 | ルール | 条件: 一致パスが次で始まる場合 | 処理: バックエンド・セットにルーティング |
---|---|---|---|---|
管理サーバー・コンソール | Admin_Rules |
Admin_routerule |
|
Admin_backendset |
アプリケーション1 | Application_Rules |
WLSCluster1_routerule |
|
WLSCluster1_backendset |
アプリケーション2 | Application_Rules |
WLSCluster2_routerule |
|
WLSCluster2_backendset |
環境に必要な数のルーティング・ポリシー、ルールおよび条件を作成できます。
リスナーの作成
システムへのアクセスに使用されるフロントエンド名とポートの組合せごとにリスナーを作成します。プライマリ・ロード・バランサで使用されているものと同じホスト名(仮想フロントエンド名)およびポートを使用する必要があります。
- 仮想フロントエンド・ホスト名をホスト名としてOracle Cloud Infrastructure Load Balancerに追加します。
- リスナーを作成します。
次の表に、このドキュメントの例で作成されたリスナーと、それに関連付けられたプロトコル、ポート、バックエンド・セット、ルーティング・ポリシー、ホスト名およびSSL使用状況のサマリーを示します。これは参考例です。システムでプライマリOracle WebLogic Serverシステムで追加のフロントエンド・ホスト名、ポートまたはプロトコルを使用する場合は、ニーズに応じて対応するリスナーおよびホスト名を作成する必要があります。たとえば、代替フロントエンドを使用してOracle WebLogic ServerコンソールおよびOracle Enterprise Managerコンソールにアクセスする場合です。
リスナー | プロトコル | 港 | バックエンド・セット | ルーティング・ポリシー | HostName | SSLの使用 |
---|---|---|---|---|---|---|
Admin_listener |
HTTP | 7001 |
|
Admin_Rules |
wlsfrontend.example.com | いいえ |
HTTPS_listener |
HTTPS | 443 |
|
App_Rules |
wlsfrontend.example.com | はい |
HTTP_listener |
HTTP | 80 | N/A* | 該当なし | wlsfrontend.example.com | いいえ |
*この例のHTTP_listener
は、リクエストをHTTPS_listener
(HTTPS)にリダイレクトするためにのみ使用されます。割り当てられたバックエンドは使用されません。ただし、指定は必須であるため、SSLが選択されていないものを指定する必要があります(デフォルトの空のバックエンド・セットを使用します)。
SSLヘッダーのルール・セットの作成
Oracle Cloud Infrastructure (OCI) Load BalancerでSSLヘッダーのルール・セットを作成し、HTTPSリスナーに関連付けます。
HTTPプロトコルをHTTPSにリダイレクトするルール・セットの作成
リダイレクト・ルールを作成し、それをHTTP_listenerに関連付けて、ポート80をポート443にリダイレクトします。EDGトポロジでは、Load Balancerのポート80 (HTTP)に達するすべてのリクエストをポート443 (HTTPS)にリダイレクトする必要があります。
WLSコンピュートインスタンスへの仮想フロントエンドの名前とIPの追加
障害時リカバリ・トポロジでは、クライアントは、データ・センターに依存しないフロントエンドFQDN (通常は仮想フロントエンド名またはバニティURL)を使用してシステムにアクセスする必要があります。この仮想フロントエンド名は、現在のアクティブ(プライマリ)サイトのLoad Balancer IPアドレスに解決される必要があります。
プライマリ・システムは、プライマリLoad BalancerのIPを使用してDNSによって解決されるフロントエンド仮想名をすでに使用している必要があります。ただし、各サイトのOracle WebLogic Serverホストは、DNSでのクライアント対応の解決に関係なく、常にローカル・ロード・バランサでフロントエンド名を解決する必要があります。この場合、仮想フロントエンド名は各サイトで適切なIPアドレスを使用して/etc/hosts
ファイルに追加されます。これは、各サイトで異なるDNSサーバーを使用して実現することもできます。その場合、ローカルDNSサーバーは、各サイトで適切なロード・バランサIPを使用してフロントエンド名を解決します。
/etc/hosts
ファイルの使用
/etc/hosts
ファイルを変更しないでください。Oracle WebLogic Serverホストは、常に仮想フロントエンド名をフロントエンドIPで解決します。スイッチオーバーおよびフェイルオーバーの手順で必要なDNS更新は、Oracle WebLogic Serverクライアントで使用されるDNSまたはホスト・ファイルで実行されます。
ドメイン名システム(DNS)の使用
このアプローチに従っている場合は、セカンダリ・ミッドティアで使用されるDNSサービスにフロントエンド名(セカンダリ・ロード・バランサIPを指す)を追加できます。プライマリでは、フロントエンド名がプライマリ・ロード・バランサIPを指してすでに解決されていることが予想されます。
プライマリでは、フロントエンド名がプライマリ・ロード・バランサIPを指してすでに解決されていることが予想されます。