| Oracle® Fusion Middleware高可用性ガイド 12c (12.2.1.0.0) E69925-01 |
|
 前 |
 次 |
Oracle Fusion MiddlewareのWeb層は、エンド・ユーザーに最も近い、アーキテクチャの最も外側にあります。この項の内容は次のとおりです。
Oracle HTTP Server (OHS)は、Oracle Fusion MiddlewareのWebサーバー・コンポーネントで、主要なWeb層コンポーネントです。それは、Oracle WebLogic Server用のリスナーと、静的ページ、動的ページおよびWeb上のアプリケーションをホストするフレームワークを提供します。
|
関連項目: OHSの操作の詳細は、次を参照してください。
|
Oracle HTTP Server (OHS)は、Apacheインフラストラクチャをベースとしており、OHSのコア機能を拡張するためのOracleモジュールが含まれます。Oracle HTTP Serverには、クライアント・リクエストを処理するための次のコンポーネントが含まれます。
HTTPリスナー: 受信リクエストを処理し、これを適切な処理ユーティリティにルーティングします。
モジュール(mod): OHS機能を実装および拡張します。Oracle HTTP Serverには、多数の標準Apacheモジュールが含まれます。OHSおよびOHSコンポーネント統合をサポートするOHS固有のモジュールも含まれます。
Oracle HTTP Serverは、フォワード・プロキシ・サーバーにも、リバース・プロキシ・サーバーにもなります。リバース・プロキシでは、様々なサーバーで処理されたコンテンツを1つのサーバーから送信されたように処理することができます。
Oracle HTTP ServerにとってOracle WebLogicドメインは必須ではありませんが、通常はOracle WebLogicドメインと組み合せて使用します。OHSを管理コンソールに組み込むことにより一元的な管理やモニタリングが実現するため、OHSはドメインと関連付けることをお薦めします。
mod_wl_ohsモジュールは、管理対象サーバーへのリンクを処理します。このモジュールは、特定のタイプ(JSPなど)のリクエストのルーティング、または特定の管理対象サーバーへのURL対するリクエストのルーティングによって構成されています。
Oracle HTTP Serverは、通常、クラスタのフロントエンド処理を行います。この構成では、特殊なmod_wl_ohsディレクティブ、WebLogicClusterにより、クラスタ・メンバーをカンマ区切りリストで指定します。
次の手順では、mod_wl_ohsディレクティブ・プロセスを説明します。
管理対象サーバーへのリクエストがmod_wl_ohsで受信されると、そのリクエストは、ディレクティブのクラスタ・メンバーの1つに送信されます。少なくとも1つの管理対象サーバーが、要求を満たすために使用できる必要があります。
管理対象サーバーがリクエストを受信すると、そのリクエストを処理して、クラスタ・メンバーの完全なリストをmod_wl_ohsに送り返します。
mod_wl_ohsがその更新されたリストを受信すると、未知のサーバーが既知のサーバーのリストに動的に追加されます。これにより、後続のリクエストはすべてクラスタ・メンバー・リスト間でロード・バランシングされます。これは、mod_wl_ohsを更新またはOHSを追加せずに、新しい管理対象サーバーがクラスタに追加されるという利点があります。
|
注意: 未知のサーバーが既知のサーバーのリストに追加されるかどうかは、mod_wl_ohsディレクティブDynamicServerListによって制御されます。動的なサーバーの追加を有効にするには、DynamicServerListをONに設定する必要があります。 |
|
注意: 開始時に、すべての現行の管理対象サーバーをmod_wl_ohsディレクトリに含める必要はありません。高可用性設定では、リスト内に2つのクラスタ・メンバーさえいれば、最初の呼出しが機能します。OHSの高可用性デプロイメントを実行する方法の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverプロキシ・プラグインの使用』のOracle HTTP Server用のWebLogicプロキシ・プラグインの構成に関する項を参照してください。 |
|
関連項目: Oracle WebLogicクラスタの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使用』を参照してください。 |
Oracle HTTP Serverが起動すると、HTTP(S)リクエストのリスニングおよび応答の準備が整います。
Microsoft Windowsシステムでのリクエスト処理モデルは、UNIXシステムでのモデルとは異なります。
Microsoft Windowsの場合、1つの親プロセスと1つの子プロセスが存在します。子プロセスは、クライアント・リクエストを処理するスレッドを作成します。作成されるスレッド数は静的で、パフォーマンスに応じて構成できます。
UNIXでは、複数の子プロセスを管理する1つの親プロセスがあります。子プロセスは、リクエストを処理します。親プロセスは、構成に基づき、必要に応じて追加の子プロセスを作成します。
|
関連項目: OHS処理モデルの詳細は、『Oracle HTTP Server管理者ガイド』の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管理者ガイド』のOracle HTTP Serverの基本タスクの実行に関する項を参照してください。 |
次の図は、ロード・バランサの後方に配置された2つのOracle HTTP Serverを示しています。
ロード・バランサは、ユーザーからリクエストを受信して、それを接続されたOracle HTTP Serverに転送します。ロード・バランサは、リクエストを標準HTTP/HTTPSポート(80/443)で受信します。しかし、Oracle HTTP Serverにリクエストを渡すときは、まったく別のポートを使用します。この設定の利点は、次のとおりです。
ユーザーからは実際のポートが見えなくなります。
ユーザーは、ポート番号をURLに付加する必要がなくなります。
UNIXベースのシステムでは、root権限でのOHSの起動は必須ではありません。1024未満のポートを使用するプロセスを起動できるのは、rootのみです。ただし、1024未満のポート番号を使用するプロセスを起動するには、root権限を使用してプロセスを起動する必要があります。
ロード・バランサは、稼働中のOracle HTTP Serverにリクエストをルーティングします。
前述の図は、OHSから管理対象サーバーにリクエストが分散される仕組みも示しています。高可用性の場合、コンポーネントの各ペア(OHSと管理対象サーバー)は、別のホスト・コンピュータに存在する必要があります。管理対象サーバーは同じクラスタに存在しています。管理対象サーバー間でロード・バランシングするには、それらのサーバーが同じクラスタに存在する必要があります。
Oracle HTTP Serverでは、プロセス障害とノード障害の2つのタイプの障害が発生します。プロセス障害は、個々のオペレーティング・システムで発生する可能性があります。一方、ノード障害は、Oracle HTTP Server (OHS)を実行しているホスト・コンピュータ全体の障害に及ぶ可能性があります。
Table 9-1 OHS障害タイプと障害保護
| 障害タイプ | 保護 |
|---|---|
|
プロセス |
ノード・マネージャは、OHSプロセスの保護と監視を行います。OHSプロセスに障害が発生すると、ノード・マネージャによって自動的にプロセスが再起動されます。 |
|
ノード |
OHSの前面のロード・バランサは、最初のOHSが応答しない、またはURLピングが障害は発生したことを示している場合、別のOHSにリクエストを送信します。 |
|
管理対象サーバー |
クラスタ内で管理対象サーバーに障害が発生すると、 |
|
データベース |
通常、 クライアント接続フェイルオーバーが構成されている場合、進行中のトランザクションがロールバックされます。データベースが接続されている必要があります。 透過的アプリケーション・フェイルオーバー(TAF)が構成されている場合は、進行中のすべてのデータベースの書込みはロールバックされますが、データベースへの再接続が自動的に行われ、select文は自動的にリカバリされます。TAFはselect文のみをフェイルオーバーし、パッケージ変数は失われます。TAFのJDBC Oracle Call Interfaceドライバ機能により、接続先のデータベース・インスタンスに障害が発生した場合でも、アプリケーションはデータベースに自動的に再接続できます。この場合、アクティブ・トランザクションはロールバックされます。 |
構成ウィザードを使用してOracle HTTP Server (OHS)を構成し、OHSがドメインの一部である場合、各インスタンスのmod_wl_ohs.confファイルを更新します。ファイルは、DOMAIN_HOME/config/fmwconfig/components/OHS/componentNameディレクトリ内にあります。管理サーバーを再起動して、ドメインのすべてのOHSインスタンス(たとえそれらが別のホストにある場合でも)に変更を伝搬します。
|
注意: OHSインスタンスを別々のドメインにインストールおよび構成する場合、変更を他のOracle HTTP Serverに手動でコピーする必要があります。すべてのOHSインスタンスに変更が適用されていることと、それらのインスタンスが同期されていることを確認する必要があります。 |
この項では、Oracle HTTP Server (OHS)の高可用性デプロイメントの構成方法について、例をあげて説明します。
この項の内容は次のとおりです。
Oracle HTTP Serverの高可用性デプロイメントを構成する前に、次の前提条件を考慮します。
Oracle HTTP Serverにリクエストを分散させるには、使用可能なOracle HTTP Server間でHTTP(S)リクエストを分散させるために、外部ロード・バランサを使用する必要があります。外部ロード・バランサを使用している場合は、第2.2.2項「サード・パーティ製のロード・バランサの要件」で説明する機能を備えている必要があります。
OHSのインストールでは、これらの仮想サーバーはHTTP接続に対して構成され、この接続はHTTPサーバー全体に分散されます。
サイトでHTTPおよびHTTPS接続のリクエストを処理する場合は、HTTPSリクエストはロード・バランサで終了し、そのリクエストをHTTPリクエストとして通過させることをお薦めします。これを行うには、ロード・バランサでプロトコルを変換できることが必要です。また、永続HTTPセッションを実行できるように構成する必要があります。
この例では、ロード・バランサが次のように構成されていると想定します。
仮想ホスト: Myapp.example.com
仮想ポート: 7777
サーバー・プール: Map
サーバー: WEBHOST1、Port 7777、WEBHOST2、Port 7777
多くのOracle Fusion Middlewareコンポーネントおよびサービスはポートを使用します。管理者は、これらのサービスが使用するポート番号を把握し、1つのホスト・コンピュータ上の2つのサービスによって同じポート番号が使用されないようにする必要があります。
ほとんどのポート番号は、インストール中に割り当てられます。Oracle HTTP ServerからOracle WebLogic Serverに送信されるすべてのトラフィックは、すべてのファイアウォールを通じてアクセスできることが重要です。
WEBHOST1上にOHSをインストールする方法については、『Oracle Fusion Middleware Oracle HTTP Serverのインストールと構成』のOracle HTTP Serverソフトウェアのインストールに関する項の手順を参照してください。
OHSホーム・ページにアクセスする次のURLを使用して、インストールを確認します。
http://webhost1:7777/
使用するそれぞれの仮想ホストまたはサイト名に対して、OHSの構成にエントリを追加します。次のように、ORACLE_HOME/config/fmwconfig/components/OHS/componentName/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 Oracle Fusion Middlewareの管理』のコンポーネントを一緒にワイヤリングする方法に関する項を参照してください |
Oracle HTTP Serverのインストールと構成を終えたら、DOMAIN_HOME/config/fmwconfig/components/OHS/コンポーネント名ディレクトリにあるmod_wl_ohs.confファイルを編集して、定義済の管理対象サーバーにそれをリンクします。
mod_wl_ohs.confファイルを編集する方法の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverプロキシ・プラグイン12.1.2の使用』のOracle HTTP Server用のWebLogicプロキシ・プラグインの構成に関する項を参照してください。
|
注意: また、Fusion Middleware Controlを使用して、OHSを管理対象サーバーにリンクできます。『Oracle Fusion Middleware 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ターミネーションを使用しており、なおかつWebLogicにリクエストをルーティングしている場合は、次の追加の構成手順が必要です。
WebLogicコンソールで、「WebLogicプラグインの有効化」が、ドメイン、クラスタ、または管理対象サーバーのレベルでtrueに設定されていることを確認します。
これらの行を、管理対象サーバーにリクエストを転送する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プラグインを有効化した後、管理サーバーを再起動します。
WEBHOST2上にOracle HTTP Serverをインストールする方法については、『Oracle Fusion Middleware Oracle HTTP Serverのインストールと構成』のOracle HTTP Serverソフトウェアのインストールに関する項を参照してください。
Oracle HTTP Serverホーム・ページにアクセスする次のURLを使用して、WEBHOST2上のインストールを確認します。
http://webhost2:7777/
OHS高可用性デプロイメントの構成と検証は、次の手順で実行します。
DOMAIN_HOME/config/fmwconfig/components/OHS/コンポーネント名ディレクトリに置かれているmod_wl_ohs.confファイルを更新します。管理サーバーを再起動して、ドメインのすべてのOHSインスタンスに変更を伝搬する必要があります。
次のURLを使用して構成を検証します。
http://myapp.example.com/
https://myapp.example.com (SSL/SSLターミネーションを使用している場合)
http://myapp.example.com:7777/weblogic
