10gリリース3（10.1.3.2.0）
E05048-01
 目次 |
 索引 |
| Oracle Application Server 高可用性ガイド 10gリリース3（10.1.3.2.0） E05048-01 |
|
この章では、アクティブ/アクティブ・トポロジについて説明します。この章の項は次のとおりです。
アクティブ/アクティブ・トポロジは、単一インスタンスよりも優れたスケーラビリティと可用性を実現する冗長なOracle Application Serverインスタンスで構成されています。アクティブ/アクティブ・トポロジを使用すると、単一インスタンスで発生するシングル・ポイント障害を回避できます。単一のOracle Application Serverインスタンスでは、単一ホストのリソースを利用しますが、Oracle Application Serverインスタンスのクラスタでは複数のホストにわたって、多数のCPUにアプリケーションの実行を分散できます。単一のOracle Application Serverインスタンスは、ホストおよびオペレーティング・システムの障害に対して脆弱ですが、アクティブ/アクティブ・トポロジではオペレーティング・システムまたはホストの損失が発生しても引き続き機能します。クライアントがこれらの障害の影響を受けることはありません。
アクティブ/アクティブ・トポロジでは、すべてのインスタンスが同時にアクティブになります。これは、一度に1つのみのインスタンスがアクティブになるアクティブ/パッシブ・トポロジとは異なります。
アクティブ/アクティブ・トポロジのノードは、ハードウェア・クラスタには含まれていません。
アクティブ/アクティブ・トポロジではロード・バランサを使用して、トポロジ内のいずれかのOracle Application Serverインスタンスにリクエストを送信します。つまり、Oracle Application Serverインスタンスの前にはロード・バランサが配置されています。
ロード・バランサは、HTTPおよびHTTPSトラフィック用の仮想サーバー名を使用して構成します。クライアントはリクエストの中でこれらの仮想サーバー名を使用します。ロード・バランサは、使用可能なOracle Application Serverインスタンスにリクエストを送信します。
ロード・バランサに必要な機能の一覧は、第2.5項「外部ロード・バランサ」を参照してください。
WebCenterアプリケーションをアクティブ/アクティブ・トポロジで実行している場合は、次の点に注意してください。
各ノードのローカル・ドライブに加えて、アクティブ/アクティブ・トポロジ内のすべてのノードからアクセス可能な共有記憶域が必要です。共有記憶域には、Oracle Metadata Services（MDS）用のディレクトリを作成する必要があります。MDSディレクトリには、デプロイされたWebCenterアプリケーション用のページ・カスタマイズ・データとポートレット・メタデータが格納されます。
共有記憶域にMDSディレクトリがあると、すべてのOracle Application Serverインスタンスが同じデータにアクセスできるようになり、データのレプリケートを考慮する必要はなくなります。
MDSディレクトリのマウント・ポイントは、アクティブ/アクティブ・トポロジ内のすべてのノードで同じにする必要があります（たとえば、UNIXでは/oracle/mds、WindowsではS:¥oracle¥mds）。Windowsでは、マウント・ポイントは、ドライブ文字も含めてすべてのノードで同じにする必要があります。たとえば、あるノードでS:¥oracle¥mdsとし、別のノードでT:¥oracle¥mdsとすることはできません。
共有記憶域は、インストール時には不要ですが、アプリケーションをデプロイするときに必要となります。アプリケーションのデプロイ時に、MDSディレクトリへのパスを指定します。
ポートレット・プリファレンス・ストアの共有記憶域: 高可用性トポロジでは、ポートレット・プリファレンス・ストアとして、（MDSとは別の）データベースを使用することをお薦めします。ただし、ファイルベースのポートレット・プリファレンス・ストアを使用する場合は、ファイルを共有記憶域に配置することもできます。ポートレット・プリファレンス・ストアの詳細は、第3.1.2.2項「ポートレット・プリファレンス・ストアのタイプと場所」を参照してください。
WebCenterアプリケーションでは、リモート・コンピュータのポートレット・プロデューサでホスト可能なポートレットを消費します。ポートレット・プロデューサは、ポートレットのプリファレンスまたはカスタマイズをプリファレンス・ストアに格納します。プリファレンス・ストアは、データベースベースでもファイルベースでもかまいません。
|
注意 Webクリッピング・ポートレットは、プリファレンス・ストアを使用しません。そのかわり、クリッピングおよびクリッピングの定義の格納にはリポジトリを使用します。詳細は、第3.1.2.3項「Webクリッピング・ポートレットのリポジトリ」を参照してください。 |
高可用性トポロジでは、データベースベースのプリファレンス・ストアを使用し、このデータベースを、Real Application Clustersデータベースやコールド・フェイルオーバー・クラスタ・データベースなど、高可用性に構成することをお薦めします。
プリファレンス・ストアのタイプは、ポートレット・プロデューサのweb.xmlファイル（WSRPプロデューサ用）、またはprovider.xmlファイル（PDK-Javaプロデューサ用）で指定します。
ポートレット・プリファレンス・ストアのバックアップ: Oracle Application Server環境をバックアップする際は、ポートレット・プリファレンス・ストア（ファイルまたはデータベース）を含める必要があります。詳細は、『Oracle Application Server管理者ガイド』のポートレット・プロデューサのバックアップの実行に関する項を参照してください。
ポートレット・プリファレンス・ストアとMDSを混同しないでください。この2つの概念はまったく違います。第3.1.2.1項「Oracle Metadata Services（MDS）の共有記憶域」の説明にあるように、MDSはファイルベースしかなく、共有記憶域に格納されます。
ポートレット・プリファレンスをデータベースに格納する場合、このデータベースは、Real Application Clustersデータベースやコールド・フェイルオーバー・クラスタ・データベースなど、高可用性データベースにする必要があります。
プリファレンス・ストアでなくリポジトリを使用するWebクリッピング・ポートレットについては、第3.1.2.3項「Webクリッピング・ポートレットのリポジトリ」を参照してください。
データベースベースのプリファレンス・ストアを構成する具体的な手順については、『Oracle WebCenter Framework開発者ガイド』のデータベース・プリファレンス・ストアの設定に関する項を参照してください。
注意:
log.xmlファイルに、次のようなメッセージが記録される場合があります。
<MSG_TEXT>ERROR: PrefStorePersonalizationManager: Failed to read customization for Portlet: 1163787272417/100/PI1163787272417_86327909/tom Type: 2</MSG_TEXT> <SUPPL_DETAIL><
この項では、インストール手順の概要を示します。詳細は、ご使用のプラットフォームのOracle Application Serverのインストレーション・ガイドを参照してください。
データベースの初期化パラメータが正しく設定されているかどうかを確認してください。詳細は、ご使用のプラットフォームのOracle Application Serverのインストレーション・ガイドを参照してください。
SYSユーザーのパスワードも知っておく必要があります。
Oracle Internet Directoryを用意していない場合は、リポジトリ情報をファイルに格納できます。
インストール後に、次の手順を実行します。
各ノードのORACLE_HOME/Apache/Apache/conf/httpd.confファイルを次のように編集します。
httpd.confファイルに次の行を追加します。
LoadModule certheaders_module libexec/mod_certheaders.so
httpd.confファイルに次の行を追加します。
LoadModule certheaders_module modules/mod_certheaders.so
httpd.confファイルに次の行を追加します。
LoadModule certheaders_module modules/ApacheModuleCertHeaders.dll
<VirtualHost *:7777> ServerName myworkplace.com Port 443 ServerAdmin you@youraddress.com RewriteEngine On RewriteOptions inherit SimulateHTTPS On </VirtualHost>
IFS.DOMAIN.APPLICATION.ApplicationHostを、ロード・バランサ上に構成された仮想ホスト名に設定します。
IFS.DOMAIN.APPLICATION.ApplicationHostを、ロード・バランサ上に構成されたポート番号に設定します。
Application Server Controlを使用してこれらのプロパティを編集する手順は、次のとおりです。
IFS.DOMAIN.APPLICATION.ApplicationHost」プロパティをクリックし、その値を、ロード・バランサ上に構成された仮想ホスト名に設定します。「OK」をクリックします。
IFS.DOMAIN.APPLICATION.ApplicationPort」プロパティをクリックし、その値を、ロード・バランサ上に構成されたポート番号に設定します。「OK」をクリックします。
> ORACLE_HOME/opmn/bin/opmnctl reload
図3-2は、Oracle HTTP Server、WebCenter FrameworkおよびOracle Content DBが個別のノードにインストールされている分散アクティブ/アクティブ・トポロジを示しています。このトポロジを使用できるのは、ノードがWeb層とアプリケーション層に分かれていて、かつ層の中でノードがファイアウォールによって切り離されている場合です。
Oracle HTTP Serverは、Web層で実行されています。Oracle HTTP Serverの可用性を高めるには、アクティブ/アクティブとアクティブ/パッシブいずれかのトポロジで実行します。
Oracle HTTP Serverインスタンス、WebCenter FrameworkインスタンスおよびOracle Content DBインスタンスを同じクラスタにクラスタリングして、Oracle HTTP Serverがどのノードにもリクエストを転送できるようにします。
Oracle HTTP ServerインスタンスとWebCenter Suiteインスタンスを同じクラスタ内のアプリケーション層に配置し、WebCenter Suiteを実行するノードの位置をOracle HTTP Serverで認識できるようにします。
WebCenter FrameworkとOracle Content DBは、アプリケーション層のノードのローカル記憶域にある個別のOracleホームにインストールします。これらは個別のインストールであるため、同じノードにも別のノードにもインストールできます。WebCenter FrameworkとOracle Content DBは、両方のコンポーネントが必要である場合を除き、両方ともインストールする必要はありません。
Web層とアプリケーション層にあるOracleホームはすべて、同じOracleAS Clusterにあります。これによって、Oracle HTTP Serverは、同じクラスタに属するどのOC4Jインスタンスにもリクエストを送信できます。
アプリケーション層のノードには、共有記憶域に対するアクセス権限が必要です。この共有記憶域には、Oracle Metadata Services（MDS）ディレクトリが含まれます。詳細は、第3.1.2.1項「Oracle Metadata Services（MDS）の共有記憶域」を参照してください。
この項では、インストール手順の概要を示します。詳細は、ご使用のプラットフォームのOracle Application Serverのインストレーション・ガイドを参照してください。
データベースの初期化パラメータが正しく設定されているかどうかを確認してください。詳細は、ご使用のプラットフォームのOracle Application Serverのインストレーション・ガイドを参照してください。
SYSユーザーのパスワードも知っておく必要があります。
Oracle Internet Directoryを用意していない場合は、リポジトリ情報をファイルに格納できます。
（Oracle HTTP Server、WebCenter FrameworkまたはOracle Content DBを実行する）Oracle Application Serverインスタンスをクラスタリングする必要があります。クラスタの構成は、インストール時でもインストール後でも実行できます。
インストール後に、次の手順を実行します。
Oracle HTTP Serverノードで、ORACLE_HOME/Apache/Apache/conf/httpd.confファイルを次のように編集します。
httpd.confファイルに次の行を追加します。
LoadModule certheaders_module libexec/mod_certheaders.so
httpd.confファイルに次の行を追加します。
LoadModule certheaders_module modules/mod_certheaders.so
httpd.confファイルに次の行を追加します。
LoadModule certheaders_module modules/ApacheModuleCertHeaders.dll
<VirtualHost *:7777> ServerName myworkplace.com Port 443 ServerAdmin you@youraddress.com RewriteEngine On RewriteOptions inherit SimulateHTTPS On </VirtualHost>
IFS.DOMAIN.APPLICATION.ApplicationHostを、ロード・バランサ上に構成された仮想ホスト名に設定します。
IFS.DOMAIN.APPLICATION.ApplicationHostを、ロード・バランサ上に構成されたポート番号に設定します。
Application Server Controlを使用してこれらのプロパティを編集する手順は、次のとおりです。
IFS.DOMAIN.APPLICATION.ApplicationHost」プロパティをクリックし、その値を、ロード・バランサ上に構成された仮想ホスト名に設定します。「OK」をクリックします。
IFS.DOMAIN.APPLICATION.ApplicationPort」プロパティをクリックし、その値を、ロード・バランサ上に構成されたポート番号に設定します。「OK」をクリックします。
> ORACLE_HOME/opmn/bin/opmnctl reload
アクティブ/アクティブ・トポロジ内のすべてのOracle Application Serverインスタンスは、同じクラスタに属しています。Oracle HTTP Serverは、アプリケーションのリクエストを、同じクラスタ内のどのOC4Jインスタンスにも転送できます。WebCenter FrameworkとOracle Content DBのコンポーネントがOC4Jコンテナで実行されるため、この機能は有用です。
| コンポーネント | 実行されるOC4Jインスタンス |
|---|---|
|
WebCenter Framework |
OC4J_WebCenter |
|
Oracle Content DB |
OC4J_Content |
クラスタ内のインスタンスは、次の方法のいずれかを使用してグループ化できます。
また、OracleAS Clusterを使用すると、一部のopmnctlコマンドで@clusterパラメータを使用できるようになります。@clusterパラメータを使用するコマンドは、クラスタ内のすべてのインスタンスに適用されます。たとえば、@clusterパラメータを使用して、クラスタ内のすべてのインスタンスのコンポーネントをすべて起動できます。
クラスタ内のOC4Jインスタンスには、次の特徴があります。
詳細は、『Oracle Containers for J2EE構成および管理ガイド』の「クラスタおよびOC4Jグループの構成と管理」を参照してください。
OC4Jで実行されているステートフルWebアプリケーションとステートフル・セッションEJBに対し、クライアントは一連のHTTPリクエストとレスポンスにおいて同じOC4Jプロセスを使用して通信します。ただし、アプリケーションを実行しているOC4Jプロセスが停止またはハングするか、ノードに障害が発生した場合、クライアントのリクエストに関連付けられている状態は失われます。
このようなソフトウェアやハードウェアの障害から保護するには、次の手順を実行する必要があります。
OracleAS Cluster（OC4J）のアプリケーションレベルのクラスタリングでは、OC4Jプロセスがセッション状態を互いにレプリケートします。この構成では、異なるOracle Application Serverインスタンスで実行している複数のOC4Jプロセス間で状態をレプリケートすることにより、フェイルオーバーと高可用性が実現します。障害が発生した場合、Oracle HTTP Serverは、OracleAS Cluster（OC4J）内のアクティブなOC4Jプロセスにリクエストを転送します。
ノードの障害などのハードウェア障害から保護するには、1つのOracleAS Cluster（OC4J）内の各ノード上のOC4Jインスタンスをクラスタリングします。1つのOracleAS Cluster（OC4J）内の異なるノードで実行されるOC4Jプロセスは、セッションの状態情報を共有できます。OC4Jインスタンスに障害が発生するか、使用不可になると、Oracle HTTP Serverは使用可能なOC4Jプロセスにリクエストを転送します。Oracle HTTP Serverは、クラスタ内のアクティブな（動作中の）OC4Jプロセスにのみリクエストを転送します。
OracleAS Cluster（OC4J）をmod_oc4jリクエスト・ルーティングとともに使用すると、ソフトウェアまたはハードウェアに問題が発生したときにステートフル・フェイルオーバーを利用できます。たとえば、OracleAS Cluster（OC4J）の一部であるOC4Jプロセスで障害が発生すると、OPMNによってこの障害がmod_oc4jに通知され、リクエストはmod_oc4jによって同じクラスタ内の別のOC4Jプロセスにルーティングされます。クライアントのセッション状態は維持されます。サービスの損失はクライアントからは見えません。
図3-3は、2つのOracle Application Serverインスタンスに構成されているOracleAS Cluster（OC4J）を示しています。OC4Jプロセスは各インスタンスで実行されています。Oracle Application Serverのインスタンス1に障害が発生した場合、インスタンス2のOC4Jプロセスはセッション状態情報を含んでいるので、リクエストを処理できます。この構成により、OracleAS Cluster（OC4J）におけるWebアプリケーションのセッション状態レプリケーションのフェイルオーバーが可能になります。
アプリケーション・クラスタリングを使用するように構成されたアプリケーションの一部となるすべてのWebモジュール用のweb.xmlファイルに、空の<distributable/>タグを追加する必要があります。デプロイ後に、このJ2EE標準Webモジュール・ディスクリプタは、ORACLE_HOME/j2ee/j2ee_instance_name/applications/app_name/web_module_name/WEB-INFディレクトリに配置されています。
最小のOC4Jプロセス数を維持しつつ、ソフトウェアまたはハードウェア障害から保護するには、同じクラスタ内に少なくとも2つのOC4Jプロセスを構成する必要があります。たとえば、インスタンス1とインスタンス2の2つのOracle Application Serverインスタンスがある場合は、それぞれのインスタンスに2つのOC4Jプロセスを構成できます。この構成では、ステートフル・セッションのアプリケーションがハードウェアおよびソフトウェア障害から保護され、次のいずれかのタイプの障害が発生しても、クライアントの状態は維持されます。
OracleAS Cluster（OC4J-EJB）では、ステートフル・セッションEJBの高可用性が実現します。EJBクラスタでは、同じマルチキャスト・アドレス経由で通信する複数のOC4Jプロセス間でこれらのEJBをフェイルオーバーできます。このように、ステートフル・セッションEJBでレプリケーションを使用すると、プロセスとノードの障害から保護し、Oracle Application Serverで実行されているステートフル・セッションEJBの高可用性を実現できます。
詳細は、『Oracle Containers for J2EE Enterprise JavaBeans開発者ガイド』の第24章「OC4J EJBアプリケーション・クラスタリング・サービスの構成」を参照してください。
ロード・バランサはトポロジ内の任意のOracle Application Serverインスタンスにリクエストを送信できるため、どのインスタンスがリクエストを処理してもクライアントが同じレスポンスを取得するように、各インスタンスの構成を同じにする必要があります。これには次の作業が含まれます。
OC4Jインスタンスをグループに配置することで、いくつかの一般的な管理タスクをグループ・レベルで実行できます。たとえば、Application Server Controlの「グループ」ページで、グループ内のすべてのメンバーに対して次の作業を実行できます。
「グループ」ページを表示するには、「クラスタ・トポロジ」ページの「グループ」セクションでグループ名をクリックします。
各OC4Jインスタンスは、1つのグループに存在している必要があります。Oracle Application Serverをインストールすると、"default_group"というグループが自動的に作成されます。
図3-4は、3つのOracle Application Serverインスタンスを示しています。これらの各Oracle Application Serverインスタンスには、"home"というOC4Jインスタンスがあり、それらは"Apps"というグループに属しています。またこの図は、3つのOracle Application Serverインスタンスのうち2つに"sales"というOC4Jインスタンスがあり、それらのOC4Jインスタンスが"finance"というグループに属していることも示しています。
グループには、クラスタ内のすべてのOracle Application ServerインスタンスのOC4Jインスタンスが含まれている必要はありません。たとえば、図3-4では、"sales" OC4Jインスタンスは2つのOracle Application Serverインスタンスにのみ存在します。これは有効です。
Oracle Application Serverでは、グループ内のインスタンスを同一に構成する必要はありません。ただし、一部の構成（データソース、JMSリソース、セキュリティ・プロバイダ設定など）は同一にして、どのインスタンスがリクエストを処理しても、同じレスポンスがアプリケーションから返されるようにしてください。
グループの詳細は、Application Server Controlのオンライン・ヘルプで、OC4Jインスタンスおよびグループの作成に関するガイドラインを参照してください。
グループは、Application Server Controlを使用して作成できます。「クラスタ・トポロジ」ページには「グループ」セクションがあり、ここでグループに対する操作（起動、停止、削除、作成など）を実行できます。
グループは、OC4Jインスタンスの作成時に作成することもできます。Application Server Controlを使用してOC4Jインスタンスを作成する場合、OC4Jインスタンスの名前を入力するほかに、新しいOC4Jインスタンスが属するグループを指定する必要があります。既存のグループを指定することも、グループを新規作成することもできます。第3.1.9.2項「追加のOC4Jインスタンスの作成」を参照してください。
createinstanceコマンドを使用してOC4Jインスタンスを作成する場合、groupNameパラメータでグループの名前を指定します。createinstanceコマンドについては、第3.1.9.2項「追加のOC4Jインスタンスの作成」で説明します。
グループの作成手順、OC4Jインスタンスの作成手順、OC4Jインスタンスの削除手順など、グループの詳細は、『Oracle Containers for J2EE構成および管理ガイド』の第8章「クラスタおよびOC4Jグループの構成と管理」の「Oracle Application Serverクラスタ内のOC4Jグループの作成および管理」を参照してください。
追加のOC4Jインスタンスを作成するには、Application Server ControlまたはORACLE_HOME/bin/createinstanceコマンドを使用します。
「クラスタ・トポロジ」ページでOracle Application Serverインスタンスの名前をクリックすると、「アプリケーション・サーバー: <インスタンス名>」ページが表示されます。「OC4Jインスタンスの作成」ボタンをクリックすると、「OC4Jインスタンスの作成」ページが表示されます（図3-5）。
「OC4Jインスタンスの作成」ページで、作成するOC4Jインスタンスの名前と、そのOC4Jインスタンスが属するグループを入力します。既存のグループを指定することも、グループを新規作成することもできます。
追加のOC4Jインスタンスを作成するには、ORACLE_HOME/bin/createinstanceコマンドを使用します。構文は次のとおりです。
createinstance -instanceName name [-port httpPort] [-groupName groupName]
nameには、作成するOC4Jインスタンスの名前を指定します。
オプションのportパラメータは、Oracle Application ServerインスタンスにOracle HTTP Serverが含まれていない場合に役立ちます。HTTPポートを設定すると、新しいOC4Jインスタンスのホームページに直接アクセスできるようになります。
オプションのgroupNameパラメータを使用すると、指定したグループに新しいOC4Jインスタンスを追加できます。このパラメータを指定しないと、インスタンスはdefault_groupグループに追加されます。指定したグループが存在しない場合は作成されます。
たとえば、"sales" OC4Jインスタンスを作成して"finance"グループに追加するには、次のコマンドを使用します。
createinstance -instanceName sales -groupName finance
このコマンドによって、"sales"インスタンスのoc4jadminユーザーのパスワードを設定するように求められます。このパスワードは"home"インスタンスのパスワードとは異なるものに設定できますが、お薦めはしません。OPMNに問題が発生しないようにするためにも、パスワードは"home"インスタンスのoc4jadminユーザーのパスワードと同じものに設定してください。
パスワードの詳細は、『Oracle Containers for J2EE構成および管理ガイド』の第8章「クラスタおよびOC4Jグループの構成と管理」の「createinstanceユーティリティを使用したOC4Jインスタンスの作成」を参照してください。
このコマンドによってインスタンスが作成されますが、起動はされません。起動はApplication Server Controlコンソールまたはopmnctlコマンドで行います。
インスタンスを作成したら、OPMNをリロードし、新しいインスタンスが認識されるようにします。
opmnctl reload
createinstanceコマンドの詳細は、『Oracle Containers for J2EE構成および管理ガイド』の第8章「クラスタおよびOC4Jグループの構成と管理」の「OC4Jインスタンスの追加作成」を参照してください。
OC4Jインスタンスのグループは、一括管理することも、個別に管理することもできます。すべてのアプリケーションとインスタンスは、一度にまたは個別に起動および停止でき、またアプリケーションは、グループ内のすべてのインスタンスまたは一部のインスタンスにデプロイ、再デプロイ、アンデプロイすることもできます。
グループ内の一部のインスタンスのみにアプリケーションをデプロイすることはお薦めできません。グループ内のすべてのインスタンスに同じアプリケーションをデプロイするようにしてください。
グループは、Application Server Controlコンソールまたはadmin_client.jarを使用して管理できます。Application Server Controlコンソールでは、グループに対して次のような操作を実行できます。
admin_client.jarユーティリティを使用して、アプリケーションをグループにデプロイできます。構文は次のとおりです。
> cd ORACLE_HOME/j2ee/home > java admin_client.jar deployer:cluster:opmn://<host>:<opmnPort>/<groupName> <adminID> <adminPassword> -deploy -file <pathToArchiveFile> -deploymentName <appName>
<host>には、グループ内の任意のホストを指定できます。
<opmnPort>には、OPMNがリスニングするポートを指定します。このポートは、opmn.xmlファイルに記載されています。
<groupName>には、グループの名前を指定します。これは、OC4Jインスタンスの名前（homeなど）です。
<adminID>と<adminPassword>には、管理者のIDとパスワードを指定します。通常、adminIDはoc4jadminです。
<pathToArchiveFile>には、デプロイするEAR、WAR、またはJARファイルへのフルパスを指定します。
<appName>には、アプリケーション名を指定します。
デプロイについては、コマンドラインで指定できるオプションが他にもあります。詳細は、『Oracle Containers for J2EEデプロイメント・ガイド』を参照してください。
Oracle HTTP Serverでは、J2EEアプリケーションに対するリクエストを受信すると、そのリクエストをOracle HTTP Server内にあるmod_oc4jモジュールに転送します。ロード・バランシング・アルゴリズムに従って、mod_oc4jではリクエストを同じクラスタ内のOC4Jインスタンスに転送します。図3-6を参照してください。
リクエストの分散にmod_oc4jが使用するデフォルトのロード・バランシング・アルゴリズムは、単純なラウンド・ロビン・アルゴリズムです。別のアルゴリズムを使用する場合は、mod_oc4j.confファイルにディレクティブを設定します。詳細は、第3.2.8項「mod_oc4jのロード・バランシング・オプションの設定」を参照してください。
セッションの一部であるリクエストは、同じOC4Jインスタンスに送信されます。最初のリクエスト後にOC4Jインスタンスが使用不可になった場合は、リクエストを処理する別のインスタンスがmod_oc4jによって検索され、同じセッション内の後続リクエストがそのインスタンスに送信されます。
Oracle Application Server 10gリリース3（10.1.3.1.0）にはOracle Identity Managementは含まれていませんが、Oracle Application Server 10gリリース3（10.1.3.1.0）を、リリース9.0.4、リリース2（10.1.2）またはリリース10.1.4のOracle Identity Managementとともに使用することはできます。
Oracle Internet Directory、OracleAS Single Sign-On、OracleAS Certificate Authority、Oracle Directory Integration and ProvisioningなどのOracle Identity Managementサービスが必要な場合は、アクティブ/アクティブ・トポロジをOracle Identity Managementに関連付けることができます。
リリース3（10.1.3.1.0）のアクティブ/アクティブ・トポロジとOracle Identity Managementインスタンスは個別にインストールします。インストール後に、Application Server Controlコンソールを使用してリリース3（10.1.3.1.0）のインスタンスをOracle Identity ManagementのOracle Internet Directoryに関連付けます。
Oracle Identity Managementをリリース3（10.1.3.1.0）のインスタンスに関連付ける方法の詳細は、『Oracle Application Server管理者ガイド』の「10.1.4および10.1.2のOracle Identity Managementを使用するためのインスタンスの構成」を参照してください。
高可用性環境では、高可用性を実現するために、リリース3（10.1.3）のインスタンスとOracle Identity Managementインスタンスの両方が必要になります。このガイドでは、リリース3（10.1.3）のインスタンス用の高可用性についてのみ説明します。Oracle Identity Managementの高可用性の詳細は、使用しているOracle Identity Managementリリースの『Oracle Application Server高可用性ガイド』を参照してください。
図3-7は、リリース2（10.1.2）のOracle Identity Managementを使用して実行されているアクティブ/アクティブ・トポロジのOracle Application Server 10gリリース3（10.1.3）のインスタンスを示しています。
アクティブ/アクティブ・トポロジでは、リリース3（10.1.3.1.0）のOracle HTTP Serverを使用するかわりに、リリース2（10.1.2）のOracle HTTP Serverを使用できます。これは次のような理由で行います。
リリース2（10.1.2）のOracle HTTP Serverは、分散アクティブ/アクティブ・トポロジ（図3-2）に対してのみ使用できます。
図3-7に示すように、Oracle Application Server 10gリリース3（10.1.3）で、リリース2（10.1.2）のOracleAS Web Cacheを使用できます。
OracleAS Web Cacheは、リバース・プロキシ・サーバーとして使用します。リバース・プロキシ・サーバーは、OracleAS Web Cacheの1つのインスタンスまたはクラスタ（OracleAS Web Cacheクラスタ）として構成されている複数のインスタンスで構成できます。
リバース・プロキシ・サーバーとしてのOracleAS Web Cache（単一インスタンスまたはクラスタ）の構成方法の詳細は、『Oracle Application Server管理者ガイド』の「リバース・プロキシとしての10.1.2 OracleAS Web Cacheの構成」を参照してください。
この項では、アクティブ/アクティブ・トポロジの管理に必要な一般的な手順について説明します。
OracleAS Clusterの作成には、いくつかの方法があります。この項では、2つの方法についてのみ説明します。
その他の方法については、『Oracle Containers for J2EE構成および管理ガイド』の「クラスタおよびOC4Jグループの構成と管理」を参照してください。
この方法では、クラスタ内の各Oracle Application Serverインスタンスに対して同じマルチキャスト・アドレスとポートを定義します。この方法の利点は、クラスタ内の各Oracle Application Serverインスタンスの名前を指定する必要がないことです。クラスタのインスタンスの追加または削除は、マルチキャスト・アドレスおよびポートを編集することで実行できます。
opmnctl config topology update discover="*<multicastAddress>:<multicastPort>"
multicastAddressは、このクラスタに使用するマルチキャスト・アドレスを指定します。マルチキャスト・アドレスは、224.0.1.0〜239.255.255.255の有効なアドレス範囲内で指定する必要があります。コマンドでは、マルチキャスト・アドレスの前に*文字を付けます。
multicastPortには、未使用のポート番号を指定できます。
例:
> ORACLE_HOME/opmn/bin/opmnctl config topology update discover="*225.0.0.20:8001"
分散インストール（異なるOracleホームにOracle HTTP ServerおよびOC4Jがインストールされている場合）では、すべてのOracle Application Serverインスタンスを同じクラスタにクラスタリングする必要があります。すべてのインスタンスには同じマルチキャストIPとポートを使用する必要があります。
opmnctl config topology updateコマンドを実行するOracle Application Serverインスタンスごとにopmnctl reloadコマンドを実行し、更新されたopmn.xmlファイルのOPMNによる読取りを強制します。
> ORACLE_HOME/opmn/bin/opmnctl reload
マルチキャスト方法を使用しない場合は、Oracle Application Serverインスタンスを実行するノードの名前を各インスタンスのopmn.xmlファイルで指定して、クラスタを定義できます。
例: 4つのインスタンス（inst1.node1.mycompany.com、inst2.node2.mycompany.com、inst3.node3.mycompany.com、inst4.node4.mycompany.com）をクラスタリングする場合は、次の手順を実行します。
この例では、inst1.node1.mycompany.comとinst2.node2.mycompany.comがクラスタの検出サーバーになることを前提としています。
分散インストール（異なるOracleホームにOracle HTTP ServerおよびOC4Jがインストールされている場合）では、Oracle HTTP ServerまたはOC4Jのどちらを実行するインスタンスでも検出サーバーとして機能できます。
opmn.xmlファイルで、検出サーバーを実行しているノード（この例ではnode1.mycompany.comとnode2.mycompany.com）を指定します。この例では、次の行を含むようにopmn.xmlファイルを変更します。
<notification-server> <topology> <discover list="node1.mycompany.com:6201,node2.mycompany.com:6201"/> </topology> ... </notification-server>
6201は、通知サーバーがリスニングするポート番号を示します。この値はそのインスタンスのopmn.xmlファイルに含まれています。
複数の検出サーバーを使用する場合は、これらをカンマで区切ります。
opmnctl reloadを実行して、更新されたopmn.xmlファイルのOPMNによる読取りを強制します。
> ORACLE_HOME/opmn/bin/opmnctl reload
レプリケーションは様々な方法で設定できます。
レプリケーションのポリシーを定義することができます。これにより、レプリケーションの実行時期、およびデータをレプリケートするノード数の制限を指定します。
マルチキャスト・レプリケーションは、デフォルトのレプリケーション・タイプです。マルチキャスト・レプリケーションを使用するようにアプリケーションを設定するには、空の<cluster/>タグをアプリケーションのorion-application.xmlファイルまたはグローバルのORACLE_HOME/j2ee/home/config/application.xmlファイルに追加します。次に、例を示します。
<orion-application ... > ... <cluster/> </orion-application>
<cluster/>タグは、アプリケーションのデプロイ先のノードすべてに追加する必要があります。
デフォルトでは、マルチキャスト・レプリケーションには230.230.0.1のマルチキャスト・アドレスと45566のポートが使用されます。これらの値を変更する場合は、multicast要素のip属性とport属性に必要な値を指定します。たとえば次のコードでは、ip属性とport属性に、カスタマイズされた値が設定されています。
<orion-application ... > ... <cluster allow-colocation="false"> <replication-policy trigger="onShutdown" scope="allAttributes"/> <protocol> <multicast ip="225.130.0.0" port="45577" bind-addr="226.83.24.10"/> </protocol> </cluster> </orion-application>
マルチキャスト・アドレスには、224.0.1.0〜239.255.255.255の範囲の値を指定する必要があります。
上のコードで使用されている他のタグと属性を次に説明します。
allow-colocation: アプリケーション状態が、同じホストで実行されている他のOracle Application Serverインスタンスにレプリケートされるかどうかを指定します。デフォルトはtrueです。
triggerおよびscope: 第3.2.2.4項「レプリケーション・ポリシーの設定」を参照してください。
bind-addr: バインド先のネットワーク・インタフェース・カード（NIC）のIPを指定します。これは、ホスト・マシンに複数のNICがあり、各NICに独自のIPアドレスが指定されている場合に役立ちます。
Oracle Application Serverでは、動的と静的の2種類のpeer-to-peerレプリケーションをサポートしています。
動的なpeer-to-peerレプリケーションを指定するには、空の<opmn-discovery/>タグをアプリケーションのorion-application.xmlファイルまたはグローバルのORACLE_HOME/j2ee/home/config/application.xmlファイルに追加します。
<orion-application ... > ... <cluster allow-colocation="false"> <replication-policy trigger="onShutdown" scope="allAttributes"/> <protocol> <peer> <opmn-discovery/> </peer> </protocol> </cluster> </orion-application>
OPMNによるクラスタ内のインスタンスの検出方法は、OracleAS Clusterの設定時に定義しました。詳細は、第3.2.1項「OracleAS Clusterの設定」を参照してください。
静的なpeer-to-peerレプリケーションを指定するには、ホスト名のリストをアプリケーションのorion-application.xmlファイルまたはグローバルのORACLE_HOME/j2ee/home/config/application.xmlファイルの<node>要素に含めます。ノードごとにアクティブ/アクティブ・トポロジ内の別のノードを指定し、トポロジ内のすべてのノードが連鎖の中で接続されるようにします。たとえば、トポロジに3つのOracle Application Serverインスタンスがある場合、ノード1はノード2を指定し、ノード2はノード3を指定し、ノード3はノード1を指定できます。
例:
ノード1では、<node>タグによってノード2が指定されます。
<orion-application ... > ... <cluster allow-colocation="false"> <replication-policy trigger="onShutdown" scope="allAttributes"/> <protocol> <peer start-port="7900" range="10" timeout="6000"> <node host="node2.mycompany.com" port="7900"/> </peer> </protocol> </cluster> </orion-application>
ノード2では、<node>タグによってノード3が指定されます。
<orion-application ... > ... <cluster allow-colocation="false"> <replication-policy trigger="onShutdown" scope="allAttributes"/> <protocol> <peer start-port="7900" range="10" timeout="6000"> <node host="node3.mycompany.com" port="7900"/> </peer> </protocol> </cluster> </orion-application>
ノード3では、<node>タグによってノード1が指定されます。
<orion-application ... > ... <cluster allow-colocation="false"> <replication-policy trigger="onShutdown" scope="allAttributes"/> <protocol> <peer start-port="7900" range="10" timeout="6000"> <node host="node1.mycompany.com" port="7900"/> </peer> </protocol> </cluster> </orion-application>
これを実現する別の方法は、すべてのノードで同じノードを指定することです。3つのノードを含む例では、ノード1とノード2がノード3を指定し、ノード3がノード1またはノード2のどちらかを指定することもできます。
上の例で使用されているタグと属性を次に説明します。
start-port: ピア通信用にOracle Application Serverがバインドするローカル・ノード上の最初のポートを指定します。このポートが使用中の場合は、使用可能なポートが見つかるまでOracle Application Serverによってポート番号が増加されます。デフォルトは7800です。
timeout: 指定したピア・ノードからのレスポンスを待機する時間をミリ秒で指定します。デフォルトは3000ミリ秒です。
host: ピア・ノードの名前を指定します。
port: 指定したホスト（host属性で指定）でピア通信に使用するポートを指定します。デフォルトは7800です。
range: port（start-portではない）属性で指定したポートの番号を増加する回数を指定します。デフォルトは5です。
次の点に注意してください。
orion-application.xmlファイルはインスタンスごとに異なります。アプリケーションをデプロイするときは、それに伴ってorion-application.xmlを更新する必要があります。
このレプリケーション・メカニズムでは、レプリケートされたデータはデータベースに保存されます。データベースはアプリケーションのorion-application.xmlファイルまたはグローバルのORACLE_HOME/j2ee/home/config/application.xmlファイルの<database>タグに指定します。次に、例を示します。
<orion-application ... > ... <cluster allow-colocation="false"> <replication-policy trigger="onShutdown" scope="allAttributes"/> <protocol> <database data-source="jdbc/MyOracleDS"/> </protocol> </cluster> </orion-application>
data-source属性の値は、data-sources.xmlファイルに指定されているデータソースのjndi-nameに一致する必要があります。データソースの作成と使用の詳細は、『Oracle Containers for J2EEサービス・ガイド』を参照してください。
<replication-policy>タグの属性を使用すると、レプリケートするデータおよびデータをレプリケートする頻度を指定できます。
trigger属性は、レプリケーションを行う時期を指定します。表3-3では、この属性でサポートされている値について説明しています。
scope属性は、レプリケートするデータを指定します。表3-4では、この属性でサポートされている値について説明しています。
レプリケート先のノードの数を指定するには、<cluster>タグのwrite-quota属性を使用します。たとえば、次のコードでは、レプリケート・データが2つの他のノードにレプリケートされることを指定しています。
<orion-application ... > ... <cluster allow-colocation="false" write-quota="2"> <replication-policy trigger="onShutdown" scope="allAttributes"/> <protocol> <peer> <opmn-discovery/> </peer> </protocol> </cluster> </orion-application>
デフォルトは1です。
推奨事項: 2つのノードを含むアクティブ/アクティブ・トポロジでは、write-quotaを1に設定し、データが他方のノードにレプリケートされるようにします。
3つ以上のノードを含むトポロジでは、write-quotaを2以上に設定し、データが少なくともその他2つのノードにレプリケートされるようにします。
トポロジ内のノードすべてにデータをレプリケートするには、write-quotaをトポロジ内のノードの合計数に設定します。そのノードで別のインスタンスが実行されていると、同じノードに書込みが行われる場合があります。
データベースにレプリケートする場合、write-quota属性は使用されません。
アクティブ/アクティブ・トポロジのインスタンスのステータスをチェックするには、トポロジ内の任意のインスタンスから次のコマンドを実行します。
> cd ORACLE_HOME/opmn/bin > opmnctl @cluster status
opmnctlコマンドを使用すると、トポロジ内のコンポーネントを起動および停止できます。トポロジ内のすべてのOracle Application Serverインスタンスのコンポーネントを起動および停止するには、opmnctlで@clusterパラメータを使用する必要があります。opmnctlコマンドは、トポロジ内の任意のインスタンスから実行できます。
たとえば、トポロジ内のすべてのインスタンスのOracle HTTP Serverコンポーネントを起動するには、トポロジ内の任意のインスタンスから次のコマンドを実行します。
> cd ORACLE_HOME/opmn/bin > opmnctl @cluster startproc ias-component=HTTP_Server
今回のリリースでデプロイ手順が変更されましたので注意してください。特に、共有記憶域上のMDSディレクトリへのパスを指定することが必要になりました。これを行うには、新たに導入された「Predeploymentツール」を実行します。
Predeploymentツールは1つのノードでのみ実行します。トポロジの各ノードで実行する必要はありません。
デプロイ手順の詳細は、『Oracle WebCenter Framework開発者ガイド』の第9章「WebCenterアプリケーションのデプロイ」を参照してください。
アプリケーションは、Application Server Controlコンソールを使用するか、コマンドラインから実行するコマンドを使用してデプロイできます。
アプリケーションをクラスタ内のすべてのインスタンスにデプロイする場合は、次のようにadmin_client.jarを使用できます。
> cd ORACLE_HOME/j2ee/home > java admin_client.jar deployer:cluster:opmn://<host>:<opmnPort>/<oc4jInstanceName> <adminID> <adminPassword> -deploy -file <pathToArchiveFile> -deploymentName <appName>
<host>には、クラスタ内の任意のホストを指定できます。
<opmnPort>には、OPMNがリスニングするポートを指定します。このポートは、opmn.xmlファイルに記載されています。
<oc4jInstanceName>には、アプリケーションのデプロイ先のOC4Jインスタンスを指定します。たとえば、"home"インスタンスにデプロイするには、homeを指定します。
<adminID>と<adminPassword>には、管理者のIDとパスワードを指定します。通常、adminIDはoc4jadminです。
<pathToArchiveFile>には、デプロイするEAR、WAR、またはJARファイルへのフルパスを指定します。
<appName>には、アプリケーション名を指定します。
デプロイについては、コマンドラインで指定できるオプションが他にもあります。詳細は、『Oracle Containers for J2EEデプロイメント・ガイド』を参照してください。
インスタンスを既存のトポロジに追加する手順は次のとおりです。
インスタンスをトポロジから削除する手順は次のとおりです。
Oracle HTTP Server内のmod_oc4jモジュールは、リクエストをOC4Jプロセスに委任します。Oracle HTTP ServerがOC4Jに対するURLのリクエストを受信すると、Oracle HTTP Serverではそのリクエストをmod_oc4jモジュールにルーティングします。mod_oc4jモジュールでは、このリクエストをOC4Jプロセスにルーティングします。OC4Jプロセスで障害が発生すると、OPMNはその障害を検出し、mod_oc4jは、障害の発生したOC4Jプロセスが再起動されるまでそのOC4Jプロセスにリクエストを送信しません。
mod_oc4jは、OC4Jプロセスに対するリクエストをロード・バランシングするように構成できます。Oracle HTTP Serverでは、mod_oc4jを経由して、各種のロード・バランシング・ポリシーをサポートしています。ロード・バランシング・ポリシーは、ネットワーク・トポロジやホスト・マシンの性能に応じて、パフォーマンス上のメリットだけでなく、フェイルオーバーや高可用性も実現します。
mod_oc4jには、必要なルーティングのタイプと複雑さに応じて、異なるロード・バランシング・ルーティング・アルゴリズムを指定できます。ステートレス・リクエストは、mod_oc4j.confで指定されたアルゴリズムに基づいて使用可能な宛先にルーティングされます。ステートフルHTTPリクエストは、セッションIDを使用して前回のリクエストを処理したOC4Jプロセスに転送されます。ただし、mod_oc4jがOPMNとの通信によってそのプロセスが使用不可であると判断した場合を除きます。その場合、mod_oc4jは、指定されたロード・バランシング・プロトコルに従って使用可能なOC4Jプロセスにそのリクエストを転送します。
デフォルトでは、すべてのOC4Jインスタンスに同じ重みが付けられており（すべてのインスタンスに1の重みが付けられている）、mod_oc4jではラウンド・ロビン方法を使用して、リクエストの転送先のOC4Jインスタンスを選択します。OC4Jインスタンスの重みは、トポロジ内の他の使用可能なOC4Jインスタンスの重みに対する比率として扱われ、インスタンスが処理するリクエストの数が定義されます。リクエストが確立済のセッションに属する場合、mod_oc4jでは、そのセッションを開始したのと同じOC4Jインスタンスおよび同じOC4Jプロセスにそのリクエストを転送します。
mod_oc4jのロード・バランシング・オプションでは、リクエストの送信先OC4Jインスタンスを判断するとき、OC4Jインスタンス上で実行されているOC4Jプロセスの数を考慮しません。OC4Jインスタンスの選択は、インスタンスに対して構成済の重みと、その可用性に基づいて行われます。
mod_oc4jロード・バランシング・ポリシーを変更するには、ORACLE_HOME/Apache/Apache/conf/mod_oc4j.confファイル内のOc4jSelectMethodディレクティブとOc4jRoutingWeightディレクティブを設定します。
mod_oc4j.confファイルの<IfModule mod_oc4j.c>セクションで、Oc4jSelectMethodディレクティブを表3-5に示す値のいずれかに設定します。Oc4jSelectMethodディレクティブをroundrobin:weightedまたはrandom:weightedに設定した場合は、Oc4jRoutingWeightディレクティブも設定して重みを指定します（次の手順を参照）。
ルーティング・アルゴリズムを選択する際のヒントについては、「mod_oc4jのロード・バランシング・アルゴリズムの選択」を参照してください。
例:
Oc4jSelectMethod random:local
メトリックベースのロード・バランシングの設定方法の詳細は、『Oracle HTTP Server管理者ガイド』の付録「mod_oc4jを使用するロード・バランシング」を参照してください。
Oc4jSelectMethodディレクティブを重みベースの方法（つまりroundrobin:weightedまたはrandom:weighted）に設定した場合は、Oc4jRoutingWeightディレクティブも設定して重みを指定します。Oc4jRoutingWeightの構文は次のとおりです。
Oc4jRoutingWeight hostname weight
Oc4jRoutingWeightディレクティブを設定しない場合は、デフォルトの重みの1が使用されます。
例: 3つのインスタンス（A、BおよびC）で構成されるトポロジがあり、BとCがAの2倍のリクエストを受信するように設定するには、すべてのインスタンスに対して次のディレクティブを設定します。
Oc4jSelectMethod roundrobin:weighted Oc4jRoutingWeight hostB 2 Oc4jRoutingWeight hostC 2
hostAのOc4jRoutingWeightの設定はオプションです。指定しない場合はデフォルト値の1が使用されるためです。
> opmnctl @cluster restartproc ias-component=HTTP_Server
mod_oc4jで使用するロード・バランシング・オプションを決定する際は、次のガイドラインが役に立ちます。
JMSの高可用性の構成方法の詳細は、『Oracle Containers for J2EEサービス・ガイド』の第4章「Oracle Enterprise Messaging Serviceの使用」を参照してください。
表3-6は、Oracle HTTP ServerおよびOC4Jにおける高可用性機能の要約を示しています。
EJBクラスタリングを有効にすると、中間層OracleAS ClusterのOC4Jインスタンス間のJNDIネームスペースのレプリケーションも有効になります。1つのOC4Jインスタンス内のJNDIネームスペースへの新規バインドは、中間層OracleAS Cluster内の他のOC4Jインスタンスに伝播されます。再バインドとアンバインドはレプリケートされません。
このレプリケーションは、各OracleAS Cluster（OC4J）の有効範囲外で行われます。つまり、OC4Jインスタンス内の複数のOracleAS Cluster（OC4J）は、同じレプリケート済JNDIネームスペースへの可視性を持ちます。
JNDIの詳細は、『Oracle Containers for J2EEサービス・ガイド』を参照してください。
EJBクライアント・ルーティングでは、Oracle HTTP ServerとサーブレットおよびJSP間でmod_oc4jが提供するルーティング機能は、EJBクラスによって実行されます。クライアントは、Remote Method Invocation（RMI）プロトコルを使用してEJBを起動します。RMIプロトコル・リスナーは、RMI構成ファイルrmi.xmlによってOC4Jインスタンスごとに設定されます。これはWebサイト構成とは別です。EJBクライアントとOC4Jツールは、構成されたRMIポートを使用してOC4Jサーバーにアクセスします。OPMNによって、RMIリスナーが使用できる一連のポートが指定されます。
EJBルックアップで「opmn:ormi://」接頭辞文字列を使用すると、クライアントは割り当てられたRMIポートを自動的に取得します。ロード・バランシングとクライアント・リクエスト・ルーティングは、使用可能な様々なOC4Jプロセスを選択するOPMNによって提供されます。このロード・バランシングに使用されるアルゴリズムは、ランダム・アルゴリズムです。高可用性を確保するために、カンマで区切られた複数のOPMN URLを使用できます。
Oracle Application Server Java Object Cacheでは、OC4Jにデプロイされたアプリケーションに対する高可用性ソリューションとして機能する分散キャッシュを提供します。Java Object Cacheは、あらゆるJavaプラットフォーム上のあらゆるJavaアプリケーションで使用可能なJavaオブジェクトのインプロセス・キャッシュです。これにより、アプリケーションで、複数のリクエストおよびユーザー間でオブジェクトを共有し、複数のプロセス間でオブジェクトのライフサイクルを調整することが可能になります。
Java Object Cacheは、同じOracleAS Cluster（OC4J）、Oracle Application Serverインスタンスまたは全般的なOracle Application Server Clusterに属していないプロセスも含めた、OC4Jプロセス間でのデータ・レプリケーションを可能にします。
Java Object Cacheを使用すると、オブジェクトの生成元のアプリケーションがどれであるかにかかわらず、共有Javaオブジェクトがローカルにキャッシュされるため、パフォーマンスが向上します。これにより、可用性も向上します。オブジェクトのソースが使用できなくなっても、ローカルにキャッシュされたバージョンは引き続き使用できます。
Java Object Cacheの使用方法の詳細は、『Oracle Containers for J2EEサービス・ガイド』の「Java Object Cache」を参照してください。
|
 Copyright © 2007, Oracle. All Rights Reserved. |
|