| Oracle® Fusion Middleware Oracle Enterprise Repositoryインストレーション・ガイド 11g リリース1 (11.1.1.6.0) B66435-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Enterprise Repositoryインストレーション・ガイド 11g リリース1 (11.1.1.6.0) B66435-01 |
|
前 |
次 |
この章では概要を示し、クラスタ化環境にOracle Enterprise Repositoryをインストールする方法について説明します。
この章には次の項が含まれます:
Oracle Enterprise Repositoryでは、各アプリケーション・サーバー上のサーバー側キャッシュが使用されます。使用可能な場合のみ、キャッシュされたデータが使用されます。それ以外の場合は、データベースがデータ・コンテンツをキャッシュおよびアプリケーションに配信します。
Oracle Enterprise Repositoryをクラスタ内で実行する場合、クラスタ・メンバーはHTTPを使用して相互に通信する必要があります。あるクラスタ・メンバー上で編集を行うと、そのクラスタ・メンバー上のキャッシュされた要素が無効になり、編集内容が他のクラスタ・メンバーに渡されます。これは、cachesyncurlと呼ばれるシステム・プロパティによって実行されます。このシステム・プロパティは、アプリケーションへのURLを有効な値として受け入れます。
システムの起動時に、cachesyncurlがデータベースに書き込まれ、データベースから他のサーバーのURLのリストが取得されます。クラスタの新規メンバーの存在を通知するメッセージが、検出されたすべてのURLに送信されます。その後、各サーバーはデータベースからサーバー・リストをリフレッシュします。サーバーが正常に停止するときに、リストから値が削除され、キャッシュ・リフレッシュ通知がサーバー・リストにブロードキャストされます。
編集によってローカル・キャッシュ内の要素が無効になると、無効にする必要があるキャッシュ要素を通知するメッセージが他のすべてのサーバーに送信されます。メッセージを受信すると、指定した要素がキャッシュから削除されます。その後データを要求すると、キャッシュにはデータが含まれていないため、まずデータをキャッシュに格納してから、データベースによってデータがアプリケーションに配信されます。
クラスタ化とインストールの要件
セッションの類似性
サーバー側のHTTPキャッシュ通信
オプション
フェイルオーバー
セッション管理および永続セッションが必要
ロード・バランシング
サポートされているアプリケーション・サーバー
ここにリストされているアプリケーション・サーバーは、現在Oracle Enterprise Repositoryのクラスタ化に使用する目的でサポートされています。
Oracle WebLogic Server
IBM WebSphere Application Server
前述のアプリケーション・サーバーのサポートされているバージョンの詳細は、次のOracle Enterprise Repositoryの索引ページにあるサポートされている構成に関するドキュメントを参照してください。
http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html
クラスタ化環境へのOracle Enterprise Repositoryのインストール
クラスタ化環境にOracle Enterprise Repositoryをインストールする手順は、次のとおりです。
Oracle Enterprise Repositoryをインストールして構成します。
Oracle Enterprise Repositoryをホストするクラスタ化環境を作成します。
クラスタ化されたアプリケーション・サーバーのメンバーにOracle Enterprise Repositoryアプリケーションをデプロイします。クラスタのメンバー上でアプリケーションのデプロイメントを検証します。
アプリケーション・プロパティをデータベースに移動します。
クラスタを停止します。
他のすべてのクラスタ・メンバーにアプリケーションをインストールしてデプロイします。
各クラスタ・メンバー上でcluster.propertiesファイルを構成します。
クラスタおよびすべてのメンバーを起動します。
クラスタを検証します。
Oracle Enterprise Repositoryのインストールの詳細は、第2章「Oracle Enterprise Repositoryのインストール」を参照してください。
アプリケーション・サーバー上にOracle Enterprise Repositoryをインストール、デプロイおよび検証する方法の詳細は、第3.1項「アプリケーション・サーバーの構成」を参照してください。(たとえば、すべてのサンプル名を変更する必要があります。)
|
注意: JMSクラスタリングを実行する場合、データベース・オプションへの移動設定を使用する前にcmee.eventframework.clustering.enabledを有効にする必要があります。 |
ドメインを別のサーバーにパッケージ化および解凍するWLS標準フォームの詳細は、次の場所にある「packおよびunpackコマンドを使用したテンプレートとドメインの作成」を参照してください。
http://download.oracle.com/docs/cd/E12840_01/common/docs103/pack/commands.html
WebLogicまたはWebSphereでのクラスタ化の詳細は、アプリケーション・サーバーのドキュメントおよび組織の標準を参照してください。
WebLogicの場合:
Oracleから入手できる『WebLogic Serverクラスタの使用』を参照してください。
WebSphere Application Serverの場合:
WebSphere Software Information Centerを参照してください。特定のappserverバージョンのドキュメントを探し、「All topics by feature」→「Servers」→「Clusters」→「Balanced workloads with clusters」にナビゲートします。
プロパティをOracle Enterprise Repositoryアプリケーションに読み込む場合、常にプロパティ・ファイルが優先されます。アプリケーションでは、まずデータベース内でプロパティおよび対応する値を検索してから、プロパティ・ファイル内を検索します。データベースから読み込まれたプロパティは、ファイル内の対応する値で上書きされます。ただし、ファイルがない場合、データベース内のプロパティは参照のみが行われ、データベース内にのみ存在するプロパティが上書きされることはありません。
この手順は、アプリケーションのデプロイで開始します。
「Admin」画面で、左ペインの「System Settings」をクリックします。図5-1に示すように、メイン・ペインに「System Settings」セクションが表示されます。
下部にスクロールし、「Move settings to database」ボタンをクリックします。
確認メッセージが表示されます。
クラスパスからプロパティ・ファイルを削除します。
appserverを再起動します。
アプリケーション・サーバー内で構成ファイルのフォルダ(通常は./WEB-INF/classes/フォルダまたはoer_home内にあります)を探します。
構成フォルダから次にリストされているプロパティ・ファイルを削除します。
enterprise.properties
ldap.properties
containerauth.properties
eventing.properties
juddi.properties
openapiserverlog.properties
これらのプロパティは、データベース内のentSettings表に書き込まれます。
cmee.propertiesファイルを変更します。URL値を含むプロパティ値を除く、すべてのプロパティ値を削除します。クラスタ・メンバーへのロード・バランス・アクセスに使用されているプロキシ・サーバー・パスを指すように、URL参照を更新します。
ここで、Oracle Enterprise Repositoryクラスタに直接アプリケーションを再デプロイします。
|
注意: この手順がプロパティ・ファイルではなくデータベースに書き込まれた後、プロパティが有効になります。 |
各クラスタ・メンバー上でcluster.propertiesファイルを構成する手順は、次のとおりです。
各クラスタ・メンバーを停止します。
各クラスタ・メンバー上でcluster.propertiesと呼ばれるファイルを作成します。このファイルは、他のすべての.propertiesファイルと同じ場所にあります。
展開されたディレクトリ・デプロイメントの場合、この場所はwebappの下のWEB-INF/classesディレクトリになります。
earファイル・デプロイメントの場合、この場所はoer_homeディレクトリになります。
cluster.propertiesの内容は、cmee.propertiesファイルのプロパティcmee.server.paths.servletに基づいています。ただし、パス内のホスト名は、クラスタ全体のプロキシ・ホスト名ではなく、クラスタ・メンバーのホスト名を参照する必要があります。
cluster.properties #cluster.properties cachesyncurl=http://<SERVLET-PATH>/<APP_PATH> Example: #cluster.properties cachesyncurl=http://node1.oracle.com:7101/oer # oer is the name of the Oracle Enterprise Repository application during # deployment Other properties that are optional # alias is used as an alternate/convenient name to refer # to the server # example: server1 # default: same value as =cachesyncurl= alias=EclipseServer # registrationIntervalSeconds is the number of seconds between # attempts to update the server's registration record in the database # default: 120 registrationIntervalSeconds=120 # registrationTimeoutSeconds is the number of seconds before a server # is considered to be inactive/not running # make sure this value is higher than the registrationIntervalSeconds # default: 240 registrationTimeoutSeconds=240 # maxFailures is the number of consecutive attempts that are made # to deliver a message to another server after which it is determined # to be unreachable # default: 20 maxFailures=20 # maxQueueLength is the number of messages that are queued up to # send to another server after which server are determined to be # unreachable # default: 4000 maxQueueLength=5000 # email.to is the address of the email recipient for clustering status # messages email.to=jsmith@company.com # email.from is the address of the sender for clustering status messages email.from=jsmith@company.com # email.subject is the subject line of the message for clustering status # messages email.subject=Oracle Enterprise Repository Clustering communication failure # email.message is the body of the message for clustering status messages email.message=This is an automated message from the Oracle Enterprise Repository informing you of a cluster member communication failure.
cluster.propertiesファイルの例
cachesyncurl=http://server.example.com:7221/cluster01alias=node1 registrationIntervalSeconds=120registrationTimeoutSeconds=240 maxFailures=20 maxQueueLength=5000 email.to=jsmith@example.com email.from=jsmith@example.com email.subject=Oracle Enterprise Repository Clustering communication failure email.message=This is an automated message from the Oracle Enterprise Repository informing you of a cluster member communication failure
|
注意:
|
各クラスタ・メンバーを再起動します。
|
注意: maxFailuresを超えたためにクラスタ・メンバーが無効になった場合、アクティブ化する方法はサーバーの再起動のみです。 |
各クラスタ・メンバーの標準出力ログにメッセージが送信されます。
「running in single server mode」
Oracle Enterprise Repositoryクラスタリングが構成されていないため、アプリケーションは単一サーバー・モードで実行されていることを示します。
「running in multi server mode with a sync-url of...」
Oracle Enterprise Repositoryクラスタリングが機能しており、アプリケーションはクラスタ化モードで実行されていることを示します。
cachesyncurl
cluster.propertiesファイル内のcachesyncurlの値は、/cachesyncのパスが追加された個別のノードのインスタンスと同じURLを参照します。ほとんどのクラスタ構成には、クラスタ化されたサーバー内の各ノードをロード・バランシングするプロキシ・サーバーがあります。
例:
Node1: cachesyncurl=http://node1.oracle.com:7101/oer
Node2: cachesyncurl=http://node1.oracle.com:7101/oer
Oracle Enterprise Repositoryの「Diagnostics」画面からクラスタリング診断ページを表示することで、クラスタリングのインストールを検証することもできます。Cluster Diagnosticページを表示するには、「Diagnostics」画面の「Cluster Info」をクリックします。このページには、クラスタに登録されているすべてのサーバーに関する情報、およびサーバー間通信に関する情報がリストされます。
Oracle HTTP Serverの構成ファイル
Oracle HTTP Serverを使用してロード・バランサからノードにルーティングする場合、HTTP Serverの構成ファイル(httpd.conf)に/oerおよび/oer-webの2つのエントリを含める必要があります。サンプルのhttpd.confファイルを次に示します。
<VirtualHost 10.0.0.1:80>
ServerName 10.0.0.1:80
<IfModule mod_weblogic.c>
SecureProxy OFF
# TrustedCAFile /usr/local/apache2/ca.pem
RequireSSLHostMatch false
Debug ERR
DebugConfigInfo ON
ErrorPage /error.html
WLLogFile logs/worker_matchproxy.log
WLTempDir /tmp
KeepAliveEnabled ON
KeepAliveSecs 15
HungServerRecoverSecs 30
MaxSkipTime 10
ConnectRetrySecs 5
</IfModule>
<Location /console>
SetHandler weblogic-handler
WebLogicCluster 10.0.0.2:7001
</Location>
<Location /oer_fa_cluster>
SetHandler weblogic-handler
WebLogicCluster 10.0.0.3:7101,10.0.0.4:7101
</Location>
<Location /oer_fa_cluster-web>
SetHandler weblogic-handler
WebLogicCluster 10.0.0.3:7101,10.0.0.4:7101
</Location>
</VirtualHost>
この例では、ホスト10.0.0.1はクラスタ・マシンをプロキシするためのHTTPサーバー、ホスト10.0.0.2は管理サーバー、ホスト10.0.0.3および10.0.0.4はOracle Enterprise Repository管理対象サーバーです。
Oracle HTTP Serverの詳細は、http://download.oracle.com/docs/cd/E12840_01/wls/docs103/plugins/apache.htmlを参照してください。
クラスタ・ノードが集中化された管理コンソールを介してデプロイされる場合、cluster.propertiesファイルがなくても適切なOracle Enterprise Repositoryクラスタリング操作が許可されるように、JVMパラメータの適用が必要なことがあります。
このJVMパラメータは、クラスタ内のメンバーごと、または管理対象サーバーの起動コマンド・ファイル内で静的に適用する必要があります。このJVMパラメータは、WebLogic ApplicationサーバーのJAVA_OPTIONS環境変数内、またはTomcatサーバーのCATALINA_OPTSまたはJAVA_OPTS内で設定できます。JVMパラメータは次のようになります。
-Dcmee.cachesyncurl=http://<member host name>:<port>/<APP_PATH>
|
注意: この機能は、アセット登録プロセスを自動化するためにアドバンスト登録フロー・サブシステムを使用する場合のみ使用できます。また、JMSクラスタリングは、Oracle Enterprise Repository内の組込みのActiveMQ JMSサーバーにのみ適用され、外部JMSサーバーには適用されません。ActiveMQを使用している場合、JDBC永続性が必要です。 |
アドバンスト登録フロー・サブシステムを使用するOracle Enterprise Repositoryクラスタ化環境では、クラスタ内の各メンバーのOracle Enterprise Repositoryサーバーには、信頼性およびスケーラビリティの向上のために、組込みのActiveMQ JMSサーバーがあります。たとえば、2ノード・クラスタの場合は、2つのOracle Enterprise Repositoryサーバー(server01とserver02など)が1つの組込みのJMSサーバーに割り当てられます。「外部統合: イベント」で説明するように、JMSサーバー・クラスタリングはOracle Enterprise Repositoryのイベント・システム設定を使用して有効化します。組込みのJMSサーバーでクラスタ化を有効にした場合は、server01とserver02でそのサーバーの接続URL情報を指定する必要があります。
詳細は、Oracle Fusion Middleware Oracle Enterprise Repository構成ガイドのOracle Enterprise RepositoryのJMSサーバーの構成に関する項を参照してください。
