1. Oracle HTTP Serverの管理
  2. Oracle HTTP Serverの管理
  3. Web層コンポーネントの高可用性の構成

6 Web層コンポーネントの高可用性の構成

この章の手順を使用して、Oracle HTTP ServerとWebLogic管理対象サーバーが別々のホスト上でロード・バランサの背後に位置する、Oracle HTTP Server高可用性デプロイメントを構成します。

この章の内容は次のとおりです。

親トピック: Oracle HTTP Serverの管理

Oracle HTTP Serverの単一インスタンスの特性

Oracle HTTP Server (OHS)は、Apacheインフラストラクチャをベースとしており、OHSのコア機能を拡張するためのOracleモジュールが含まれます。

OHSには、クライアント・リクエストを処理するための次のコンポーネントが含まれます。

  • HTTPリスナー: 受信リクエストを処理し、これを適切な処理ユーティリティにルーティングします。

  • モジュール(mod): OHS機能を実装および拡張します。OHSには、多数の標準Apacheモジュールが含まれます。OHSおよびOHSコンポーネント統合をサポートするOHS固有のモジュールも含まれます。

OHSは、フォワード・プロキシ・サーバーにも、リバース・プロキシ・サーバーにもなります。リバース・プロキシでは、様々なサーバーで処理されたコンテンツを1つのサーバーから送信されたように処理することができます。

親トピック: Web層コンポーネントの高可用性の構成

Oracle HTTP Serverおよびドメイン

Oracle HTTP Server (OHS)にとってWebLogicドメインは必須ではありませんが、通常はOracle WebLogicドメインと組み合せて使用します。OHSを管理コンソールに組み込んでそこで管理やモニタリングを行えるようにするため、OHSはドメインと関連付けることをお薦めします。

mod_wl_ohsモジュールは、管理対象サーバーへのリンクを処理します。mod_wl_ohsは、特定のタイプ(JSPなど)のリクエスト、またはURL宛てのリクエストを特定の管理対象サーバーにルーティングすることで構成します。

OHSは、通常、クラスタのフロントエンド処理を行います。この構成では、特殊なmod_wl_ohsディレクティブ、WebLogicClusterにより、クラスタ・メンバーをカンマ区切りリストで指定します。

次のステップでは、mod_wl_ohsディレクティブ・プロセスを説明します。

  1. 管理対象サーバーへのリクエストがmod_wl_ohsで受信されると、そのリクエストは、ディレクティブのクラスタ・メンバーの1つに送信されます。少なくとも1つの管理対象サーバーが、要求を満たすために使用できる必要があります。

  2. 管理対象サーバーがリクエストを受信すると、そのリクエストを処理して、クラスタ・メンバーの完全なリストをmod_wl_ohsに送り返します。

  3. mod_wl_ohsがその更新されたリストを受信すると、未知のサーバーが既知のサーバーのリストに動的に追加されます。これにより、後続のリクエストはすべてクラスタ・メンバー・リスト間でロード・バランシングされます。これは、mod_wl_ohsを更新またはOHSを追加せずに、新しい管理対象サーバーがクラスタに追加されるという利点があります。

    ノート:

    未知のサーバーが既知のサーバーのリストに追加されるかどうかは、mod_wl_ohsディレクティブDynamicServerListによって制御されます。動的なサーバーの追加を有効にするには、DynamicServerListをONに設定する必要があります。

ノート:

開始時に、すべての現行の管理対象サーバーをmod_wl_ohsディレクトリに含める必要はありません。高可用性設定では、リスト内に2つのクラスタ・メンバーさえいれば、最初の呼出しが機能します。OHS高可用性デプロイメントの実行の詳細は、『Oracle WebLogic Serverプロキシ・プラグインの使用』のOracle HTTP Server用WebLogicプロキシ・プラグインの構成に関する項を参照してください。

Oracle WebLogicクラスタの詳細は、『Oracle WebLogic Serverクラスタの管理』の概要とロードマップに関する項を参照してください。

親トピック: Web層コンポーネントの高可用性の構成

Oracle HTTP Serverの起動とシャットダウンのライフサイクル

Oracle HTTP Serverが起動すると、HTTP(S)リクエストのリスニングおよび応答の準備が整います。

Microsoft Windowsシステムでのリクエスト処理モデルは、UNIXシステムでのモデルとは異なります。

  • Microsoft Windowsの場合、1つの親プロセスと1つの子プロセスが存在します。子プロセスは、クライアント・リクエストを処理するスレッドを作成します。作成されるスレッド数は静的で、パフォーマンスに応じて構成できます。

  • UNIXでは、複数の子プロセスを管理する1つの親プロセスがあります。子プロセスは、リクエストを処理します。親プロセスは、構成に基づき、必要に応じて追加の子プロセスを作成します。

ノート:

OHSの処理モデルの詳細は、「Oracle HTTP Serverの処理モデル」を参照してください。

親トピック: Web層コンポーネントの高可用性の構成

Oracle HTTP Serverの起動と停止

Fusion Middleware ControlまたはWebLogic Scripting Tool (WLST)を使用して、Oracle HTTP Serverを起動、停止および再起動します。

WLSTの使用を予定している場合は、ツールについてよく理解しておく必要があります。Oracle Fusion Middleware管理者ガイドの「Oracle WebLogic Scripting Tool (WLST)の使用に関するスタート・ガイド」を参照してください。

ノート:

OHSインスタンスの起動および停止の詳細は、「基本的なOracle HTTP Serverタスクの実行」を参照してください。

親トピック: Web層コンポーネントの高可用性の構成

Oracle HTTP Serverの高可用性アーキテクチャとフェイルオーバーに関する考慮事項

高可用性トポロジでは、Oracle HTTP Serverと管理対象サーバーは、1つのロード・バランサの後方の異なるホスト上に配置されます。

図6-1は、ロード・バランサの後方に配置された2つのOracle HTTP Serverを示しています。

図6-1 Oracle HTTP Serverの高可用性アーキテクチャ

図6-1の説明が続きます
「図6-1 Oracle HTTP Serverの高可用性アーキテクチャ」の説明

ロード・バランサは、ユーザーからリクエストを受信して、それを接続されたOracle HTTP Serverに転送します。ロード・バランサは、リクエストを標準HTTP/HTTPSポート(80/443)で受信します。しかし、Oracle HTTP Serverにリクエストを渡すときは、まったく別のポートを使用します。この設定の利点は、次のとおりです。

  • ユーザーからは実際のポートが見えなくなります。

  • ユーザーは、ポート番号をURLに付加する必要がなくなります。

UNIXベースのシステムでは、root権限でのOHSの起動は必須ではありません。1024未満のポートを使用するプロセスを起動できるのは、rootのみです。ただし、1024未満のポート番号を使用するプロセスを起動するには、root権限を使用してプロセスを起動する必要があります。

ロード・バランサは、稼働中のOracle HTTP Serverにリクエストをルーティングします。

図6-1は、OHSから管理対象サーバーにリクエストが分散される仕組みも示しています。高可用性の場合、コンポーネントの各ペア(OHSと管理対象サーバー)は、別のホスト・コンピュータに存在する必要があります。管理対象サーバーは同じクラスタに存在しています。管理対象サーバー間でロード・バランシングするには、それらのサーバーが同じクラスタに存在する必要があります。

親トピック: Web層コンポーネントの高可用性の構成

Oracle HTTP Serverの障害保護および予想される動作

Oracle HTTP Server (OHS)では、プロセス障害とノード障害の2つのタイプの障害が発生します。プロセス障害は、個々のオペレーティング・システムで発生する可能性があります。一方、ノード障害は、OHSを実行しているホスト・コンピュータ全体の障害に及ぶ可能性があります。

Table 6-1 OHS障害タイプと障害保護

障害タイプ 保護

プロセス

ノード・マネージャは、OHSプロセスの保護と監視を行います。OHSプロセスに障害が発生すると、ノード・マネージャによって自動的にプロセスが再起動されます。

ノード

OHSの前面のロード・バランサは、最初のOHSが応答しない、またはURLピングが障害は発生したことを示している場合、別のOHSにリクエストを送信します。

管理対象サーバー

クラスタ内で管理対象サーバーに障害が発生すると、mod_wl_ohsによってアクティブなクラスタ・メンバーのいずれかにリクエストが自動的にリダイレクトされます。アプリケーションに状態が格納されている場合、状態のレプリケーションがクラスタ内で使用可能になり、これにより、リダイレクトされたリクエストが、同じ状態情報にアクセスできます。

データベース

通常、mod_oradavまたはmod_plsqlを使用している場合にのみ、問題になります。Oracle RACデータベースでは、Oracle RAC接続により、障害の特徴が判別されます。

クライアント接続フェイルオーバーが構成されている場合、進行中のトランザクションがロールバックされます。データベースが接続されている必要があります。

透過的アプリケーション・フェイルオーバー(TAF)が構成されている場合は、進行中のすべてのデータベースの書込みはロールバックされますが、データベースへの再接続が自動的に行われ、select文は自動的にリカバリされます。TAFはselect文のみをフェイルオーバーし、パッケージ変数は失われます。TAFのJDBC Oracle Call Interfaceドライバ機能により、接続先のデータベース・インスタンスに障害が発生した場合でも、アプリケーションはデータベースに自動的に再接続できます。この場合、アクティブ・トランザクションはロールバックされます。

親トピック: Web層コンポーネントの高可用性の構成

複数のマシンでのOracle HTTP Serverインスタンスの構成

構成ウィザードを使用してOracle HTTP Server (OHS)を構成し、OHSがドメインの一部である場合、各インスタンスのmod_wl_ohs.confファイルを更新します。

このファイルはDOMAIN_HOME/config/fmwconfig/components/OHS/componentNameディレクトリにあります。管理サーバーを再起動して、ドメインのすべてのOHSインスタンス(たとえそれらが別のホストにある場合でも)に変更を伝搬します。「mod_wl_ohs.confの構成」を参照してください。

ノート:

OHSインスタンスを別々のドメインにインストールおよび構成する場合、変更を他のOracle HTTP Serverに手動でコピーする必要があります。すべてのOHSインスタンスに変更が適用されていることと、それらのインスタンスが同期されていることを確認する必要があります。

親トピック: Web層コンポーネントの高可用性の構成

高可用性のためのOracle HTTP Serverの構成

Oracle HTTP Server (OHS)の高可用性デプロイメントの例を構成するには、特定の前提条件を満たす必要があります。その上で、OHSを追加のWebサーバーにインストールし、OHSの高可用性を構成および検証できます。

親トピック: Web層コンポーネントの高可用性の構成

高可用性OHSの構成の前提条件

Oracle HTTP Serverの高可用性デプロイメントを構成する前に、次の前提条件を完了します:

  • ロード・バランサに関する前提条件
    Oracle HTTP Serverに対するリクエストを分散させるには、外部のロード・バランサを使用して使用可能なOracle HTTP Server間にHTTP(S)リクエストを分散させるか、またはロード・バランシング用にOracle HTTP Server VirtualHostプロキシを構成します。
  • ロード・バランサの仮想サーバー名とポートの構成
    OHSのインストールでは、仮想サーバーはHTTP接続用に構成され、HTTPサーバー全体に分散されます。
  • ロード・バランサのポート番号の管理
    多くのOracle Fusion Middlewareコンポーネントおよびサービスがポートを使用します。管理者は、これらのサービスが使用するポート番号を把握し、2つのサービスによってホスト・コンピュータ上の同じポート番号が使用されないようにする必要があります。
  • WEBHOST1へのOracle HTTP Serverのインストールと検証
  • WEBHOST1での仮想ホストの作成
    使用するそれぞれの仮想ホストまたはサイト名に対して、OHSの構成にエントリを追加します。
  • mod_wl_ohs.confの構成
    OHSのインストールと構成が完了したら、mod_wl_ohs.confファイルを編集して、定義された任意の管理対象サーバーへのリンクを設定します。
  • SSL終端使用時のmod_wl_confの構成
    SSL終端を使用しており、なおかつWebLogicにリクエストをルーティングしている場合は、追加の構成ステップを実施する必要があります。
  • proxy.confファイルの作成
    外部ロード・バランサを使用していない場合は、ロード・バランシング用にOracle HTTP Server仮想ホスト・プロキシを構成できます。

親トピック: 高可用性のためのOracle HTTP Serverの構成

ロード・バランサに関する前提条件

Oracle HTTP Serverに対するリクエストを分散させるには、外部のロード・バランサを使用して使用可能なOracle HTTP Server間にHTTP(S)リクエストを分散させるか、またはロード・バランシング用にOracle HTTP Server VirtualHostプロキシを構成します。

外部ロード・バランサを使用している場合は、サード・パーティ製のロード・バランサの要件 で説明する機能を備えている必要があります。

ロード・バランシング用にOracle HTTP Serverを構成する場合は、仮想ホスト・ベースのプロキシ構成を使用します。これを行うには、構成の詳細を記載した構成ファイルをproxy.confなどの名前で別途作成し、includeタグを使用してこの構成をhttpd.confに追加します。たとえば、include "proxy.conf"とします。詳細は、proxy.confファイルの作成を参照してください。

ロード・バランサの仮想サーバー名とポートの構成

OHSのインストールでは、仮想サーバーはHTTP接続用に構成され、HTTPサーバー全体に分散されます。

サイトでHTTPおよびHTTPS接続のリクエストを処理する場合は、HTTPSリクエストはロード・バランサで終了し、そのリクエストをHTTPリクエストとして通過させることをお薦めします。これを行うには、ロード・バランサでプロトコルを変換できることが必要です。また、永続HTTPセッションを実行できるように構成する必要があります。

この例では、ロード・バランサが次のように構成されていると想定します。

  • 仮想ホスト: Myapp.example.com

  • 仮想ポート: 7777

  • サーバー・プール: Map

  • サーバー: WEBHOST1、Port 7777、WEBHOST2、Port 7777

ロード・バランサのポート番号の管理

多くのOracle Fusion Middlewareコンポーネントおよびサービスはポートを使用します。管理者は、これらのサービスが使用するポート番号を把握し、2つのサービスによってホスト・コンピュータ上の同じポート番号が使用されないようにする必要があります。

ほとんどのポート番号はインストール時に割り当てられます。Oracle HTTP ServerからOracle WebLogic Serverに送信されるすべてのトラフィックは、すべてのファイアウォールを通じてアクセスできることが重要です。

WEBHOST1へのOracle HTTP Serverのインストールと検証

WEBHOST1上にOracle HTTP Serverをインストールする方法については、『Oracle HTTP Serverのインストールと構成』のOracle HTTP Serverソフトウェアのインストールのステップを参照してください。

OHSホーム・ページにアクセスする次のURLを使用して、インストールを確認します。

http://webhost1:7777/

WEBHOST1での仮想ホストの作成

使用するそれぞれの仮想ホストまたはサイト名に対して、OHSの構成にエントリを追加します。

次のように、DOMAIN_HOME/config/fmwconfig/components/OHS/ohs_component_name/moduleconfディレクトリにvirtual_hosts.confという名前のファイルを作成します: 

NameVirtualHost *:7777
<VirtualHost *:7777>
 ServerName http://myapp.example.com:80
 RewriteEngine On
 RewriteOptions inherit
 UseCanonicalName On
</VirtualHost>

SSL/SSLターミネーション(*)を使用する場合は、次のようになります

NameVirtualHost *:7777
<VirtualHost *:7777>
 ServerName https://myapp.example.com:443
 RewriteEngine On
 RewriteOptions inherit
 UseCanonicalName On
</VirtualHost>

ノート:

また、Fusion Middleware Controlを使用して仮想ホストを作成できます。Oracle Fusion Middlewareの管理のコンポーネントを一緒にワイヤリングする方法を参照してください。

mod_wl_ohs.confの構成

OHSのインストールと構成が完了したら、mod_wl_ohs.confファイルを編集して、定義された任意の管理対象サーバーへのリンクを設定します。

このファイルはDOMAIN_HOME/config/fmwconfig/components/OHS/componentNameディレクトリにあります。

mod_wl_ohs.confファイルの編集の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverプロキシ・プラグイン12.1.2の使用』のOracle HTTP Server用WebLogicプロキシ・プラグインの構成に関する項を参照してください。

ノート:

また、Fusion Middleware Controlを使用して、OHSを管理対象サーバーにリンクできます。Oracle Fusion Middlewareの管理のコンポーネントを一緒にワイヤリングする方法を参照してください。

次のサンプルは、mod_wl_ohs.confエントリを示します。 

LoadModule weblogic_module PRODUCT_HOME/modules/mod_wl_ohs.so
 
<IfModule mod_weblogic.c>
 WebLogicCluster apphost1.example.com:7050, apphost2.example.com:7050
 MatchExpression *.jsp
 </IfModule>
 
<Location /weblogic>
 SetHandler weblogic-handler
 WebLogicCluster apphost1.example.com:7050,apphost2.example.com:7050
 DefaultFileName index.jsp
</Location>

<Location /console>
 SetHandler weblogic-handler
 WebLogicCluster apphost1.example.com
 WebLogicPort 7003
</Location>

この例は、管理対象サーバーにリクエストをルーティングする2つの方法を示しています。

  • <ifModule>ブロックでは、*.jspで終わるすべてのリクエストがAPPHOST1およびAPPHOST2上にあるWebLogic管理対象サーバーのクラスタに送信されます。

  • <Location>ブロックでは、/weblogicの接頭辞を持つURLのすべてのリクエストがAPPHOST1およびAPPHOST2上にある管理対象サーバーのクラスタに送信されます。

SSL終端使用時のmod_wl_confの構成

SSL終端を使用しており、なおかつWebLogicにリクエストをルーティングしている場合は、追加の構成ステップを実施する必要があります。

SSL終端を使用している場合にmod_wl_confを構成するには:

  1. WebLogicコンソールで、「WebLogicプラグインの有効化」が、ドメイン、クラスタ、または管理対象サーバーのレベルでtrueに設定されていることを確認します。
  2. これらの行を、管理対象サーバーにリクエストを転送するLocationブロックに追加します。
    WLProxySSL ON
WLProxySSLPassThrough ON

たとえば:

<Location /weblogic>
 SetHandler weblogic-handler
 WebLogicCluster apphost1.example.com:7050,apphost2.example.com:7050
 WLProxySSL On
 WLProxySSLPassThrough ON
 DefaultFileName index.jsp
</Location>

WebLogicプラグインを有効化した後、管理サーバーを再起動します。

proxy.confファイルの作成

外部ロード・バランサを使用していない場合は、ロード・バランシング用にOracle HTTP Server仮想ホスト・プロキシを構成できます。

これを行うには、構成ファイルをproxy.confなどの名前で次の場所に別途作成します:

  • MW_HOME/user_projects/domains/DOMAIN_NAME/config/fmwconfig/components/OHS/INSTANCE_NAME/
  • MW_HOME/user_projects/domains/DOMAIN_NAME/config/fmwconfig/components/OHS/instances/INSTANCE_NAME/

新規に作成した構成ファイル(両方の場所)に次のスニペットを追加します:

LoadModule lbmethod_byrequests_module
"${PRODUCT_HOME}/modules/mod_lbmethod_byrequests.so"

<VirtualHost myohs.com:8080>

   # Proxy : HTTP - HTTP
   <Proxy "balancer://ha">
      ProxySet lbmethod=byrequests
      BalancerMember http://OHS_Host1:Port
      BalancerMember http://OHS_Host1:Port
   </Proxy>

   # Proxy pass : HTTP - HTTP
   ProxyPass        "/ha"   "balancer://ha"
   ProxyPassReverse "/ha"   "balancer://ha"

</VirtualHost>

この構成ファイル(proxy.conf)をhttpd.confファイルに追加します。

WEBHOST2へのOracle HTTP Serverのインストールと検証

WEBHOST2上にOracle HTTP Serverをインストールする方法については、Oracle Fusion Middleware Oracle HTTP Serverのインストールと構成のOracle HTTP Serverソフトウェアのインストールを参照してください。

Oracle HTTP Serverホーム・ページにアクセスする次のURLを使用して、WEBHOST2上のインストールを確認します。

http://webhost2:7777/

親トピック: 高可用性のためのOracle HTTP Serverの構成

OHS高可用性デプロイメントの構成と検証

OHS高可用性デプロイメントを構成および検証するには、mod_wl_ohs.confを更新し、テスト用URLを使用してOHS構成を検証します。

親トピック: 高可用性のためのOracle HTTP Serverの構成

WEBHOST2での仮想ホストの作成

DOMAIN_HOME/config/fmwconfig/components/OHS/コンポーネント名ディレクトリに置かれているmod_wl_ohs.confファイルを更新します。

管理サーバーを再起動して、ドメインのすべてのOHSインスタンスに変更を伝搬する必要があります。

Oracle HTTP Serverの構成の検証

特定のURLを使用してOHS構成を検証します。

http://myapp.example.com/

https://myapp.example.com (SSL/SSLターミネーションを使用している場合)

http://myapp.example.com:7777/weblogic