| Oracle® Fusion Middleware高可用性ガイド 11g リリース1 (11.1.1) B55898-08 |
|
 前 |
 次 |
Web層は、それぞれの受信HTTPリクエストを受信し、リクエストされたアプリケーションのビジネス・ロジックの処理を呼び出します。処理結果とモデルの状態に基づいて、次に表示するビューが選択されます。選択されたビューは、表示するクライアントに送信されます。
この章では、Oracle HTTP ServerおよびOracle Web Cacheの高可用性の概要と構成手順について説明します。この章の項目は次のとおりです。
Java EEアプリケーション・サーバーのWeb層は、主にHTTPリクエストとレスポンスの形式で、Webブラウザなどのエンド・ユーザーと対話します。これは、アプリケーション・サーバーでは最も外側の層であり、エンド・ユーザーに最も近くなります。最も高いレベルでは、Web層は次の4つの基本的なタスクを行います。
クライアント・リクエストの解釈
ビジネス・ロジックをカプセル化するオブジェクト(Enterprise Java Beanなど)へのリクエストのディスパッチ
次に表示するビューの選択
次のビューの生成および配信
Web層は、それぞれの受信HTTPリクエストを受信し、リクエストされたアプリケーションのビジネス・ロジックの処理を呼び出します。処理結果とモデルの状態に基づいて、次に表示するビューが選択されます。選択されたビューは、表示するクライアントに送信されます。
Oracle Web Cacheは、Web層に対しコンテンツを認識するサーバー・アクセラレータ、つまりリバース・プロキシであり、Oracle HTTP Serverで実行されるWebサイトのパフォーマンス、スケーラビリティおよび可用性を改善します。
Oracle Web Cacheは、Oracle Fusion Middlewareで提供される主要なキャッシュ・メカニズムです。キャッシュにより、アクセス頻度の高いURLがメモリーに保存されて、Oracle Application Serverで実行するWebサイトのパフォーマンス、スケーラビリティ、および可用性が向上します。
アクセス頻度の高いURLをメモリーに保存することにより、Oracle Web Cacheは、データベース層およびアプリケーションWebサーバーのURLに対して、繰り返しリクエスト処理をする必要がなくなります。静的オブジェクトのみを処理するレガシー・プロキシとは異なり、Oracle Web Cacheでは、1つ以上のアプリケーションWebサーバーで生成されたコンテンツを、静的および動的にキャッシュされます。Oracle Web Cacheでは、レガシー・プロキシより多くのコンテンツをキャッシュできます。これにより、アプリケーションWebサーバーおよびデータベース層の負荷が大幅に削減され、最適なパフォーマンスが得られます。Oracle Web Cacheは外部キャッシュであるため、アプリケーション層内で実行されるオブジェクト・キャッシュよりも、処理が格段に速くなります。
Web Cacheは、HTTP 1.0および1.1の仕様に完全に準拠しているため、ApacheやIISなどの標準的な任意のWebサーバーでホストされるWebサイトの処理速度を向上させることができます。Oracle Fusion Middlewareでは、Oracle Web Cacheは、1つ以上のOracle HTTP Serverインスタンスの前面に配置します。HTTPリクエストに基づいたブラウザへのレスポンスは、Oracle HTTP Serverインスタンスに送られて、Oracle Web Cacheを介して送信されます。Oracle Web Cacheインスタンスでは、標準HTTPプロトコルで送信されたあらゆるWebコンテンツを処理できます。
Oracle HTTP Serverは、Oracle Fusion MiddlewareのWebサーバー・コンポーネントです。Oracle WebLogic Server用のリスナーと、静的および動的なページおよびアプリケーションをホストするフレームワークがWeb経由で提供されます。
Oracle HTTP Serverは、Apache 2.2.10 インフラストラクチャをベースとしており、Oracleが専用に開発したモジュールが含まれます。シングル・サインオン、クラスタ・デプロイメント、高可用性の機能により、Oracle HTTP Serverの操作性が向上します。Oracle HTTP Serverには、クライアント・リクエストを処理する次のコンポーネントがあります。
HTTPリスナー。受信リクエストを処理し、それを処理する適切なユーティリティにルーティングします。
モジュール(mod)。Oracle HTTP Serverの基本的な機能を実装および拡張します。標準的なApacheモジュールの多くは、Oracle HTTP Serverに組み込まれています。また、Oracle HTTP Serverとその他のOracle Fusion Middlewareコンポーネントとの統合をサポートするために、Oracle Fusion Middlewareに固有のモジュールもいくつか組み込まれています。
Perlインタプリタ。 mod_perlを介してOracle HTTP Serverに組み込まれた永続的なPerlのランタイム環境です。
Oracle HTTP Serverにより、開発者は次のような様々な言語およびテクノロジを使用してそのサイトをプログラムできます。
Perl(mod_perlおよびCGIを使用)
C(CGIおよび FastCGIを使用)
C++(FastCGIを使用)
PHP(mod_phpを使用)
Oracle PL/SQL
Oracle HTTP Serverは、フォワードおよびリバースの両方で、プロキシ・サーバーとしても使用できます。リバース・プロキシでは、様々なサーバーで処理されたコンテンツを1つのサーバーから送信されたように処理することができます。
Oracle HTTP Serverは、本質的にはステートレスなアプリケーションです。セッションの状態はブラウザ・ベースのCookieを使用して保持できます。
図9-1は、次のOracle HTTP Serverコンポーネントを示しています。
Oracle Process Manager and Notification Server(OPMN)は、Oracle HTTP Serverを起動、停止および監視するために使用されます。OPMNでは定期的にOracle HTTP Serverをポーリングして、実行中であることを確認します。Oracle HTTP Serverが稼働していない場合は、OPMNによって適切な処置が取られ、障害が発生したコンポーネントは再起動されて、サービスの維持が保証されます。
Oracle HTTP Serverは、業界トップのApache Webサーバーをベースとしています。Oracle HTTP Serverの中核機能は、次のモジュールを使用して拡張できます。
mod_dmsモジュールにより、Oracle Dynamic Monitoring Service(DMS)を使用して、サイトのコンポーネントのパフォーマンスを監視できます。
mod_onsintモジュールにより、Oracle Notification Service(ONS)とOPMNとの統合サポートを提供します。
mod_oradavモジュールは、Cで記述されたOracle Call Interface(OCI)アプリケーションであり、mod_davの実装を拡張します。mod_oradavディレクティブは、ローカル・ファイルまたはOracle Databaseに対する読取りおよび書込みができます。
mod_osslモジュールにより、Oracle HTTP Serverに対する強力な暗号化が有効になります。このOracleモジュールは、サーバーでのSSLの使用を可能にするOracle HTTP Serverへのプラグインです。
mod_ossoモジュールにより、Oracle Single Sign-onを使用できます。
mod_perlモジュールにより、PerlインタプリタがOracle HTTP Serverに組み込まれます。これにより、起動時のオーバーヘッドが排除され、Oracle HTTP Serverを介してPerlアプリケーションにアクセスできます。
mod_plsqlモジュールにより、Oracle HTTP ServerはOracle Databaseに接続され、Oracleストアド・プロシージャを使用してWebアプリケーションを作成できるようになります。
mod_wl_ohsモジュールにより、Oracle HTTP ServerからOracle WebLogic Serverへのリクエストをプロキシ処理できます。
Oracle HTTP Serverに、Oracle WebLogicドメインは必要ありません。ただし、Oracle HTTP Serverは、通常、Oracle WebLogicドメインと連携して使用されます。
Oracle WebLogic管理対象サーバーへのリンクは、モジュールmod_wl_ohsを介して処理されます。このモジュールは、特定のタイプ(JSPなど)のリクエストのルーティング、およびURL、つまり特定のWebLogic管理対象サーバーへのリクエストのルーティングによって構成されています。非高可用性デプロイメントでは、WebLogic管理サーバーが配置されるホスト名およびポートを指定することでこのルーティング先を定義します。
高可用性デプロイメントでは、多くの場合WebLogic管理対象サーバーはまとめてクラスタ化されます。そのようなデプロイメントでは、特殊なmod_wl_ohsディレクティブWebLogicClusterにより、クラスタ・メンバーをカンマ区切りリストで指定します。このリストは、クラスタ・メンバーの完全なリストである必要はありません。WebLogic管理対象サーバーを必要とするリクエストが受信されると、mod_wl_ohsはそのリクエストを、ディレクティブにリストされているWebLogicクラスタ・メンバーの1つに送信します。WebLogic管理対象サーバーがリクエストを受信すると、そのリクエストを処理して、クラスタ・メンバーの完全なリストをmod_wl_ohsに送信して返します。mod_wl_ohsがその更新されたリストを受信すると、未知のサーバーが既知のサーバーのリストに動的に追加され、後続のリクエストはすべて完全なクラスタ・メンバー・リスト間でロード・バランシングされます。このプロセスは、mod_wl_ohsの更新またはOracle HTTP Serverの追加をせずに新しい管理対象サーバーをクラスタに追加できるというメリットがあります。
たとえば、WLS1、WLS2、WLS3で構成されたWebLogicクラスタがあるとします。ここで、WLS1とWLS2はmod_wl_ohsに認識されているとします。
mod_wl_ohsは、まず、リクエストを受信すると、そのリクエストをWLS1またはWLS2のいずれかへの送信を試みます。送信が成功すると、リストは更新され、以降のリクエストに対してWLS3も含まれます。ただし、WLS1とWLS2が使用不可でWLS3が使用可能な場合は、mod_wl_ohsがWLS3の存在を認識する方法がないため、リクエストは拒否されます。
Oracle WebLogicドメインでOracle HTTP Serverを使用する場合、Oracle HTTP ServerとWebLogicドメインを関連付けることをお薦めします。そうすることで、Oracle HTTP ServerをOracle Fusion Middlewareコンソールに組み込み、一元的な管理および監視が可能になります。
Oracle WebLogicクラスタの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使用』を参照してください。
Oracle HTTP Serverプロセスは、OPMNを介して間接的に呼び出されます。OPMNがOracle HTTP Serverを起動するリクエストを受信すると、Oracle HTTP Serverプロセス(httpd)を起動します。
Oracle HTTP Serverが起動すると、HTTP(S)リクエストのリスニングおよび応答の準備が整います。Microsoft Windowsシステム上のリクエスト処理モデルは、UNIXシステム上のものとは異なります。
Microsoft Windowsの場合、1つの親プロセスと1つの子プロセスが存在します。子プロセスは、クライアント・リクエストを処理するスレッドを作成します。作成されるスレッド数は静的で、パフォーマンスに応じて構成できます。
UNIXでは、複数の子プロセスを管理する1つの親プロセスがあります。子プロセスは、リクエストの処理を行います。親プロセスは、構成に基づき、必要に応じて追加の子プロセスを生成します。サーバーには追加の子プロセスを動的に生成する機能がありますが、子プロセスを増加させることなくリクエストを処理できるように、最初に十分な数の子プロセスを起動するようにサーバーを構成しておくことをお薦めします。
Fusion Middleware Controlまたはopmnctlコマンドを使用して、Oracle HTTP Serverを起動および停止できます。
|
注意: Oracle HTTP Serverの管理に |
opmnctlを使用して、次のようにOracle HTTP Serverのステータスを確認できます。
opmnctl status Processes in Instance: instance1 ---------------------------------+--------------------+---------+--------- ias-component | process-type | pid | status ---------------------------------+--------------------+---------+--------- webcache1 | WebCache-admin | 19556 | Alive webcache1 | WebCache | 19555 | Alive ohs1 | OHS | 7249 | Alive
Oracle HTTP Serverは起動時に、親httpdプロセスのプロセスID(PID)をhttpd.pidファイルに書き込みます。デフォルトでは、このファイルは次のディレクトリにあります。
ORACLE_INSTANCE/diagnostics/logs/OHSComponent/ohs1/
管理者は、デーモンを再起動および停止する場合にプロセスIDを使用できます。プロセスが異常終了した場合は、killコマンドを使用してhttpd子プロセスを停止する必要があります。
httpd.confのPidFileディレクティブで、PIDファイルの場所を指定します。
|
注意: UNIXプラットフォームで |
Fusion Middleware Controlを使用してOracle HTTP Serverを起動するには、次の手順を実行します。
Oracle HTTP Serverのホーム・ページへ移動します。
「Oracle HTTP Server」メニューから「コントロール」を選択します。
「コントロール」メニューから「起動」を選択します。
Fusion Middleware Controlを使用してOracle HTTP Serverを停止するには、次の手順を実行します。
Oracle HTTP Serverのホーム・ページへ移動します。
「Oracle HTTP Server」メニューから「コントロール」を選択します。
「コントロール」メニューから「停止」を選択します。
opmnctlを使用して、OracleインスタンスのすべてのOracle HTTP Serverコンポーネントを起動するには、次を実行します。
opmnctl startproc process-type=OHS
opmnctlを使用して、ohs1など、特定のOracle HTTP Serverコンポーネントを起動するには、次を実行します。
opmnctl startproc ias-component=ohs1
opmnctlを使用して、OracleインスタンスのすべてのOracle HTTP Serverコンポーネントを停止するには、次を実行します。
opmnctl stopproc process-type=OHS
opmnctlを使用して、ohs1など、特定のOracle HTTP Serverコンポーネントを停止するには、次を実行します。
opmnctl stopproc ias-component=ohs1
Oracle HTTP Serverは、いくつかのオペレーティング・システム・ファイルを使用して構成されます。Oracle HTTP Serverをデプロイする場合、その構成情報は次のディレクトリ構造に配置されます。
ORACLE_INSTANCE/config/OHS/OHS_NAME/
ORACLE_INSTANCE/config/OHS/OHS_NAME/moduleconf
メインの構成ファイルは、ORACLE_INSTANCE/config/OHS/OHS_NAMEにあるhttpd.confです。その他の構成ファイルはすべて、このメイン・コントロール・ファイルから呼び出されます。
|
注意: http.confファイルには、一般的なincludeディレクティブがあります。そのため、moduleconfディレクトリにある. |
Oracle HTTP Serverには2種類のログ・ファイルがあります。
エラー・ログ。サーバーの問題が記録されます。
アクセス・ログ。アクセスされたコンポーネントとアプリケーション、およびアクセスしたユーザーが記録されます。
Oracle Fusion Middleware Controlまたはテキスト・エディタを使用して、Oracle Fusion Middlewareログ・ファイルを表示できます。Oracle HTTP Serverのログ・ファイルは、次のディレクトリに配置されます。
ORACLE_INSTANCE/diagnostics/logs/OHS/OHS_NAME
ログ・ファイルのデフォルト名は、ohs_name.logです。
Oracle HTTP Serverログ・ファイルの詳細は、『Oracle Fusion Middleware Oracle HTTP Server管理者ガイド』を参照してください。
図9-2は、ロード・バランサの後方に配置された2つのOracle HTTP Serverを示しています。ロード・バランサは、ユーザーからリクエストを受信して、それを接続されたOracle HTTP Serverに転送します。この例では、ロード・バランサは標準のHTTP/HTTPSポート(80/443)でリクエストを受信しますが、完全に別のポートを使用してOracle HTTP Serverにこのリクエストを送ります。これには、次のような利点があります。
ユーザーからは実際のポートが見えなくなります。
ユーザーは、ポート番号をURLに付加する必要がなくなります。
Unixベースのシステムでは、Oracle HTTP Serverをroot権限で起動する必要はありません。1024未満のポートを使用するプロセスを起動できるのは、rootのみです。
ロード・バランサは、稼働中のOracle HTTP Serverにリクエストをルーティングします。
図9-2は、Oracle HTTP ServerがWeb Logic管理対象サーバーにリクエストを分散させるしくみを示しています。高可用性の場合、コンポーネントの各ペア(Oracle HTTP ServerとWeb Logic管理対象サーバー)は、別のホストに存在することを前提としています。
このアーキテクチャは、2つのサーバーに分けられています。また、より複雑な実装では、各コンポーネントは完全に別のサーバーに配置することもできます。
Oracle HTTP Serverの障害は、プロセス障害とノード障害という2つのカテゴリに分類できます。Oracle HTTP Serverに障害が発生すると、個々のオペレーティング・システム・プロセスに障害が発生したり、ノード障害によりホスト全体に影響する場合があります。
プロセス障害
Oracle HTTP Serverプロセスは、Oracle Process Manager and Notification(OPMN)システムによって保護されます。Oracle HTTP Serverプロセスに障害が発生すると、OPMNは自動的にプロセスを再起動します。
ノード障害
ノード全体に障害が発生したときに、1つ目のOracle HTTP Serverが応答しない場合、またはURLのpingを使用して障害が発生していると判断された場合は、その前面にあるロード・バランサまたはOracle Web Cacheがリクエストを別の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文のみをフェイルオーバーし、パッケージ変数は失われます。
Oracle HTTP Serversは、クラスタ化されたフレームワークにはデプロイされません。Oracle HTTPサーバー構成はファイルベースであるため、いずれかのOracle HTTP Serverに対して行われた変更は、その構成において他のOracle HTTP Serverに手動でコピーする必要があります。これは、htdocsディレクトリに格納されている静的HTMLファイルにも適用されます。
この項では、例として、Oracle HTTP Serverの高可用性デプロイメントを構成する前提条件および手順について説明します。
Oracle HTTP Serverの高可用性デプロイメントを構成する前に、次の前提条件を考慮します。
Oracle HTTP Serverにリクエストを分散させるには、外部ロード・バランサまたはOracle Web Cacheの形式でのロード・バランサが必要となります。外部ロード・バランサを使用する場合は、次の機能が必要です。
仮想サーバー名とポートを構成する機能
プロセス障害を検出する機能
Oracle HTTPおよびHTTPSのためにポート(HTTP、HTTPS)を監視する機能
SSLプロトコル交換(必要な場合)
ロード・バランサの仮想サーバー名とポートの構成
myapp.mycompany.comなどの各アプリケーションに対して、ロード・バランサの仮想サーバー名および関連するポートを構成します。Oracle HTTP Serverのインストールでは、これらの仮想サーバーはHTTP接続に対して構成され、この接続はHTTPサーバー全体に分散されます。
サイトでHTTPおよびHTTPS接続のリクエストを処理する場合は、HTTPSリクエストはロード・バランサで終了し、そのリクエストをHTTPリクエストとして通過させることをお薦めします。そのためには、ロード・バランサはプロトコル変換を実行できることが必要です。また、永続HTTPセッションを実行できるように構成する必要があります。
この例では、ロード・バランサが次のように構成されていることを想定します。
仮想ホスト: Myapp.mycompany.com
仮想ポート: 7777
サーバー・プール: Map
サーバー: WEBHOST1、ポート7777、WEBHOST2、ポート7777
ポート番号の管理
多数のOracle Fusion Middlewareコンポーネントおよびサービスではポートが使用されます。管理者として、これらのサービスに使用されるポート番号を把握してから、ホスト上の2つのサービスで同じポート番号を使用しないようにすることが重要です。
ほとんどのポート番号は、インストール時に割り当てられます。Oracle HTTP ServerからOracle WebLogic Serverに送信されるすべてのトラフィックは、すべてのファイアウォールを通じてアクセスできることが重要です。
Oracle Fusion Middleware Web Tier and Plug-ins 11g(11.1.1.1.0)DVDインストールのOracle Universal Installerを、次のように起動します。
UNIXでは、runInstallerコマンドを実行します。
Windowsでは、setup.exeをダブルクリックします。
「ようこそ」画面で「次へ」をクリックします。
「インストール・タイプの選択」画面で、「インストールと構成」を選択して、「次へ」をクリックします。
「インストール場所の指定」画面で、次のインストールの場所を入力します。
/u01/app/oracle/product/FMW/Web1
「前提条件のチェック」画面で、「次へ」をクリックします。
「コンポーネントの構成」画面で、「Oracle HTTP Server」を選択して、「次へ」をクリックします。
|
注意: このインストールをWebLogicドメインに関連付ける場合は、「選択されたコンポーネントとWebLogicドメインの関連付け」チェック・ボックスを選択します。 このインストールをWebLogicドメインに関連付けない場合は、「選択されたコンポーネントとWebLogicドメインの関連付け」チェック・ボックスの選択を解除します。この関連付けは、必要に応じて、インストール後に作成することもできます。 |
「Weblogicドメインの詳細の指定」画面(オプション)で、次の値を入力します。
ドメイン・ホスト名: WebLogic管理サーバーをホストしているサーバーの名前です(例: wladmin.mycompany.com)。
ドメインのポート番号: WebLogic管理サーバーのポートです(例: 7001)。
ユーザー名: WebLogic管理サーバーのユーザーです(例:WebLogic)。
パスワード: 管理サーバーのパスワードです。
「次へ」をクリックします。
「コンポーネントの詳細の指定」画面で、次の値を入力します。
インスタンス・ホームの場所: /u01/app/oracle/admin/web1
ASインスタンス名: web1
OHSコンポーネント名: ohs1
Webcacheコンポーネント名: webcache1
「次へ」をクリックします。
Web Cache管理者パスワード画面で、Web Cache管理者のパスワードを指定します。
有効なパスワード長は、5から30文字です。パスワードは英字で開始し、英数字、アンダースコア(_)、ドル記号($)、またはシャープ記号(#)のみを使用し、少なくとも1つの数字を含める必要があります。
「次へ」をクリックします。
「Web Tierポートの詳細の指定」画面で、次のエントリを含むファイルを作成します。
[OHS]#: OHSコンポーネントのhttp_mainポート
OHSポート = 7777
ファイルを保存し、「構成」ファイル・オプションを使用して、ポートの指定を選択した後に「ファイル名」フィールドでファイル名を指定します。
|
注意: すべてのWeb層のインスタンスで必ずしも同じポート番号にする必要はありませんが、同じにすることをお薦めします。この構成の例では、そのように想定されています。 |
「次へ」をクリックします。
「構成サマリー」画面で、選択した内容が正しいことを確認します。正しくない場合は「戻る」をクリックして前の画面に戻り、修正します。
「インストール」をクリックします。
「構成」画面で、複数の構成アシスタントが連続して開始されます。この処理が終了したら、「次へ」をクリックします。
「インストール完了」画面が表示されます。
「終了」をクリックします。
インストールの確認
次のOracle HTTP Serverホーム・ページにアクセスするURLを使用して、インストールを確認します。
http://webhost1:7777/
使用するそれぞれの仮想ホストまたはサイト名に対して、Oracle HTTP Serverの構成にエントリを追加します。次の内容を含むvirtual_hosts.confというファイルを、ORACLE_INSTANCE/config/OHS/ohs_component_name /moduleconfディレクトリに作成します。
NameVirtualHost *:7777
<VirtualHost *:7777>
ServerName http://myapp.mycompany.com:80
RewriteEngine On
RewriteOptions inherit
UseCanonicalName On
</VirtualHost>
SSL/SSLターミネーション(*)を使用する場合は、次のようになります
NameVirtualHost *:7777
<VirtualHost *:7777>
ServerName https://myapp.mycompany.com:443
RewriteEngine On
RewriteOptions inherit
UseCanonicalName On
</VirtualHost>
Oracle HTTP Serverをインストールして構成したら、ORACLE_INSTANCE/config/OHS/ohs_nameディレクトリにあるmod_wl_ohs.confファイルを編集して、定義済のいずれかのWebLogic管理対象サーバーにOracle HTTP Serverをリンクします。
次にmod_wl_ohs.confエントリの例を示します。
LoadModule weblogic_module ORACLE_HOME/ohs/modules/mod_wl_22.so
<IfModule mod_weblogic.c>
WebLogicCluster apphost1.mycompany.com:7050, apphost2.mycompany.com:7050
Debug ON
WLLogFile /u01/app/oracle/admin/WL1/logs/mod_wl_ohs.log
MatchExpression *.jsp
</IfModule>
<Location /weblogic>
SetHandler weblogic-handler
WebLogicCluster apphost1.mycompany.com:7050,apphost2.com:7050
Debug ERR
WLLogFile /u01/app/oracle/admin/WL1/logs/mod_wl_ohs.log
DefaultFileName index.jsp
</Location>
|
注意: SSLターミネーションを使用しており、なおかつWebLogicにリクエストをルーティングしている場合、次の追加の構成が必要です。 WebLogicコンソールで、「WebLogicプラグインの有効化を、ドメイン、クラスタ、または管理対象サーバーのレベルでtrueに設定する必要があります。 WebLogic管理対象サーバーにリクエストを転送するLocationブロックに、次の行も追加する必要があります。 WLProxySSL ON WLProxySSLPassThrough ON 例: <Location /weblogic> SetHandler weblogic-handler WebLogicCluster apphost1.mycompany.com:7050,apphost2.com:7050 WLProxySSL On WLProxySSLPassThrough ON Debug ERR WLLogFile /u01/app/oracle/admin/WL1/logs/mod_wl_ohs.log DefaultFileName index.jsp </Location> WebLogicプラグインを有効化した後、管理サーバーを再起動します。 |
この例は、Oracle WebLogic管理対象サーバーにリクエストをルーティングする2つの方法を示しています。
<ifModule>ブロックでは、*.jspで終わるすべてのリクエストがApphost1およびApphost2上にあるWebLogic管理対象サーバーのクラスタに送信されます。
<Location>ブロックでは、/weblogicで始まるURLのすべてのリクエストがApphost1およびApphost2上にあるWebLogic管理対象サーバーのクラスタに送信されます。
次のコマンドを使用して、Oracle HTTP Serverを再起動します。
opmnctl restartproc process-type=OHS
WEBHOST2で、第9.2.9.2項「WEBHOST1へのOracle HTTP Serverのインストール」の手順を実行します。
インストールの確認
次のOracle HTTP Serverホーム・ページにアクセスするURLを使用して、インストールを確認します。
http://webhost2:7777/
それぞれの仮想ホストまたはサイト名のエントリに対して、Oracle HTTP Serverの構成にエントリを追加します。virtual_hosts.confファイルをWEBHOST1からWEBHOST2にコピーします。このファイルは、ORACLE_INSTANCE/config/OHS/ohs_component_name/moduleconfディレクトリにあります。
Oracle HTTP Serverをインストールして構成したら、WEBHOST1のORACLE_INSTANCE/config/OHS/ohs_component_nameディレクトリにあるmod_wl_ohs.confファイルをコピーして、定義済のいずれかのWebLogic ServerインスタンスにOracle HTTP Serverをリンクします。
次のコマンドを使用して、HTTP Serverを再起動します。
opmnctl restartproc process-type=OHS
Oracle Web Cacheは、Web層に対しコンテンツを認識するサーバー・アクセラレータ、つまりリバース・プロキシであり、Oracle HTTP Serverで実行されるWebサイトのパフォーマンス、スケーラビリティおよび可用性を改善します。Oracle Web Cacheは、Oracle Fusion Middlewareで提供される主要なキャッシュ・メカニズムです。キャッシュにより、アクセス頻度の高いURLがメモリーに保存されて、Oracle Application Serverで実行するWebサイトのパフォーマンス、スケーラビリティ、および可用性が向上します。アクセス頻度の高いURLをメモリーに保存することにより、Oracle Web Cacheは、データベース層およびアプリケーションWebサーバーのURLに対して、繰り返しリクエスト処理をする必要がなくなります。静的オブジェクトのみを処理するレガシー・プロキシとは異なり、Oracle Web Cacheでは、1つ以上のアプリケーションWebサーバーで生成されたコンテンツを、静的および動的にキャッシュされます。Oracle Web Cacheでは、レガシー・プロキシより多くのコンテンツをキャッシュできます。これにより、アプリケーションWebサーバーおよびデータベース層の負荷が大幅に削減され、最適なパフォーマンスが得られます。Oracle Web Cacheは外部キャッシュであるため、アプリケーション層内で実行されるオブジェクト・キャッシュよりも、処理が格段に速くなります。
Oracle Web Cacheは、HTTP 1.0および1.1の仕様に完全に準拠しています。そのため、ApacheやIISなどの標準的な任意のWebサーバーでホストされるWebサイトの処理速度を向上させることができます。Oracle Fusion Middlewareでは、Oracle Web Cacheは、1つ以上のOracle HTTP Serverインスタンスの前面に配置します。HTTPリクエストに基づいたブラウザへのレスポンスは、Oracle HTTP Serverインスタンスに送られて、Oracle Web Cacheを介して送信されます。Oracle Web Cacheインスタンスでは、標準HTTPプロトコルで送信されたあらゆるWebコンテンツを処理できます。
リバース・プロキシはクライアントからはコンテンツ・サーバーのように見えますが、内部的にはプロキシとしてそのオブジェクトを他のバックエンド・オリジナル・サーバーから取得します。リバース・プロキシは、オリジナル・サーバーのゲートウェイとして機能します。これは、ファイアウォール外部からのリクエストをファイアウォールの後方にあるオリジナル・サーバーに中継し、取得したコンテンツをクライアントに戻します。
図9-3は、リバース・プロキシのWebキャッシュの動作の概要を示しています。Oracle Web CacheのIPアドレスは144.25.190.241であり、アプリケーションWebサーバーのIPアドレスは144.25.190.242です。
ブラウザがOracle Web Cacheと対話する手順は、次のとおりです。
ブラウザはwww.company.com:80というWebサイトにリクエストを送信します。
このリクエストは、このWebサイトのIPアドレスについて ドメイン・ネーム・システム(DNS)へのリクエストを生成します。
DNSは、このサイトのロード・バランサのIPアドレス(144.25.190.240)を返します。
ブラウザは、Webページへのリクエストをロード・バランサに送信します。ロード・バランサは、このリクエストをOracle Web Cacheサーバー(144.25.190.241)に送信します。
リクエストされたコンテンツがキャッシュにあれば、Oracle Web Cacheはそのコンテンツを直接ブラウザに送信します。これは、キャッシュ・ヒットと呼ばれます。
Oracle Web Cacheにリクエストされたコンテンツがない場合、あるいはコンテンツが失効または無効な場合は、そのリクエストをアプリケーションWebサーバー(144.25.190.242)に送ります。これは、キャッシュ・ミスと呼ばれます。
アプリケーションWebサーバーは、Oracle Web Cacheにコンテンツを送信します。
Oracle Web Cacheは、このコンテンツをクライアントに送信して、ページのコピーをキャッシュに保存します。
キャッシュに保存されたページは、無効または期限切れになると削除されます。
Oracle Web Cacheシステム・コンポーネントは、cacheサーバー・プロセスとadminサーバー・プロセスという2つのパフォーマンス指向のネイティブ・プロセスで構成されます。cacheサーバー・プロセスは、クライアントのリクエストを処理し、コンテンツをクライアントに返します。adminサーバー・プロセスは、管理、構成、および監視機能を提供します。
cacheおよびadminサーバー・プロセスは、Oracle Fusion Middleware Oracle Web Cache管理者ガイドの説明に従って、Oracle Process Manager and Notification Server(OPMN)で、Fusion Middleware Control、Oracle Web Cache Managerまたはopmnctlユーティリティを使用して管理します。
OPMNは、cacheおよびadminサーバー・プロセスを直接起動、停止、再起動、および監視します。Oracle Web Cacheの構成が静的に変更された場合は必ず、Oracle Web Cacheのプロセスを停止して再起動する必要があります。
cacheプロセスの実行可能ファイルはwebcachedであり、adminサーバー・プロセスの実行可能ファイルはwebcacheaです。これらの実行可能ファイルは、次のディレクトリにあります。
(UNIX) ORACLE_HOME/webache/bin (Windows) ORACLE_HOME\bin
Oracle Web Cacheを停止すると、すべてのオブジェクトはキャッシュから削除されます。さらに、すべての統計も削除されます。
Oracle Web Cacheを構成したら、Oracle Web Cacheを再起動します。また、administratorのパスワードを変更した場合は、adminサーバーを再起動します。
Oracle Web Cacheを再起動するには、次のいずれかのツールを使用します。
Fusion Middleware Controlまたはopmnctlコマンドライン・ユーティリティを使用して、cacheまたはadminサーバー・プロセスを再起動します。
Oracle Web Cache Managerを使用して、cacheサーバー・プロセスを再起動します。
次のいずれかの構成設定を変更した場合は、cacheおよびadminサーバー・プロセスの両方を再起動する必要があります。
管理ポート・プロパティ
信頼できるサブネット
ユーザーおよびグループID情報
Oracle Web Cacheの起動と停止の詳細は、Oracle Fusion Middleware Oracle Web Cache管理者ガイドを参照してください。
図9-4は、Oracle Web Cache層内でのリクエスト・フローの詳細を示しています。
図9-4に示しているように、Oracle Web Cache層内では次の処理が発生します。
受信したブラウザ・リクエストは、HTTPフォーマットが正しいか分析されます。
そのブラウザ・リクエストはさらに分析され、それがHTTPSフォーマットであるか判断されます。
ブラウザ・リクエストがHTTPSフォーマットの場合は、Oracle Web CacheはSSLを復号化します。
ブラウザ・リクエストがHTTPSフォーマットでない場合は、Oracle Web Cacheはリクエストを解析します。
リクエストが解析されたら、一連の規定済のフィルタリング・ルールによりフィルタされます。
キャッシュ検索が実行され、このHTTPリクエストが以前に送信されキャッシュに残っているかを確認します。
リクエストがキャッシュ内に存在している場合(キャッシュ・ヒット)、リクエストは圧縮され、コンテンツが直接ブラウザに送信されます。
リクエストがキャッシュに存在しない(キャッシュ・ミス)場合は、次のいずれかが実行されます。
リクエストは、直接オリジナル・サーバーに送信されます。
リクエストは、ロード・バランシングされたオリジナル・サーバーに送信します。
ロード・バランシングされたそれぞれのオリジナル・サーバーは、定期的に各Oracle Web Cacheサーバーにpingしてキャッシュの状態をチェックします。ロード・バランサは、受信したリクエストをキャッシュ・クラスタ・メンバー間に分散させます。リクエストされたコンテンツがOracle Web Cacheにない場合、またはコンテンツが失効または無効な場合は、そのリクエストをアプリケーションWebサーバーに送ります。アプリケーションWebサーバーは、Oracle Web Cacheにコンテンツを送信します。Oracle Web Cacheは、このコンテンツをクライアントに送信して、ページのコピーをキャッシュに保存します。
オリジナル・サーバーのかわりに、プロキシ・サーバーはよりセキュアでないゾーン(非武装地帯(DMZ))に配置されます。
キャッシュ・ルールにより、キャッシュするオブジェクトが決定されます。特定のURLに対してキャッシュ・ルールを作成した場合、そのURLにあるオブジェクトは、クライアント・リクエストがあるまでキャッシュされません。クライアントが最初にオブジェクトをリクエストする場合は、Oracle Web Cacheはそのリクエストをオリジナル・サーバーに送信します。このリクエストはキャッシュ・ミスとなります。このURLには関連付けられたキャッシュ・ルールがあるため、Oracle Web Cacheは後続のリクエストのためにそのオブジェクトをキャッシュします。Oracle Web Cacheが同じオブジェクトに対して2回目のリクエストを受信した場合は、Oracle Web Cacheは、キャッシュからクライアントにオブジェクトを返します。このリクエストは、キャッシュ・ヒットとなります。
Oracle Web Cacheを停止すると、すべてのオブジェクトがキャッシュから削除されます。さらに、Oracle Web Cacheは統計を削除してリセットします。
Oracle Web Cacheの構成は、webcache.xmlファイルに保存されます。このファイルは、次のディレクトリにあります。
(UNIX) ORACLE_INSTANCE/instance_name/config/WebCache/webcache_name (Windows) ORACLE_INSTANCE\instance_name\config\WebCache\webcache_name
構成ファイルを管理するために、2つのツールが用意されています。
Fusion Middleware Control
Oracle Web Cache Manager
特定の手順で、webcache.xml構成ファイルの編集が必要にならないかぎり、ファイルの編集はせず、これらのツールを使用してすべての管理タスクを実行します。ファイルを編集すると、設定に一貫性がなくなり、問題が発生する場合があります。
これらのツールの詳細は、Oracle Fusion Middleware Oracle Web Cache管理者ガイドを参照してください。
Oracle Web Cacheでは、イベントやエラーの情報はイベント・ログに記録されます。イベント・ログ・エントリにより、キャッシュに挿入されたオブジェクトの確認や、キャッシュ関連の問題についての警告ができます。Oracle Web Cacheは、リクエストを内部的に保存し、保存した内容をリクエストの最後にまとめて書き出します。リクエストベースのロギングにより、すべてのリクエストはまとめてグループ化されます。
デフォルトでは、Oracle Diagnostic Logging(ODL)テキスト形式のOracle Web Cacheのイベント・ログ・ファイル名はevent_logであり、ODL XML形式の名前はlog.xmlです。
Oracle Web Cacheでは、受信したHTTPリクエストに関する情報はアクセス・ログに記録されます。デフォルトでは、アクセス・ログの名前はaccess_logです。
Oracle Web Cacheではデフォルトで、次のディレクトリにログ・ファイルが保存されます。
(UNIX) ORACLE_INSTANCE/diagnostics/logs/WebCache/<webcache_name> (Windows) ORACLE_INSTANCE\diagnostics\logs\WebCache\<webcache_name>
これらのツールの詳細は、Oracle Fusion Middleware Oracle Web Cache管理者ガイドを参照してください。
次の各項では、Oracle Web Cacheで使用可能な高可用性ソリューションについて説明します。
ほとんどのWebサイトでは、HTTPおよびHTTPSリクエストの負荷を共有する複数のコンピュータ上で稼働する複数のオリジナル・サーバーによって、サービスが提供されています。Oracle Web Cacheで処理できないリクエストは、すべてオリジナル・サーバーに送られます。Oracle Web Cacheでは、使用可能な容量の割合、各オリジナル・サーバーで重み付けされた使用可能な容量の割合を特定して、オリジナル・サーバー間で負荷を分散します。Oracle Web Cacheでは、最も高く重み付けされた使用可能な容量を持つオリジナル・サーバーにリクエストが送信されます。重み付けされた使用可能な容量は、次の式で求められます。
(Capacity - Load) / Capacity
説明:
Capacityは、オリジナル・サーバーが受け入れ可能な同時接続の最大数です。
Loadは、現在使用中の接続数です。
重み付けされた使用可能な容量が複数のオリジナル・サーバーで等しい場合は、Oracle Web Cacheではラウンドロビンを使用してリクエストをオリジナル・サーバーに送信します。ラウンドロビンを使用すると、構成されているサーバーのリストの最初のオリジナル・サーバーがリクエストを受信し、2番目のオリジナル・サーバーが2番目のリクエストを受信します。重み付けされた使用可能な容量が異なる場合、Oracle Web Cacheは、使用可能な容量が最も大きいオリジナル・サーバーにリクエストを送信します。
オリジナル・サーバーの負荷が同じ場合は、オリジナル・サーバーの容量が異なっていても、Oracle Web Cacheはラウンドロビンを使用し続けます。そのため、等しい容量で構成されていなくても、リクエストがオリジナル・サーバーに均等に分散されることもあります。
サイトのロード・バランシングを構成するには、各オリジナル・サーバーの容量を設定し、サイトとサーバー間のマップを1つ作成して、すべての適用可能なオリジナル・サーバーをこのサイトにマップします。
図9-5は、www.company.com:80とwww.server.com:80の2つのサイトを示しています。サイトwww.company.com:80は、アプリケーションWebサーバーcompany-host1とcompany-host2でサポートされ、それぞれの容量は50です。サイトwww.server.com:80は、アプリケーションWebサーバーserver-host1、server-host2、およびserver-host3でサポートされ、それぞれの容量は150、50、50です。
すべてのアプリケーションWebサーバーの初期負荷が0とすると、www.company.com:80とwww.server.com:80へのリクエストは、次のように分散されます。
www.company.com:80へのリクエストは、ラウンドロビンを使用して2つのオリジナル・サーバーに分散されます。
company-host1とcompany-host2へのリクエストは、負荷が等しく維持されるように、2つのオリジナル・サーバーに分散されます。最初のリクエストは、company-host1に送信されます。2番目のリクエストは、company-host1で最初のリクエストを処理中であれば、company-host2に送信されます。3番目以降のリクエストは、最も高く重み付けされた使用可能な容量を持つオリジナル・サーバーに送信されます。
容量が等しい場合、Oracle Web Cacheはラウンドロビンを使用してリクエストを分散させます。
www.server.com:80へのリクエストは、重み付けされた使用可能な容量の割合を使用して3つのオリジナル・サーバーに分散されます。
www.server.com:80への最初のリクエストは、server-host1が構成リストの先頭にあるため、そこに送信されます。2番目のリクエストは、server-host2に送信されます。これは、server-host1が最初のリクエストを処理中であり、重み付けされた使用可能な容量は99.3 %となり、server-host2の重み付けされた使用可能な容量が100 %であるためです。3番目のリクエストは、server-host3に送信されます。これは、server-host2がリクエストを処理中で重み付けされた使用可能な容量は98 %となり、server-host3の重み付けされた使用可能な容量が100 %であるためです。4番目のリクエストは、server-host1に送信されます。これは、server-host2とserver-host3がリクエストを処理中で重み付けされた使用可能な容量が98 %となるためです。5番目のリクエストは、server-host1に送信されます。これは重み付けされた使用可能な容量が98.6 %となり、これがserver-host2とserver-host3それぞれよりも依然として大きいためです。
容量および負荷が異なる場合、Oracle Web Cacheは重み付けされた使用可能な容量を使用してリクエストを分散させます。新しいリクエストを受信する前にリクエストが処理されている場合、3つのオリジナル・サーバーはすべて負荷が0である可能性がありますその場合、Oracle Web Cacheはラウンドロビンを使用します。
容量の指定およびサイト・サーバー間マッピングの作成の詳細は、Oracle Fusion Middleware Oracle Web Cache管理者ガイドを参照してください。
指定された数の連続したリクエストの処理が失敗すると、Oracle Web Cacheはオリジナル・サーバーに障害が発生したとみなします。オリジナル・サーバーに障害が発生すると、Oracle Web Cacheは自動的に残りのオリジナル・サーバー間に負荷を分散させます。また、障害が発生したオリジナル・サーバーにポーリングし、そのサーバーがオンラインに戻るまで、稼働中または停止中かステータスを確認します。障害が発生したオリジナル・サーバーへの既存のリクエストはエラーとなります。ただし、新しいリクエストは、別のオリジナル・サーバーに送信されます。障害が発生したサーバーが再び運用されると、Oracle Web Cacheはそのサーバーを重み付けされた使用可能な容量に加え、リクエストをロード・バランシングします。
障害時のしくみを図9-6に示します。server-host3(障害直前の容量は50)の障害によって、リクエストの75 %がserver-host1に分散され、25 %がserver-host2に分散されます。
フェイルオーバーのしきい値の指定方法は、Oracle Fusion Middleware Oracle Web Cache管理者ガイドを参照してください。
Oracle Web Cacheを構成して、セッション・バインディングをサポートできます。これにより、特定のサイトのユーザー・セッションは、オリジナル・サーバーにバインドされ、一定の期間、状態が保持されます。この機能を使用するには、オリジナル・サーバー自体が状態を維持する(ステートフルである)必要があります。
セッション・バインディングが必要なオブジェクトに対するリクエストがオリジナル・サーバーに転送される場合、オリジナル・サーバーは、セッションCookieの形式でOracle Web Cacheを使用するか、埋込みURLパラメータを使用して、クライアントへのセッション情報を組み込み、ユーザー・セッションを作成します。Oracle Web Cacheでは、パラメータの値またはCookieを処理せず、情報をクライアント・ブラウザに返します。クライアントで後続リクエストにセッション情報が組み込まれた場合、Oracle Web Cacheは、そのリクエストをユーザー・セッションが最初に作成されたオリジナル・サーバーに転送します。Oracle Web Cacheは、ユーザー・セッションをその特定のオリジナル・サーバーにバインドします。
図9-7は、Oracle Web Cacheでセッション・バインディングを使用するオブジェクトをサポートするしくみを示しています。
リクエストのセッション・バインディングを機能させるための手順は次のとおりです。
Oracle Web Cacheは、リクエストを初めて受信したときに、ロード・バランシング機能を使用してリクエストを転送するオリジン・サーバーを決定します。この例では、アプリケーションWebサーバーwww.server2.comが選択されています。
リクエストされたオブジェクトにセッション・バインディングが必要な場合、オリジナル・サーバーは、Cookie形式でOracle Web Cacheを使用するか、埋込みURLパラメータを使用して、セッション情報をクライアントに返します。
Oracle Web Cacheでは、このセッションの後続のリクエストを、ロード・バランシングをバイパスして、セッションを確立したオリジナル・サーバーに送信します。この例では、アプリケーションWebサーバーwww.server2.comで後続のリクエストを処理しています。
キャッシュ・クラスタを構成している場合、セッション・バインディングを構成する際に「内部-トラッキング」メカニズム・オプションは選択しないでください(これは、キャッシュ・クラスタでは機能しません)。キャッシュ・クラスタのその他のメカニズムは機能します。
Oracle Web Cacheでは、キャッシュ・クラスタを介して、クラスタワイドの機能を提供します。キャッシュ・クラスタでは、Oracle Web Cacheの複数のシステム・コンポーネントが1つの論理キャッシュとして機能します。この1つの論理キャッシュをキャッシュ・クラスタ・メンバーといいます。キャッシュ・クラスタ・メンバーは、相互に通信して、別のキャッシュ・クラスタ・メンバーでキャッシュされたキャッシュ可能なコンテンツをリクエストします。また、キャッシュ・クラスタ・メンバーに障害が発生した場合はそれを検出します。
図9-8は、3つのキャッシュ・クラスタ・メンバーを含むOracle Web Cacheクラスタを示しています。この図に示すように、クラスタ・メンバーは相互に通信し、さらにアプリケーションWebサーバーおよびクライアントとも通信します。
Oracle Web Cacheでは、各キャッシュ・インスタンスの相対容量を使用して、キャッシュ・コンテンツをキャッシュ・クラスタ・メンバー間で分散させます。実際には、特定のオブジェクトの所有者になるキャッシュ・クラスタ・メンバーに割り当てられます。このコンテンツを所有されたコンテンツと呼びます。
所有されたコンテンツの他に、Oracle Web Cacheでは、使用頻度の高いオブジェクトも各クラスタ・メンバーのキャッシュに保存されます。これらのオブジェクトは、オンデマンド・コンテンツと呼ばれます。オンデマンド・コンテンツを保存することによって、Oracle Web Cacheがそれらのオブジェクトに対するリクエストに迅速に応答するため、キャッシュ・ミス数が減少します。アプリケーションWebサーバーに送信されるリクエスト数も減少します。そのため、パフォーマンスが改善されます。
キャッシュ・クラスタでは、すべてのクラスタ・メンバーに同期化される1つの構成を使用します。その構成には、セキュリティ、セッション情報、キャッシュ・ルールなど、全般的な情報が含まれます。この構成は、すべてのクラスタ・メンバーで同じ内容になります。これには、容量、管理、その他のポート、リソース制限、ログ・ファイルなど、各クラスタ・メンバーのキャッシュ固有の情報も含まれます。
各メンバーをキャッシュ・クラスタに追加する前には、認証が必要になります。この認証には、Oracle Web Cacheインスタンスの管理ユーザー名とパスワードが必要です。クラスタの管理ユーザー名およびパスワードと同じものを、Oracle Web Cacheインスタンスの管理ユーザー名およびパスワードとして追加する必要があります。
キャッシュをクラスタに追加する場合、新しいクラスタ・メンバーのキャッシュ固有の情報は、キャッシュ・クラスタの構成に追加されます。次に、Oracle Web Cacheは、この構成をクラスタのすべてのメンバーに同期化します。新しいメンバーが追加されると各Webキャッシュの相対容量が変化するため、Oracle Web Cacheは容量に関する情報を使用して、各クラスタ・メンバーで所有するコンテンツを再計算します。
キャッシュ・クラスタ・メンバーで他のクラスタ・メンバーの障害を検出した場合は、残りのキャッシュ・クラスタ・メンバーが自動的に障害メンバーのコンテンツの所有権を引き継ぎます。そのキャッシュ・クラスタ・メンバーに再びアクセスできるようになると、Oracle Web Cacheはコンテンツの所有権を再割当てします。
キャッシュ・クラスタからWebキャッシュを削除する場合は、残りのキャッシュ・クラスタ・メンバーが削除されたメンバーのコンテンツの所有権を引き継ぎます。また、削除されたメンバーに関する構成情報は構成から削除され、修正された構成が残りのキャッシュ・クラスタ・メンバーに同期されます。
キャッシュ・クラスタの構成方法は、第9.3.3.2項「キャッシュ・クラスタの構成」を参照してください。
Oracle Web Cache専用のモードを構成し、Oracle Web CacheをHTTPトラフィックのソフトウェア・ロード・バランサとして単体で使用することができます。この構成モードは、次の用途に有効です。
ボリュームの小さいサイト、部門レベルのサイト、またはテストWebサイトの管理
ハードウェア・ロード・バランサとOracle PortalまたはOracle Single Sign-Onを使用したアプリケーション間のDMZのトラフィックの管理
このモードでは、キャッシュはすべてキャッシュされず、次の機能はサポートされません。
圧縮: Oracle Web Cacheはすべての圧縮設定を無視します。
リクエスト・フィルタリング: Oracle Web Cacheはすべての構成リクエスト・フィルタおよびルールを無視します。
ESI: Oracle Web CacheはESIコンテンツをアセンブルしません。
キャッシュ階層: キャッシュ階層に2つのキャッシュ構成を計画している場合、キャッシュの1つをロード・バランサとして構成しないでください。
単一のOracle Web Cacheサーバーをロード・バランサとしてデプロイできます。ただしこのデプロイメントでは、Oracle Web Cacheサーバーがアプリケーションのシングル・ポイント障害になります。そのかわりに、オペレーティング・システムのロード・バランシング機能と連携し、複数のOracle Web Cacheサーバーを使用してキャッシュ・クラスタを構成できます。この項の前半で説明されている容量の変化に注意してください。
このモードでは、ESIを使用するアプリケーションの前面、または別のOracle Web Cacheの前面で、HTTPトラフィックをロード・バランシングするようにOracle Web Cacheを構成できます。Oracle Web Cacheのロード・バランサでは、ESIコンテンツの処理や階層キャッシュへの参加は行われません。たとえば、一般的なOracle Portalデプロイメントには、ESIアセンブリに使用される組込みのOracle Web Cacheがあります。このような構成では、ESIアセンブリに使用するOracle Web Cacheを、ロード・バランサとして構成しないでください。
キャッシュや圧縮のサポートなど、その他のOracle Web Cacheの機能が必要な場合は、このモードを構成しないでください。かわりに、ハードウェア・ロード・バランサまたはオペレーティング・システムのロード・バランシングのサポートを構成し、ロード・バランシング機能を使用してオリジナル・サーバーへのリクエストを管理します。
このモードの構成方法は、第9.3.3.3項「ソフトウェア・ロード・バランサとしてのOracle Web Cacheの構成」を参照してください。
次の各項では、それぞれの高可用性ソリューションを構成する方法について説明します。
セッション・バインディングを構成するには、一連のセッション・バインディング・ルールを指定して、そのルールをサイトに適用する必要があります。デフォルトでは、サイトはデフォルト・ルールを使用するように構成されます。デフォルト・ルールを使用することもできますが、サイト用にカスタマイズした別のルールを選択することもできます。
デフォルトのセッション・バインディング・ルールの値を変更する場合は、このルールで現在構成されているすべての名前付きサイトには、セッション・バインディングが必要になります。セッション・バインディングが不要なサイトがある場合は、デフォルト・ルールの値は変更せず、かわりにそのサイトに対するセッション・バインディング設定を指定します。
セッション・バインディングを構成するには、次の手順を実行します。
Fusion Middleware Controlで「Webキャッシュ・メンバー」ページにナビゲートします。
「Webキャッシュ」メニューから「管理」を選択して、「セッション構成」を選択します。
「サイト」リストから、カスタマイズされたセッション・バインディングを作成するサイトを選択します。
「グローバル」を選択して、いずれの定義済サイトにも一致しないサイトおよびリクエストに対するデフォルト設定を指定します。カスタマイズされたセッション・バインディングをサイトに指定しない場合は、「グローバル設定を使用」オプションをクリックして、「グローバル」で指定した設定を適用します。「グローバル」のデフォルトの選択は、「セッション・バインディング無効化」です。「サイト」リストから「グローバル」を選択し、その他のセッション・バインディングに関する項目を選択して、デフォルトの設定を変更します。
「セッション定義」表で、セッション定義を作成します。
- グローバル設定を使用: 構成したセッション・バインディング設定を「サイト」リストで選択した「グローバル」に適用する場合は、このオプションを選択します。
デフォルトでは、Oracle Web Cacheはすべてのリクエストに対してセッション・バインディングを無効にします。「グローバル」のデフォルトの選択は、「セッション・バインディング無効化」です。初めてサイトを作成する場合は、デフォルトでグローバル・セッション・バインディング設定を使用するように設定されます。
- セッション・バインディング無効化: セッション・バインディングを無効にする場合は、このオプションを選択します。これは、「グローバル」サイトのデフォルトの選択です。「サイト」リストから「グローバル」を選択し、その他のセッション・バインディングに関する項目を選択して、デフォルトの設定を変更します。
- Set-Cookieを使用したCookieに基づくセッション・バインディング: クライアントでCookieがサポートされ、アプリケーション・サーバーでセッション状態に1つ以上のCookieを使用する場合は、このオプションを選択します。Oracle Web Cacheでは、独自のCookieを使用してセッションを追跡します。このCookieは、ルーティング情報を含んでおり、Oracle Web Cacheとクライアントのブラウザとの間で保持されます。クライアントとアプリケーション・サーバーのバインディングは、アプリケーション・サーバーがクライアントに送信する最初のCookieにより初期化されます。
- セッションを使用したバインド: 特定のセッションのバインディングを有効にするには、このオプションを選択して、次の手順を実行します。
「セッション名」リストから、特定のセッションに対するバインディングを有効にするセッションを選択します。
「セッション・バインディング方式」リストから、選択したセッション定義に対して次のバインディング・メカニズムのいずれかを選択します。
選択したセッション定義に対して次のバインディング・メカニズムのいずれかを選択します。
- Cookieに基づく: クライアントでCookieがサポートされている場合に選択します。Oracle Web Cacheでは、独自のCookieを使用してセッションを追跡します。このCookieは、ルーティング情報を含んでおり、Oracle Web Cacheとクライアントのブラウザとの間で保持されます。
- セッション・バインディングIAS: アプリケーションがOC4Jベースの場合に選択します。Oracle Web Cacheは、Oracle HTTP Serverを介して、各リクエストのルーティング情報をOC4Jに転送します。
- 内部-トラッキング: クライアントでCookieがサポートされておらず、アプリケーションがOracle HTTP ServerおよびOC4Jをベースとしていない場合に選択します。このオプションは、以前のリリースのOracle Web Cacheとの下位互換のために用意されています。Oracle Web Cacheでは、メモリー内ルーティング表を保持します。この表の各エントリでセッションIDとオリジナル・サーバーをマップします。ルーティング表は、クラスタ・ノード間で共有されません。このオプションを選択した場合、キャッシュ・クラスタ構成があると、ロード・バランサ層でもバインドを行う必要があります。
「適用」をクリックして、変更を送信します。
Oracle Web Cacheを再起動します。
キャッシュ・クラスタを構成するには、複数のOracle Web Cacheインスタンスをクラスタ・メンバーとして構成し、クラスタのプロパティを指定します。
キャッシュ・クラスタでは、現在のキャッシュ(クライアント・ブラウザが接続しているキャッシュ)からすべてのクラスタ・メンバーに同期化される1つの構成を使用します。この構成には、すべてのクラスタ・メンバーで同一の設定と、各クラスタ・メンバーのキャッシュ固有の設定が含まれます。
この項の項目は次のとおりです。ここでは、すべてのキャッシュが同じOracle WebLogic Serverに関連付けられる環境におけるキャッシュ・クラスタを構成できます。次の項目では、Fusion Middleware Controlを使用してクラスタを構成する方法について説明します。その環境では、すべてのキャッシュ・メンバーで同じOracle WebLogic Serverを使用する必要があります。
また、クラスタの構成の詳細は、次を参照してください。
複数のキャッシュが、異なるOracle WebLogic Serverと関連付けられている構成に対してキャッシュ・クラスタを構成する場合は、Oracle Fusion Middleware Oracle Web Cache管理者ガイドの手順に従います。
キャッシュ・クラスタは2つ以上のOracle Web Cacheのインスタンスで構成されるため、キャッシュ・クラスタを構成する前に、1つ以上のノードに2つ以上のOracle Web Cacheインスタンスをインストールしておく必要があります。それらのインスタンスは、同じバージョンのOracle Web Cacheにする必要があります。また、Oracle Web Cacheの管理者および無効化用ユーザーinvalidatorの個々のパスワードは、クラスタ・メンバー間で同じにする必要があります。これらのパスワードが異なる場合は、キャッシュのadminサーバーに接続して管理パスワードを変更する必要があります。
構成を容易にするには、次のキャッシュ・クラスタおよびそのメンバーの主要な構成設定を理解します。
キャッシュ・クラスタのフェイルオーバーのしきい値
キャッシュ・クラスタ・プロパティを構成する場合は、フェイルオーバーのしきい値を設定します。この設定は、Oracle Web Cacheが、別のキャッシュ・クラスタ・メンバーで障害が発生したことを認識するまでに許容される連続リクエスト失敗数を表しています。Oracle Web Cacheは、障害の発生したメンバーに対して一定の回数だけ連続して再試行した後で、そのキャッシュ・メンバーが停止しているとみなします。Oracle Web Cacheが再試行できる回数を、フェイルオーバーのしきい値と呼びます。
Oracle Web Cacheは、次の場合に、別のキャッシュ・クラスタ・メンバーへのリクエストが失敗したとみなします。
なんらかのネットワーク・エラーがあった場合
HTTPレスポンス・ステータス・コードが100未満の場合、または、次のいずれかの場合。500: サーバー内部エラー、502: 不正なゲートウェイ、503: サービス使用不可、504: ゲートウェイ・タイムアウト。
失敗した各リクエストに対して、Oracle Web Cacheはそのクラスタ・メンバーの失敗カウンタをインクリメントします。このカウンタは、各クラスタ・メンバー別に保持されます。リクエストがクラスタ・メンバーで正しく処理されると、Oracle Web Cacheは失敗カウンタをリセットします。
フェイルオーバーのしきい値に達すると、Oracle Web Cacheは、そのキャッシュ・クラスタ・メンバーに障害が発生したとみなします。Oracle Web Cacheは残りのキャッシュ・クラスタ・メンバーの相対容量を再計算します。次に、キャッシュ・コンテンツの所有権を再割当てします。
キャッシュ・クラスタ・メンバーが停止すると、Oracle Web Cacheは、そのキャッシュ・クラスタ・メンバーに対してポーリングを開始します。これは、指定したpingのURLにリクエストを送信することで実行されます。Oracle Web Cacheがそのキャッシュ・クラスタ・メンバーから成功レスポンスを受信すると、そのキャッシュ・クラスタ・メンバーが稼働を再開したとみなします。これは、キャッシュ・クラスタ・メンバーの相対容量を再計算し、キャッシュ・コンテンツの所有権を再割当てします。
キャッシュ・クラスタ・メンバーの容量
キャッシュ・クラスタ・メンバーを構成する場合は、そのメンバーの容量を指定します。
Oracle Web Cacheでは、次の2つの方法で容量を使用します。
他のすべてのキャッシュ・クラスタ・メンバーからこのキャッシュ・クラスタ・メンバーへの同時着信接続数に対する絶対容量として。
この接続を使用して、他のキャッシュ・クラスタ・メンバーから、所有されたコンテンツのリクエストを受信します。接続数は、他のクラスタ・メンバー間で分割されます。たとえば、3つのキャッシュ・クラスタがあり、Cache_Aの容量を50とすると、Cache_BとCache_CはCache_Aに対して、それぞれ25ずつ接続を開くことができます。
他のキャッシュ・クラスタ・メンバーのキャッシュにデータがほとんどない、または全くない場合は、より多くの接続が使用されます。たとえば、最初の起動時、障害のリカバリ時、または無効化の後などです。そのような場合、クラスタ・メンバーは多くのリクエストをそのピア(コンテンツの所有者)に送信します。多くの場合、これらのリクエストはオリジナル・サーバーへのリクエストより迅速に処理されます。その場合、接続数が多くなるにつれて、パフォーマンスが向上し、完全にキャッシュをロードする時間が短縮されます。キャッシュが完全にロードされると、使用される接続数は減少します。未使用の接続にオーバーヘッドはありません。
キャッシュ・クラスタ・メンバーの相対容量として。
キャッシュ・クラスタ・メンバーの容量は、すべてのアクティブなキャッシュ・クラスタ・メンバーの合計容量に対して重み付けされます。容量を設定すると、Oracle Web Cacheによって、クラスタ・メンバーに所有権の配列の割合が割り当てられます。これは、クラスタ・メンバーが所有するキャッシュ・コンテンツの量を示します。割合は、次の式を使用して計算されます。
cluster_member_capacity/total_capacity_of_all_active_cluster_members
たとえば、キャッシュ・クラスタ・メンバーCache_Aに100の容量があり、キャッシュ・クラスタ・メンバーCache_Bに300の容量があり、合計で400の容量があった場合、Cache_Aには所有権配列の25 %が割り当てられ、Cache_Bには75 %が割り当てられます。つまり、Cache_Aはキャッシュ・コンテンツの25 %を所有します。
相対容量を計算する場合、Oracle Web Cacheはアクティブなクラスタ・メンバーの容量を考慮し、障害が発生したと判断したクラスタ・メンバーの容量は考慮しません。
それぞれのキャッシュ・クラスタ・メンバーの初期容量は、「最大着信接続数」の設定の10 %に設定します。
アプリケーションの容量の要件およびヒット率に対してより適切な案があれば、容量を微調整します。次の2つの前提がキャッシュ・クラスタに適用される場合、次の式を適用して各クラスタ・メンバーの容量を決定します:
着信トラフィックが、すべてのキャッシュ・クラスタ・メンバーに均等に分散されます。
コンテンツの所有権が、すべてのキャッシュ・クラスタ・メンバー間で均等に分散されます。
次の式で、デフォルト値とmax_incoming_connections式を比較して大きい方の値を選択します。
max(default_value, (max_incoming_connections * (cacheable_misses%/100) * (number_of_caches - 1) / number_of_caches))
この式の各項の内容は、次のとおりです。
default_valueは、次のいずれかの値です。
本番環境の場合、100
テスト環境の場合、30
無効化専用クラスタの場合、0
容量が増加すると、Oracle Web Cacheで必要なファイル記述子の数も増加します。
max_incoming_connectionsは、Fusion Middleware Controlの「リソース制限」ページの「最大着信接続数」設定の値です。
cacheable_misses%は、Oracle Web Cacheからは直接処理されず、Oracle Web Cacheがオリジナル・サーバーからコンテンツをフェッチした後に処理されたキャッシュ可能オブジェクトに対するリクエストの割合です。
「キャッシュ可能ミス」設定は、Fusion Middleware Controlの「Web Cache統計」ページで確認できます。
たとえば、4つのメンバーを持つキャッシュ・クラスタがあるとします。Oracle Web Cacheが最大1500の着信接続を30%のキャッシュ可能なミス率で処理する場合、この構成の容量の計算式は次のようになります。
(1500 * (30/100) * (4 - 1) / 4
計算結果は337.5になります。これを切り上げて338とし、各キャッシュ・クラスタ・メンバーの容量にこの値を入力します。
1500 * .3 * 3 / 4 = 337.5
クラスタ・メンバーの容量に0を割り当てると、そのクラスタ・メンバーは他のクラスタ・メンバーからリクエストを受信しません。ただし、そのクラスタ・メンバーは、他のクラスタ・メンバー、つまりコンテンツの所有者にリクエストを転送します。すべてのクラスタ・メンバーの容量に0を割り当てると、クラスタ・メンバー間でリクエストの転送は行われません。容量が0に設定されていても、構成の同期化は可能です。また、Oracle Web Cacheは、無効化リクエストをクラスタ・メンバーに自動的に伝播します。
キャッシュをクラスタに追加する前に、第9.3.3.2.1項「構成の前提条件」で説明されている条件が満たされていることを確認します。
キャッシュ・メンバーをクラスタに追加するには、次の手順を実行します。
いずれかのOracle Web CacheインスタンスのFusion Middleware Controlで「Webキャッシュ・メンバー」ページに移動します。
「Webキャッシュ」メニューから「管理」を選択して、「クラスタ」を選択します。
追加するそれぞれのキャッシュ・メンバーに、次の手順を実行します。
「追加」をクリックします。
「コンポーネント」フィールドで、各メンバーの名前を入力します。
「容量」フィールドには、デフォルト値が自動的に入力されます。この値は変更できます。容量の詳細は、第9.3.3.2.2項「フェイルオーバーのしきい値および容量設定の理解」を参照してください。
「フェイルオーバーのしきい値」フィールドで、Oracle Web Cacheが別のキャッシュ・クラスタ・メンバーで障害が発生したことを認識するまでに許容される連続リクエスト失敗数を入力します。
デフォルトの失敗数は5です。
このフィールドの詳細は、第9.3.3.2.2項「フェイルオーバーのしきい値および容量設定の理解」を参照してください。
「pingのURL」フィールドに、フェイルオーバーのしきい値に達したキャッシュ・クラスタ・メンバーに、他のキャッシュ・クラスタ・メンバーがアクセスを試行する際に使用するURLを入力します。
キャッシュ可能で、各キャッシュに確実に保存できるURLを使用します。デフォルトは_oracle_http_server_webcache_static_.htmlで、キャッシュに保存されます。
「pingの間隔」フィールドに、クラスタ・メンバーが障害クラスタ・メンバーにアクセスを試行する間隔の時間を秒単位で入力します。
デフォルトの10秒は、多くの環境で妥当な間隔です。
「適用」をクリックします。
キャッシュ・クラスタでは、最初はキャッシュ・クラスタ・メンバーを1つのみ介してリクエストがルーティングされましたが、すべてのキャッシュ・クラスタ・メンバーが、セッションを確立したオリジナル・サーバーを特定できる必要があります。
第9.3.3.2.3項「タスク1: クラスタへのキャッシュの追加とプロパティの構成」で、プロパティを設定したOracle Web Cacheに対して、セッション・バインディング・メカニズムによるセッション・バインディングを構成します。「内部-トラッキング」オプションは、キャッシュ・クラスタでは機能しないため、使用しないでください。
セッション・バインディングを構成するには、第9.3.3.1項「Oracle Web Cacheのセッション・バインディングの構成」を参照してください。
クラスタを変更してそれを適用すると、Oracle Web Cacheにより、新しいキャッシュ・クラスタ・メンバーのキャッシュ固有の情報が構成に追加されます。それらの変更をすべてのクラスタ・メンバーで有効にするには、構成を同期化してクラスタ・メンバーを再起動する必要があります。
新しく追加したキャッシュ・メンバーからクラスタ内の別のキャッシュに構成を同期化するには、次の手順を実行します。
第9.3.3.2.3項「タスク1: クラスタへのキャッシュの追加とプロパティの構成」でプロパティを設定したOracle Web CacheのFusion Middleware Controlで「Webキャッシュ・メンバー」ページに移動します。
「Webキャッシュ」メニューから「管理」を選択して、「クラスタ」を選択します。
クラスタ内の他のメンバーを選択して、「同期化」をクリックします。
すべてのキャッシュ・メンバーを選択し、キャッシュで処理を開始する時間調整の間隔を選択して、「起動」をクリックします。
これでキャッシュ・クラスタを使用する準備ができました。
クラスタからキャッシュ・メンバーを削除する場合は、残りのクラスタ・メンバーがそのキャッシュをクラスタ内に含んでいないこと、および削除されたキャッシュがクラスタの一部とみなされないことを確認する必要があります。
Oracle Web Cache Managerでクラスタからキャッシュを削除するには、次の手順を実行します。
いずれかのOracle Web CacheインスタンスのFusion Middleware Controlで「Webキャッシュ・メンバー」ページに移動します(これはクラスタから削除するキャッシュではありません)。
「Webキャッシュ」メニューから「管理」を選択して、「クラスタ」を選択します。
削除するキャッシュを選択して、「削除」をクリックします。
クラスタ内の他のメンバーを選択して、「同期化」をクリックします。
他のキャッシュを選択した状態で、「再起動」をクリックします。
これで、クラスタ内の残りのキャッシュはすべて、削除されたキャッシュをクラスタの一部と認識しなくなります。ただし、削除されたキャッシュでは、まだクラスタの一部と認識しています。この状況には、次の手順で対処します。
クラスタから削除したキャッシュのFusion Middleware Controlで「Webキャッシュ・メンバー」ページに移動します。
「Webキャッシュ」メニューから「管理」を選択して、「クラスタ」を選択します。
現在のキャッシュ以外のキャッシュを選択して、「削除」をクリックします。「クラスタ・メンバー」リストに現在のキャッシュのみが残るまで繰り返します。
「再起動」をクリックします。
すべてのキャッシュ・クラスタ・メンバー間で、構成および無効化リクエストの同期化をサポートするクラスタを構成できますが、リクエストはキャッシュ・クラスタ・メンバー間で転送されません。つまり、リクエストの処理時に、各クラスタ・メンバーは個々のキャッシュとして機能し、ピア・クラスタ・メンバーからのオブジェクトをリクエストしません。ただし、構成の変更および無効化リクエストは、クラスタ・メンバーへ同期化されます。
この構成を使用して、多くのキャッシュの管理を簡素化できます。これは、メンバーがファイアウォールで分けられているクラスタで必要になる可能性があります。たとえば、イントラネットとインターネットを分けるファイアウォールの両側に2つのキャッシュを配置するクラスタを構成できます。(そのようなネットワーク設定(片方のキャッシュにインターネット・トラフィックを送信し、もう一方にイントラネット・トラフィックを送信する設定)は、このドキュメントでは対象範囲外です。)
これらのキャッシュをクラスタとして管理し、キャッシュ間でコンテンツを共有しないようにするには、次の手順を実行します。
第9.3.3.2.3項「タスク1: クラスタへのキャッシュの追加とプロパティの構成」および第9.3.3.2.4項「タスク2: セッション・バインディングの追跡の有効化」の説明に従って、クラスタを作成してメンバーをそれに追加しますが、次の例外があります:
各クラスタ・メンバーで、容量を0に設定します。
「クラスタ・プロパティ」セクションで、「任意のクラスタ・メンバーに送信された無効化リクエストは、すべてのクラスタ・メンバーに伝播されます。」オプションを選択します。
第9.3.3.2.5項「タスク3: クラスタ・メンバーへの構成の同期化」の説明に従って、すべてのクラスタ・メンバーに構成を同期化します。
単一のOracle Web Cacheサーバーをソフトウェア・ロード・バランサとして構成するには、次の手順を実行します。
テキスト・エディタを使用して、次の場所にあるwebcache.xmlを開きます。
(UNIX) ORACLE_INSTANCE/<instance_name>/config/WebCache/<webcache_name> (Windows) ORACLE_INSTANCE\<instance_name>\config\WebCache\<webcache_name>
CACHE要素を探します。
ROUTINGONLY属性をCACHE要素に追加します。例:
... <CACHE WCDEBUGON="NO" CHRONOSONPERNODE="NO" CAPACITY="301" VOTES="1" INSTANCENAME="instance_name" COMPONENTNAME="component_name" ORACLEINSTANCE="instance" HOSTNAME="host" ORACLEHOME="directory" NAME="web_cache_name" ROUTINGONLY="YES"> ...
webcache.xmlを保存します。
次のコマンドを使用して、Oracle Web Cacheを再起動します。
opmnctl restartproc ias-component=component_name
この実行ファイルは、次のディレクトリにあります。
(UNIX) ORACLE_INSTANCE/bin (Windows) ORACLE_INSTANCE\bin
Oracle Web Cache Managerで、Oracle Web Cacheがロード・バランサ・モードで稼働していることを確認します。これは、「変更を適用」および「変更の取消」ボタンの下に表示される次のステータス・メッセージで確認できます。
Web Cache running in Routing Only Mode with current configuration
Fusion Middleware Controlのコンソールでは、同じ検証ステータスは表示されません。
Oracle Fusion Middleware Oracle Web Cache管理者ガイドの説明に従って、オリジナル・サーバーを構成します。
Oracle Fusion Middleware Oracle Web Cache管理者ガイドの説明に従って、サイト定義を作成し、それらをオリジナル・サーバーにマッピングします。
アプリケーション・デプロイメントにスティッキー・セッションが必要な場合は、セッション・バインディングを有効にします。第9.3.2.3項「Oracle Web Cacheのセッション・バインディング」を参照してください。
