Oracle® Fusion Middleware Oracle Enterprise Repositoryインストレーション・ガイド 11g リリース1 (11.1.1.7) B66435-03 |
|
前 |
次 |
この章ではOracle Enterprise Repositoryの概要を示し、クラスタ化環境に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クラスタリングを実行する場合、データベース・オプションへの移動設定を使用する前に |
ドメインを別のサーバーにパッケージ化および解凍する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アプリケーションに読み込む場合、常にプロパティ・ファイルが優先されます。アプリケーションでは、まずデータベース内でプロパティおよび対応する値を検索してから、プロパティ・ファイル内を検索します。データベースから読み込まれたプロパティは、ファイル内の対応する値で上書きされます。ただし、ファイルがない場合、データベース内のプロパティは参照のみが行われ、データベース内にのみ存在するプロパティが上書きされることはありません。
この手順は、アプリケーションのデプロイから始まります。
「管理」画面で、左ペインの「システム設定」をクリックします。図5-1に示すように、メイン・ペインに「システム設定」セクションが表示されます。
下部にスクロールし、設定をデータベースに移動するボタンをクリックします。
確認メッセージが表示されます。
クラスパスからプロパティ・ファイルを削除します。
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.example.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を超えたためにクラスタ・メンバーが無効になった場合、アクティブ化する方法はサーバーの再起動のみです。 |
各クラスタ・メンバーの標準出力ログにメッセージが送信されます。
「単一サーバー・モードで実行しています」
Oracle Enterprise Repositoryのクラスタリングが構成されていないため、アプリケーションは単一サーバー・モードで実行されていることを示します。
「次のsync-urlで、マルチ・サーバー・モードで実行しています」
Oracle Enterprise Repositoryのクラスタリングが機能しており、アプリケーションはクラスタ化モードで実行されていることを示します。
cachesyncurl
cluster.propertiesファイル内のcachesyncurlの値は、/cachesyncのパスが追加された個別のノードのインスタンスと同じURLを参照します。ほとんどのクラスタ構成には、クラスタ化されたサーバー内の各ノードをロード・バランシングするプロキシ・サーバーがあります。
例:
ノード1: cachesyncurl=http://node1.example.com:7101/oer
ノード2: cachesyncurl=http://node1.example.com:7101/oer
Oracle Enterprise Repositoryの診断画面からクラスタリング診断ページを表示することで、クラスタリングのインストールを検証することもできます。クラスタ診断ページを表示するには、診断画面の「クラスタ情報」をクリックします。このページには、クラスタに登録されているすべてのサーバーに関する情報、およびサーバー間通信に関する情報がリストされます。
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サーバーの構成に関する項を参照してください。