| Oracle® Fusion Middleware高可用性ガイド 12c (12.1.3.0.0) E56218-02 |
|
 前 |
 次 |
Oracle Fusion MiddlewareのWeb層は、エンド・ユーザーに最も近い、アーキテクチャの最も外側にあります。Web層のコンポーネントの主要なコンポーネントはOracle HTTP Serverです。この章では、Oracle HTTP Serverの高可用性の概要と構成手順について、次の各項で説明します。
Oracle HTTP Server (OHS)は、Oracle Fusion MiddlewareのWebサーバー・コンポーネントです。それは、Oracle WebLogic Server用のリスナーと、静的ページ、動的ページおよびWeb上のアプリケーションをホストするフレームワークを提供します。
|
関連項目: OHSの操作の詳細は、次の各項を参照してください。
|
Oracle HTTP Serverは、Apacheインフラストラクチャをベースとしており、Oracle HTTP Serverのコア機能を拡張するためにOracleが開発したモジュールが含まれます。Oracle HTTP Serverには、クライアント・リクエストを処理するための次のコンポーネントが含まれます。
HTTPリスナー: 受信リクエストを処理し、これを適切な処理ユーティリティにルーティングします。
モジュール(mod): Oracle HTTP Serverの基本機能を実装および拡張します。標準的なApacheモジュールの多くは、Oracle HTTP Serverに組み込まれています。また、Oracle HTTP Serverと他のOracle HTTP Serverコンポーネントとの統合をサポートする、Oracle HTTP Serverに固有のモジュールも含まれています。
Oracle HTTP Serverは、フォワード・プロキシ・サーバーにも、リバース・プロキシ・サーバーにもなります。リバース・プロキシでは、様々なサーバーで処理されたコンテンツを1つのサーバーから送信されたように処理することができます。
Oracle HTTP ServerにとってOracle WebLogicドメインは必須ではありませんが、通常はOracle WebLogicドメインと組み合せて使用します。Oracle HTTP Serverを管理コンソールに組み込むことにより一元的な管理やモニタリングが実現するため、Oracle HTTP ServerはWebLogicドメインと関連付けることをお薦めします。
WebLogic管理対象サーバーへのリンクは、mod_wl_ohsモジュールを介して処理されます。このモジュールは、特定のタイプ(JSPなど)のリクエストのルーティング、およびURL、つまり特定の管理対象サーバーへのリクエストのルーティングによって構成されています。
一般に、Oracle HTTP ServerはWebLogic Serverクラスタのフロントエンドに使用します。Oracle HTTP ServerをWebLogic Serverクラスタのフロントエンドにする場合、WebLogicClusterという特殊なmod_wl_ohsディレクティブにより、クラスタ・メンバーをカンマ区切りリストで指定します。このプロセスは次のように機能します。
管理対象サーバーを必要とするリクエストがmod_wl_ohsで受信されると、そのリクエストは、ディレクティブにリストされているWebLogicクラスタ・メンバーの1つに送信されます。少なくとも1つ以上のサーバーが使用可能な状態になっており、リクエストに対応する必要があります。
管理対象サーバーがリクエストを受信すると、そのリクエストを処理して、クラスタ・メンバーの完全なリストをmod_wl_ohsに送り返します。
mod_wl_ohsディレクティブがその更新されたリストを受信すると、未知のサーバーが既知のサーバーのリストに動的に追加されます。これにより、後続のリクエストはすべて完全なクラスタ・メンバー・リスト間でロード・バランシングされます。このプロセスは、mod_wl_ohsを更新したりOracle HTTP Serverを追加しなくても、新しい管理対象サーバーをクラスタに追加できるというメリットがあります。
|
注意: 未知のサーバーが既知のサーバーのリストに追加されるかどうかは、 |
|
注意: 開始時に現行のすべての管理対象サーバーを |
|
関連項目: 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処理モデルに関する項を参照してください。 |
Oracle HTTP Serverの起動、停止および再起動は、Fusion Middleware ControlまたはWebLogic Scripting Tool (WLST)を使用して実行できます。WLSTの使用を予定している場合は、『Oracle Fusion Middleware管理者ガイド』のOracle WebLogic Scripting Tool (WLST)の使用のスタート・ガイドを参照してください。
|
関連項目: OHSの起動と停止の詳細は、『Oracle HTTP Server管理者ガイド』のOracle HTTP Serverの起動、停止および再起動に関する項を参照してください。 |
図9-1は、ロード・バランサの後方に配置された2つのOracle HTTP Serverを示しています。
ロード・バランサは、ユーザーからリクエストを受信して、それを接続されたOracle HTTP Serverに転送します。図9-1のロード・バランサでは、標準的なHTTP/HTTPSポート(80/443)でリクエストを受信しています。しかし、Oracle HTTP Serverにリクエストを渡すときは、まったく別のポートを使用します。この設定には、次の利点があります。
ユーザーからは実際のポートが見えなくなります。
ユーザーは、ポート番号をURLに付加する必要がなくなります。
Unixベースのシステムでは、Oracle HTTP Serverをroot権限で起動する必要はありません。1024未満のポートを使用するプロセスを起動できるのは、rootのみです。ただし、1024未満のポート番号を使用するプロセスを起動するには、root権限が必要です。
ロード・バランサは、稼働中のOracle HTTP Serverにリクエストをルーティングします。
図9-1には、Oracle HTTP ServerからWebLogic管理対象サーバーにリクエストが分散される仕組みも示しています。高可用性の場合、コンポーネントの各ペア(Oracle HTTP ServerとWebLogic管理対象サーバー)は、別のホスト・コンピュータに存在することを前提としています。図9-1では、管理対象サーバーは同じクラスタに存在しています。管理対象サーバー間でロード・バランシングするには、それらのサーバーが同じクラスタに存在する必要があります。
Oracle HTTP Serverの障害は、プロセス障害とノード障害という2つのカテゴリに分類できます。プロセス障害は、個々のオペレーティング・システムで発生する可能性があります。一方、ノード障害は、Oracle HTTP Serverを実行しているホスト・コンピュータ全体の障害に及ぶ可能性があります。この項では、障害タイプと、それらが発生したときのシステムまたはプロセスの引継ぎについて説明します。
プロセス障害
ノード・マネージャは、Oracle HTTP Serverプロセスの保護と監視を行います。Oracle HTTP Serverプロセスに障害が発生すると、ノード・マネージャによって自動的にプロセスが再起動されます。
ノード障害
ノード全体に障害が発生したときに、1つ目のOracle HTTP Serverが応答しない場合、またはURLのpingを使用して障害が発生していると判断された場合は、その前面にあるロード・バランサによってリクエストが別のOracle HTTP Serverに送信されます。
WebLogic管理対象サーバーの障害
高可用性デプロイメントでは、Oracle WebLogic管理対象サーバーはクラスタの一部になります。管理対象サーバーのいずれかに障害が発生した場合、mod_wl_ohsによってアクティブなクラスタ・メンバーのいずれかにリクエストが自動的にリダイレクトされます。アプリケーションに状態が格納されている場合、状態のレプリケーションがクラスタ内で使用可能になり、これにより、リダイレクトされたリクエストが、同じ状態情報にアクセスできます。
データベース障害
通常、データベース障害が問題となるのはmod_oradavまたはmod_plsqlを使用しているときのみです。このデータベースがOracle Real Application Clusters (Oracle RAC)データベースの場合は、定義済のOracle RAC接続により障害の特性が判断されます。
クライアント接続のフェイルオーバーが構成されている場合、進行中のすべてのトランザクションはロールバックされ、データベースへの再接続が必要になります。
透過的アプリケーション・フェイルオーバー(TAF)が構成されている場合は、進行中のすべてのデータベースの書込みはロールバックされますが、データベースへの再接続が自動的に行われ、select文は自動的にリカバリされます。このシナリオでは、TAFはselect文のみをフェイルオーバーし、パッケージ変数は失われます。TAFはJava Database Connectivity (JDBC) Oracle Call Interfaceドライバの機能です。この機能により、接続先のデータベース・インスタンスに障害が発生した場合でも、アプリケーションはデータベースに自動的に再接続できます。この場合、アクティブ・トランザクションはロールバックされます。
構成ウィザードを使用してOracle HTTP Server (OHS)のを構成し、かつOHSがドメインの一部である場合、各インスタンスごとにmod_wl_ohs.confファイル(DOMAIN_HOME/config/fmwconfig/components/OHS/コンポーネント名ディレクトリに置かれている)を更新します。管理サーバーを再起動して、ドメインのすべてのOHSインスタンス(たとえそれらが別のホストにある場合でも)に変更を伝搬します。
|
注意: OHSインスタンスを別々のドメインにインストールおよび構成する場合、変更を他のOracle HTTP Serverに手動でコピーする必要があります。すべてのOHSインスタンスに変更が適用されていることと、それらのインスタンスが同期されていることを確認する必要があります。 |
この項では、Oracle HTTP Serverの高可用性デプロイメントの構成方法について、例を挙げて説明します。
この項の内容は次のとおりです。
Oracle HTTP Serverの高可用性デプロイメントを構成する前に、次の前提条件を確認します。
Oracle HTTP Serverにリクエストを分散させるには、使用可能なOracle HTTP Server間でHTTP(S)リクエストを分散させるために、外部ロード・バランサを使用する必要があります。外部ロード・バランサを使用している場合は、第2.1.1項「サード・パーティ製のロード・バランサの要件」で説明した次の機能を備えている必要があります:
仮想サーバー名とポートの構成
プロセス障害の検出
Oracle HTTPおよびHTTPSのためにポート(HTTP、HTTPS)のモニタリング
SSLプロトコル交換(必要な場合)
次の項では、ロード・バランサを構成する手順について説明します。
ロード・バランサの仮想サーバー名とポートの構成
myapp.example.comなどの各アプリケーションに対して、ロード・バランサの仮想サーバー名および関連するポートを構成します。Oracle HTTP Serverのインストールでは、これらの仮想サーバーは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上にOracle HTTP Serverをインストールする方法については、『Oracle Fusion Middleware Oracle HTTP Serverのインストールと構成』のOracle HTTP Serverソフトウェアのインストールに関する項の手順を参照してください。
OHSインストールの検証
次のOracle HTTP Serverホーム・ページにアクセスするURLを使用して、インストールを確認します。
http://webhost1:7777/
使用するそれぞれの仮想ホストまたはサイト名に対して、Oracle HTTP Serverの構成にエントリを追加します。次のように、ORACLE_HOME/config/fmwconfig/components/OHS/コンポーネント名/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>
|
注意: 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プラグインを有効化した後、管理サーバーを再起動します。 |
この例は、管理対象サーバーにリクエストをルーティングする2つの方法を示しています。
<ifModule>ブロックでは、*.jspで終わるすべてのリクエストがApphost1およびApphost2上にあるWebLogic管理対象サーバーのクラスタに送信されます。
<Location>ブロックでは、/weblogicで始まるURLのすべてのリクエストがApphost1およびApphost2上にある管理対象サーバーのクラスタに送信されます。
WEBHOST2上にOracle HTTP Serverをインストールする方法については、『Oracle Fusion Middleware Oracle HTTP Serverのインストールと構成』のOracle HTTP Serverソフトウェアのインストールに関する項の手順を参照してください。
OHSインストールの検証
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
