| Oracle® Fusion Middleware高可用性ガイド 11g リリース1(11.1.1) B55898-04 |
|
 前 |
 次 |
Oracle Enterprise Content Management(ECM)Suiteは、Oracle Fusion Middlewareコンポーネントの1つで、コンテンツを管理するために設計された統合的な製品スイートです。これは、業界で最も統合化されたエンタープライズ・コンテンツ管理プラットフォームです。これを使用して、業界最先端のドキュメント管理、Webコンテンツ管理、デジタル資産管理、レコード管理機能を活用し、ビジネス・アプリケーションを構築することができます。コンテンツおよびアプリケーションの戦略的なエンタープライズ・コンテンツ管理インフラストラクチャを構築することで、コストの削減、エンタープライズを横断する容易なコンテンツの共有、リスクの最小化、時間を浪費する高価な手動プロセスの自動化、および複数のWebサイトの単一のプラットフォームへの統合化を支援します。
Oracle ECMには次のような利点があります。
優れたユーザビリティ: エンド・ユーザー、ワークグループ、コンテンツ・エキスパート、プロセスの所有者、管理者、およびWebマスターに対する組込みのサポート
最適化された管理: ドキュメント、ファイル、Webコンテンツ、およびデジタル資産を安全に管理するための統合されたアーキテクチャ
ホットプラッガブル: Oracleおよびサード・パーティのリポジトリ、セキュリティ・システム、およびエンタープライズ・アプリケーションに対するインストール時からのサポート
この章では、Oracle Enterprise Content Managementコンポーネントについて、高可用性の観点から説明します。この章では、高可用性を備えたデプロイメントの設計に重要な単一インスタンスの概念について概要を説明します。
この章の項目は次のとおりです。
この項では、Oracle Imaging and Process Management(Oracle I/PM)の概要およびOracle I/PMの高可用性環境の設計とデプロイについて説明します。
Oracle I/PMでは、プロセス指向のイメージング・アプリケーション、およびOracle E-Business SuiteやPeopleSoft Enterpriseなどのイメージ対応のビジネス・アプリケーションに焦点を当てたスケーラブルなソリューションを組織に提供します。これにより、イメージの注釈およびマークアップの対応、ルーティングおよび承認の自動化、大量のアイテムに対応する高容量アプリケーションのサポートを実現します。
Oracle I/PMは、ビジネス・トランザクションまたはプロセスの一環としてそれぞれのドキュメントを管理する、トランザクション・コンテンツ管理ツールです。トランザクション・ドキュメントは、通常は比較的短期間のトランザクションの発生時に重要になります。
図11-1は、Oracle I/PMの内部コンポーネント(Oracle I/PMパッケージ内のコンポーネント)を示しています。
Oracle I/PMの構成の設定を開始する前に、次の点に注意してください。
Oracle I/PMは、Oracle Universal Content Manager(Oracle UCM)リポジトリの最上位にある比較的薄い機能層です。Oracle I/PMでは、Oracle UCMでイメージの側面を提供します。リポジトリによって、リソース利用の大部分が実行されます。そのため、すべてのOracle I/PMインスタンスにOracle UCMインスタンスを配置することでOracle UCMを構成するようにお薦めします。この構成によって、ハードウェアを最適に利用できます。
Oracle I/PMの最大のパフォーマンス要素は、ドキュメント・コンテンツの移動です。通常、Oracle I/PMは、毎日数十万ものドキュメントを収集するような大容量シナリオで使用されます。これらのドキュメントは、一日中、頻繁に検索、取得および表示されます。システム内外とのドキュメント・コンテンツのやりとりは、パフォーマンスに大きく影響します。Oracle I/PMでは、平均25KバイトのサイズのTIFドキュメントを保存します。ただし、TIFドキュメントには複数のページが含まれていることがあり、それによってドキュメントのサイズは増加します。さらに、Oracle I/PMでは、その他にも様々なサイズの400のファイル形式をサポートしています。これらのファイルには、より大きなサイズのものもあります。
Oracle I/PMは、WebLogic Server管理対象サーバー環境で稼動するJEEアプリケーションです。これには、次のコンポーネントおよびサブコンポーネントが含まれます。
サーブレット: Oracle I/PMには、REST APIおよびI/PMアプレット・ビューアがシステムのパブリックAPI関数にアクセスするメカニズムを提供する、内部で使用するためのサーブレットがあります。
EJB: Oracle I/PMでは、内部的にいくつかのEJBの概念を利用していますが、外向きのEJBはありません。
Oracle I/PMでは、JMSを使用してその入力エージェントとそのBPELエージェント・メッセージ駆動Bean(MDB)の両方を駆動します。図11-1で、BPELエージェントはBPEL MDBの集合です。これらのキューは永続するため、配信は保証されます。これによりクラスタ間でも作業が配信されます。
Oracle I/PMでは、JAX-WSおよびJAX-Bを使用して、そのWebサービスおよびシリアライズ・メカニズムを実装します。
Oracle I/PMでは、定義の保存および構成にTopLinkを使用します。この目的は、一般的にはアプリケーションおよび検索を定義することです。また、TopLinkはユーザーおよびシステム・プリファレンスの取得にも使用されます。
Oracle I/PMでは、リポジトリからのドキュメントの取得や表示するドキュメントの処理に内部キャッシュとしてJava Object Cache(JOC)を使用します。これらのキャッシュはローカルにのみ存在し、サーバー間で共有することはありません。
AXFとBPEL間の相互作用は、EJBを介してRMIを使用するBPELリモートAPIによって実行されます。
|
注意: Oracle I/PMでは、複数コンポーネントのトランザクションをサポートしないため、Java Transaction API(JTA)を使用しません。 |
Oracle I/PMにはステートフルなUIを備えていますが、セッション・レプリケーションをサポートしていないため、スティッキーなロード・バランシング・ルーターが必要になります。
Oracle I/PM APIを使用したOracle I/PMサービスの呼出しは、ステートレスです。
Oracle I/PMのコアでは、中央API、UI、およびWebサービス・インタフェースを含むサービスベースのアーキテクチャを使用します。このADFベースのUIは、Oracle I/PMのパブリックAPIを使用して、コア・サービスにアクセスします。エンド・ユーザーは、Webサービスを開始してこのAPIにアクセスします。Java開発者には、より便利なパッケージでこれらのWebサービスを公開するシンJavaクライアント・ライブラリも提供します。
Oracle I/PMには、バックグラウンド処理を実行するための次のエージェントがあります。
入力エージェントは、インジェストするドキュメントの受信リストの入力ディレクトリを監視します。
BPELエージェントは、ドキュメント作成イベントに応答して、そのドキュメントおよびURLからメタデータを含む新しいBPELプロセス・インスタンスをアタッチするドキュメントに作成します。図11-1で、BPELエージェントはBPEL MDBの集合です。
チケット・エージェントは、タイマーなしで呼び出されるステートレスのEJBです。これは、図11-1には示されていません。チケット・エージェントは、有効期限が切れたURLチケットの特定および削除を行います。これらのチケットは、パラメータを使用しないクリーンなURLを作成するために使用されます。
Oracle I/PMサービスでは、スキャン・ドキュメントの保存にOracle UCMドキュメント・リポジトリを使用します。Oracle UCMリポジトリは、RIDCと呼ばれるOracle UCMで提供されるTCP/IPストックベースの接続メカニズムを介してOracle I/PMと通信するスタンドアロン製品です。
Oracle I/PMは、WebLogic Server管理対象サーバーで稼動するJEEアプリケーションです。これは特定の障害検出を提供するものではありませんが、WebLogic Serverノード・マネージャを使用して継続的にサーバーを稼働することができます。
Oracle I/PMプロセス・ライフサイクルのステップは次のとおりです。
ドメイン構成が実行されると、通常は、Oracle I/PMは初期化されます。Oracle I/PMが起動して最初のユーザーがログオンすると、残りの初期化が実行されます。
最初のユーザーがログオンしたときに、そのユーザーはそれ以降の他のユーザーに権限を付与できるという前提の下で、完全なセキュリティ権限が付与されます。Oracle I/PMは、セルフ・シード・データベース・セキュリティ・メカニズムを提供します。Oracle I/PMが起動したときにセキュリティが定義されていない場合、システムに最初にログインしたユーザーはすべてのものにアクセスする権限が付与されます。
Oracle I/PMが初めて起動した直後は、Oracle I/PMは「空」です。Oracle UCMドキュメント・リポジトリおよびBPELサーバーへの接続は、管理ユーザーの責任で作成します。
最初のUCM接続が作成されると、Oracle I/PMで使用するOracle UCMリポジトリは初期化されます。
ここで、アプリケーション、検索、入力などを含む適切なビジネス・オブジェクトを作成する必要があります。管理ユーザーは、これらをゼロから作成するかわりに、そのビジネス・オブジェクトをインポートすることもできます。
ステップ1でエージェント・ユーザーが指定された場合、エージェントはサーバーが再起動した後JMSキュー・イベントがその処理を開始するのを待ちます。
サーバーが稼働してJAX-WSメカニズムの準備ができたら、Oracle I/PMはクライアント・リクエストを受信できます。
Oracle I/PMには、次のような構成アーティファクトがあります。
すべてのOracle I/PM構成データは、Oracle I/PMデータベースの中に保存されます。構成は、ローカル・ファイルには保存されません。構成パラメータは、(Enterprise ManagerまたはWLSTから使用できる)適切なMBeanまたはOracle I/PMのUIを介して公開されます。
その他のOracle I/PM構成アーティファクトは、第11.1.1.1.5項「Oracle I/PMの外部依存性」で説明されている定義オブジェクトです。
Oracle I/PMでは、UCMプロファイルや情報フィールドの管理など、Oracle I/PMで使用するOracle UCMのカスタマイズにOracle UCMメカニズムを使用します。
Oracle I/PMには、次のような外部依存性があります。
Oracle I/PMには、構成を格納するためのデータベースが必要です。データベースは最初にRCUを介して作成され、WebLogic Server JDBCデータ・ソースを介して管理されます。データベースには、TopLinkを介してアクセスします。
Oracle I/PMでは、JAX-WS、JAX-B、ADF、TopLink、JMSなどの様々なOracleおよびJavaテクノロジを活用します。これらはインストールに含まれ、外部構成は不要です。
Oracle I/PMには、構成用のMbeanが用意されています。これらは、WLSTおよびEM Mbeanブラウザを介して使用できます。Oracle I/PMには、いくつかのカスタムWLSTコマンドが用意されています。
Oracle I/PMは、Oracle UCMリポジトリが存在するかどうかに依存しています。
次のクライアントは、Oracle I/PMに依存します。
Oracle I/PM UIは、パブリック・ツールキット(Oracle I/PM API)で構築されます。UIおよびコアAPIは、同じEARファイルで配信されます。
Oracle I/PMには他の製品と統合するためのWebサービスが用意されています。また、他の製品と統合するためのJavaの便利な機能としてこれらのWebサービスをラップするJavaクラスのセットも用意されています。
Oracle I/PMには、他のアプリケーションとOracle I/PMの検索およびコンテンツとの相互作用を円滑にするURLツールキットが用意されています。
Oracle I/PMには、Webプレゼンテーションのドキュメントの個々のページを参照するためのRESTツールキットが用意されています。
クライアントは、次のようにOracle I/PMと接続します。
JavaクライアントまたはWebサービス用のJAX-WSを介した接続。これらの接続はステートレスで、単一の機能を実行します。
URLおよびRESTツールにアクセスするためのHTTPを介した接続
RESTリクエストはステートレスで、単一の機能を実行します。
URLツールはOracle I/PM UIにログインして、関連するUIコンポーネントを含むよりステートフルな体験を提供します。
Oracle/IPMは、WebLogic Server上にデプロイされるJEEアプリケーションです。ログ・メッセージはすべて、アプリケーションがデプロイされるWebLogic Serverのサーバー・ログ・ファイルに記録されます。
診断ログ・ファイルのデフォルトの場所は次のとおりです。
WL_HOME/user_projects/domains/domainName/servers/serverName/logs/serverName-diagnostic.log
Oracle Enterprise Managerを使用して、これらのログ・ファイルの検索および解析を簡単に行えます。
この項では、Oracle I/PMを2ノードのクラスタ構成による高可用性で使用する場合の概要について説明します。
図11-2は、Oracle I/PMの高可用性アーキテクチャを示しています。
Oracle I/PMは、標準的な2ノードのアクティブ/アクティブの高可用性構成で構成できます。Oracle I/PMのUI層はアクティブ・サーバー間でフェイルオーバーされませんが、その他のバックグラウンド・プロセスはフェイルオーバーされます。
図11-2は、Oracle I/PMの高可用性構成を示しています。
Oracle I/PMノードは、お互いに同一なレプリカです。高可用性構成のすべてのノードは、同一のサービスを実行し、中央の構成データベースで構成されます。すべてのサーバーはこのデータベースからその構成を取得します。
Oracle I/PMノードのフロントエンドには、スティッキーなセッション・ルーティングを持つロード・バランシング・ルーターを使用する必要があります。この目的のためにOracle HTTP Serverを使用できます。
Oracle I/PMは、WebLogic Serverクラスタ内でもクラスタなしでも実行できます。
すべてのOracle I/PMインスタンスは、同じデータベース接続を共有する必要があります。そうすることで、Oracle RACの高可用性の潜在機能が高まります。Oracle I/PMは、データベース処理にTopLinkを使用します。
Oracle I/PMには共通の共有ディレクトリが必要です。入力エージェントはインジェスト用にステージングされたインバウンド・データファイルをここから取得します。入力エージェントが入力定義ファイルを取得したら、関連する入力ファイルおよびイメージの処理は、そのWebLogic Serverインスタンスから分離されます。
Oracle I/PMのエージェント(入力エージェント、BPELエージェント)は、クラスタ内のWebLogic Serverに存在するOracle I/PMアプリケーションの不可欠な機能として起動します。JMSキューに存在する未処理の作業(これらは障害を越えて永続的に保存されます)に基づいて、即座に処理が開始されます。入力エージェントは、インバウンド・ファイル・ディレクトリでも作業を検索します。処理対象のファイルがある場合、それらは対応するJMSキューにプッシュされ、クラスタ内のサーバーはそれを使用して関連するイメージを処理します。BPELエージェントおよび入力エージェントに専用のスレッド数は、対応するWebLogic Serverワークロード・マネージャで管理できます。
クラスタ内のサーバーが停止すると、エージェントはそのアクティビティを終了します。BPELエージェントの実行サイクルは短く、すべての処理はシャットダウン前に完了することが見込まれます。進行中のBPEL呼出しは3回再試行され、JMSログは保留中の操作を保存します。入力エージェントは大規模なサイズのファイルを処理できます。大きな入力ファイルは処理に何時間もかかる場合があります。停止後に保留された作業の量は、関連するJMS永続ストアに保存されます。入力エージェントをホストするサーバーが再起動されると、エージェントは残されていた処理を再開します。イメージ・ファイルの処理は、再起動またはサーバーの移行後に、対応する入力ファイルを最初に使用するサーバーで継続されます。
次の推奨事項を実行して、Oracle I/PMの高可用性構成で障害から保護します。
スティッキーなセッション・ルーティング機能を持つロード・バランシング・ルーターを使用して、Oracle I/PMノードのフロントエンド処理を行います。この目的のためにOracle HTTP Serverを使用できます。
Oracle I/PMでアップロードまたは取得される表示用のドキュメントのサイズに基づいて、ロード・バランシング・ルーターのタイムアウトを構成します。
また、次の機能もOracle I/PMの高可用性構成での障害からの保護に役立ちます。
JMSフェイルオーバーは、WebLogic ServersのJMS実装で提供されます。
TopLinkには、データベースの再試行ロジックが用意されています。
Oracle UCMに接続する際に、ネットワーク障害の解決を即座に再試行するために、再試行ロジックが存在します。Oracle I/PMには、クラスタ内の他のOracle UCMサーバーを検索するフェイルオーバー・メカニズムが用意されています。Oracle I/PMとOracle UCMの間にロード・バランサを使用して、ロード・バランシング/フェイルオーバーの目的を実現できます。
BPELに接続する際に、Oracle I/PMは即座に再試行を実行し、タイムアウト時間(5分間)を超えたら失敗したアイテムを関連する再試行用のJMSキューに押し戻します。このJMS再試行メカニズムは、3回実行されます。失敗し続けるオブジェクトは、ユーザー操作用の保存キューに格納されます。
APIレベル統合(JPSなど)は再試行されず、内部的な再試行ロジックで処理されます。
ノード障害
Oracle/IPMノードで障害が発生すると、そのノードのエージェント・プロセスに影響します。未完了のトランザクションは、廃棄されて失われます。フェイルオーバー時に、そのノードのOracle I/PM UIのユーザー・セッションは失われます。ユーザーは、再度ログインして再起動する必要があります。それぞれのOracle I/PMクラスタ・ノードは独立しているので、フェイルオーバーはロード・バランシング・ルーターで管理され、Oracle I/PMで直接管理されることはありません。
すべてのOracle I/PM構成情報はデータベースに保存され、すべてのノードはお互いにレプリカになるため、構成情報はフェイルオーバー後に新しいノードで即座に使用できます。
外部リソースでのOracle I/PMノード障害の影響は次のとおりです。
JMSトランザクションでは、JMSに対して実行されたアトミック・アクションは内部的にトランザクション処理され、未完了のキューから受信したすべてのメッセージは再送信されることが想定されています。BPELエージェントおよび入力エージェントの障害回復は、ローカル・メッセージのファイル・システムへの永続性に依存します。メッセージがローカル・ノードに存在するイベントは、そのノードの起動時に続行されます。その他のメッセージは、稼働しているノードで取得されます。
データベース・トランザクションでは、接続が切断されたときに暗黙的なロールバック処理を強制する場合を除いて、データベースがクライアントの障害に対処することはありません。データベース障害時のデータベース・トランザクションは、必要なデータベース機能により管理されます(たとえば、Oracle RACデータベースが使用されていればフェイルオーバーが行われ、単一ノードのデータベースが使用されていればフェイルオーバーは行われません)。データベースへのアクセス中にノード障害が発生すると、多くの場合、ユーザーは再度ログインして、UI操作を再試行することになります。
Oracle I/PMサーバーの障害発生時は、Oracle I/PM内のユーザー・セッションは失われます。Oracle I/PM UIを介してドキュメントをアップロードしているときにOracle I/PMサーバーの障害が発生すると、手動のドキュメントのアップロードが成功したという確認通知が受信されない場合があります。その場合、それを再度アップロードする前に、サーバー障害発生時にアップロードしていたドキュメントがあるかどうか探してみることをお薦めします。そうすることで、ドキュメントの重複作成が回避されます。
外部アプリケーションがWebService呼出しを使用してOracle I/PMクラスタにアクセスする場合、Oracle I/PMサーバーに障害が発生すると、フロントエンド・ロード・バランサで適切なフェイルオーバー・ロジックが提供されることが想定されます。入力ディレクトリにファイルを直接プッシュすることでアプリケーションがOracle I/PMシステムと相互作用する場合、ファイル・システムで障害が発生したときの再試行は、アプリケーションで処理します。
障害発生時に入力定義ファイルが処理中の場合、Oracle I/PMはファイルの詳細を保持し、その特定のノードの再起動時に、ローカルJMSキューでその再試行するJMSメッセージを再作成します。再試行時に、入力インジェスタはシャットダウンが発生したときのファイル内の場所の特定を試みて、バッチのドキュメントが失われないように未処理の場所を取得します。定義ファイルを処理していたノードが完全に再起動してファイルの処理が終了するまで、定義ファイルはStageディレクトリに保持されます。
入力ファイルは、入力エージェントがスケジュール設定および処理できる作業の最小単位です。最高のパフォーマンス、スケーラビリティ、および可用性を実現するために、いくつかの考慮事項があります。
Oracle I/PMクラスタ内のすべてのマシンは、共通の入力ディレクトリを共有します。
このディレクトリからの入力ファイルは、JMSキューを介してそれぞれのマシンに配信されます。
このディレクトリで新しいファイルをポーリングする頻度は、CheckInterval MBean構成設定を使用して構成できます。
それぞれのマシンには、指定された数の入力インジェスタが配置されます。入力インジェクタは、入力定義ファイルの解析を行います。インジェスタの数は、InputAgentのワークロード・マネージャを介して制御し、WebLogic Serverで管理します。
次のような場合に最適なパフォーマンスを実現できます。
それぞれのOracle I/PMクラスタ・ノードに、ユーザー・インタフェースやWebサービスなどの他のI/PMアクティビティのパフォーマンスを損ねることなく、ワーク・マネージャを介して構成された最適な最大数の解析エージェントがある場合。
ドキュメントのインバウンド・フローは、最適な数のドキュメントを含む入力ファイルに分割されます。平均では、クラスタ内の解析エージェントごとに2つの入力ファイルをキューに格納する必要があります。
クラスタ内で1台以上のマシンに障害が発生した場合、アクティブなマシンが入力ファイルの処理を続行します。障害が発生したマシンの入力ファイルは、サーバーが再起動するまで処理されません。入力ファイルを小さくすることで、マシンの障害によって大量のドキュメントが未処理の状態にならないようにします。
例: 2台のサーバーで1時間当たり10,000のインバウンド・ドキュメントが処理されるとします。サーバーごとに2つの解析エージェントを構成すると、全体的に適度なパフォーマンスが実現され、エージェントごとに2ドキュメント/秒でインジェストされます。2ドキュメント/秒の解析エージェントが4つある場合、8ドキュメント/秒(28,800ドキュメント/時)で処理されます。10,000ドキュメントの単一の入力ファイルは、1時間では処理できません(7,200ドキュメント/時で処理する単一の解析エージェントだとその処理を完了できまません)。ただし、その入力ファイルを8つに分割して1,250ドキュメントずつにすると、4つのすべての解析エージェントはフルに活用され、1時間の期間内に10,000ドキュメントの処理が完了するようになります。また、一方のサーバーで障害が発生した場合、処理が正常に終了するまでもう一方のサーバーで解析エージェントに残っている処理を続行できます。
Oracle I/PMが依存するコンポーネントの障害
Oracle I/PMはOracle SOA Suiteと統合します。SOAサーバーが停止すると、Oracle I/PMに障害が発生します。Oracle I/PMは、アクションを3回再試行します。それぞれの試行を繰り返す前に、構成可能な遅延時間が後に続きます。3回の試行の後もアクションが完了できない場合、これらのリクエストはデータベース・テーブルのキューに格納され、後で再送信されます。再送信は、WLSTコマンドを使用して実行します。
Oracle I/PMはOracle WebCenterに依存していません。
その他のOracle ADFアプリケーションは、Oracle I/PMの操作には影響しません。
Oracle I/PMのUIで、接続先のOracle UCMサーバーのリストを指定できます。これは、プライマリ・サーバーを使用して、複数のセカンダリ・サーバーに接続して指定できます。プライマリUCMサーバーで障害が発生した場合、Oracle I/PMはリスト内の次のUCMサーバーで再試行します。すべてのUCMサーバーが停止した場合、例外が返され、Oracle I/PMサーバーのログにトレースされます。
検索、入力、アプリケーション(すべてOracle I/PM構造構成)は、Oracle I/PMデータベースの中に保存されます。これらは、Web UI層を含め、クラスタ内のすべてのマシンで即座に使用可能になります。新しいエントリがクラスタ内の別のOracle I/PMサーバーまたは別のユーザー・セッションの同じサーバーで作成された場合、Web UIは自動的にはリフレッシュしません。ただし、Webブラウザをリフレッシュしてイメージ・アプリケーションのナビゲーション・バーをリフレッシュすることはできます。
この項では、高可用性環境でOracle I/PMサーバー、アドバンスト・ビューア、入力エージェントをトラブルシューティングする方法について説明します。
追加のOracle I/PMトラブルシューティング情報は、Oracle Fusion Middleware Oracle Imaging and Process Management管理者ガイドに記載されています。
Oracle I/PMサーバーのトラブルシューティング
Oracle/IPMは、WebLogic Server上にデプロイされるJEEアプリケーションです。ログ・メッセージはすべて、アプリケーションがデプロイされるWebLogic Serverのサーバー・ログ・ファイルに記録されます。
診断ログ・ファイルのデフォルトの場所は次のとおりです。
WL_HOME/user_projects/domains/domainName/servers/serverName/logs/serverName-diagnostic.log
Oracle Enterprise Managerを使用して、これらのログ・ファイルの検索および解析を簡単に行えます。
アドバンスト・ビューアのトラブルシューティング
Oracle I/PMでは、主にサーバー側でロギング機能を提供しますが、クライアント側にアドバンスト・ビューアというコンポーネントもあります。このJavaアプレットでは、標準的なロギング・ユーティリティを使用します。ただし、これらのユーティリティは、クライアントでは無効です。Javaプラグインのlogging.propertiesファイルを適切に変更して、ログの出力をファイルまたはJavaコンソールのいずれかに送信するようにこれらのユーティリティを構成できます。
入力エージェントのトラブルシューティング
Oracle I/PMの入力エージェントでドキュメントをアップロードするときに、Oracle Universal Content Managementで障害が発生すると、次のようなメッセージが生成されます。
Filing Invoices Input completed successfully with 48 documents processed successfully out of 50 documents.
また、次のような例外も生成されます。
[2009-07-01T16:43:01.549-07:00] [IPM_server2] [ERROR] [TCM-00787]
[oracle.imaging.repository.ucm] [tid: [ACTIVE] .ExecuteThread: '10' for queue:
'weblogic.kernel.Default (self-tuning)'] [userId: <anonymous>] [ecid:
0000I8sgmWtCgon54nM6Ui1AIvEo00005N,0] [APP: imaging#11.1.1.1.0]
A repository error has occurred.
Contact your system administrator for assistance.
[[oracle.imaging.ImagingException: TCM-00787: A repository error has occurred.
Contact your system administrator for assistance.
stackTraceId: 5482-1246491781549
faultType: SYSTEM
faultDetails:
ErrorCode = oracle.stellent.ridc.protocol.ServiceException,
ErrorMessage = Network message format error.
at
oracle.imaging.repository.ucm.UcmErrors.convertRepositoryError(UcmErrors.
java:109
.
.
.
入力エージェントは、失敗したドキュメントをエラー・ファイルに配置することでエラーを処理します。そのような状況下で、このような動作およびエラー・メッセージが生成されることが想定されます。
この項では、Oracle Universal Content Management(Oracle UCM)の概要、およびOracle UCMの高可用性環境の設計とデプロイ方法について説明します。
図11-3は、Oracle UCMの単一インスタンスのアーキテクチャを示しています。
図11-3 Oracle Universal Content Managementの単一インスタンスのアーキテクチャ
Oracle UCMのインスタンスは、Oracle WebLogic管理対象サーバー環境内で稼動します。WebLogic Serverは、アプリケーションの起動と停止など、Oracle UCMアプリケーションのライフサイクルを管理します。
Oracle UCMアプリケーションへのエントリ・ポイントは2つあります。1つはリスニングTCPソケットです。これは、Oracle I/PMやOracle WebCenterなどのクライアントからの接続を受理できます。もう1つはHTTPリスニング・ポートです。これは、Webサービス呼出しを受理できます。HTTPポートは、管理対象サーバーのリスニング・ポートと同じポートです。
UCMサーバーには、いくつかの埋込みアプリケーションも含まれています。これらは、クライアント・ブラウザ内でアプレットとして実行できます。これらには、ファイル管理および索引付け機能のためのリポジトリ・マネージャ(RM)と、ユーザー・ワークフローのセットアップのためのワークフロー管理が含まれています。これらのアプリケーションの詳細は、Oracle Fusion Middleware Content Serverアプリケーション管理者ガイドを参照してください。
UCM Serverには、3タイプの永続ストアがあります。それらのタイプは、リポジトリ(Oracleデータベースに格納可能)、検索索引(Oracleデータベースに格納可能)、メタデータおよびWebレイアウト情報(ファイル・システムに格納可能)です。
Oracle UCMは、WebLogic Serverに存在するサーブレットです。サーブレット・リクエストは、UCMリクエストのラッパーです。
Oracle UCMには、BatchLoaderやIdcAnalyzerなどの様々なスタンドアロンの管理ユーティリティが含まれます。
JMSおよびJTAは、Oracle UCMでは使用されません。
Oracle UCMは、サービス指向アーキテクチャを採用しています。それぞれのリクエストは、サービスとしてシステムに受け入れられます。共有サービス層では、リクエストを解析し、そのリクエストを正しいハンドラに渡します。通常、ハンドラは基になるリポジトリにアクセスして、リクエストを処理します。3種類のリポジトリとそれぞれで保存するデータを図11-3に示します。
Oracle UCMはOracle WebLogic Server管理対象サーバーとして起動および停止できます。UCM管理サーバーも、UCMインスタンスの起動、停止、および構成に使用できます。UCM管理サーバーは、WebLogic管理コンソールが採用されているため非推奨ですが、従来どおりWebLogic Server環境で機能します。ロード・バランサは、PING_SERVERサービスを使用して、UCMインスタンスのステータスを監視できます。
起動時に、Oracle UCMは初期化ファイルおよびデータ定義をロードして、データベース接続を初期化し、ローカライゼーション文字列をロードします。Oracle UCM内部コンポーネント・アーキテクチャを介して、起動シーケンスでシステムにインストールおよび有効化されている内部コンポーネントを検出し、それらのコンポーネントを初期化します。検索/索引エンジンおよびファイル・ストレージ・インフラストラクチャも初期化されます。
通常、クライアント・リクエストは1つのOracle UCMインスタンスですべて処理されます。クラスタ内に他のインスタンスが存在しても、クライアント・リクエストには影響しません。
Oracle UCMでは、nostageデプロイメントを使用します。つまり、すべてのデプロイメント・ファイルはローカルです。
Oracle UCMには、WebLogic Serverおよび外部Oracleデータベースが必要です。
次のクライアントはOracle UCMに依存します。
Oracle Universal Records Management(Oracle URM)
Oracle Imaging and Process Management(Oracle I/PM)
Oracle WebCenter
クライアントからの接続は短時間で、セッションレス・サービスの期間にのみ必要です。
クライアントは、HTTP、SOAP/Web Services、JCR、およびVCRプロトコルを使用して、Oracle UCMに接続できます。
Oracle UCMは、WebLogic Server上にデプロイされるJ2EEアプリケーションです。ログ・メッセージは、アプリケーションがデプロイされるWebLogic Serverのサーバー・ログ・ファイルに記録されます。サーバー・ログのデフォルトの場所は次のとおりです。
WL_HOME/user_projects/domains/domainName/servers/serverName/logs/serverName-diagnostic.log
Oracle UCMは、次の場所にログを保存することもできます。
WebLayoutDir/groups/secure/logs
Oracle UCMトレース・ファイルは、次の場所に記録および格納するように構成できます。
IntraDocDir/data/trace
Oracle UCMのGUIを使用してログ・ファイルを表示するには、UCMメニュー→「管理」→「ログ」を選択します。
Oracle UCMのGUIを使用してトレース・ファイルを表示するには、UCMメニュー→「システム監査情報」を選択します。「サーバー出力の表示」および「捕捉された出力の表示」リンクをクリックすると、現在のトレースおよび記録されたトレースが表示されます。
この項では、Oracle UCMを2ノードのクラスタ構成による高可用性で使用する場合の概要について説明します。
図11-4は、2ノードのアクティブ/アクティブOracle Universal Content Managementクラスタを示しています。
図11-4 Oracle Universal Content Managementの2ノード・クラスタ
図11-4は、Oracle UCMの高可用性構成を示しています。
それぞれのノードは、共有ファイル・システム、同じデータベース・スキーマ、同じ検索索引に対して独立に稼働します。クライアント・リクエストは、すべて単一ノードで処理されます。
Oracle UCMは、WebLogic Serverクラスタまたは外部ロード・バランサで稼働できます。Oracle UCMは、Oracle RACおよび複数のデータ・ソース構成に対しても透過的です。
Oracle UCMは、独立にスケーラビリティを持つことができ、ノード間の通信は限定的です。ノードどうしは、共有ファイル・システムへの読書きを介して通信します。この共有ファイル・システムは、書込み操作の同期化をサポートする必要があります。
クラスタが起動すると、それぞれのOracle UCMノードは通常の初期化シーケンスが実行されます。初期化シーケンスでは、リソースの解析、準備、およびキャッシュ処理、および接続の準備などが行われます。ノードがクラスタの一部である場合、他のクラスタ・メンバーが使用可能であれば、メモリー内のレプリケーションが開始されます。1つまたすべてのクラスタ・メンバーを同時に起動することができます。
クラスタ・メンバーをシャットダウンすると、そのクラスタ・メンバーはリクエストに対応できなくなります。サーバーを正常にシャットダウンすると、現在のリクエストの処理を終了して、使用不可になることを通知し、すべての共有リソースを開放して、そのファイルおよびデータベース接続を閉じます。すべてのセッション状態はレプリケートされ、このクラスタ・メンバーに接続されていたユーザーは、他のクラスタ・メンバーにフェイルオーバーされます。
クラスタ・レベルでは、Oracle UCMの内部コンポーネントを使用した新しいOracle UCMの機能や動作のカスタマイズ機能が導入されました。これらの変更を取得するには、ノードを再起動する必要があります。
たとえば、メタデータ・モデルでシステム全体を変更できます(メタデータ・フィールドの追加、変更、削除など)。これらのメタデータ・フィールドで駆動されたシステムの動作は変更できます。この変更は、ノード間の通知を介して、クラスタ・ノートで自動的に取得されます。
各クラスタ・メンバーで変更を適用するには、最初のノードで共有フォルダを構成する必要があります。それぞれのクラスタ・ノードのすべての共有フォルダが同じマウント・ポイントを持っていれば、他のノードでWebLogic Serverのpack/unpackを使用して手動で変更を行う必要はありません。
Oracle UCMを1つ以上のInbound Refineryインスタンスで構成して、ドキュメントの変換を行うことができます。
Inbound Refineryは、ドキュメント、デジタル・イメージ、動画ビデオなどの電子ドキュメントのファイルの変換を管理する変換サーバーです。また、ドキュメントおよびイメージのサムネイル機能、デジタル・イメージからEXIFを抽出および使用する機能、Adobe PhotoshopおよびAdobe Illustratorなどのプログラムから生成された電子ファイルからXMPデータを抽出および使用する機能、およびビデオのストーリーボード作成機能も用意されています。Inbound Refineryの詳細は、Oracle Fusion Middleware変換についての管理者ガイドを参照してください。
インストールが必要なInbound Refineryインスタンス数は、サポートが必要な変換の量によって異なります。可用性を高めるために、少なくとも2つのInbound Refineryインスタンスをインストールすることをお薦めします。すべてのInbound Refineryインスタンスは、プロバイダとしてContent Serverクラスタのすべてのメンバーから使用できる必要があります。
Content ServerとInbound Refinery間の通信は、Content Serverで開始されます。開始処理には次のような処理が含まれます。
ステータスを決定するための、使用可能なすべてのInbound Refineryインスタンスの定期的なチェック
ジョブ・リクエストの開始
完了したジョブの取得
ステータスには、Inbound Refineryがリクエストを受理できるかどうかを示す情報が含まれます。これは、Inbound Refineryの稼働量に依存します。使用できるInbound Refineryインスタンスがない場合、リクエストは再試行されます。
ジョブが完了すると、Content Serverのステータス・リクエストの一部としてこの情報が表示されます。そのような場合、Content Serverは完了したジョブのダウンロードを開始します。
Content Serverクラスタでは、クラスタのメンバーの間で使用可能なInbound Refineryインスタンスのリストが共有されます。
つまり、新しいInbound Refineryインスタンスが追加されると、それは任意のContent Serverクラスタ・メンバーで使用できるようになります。
ただし、各Content Serverは使用可能なすべてのInbound Refineryインスタンスと独立的に通信します。Content Serverクラスタには、共有ステータスはありません。
同様に、すべてのInbound Refineryインスタンスでは、Content Serverからのリクエストに対応して、完全に独立して操作を行います。Inbound Refineryインスタンスでは、一切の情報を共有しません。
次の理由のため、一連のInbound Refineryインスタンスの前面でロード・バランサを使用することはできません。
Content Serverは、Inbound Refineryと直接接続して、ステータスおよび可用性の情報を取得できる必要があります。
ジョブが終了したら、Content Serverは特定のジョブを持つ1つのInbound Refineryにアクセスしてダウンロード開始できるようになる必要があります。
すべてのリクエストはContent Serverを介した非同期リクエストになるので、Inbound Refineryへのリクエストはリアルタイムには発生しません。ユーザーがContent Serverにアクセスすると、Content Serverは使用可能なInbound Refineryインスタンスにリクエストを委任します。1つまたは複数のインスタンスで障害が発生しても、サービス・リクエストに対応できるInbound Refineryインスタンスがその他にも常に存在するように、十分なInbound Refineryインスタンスを構成する必要があります。
Content Serverでは、Inbound Refineryを「失敗」とマークすることはありません。あるInbound Refineryに接続できない場合、Content Serverは別の使用可能なInbound Refineryを選び、引き続きすべてのInbound Refineryインスタンスの可用性をチェックします。失敗したInbound Refineryインスタンスは、システム管理者の責任でContent Serverリストから手動で削除します。
Oracle URMおよびOracle UCMは、同じアーキテクチャを共有します。そのため、Oracle UCMに適用されるすべての高可用性に関する考慮事項は、Oracle URMにも適用されます。
高可用性を構成する場合、Oracle UCMとOracle URMでは注意する相違点が2つあります。
Oracle URMは、Oracle UCMと異なるディレクトリに、ファイル・システム・メタデータを保存します。
Oracle URMクラスタの前面のHTTPサーバーを構成する場合、Oracle UCMと異なるセッションCookie名を使用する必要があります。
これら2つの構成の違いの詳細は、後述する「Oracle ECMの高可用性の構成手順」を参照してください。
次の機能は、Oracle UCMノードの障害からの保護に役立ちます。
外部ロード・バランサを使用することで、ロード・バランシングを実現できます。セッションには、認証情報よりさらにスティッキーな状態データは不要です。
ロード・バランサは、Oracle UCMの前面に構成できます。Oracle RACをサポートするOracle UCMで、複数のデータ・ソースを構成できます。タイムアウトおよび再試行もサポートされます。
Oracle UCMでは、標準のWebLogic Server永続セッションを使用します。
Oracle UCMでは、EJBを使用しません。
Oracle UCM PING_SERVERサービスを使用して、障害を検出します。ノードを再起動するときに、クラスタ内の他のノードに影響することはありません。
フェイルオーバーは、Oracle UCMノードの前面のロード・バランサまたはApacheのWLSモジュールによって処理されます。クライアントからの処理中のリクエストは失敗しますが、後続のリクエストはアクティブ・ノードにルーティングされます。終了していないトランザクションは完了しません。
ノードからの構成情報は、共有ファイル・システムおよびデータベースに保存されているので、失われます。
ノードに障害が発生すると、データベースはノードとデータベース間の接続を再要求します。
通常、インスタンスはハングしませんが、Oracle UCM製品またはOracle UCMのカスタマイズされたバージョンでの不明のデッドロック状態が原因でハングすることがあります。
アクティブ・セッションがあるユーザーは、セッションがアクティブ・サーバーにフェイルオーバーされるため、ダウンタイムが発生することはありません。これは、UCM管理アプレットを開いているユーザーも含まれます。
Oracle UCMのインストールが完了したら、config.cfgファイルに次の値を設定する必要があります。これにより、Oracle RACのフェイルオーバー時に再試行ロジックを使用できます。
ServiceAllowRetry=true
この値が設定されていない場合、フェイルオーバーが開始されたときに、ユーザーは処理中の任意の操作を手動で再試行する必要があります。
次のURLで、Oracle UCMのWebLogic Server管理コンソールを使用して、値を設定できます。
http://<hostname>:<port>/cs
「管理」→「管理サーバー」→「一般構成」を選択し、ServiceAllowRetry=trueを追加の構成変数に追加します。保存して、すべてのUCM管理対象サーバーを再起動します。新しい値がconfig.cfg内の次の位置に表示されます。
SHARED_DISK_LOCATION_FOR_UCM/ucm/cs/config/config.cfg
Oracle UCMをトラブルシューティングするには、ログ・ファイルを調べてからトレース・ファイルを調べます。
Oracle UCMのログ・ファイルおよびトレース・ファイルの場所、およびOracle UCMのGUIを使用してログ・ファイルおよびトレース・ファイルを表示する方法の詳細は、第11.2.1.1.7項「Oracle UCMのログ・ファイルの場所」を参照してください。
図11-5のような高可用性環境の場合、Oracle ECM製品は、クラスタ・デプロイメントで設定することをお薦めします。そうすることで、クラスタ化されたインスタンスはOracle Real Applications Cluster(Oracle RAC)データベースのコンテンツ・リポジトリにアクセスし、共通の構成を保存するために共有ディスクが使用されます。
ハードウェア・ロード・バランサは、リクエストを複数のOracle HTTP Serverインスタンスにルーティングしてから、クラスタ化されたOracle ECMサーバーにルーティングします。
この項では、図11-5で示されるOracle ECMの高可用性構成のインストールおよび構成手順について説明します。
次の項目が含まれます。
|
注意: 設定プロセスを開始する前に、リリース・ノートを読んで、インストールとデプロイメントに関して追加の考慮事項がないか確認することを強くお薦めします。 |
構成には次の製品が含まれます。
Oracle I/PM
Oracle UCM
Oracle Universal Records Manager(URM)
Oracle Inbound Refinery(IBR)
すべての製品は同じマシン上にインストールされますが、Inbound Refineryだけはリモート・マシン上に想定されています。
Oracle I/PMまたはOracle URMをインストールしない場合は、構成手順の当該製品の箇所を無視してください。
クラスタ・メンバーは、同じ構成ファイルにアクセスするために、共有記憶域を必要とします。これは、クラスタのすべてのノードからアクセスできるように設定する必要があります。
Oracle UCM/URM/IBRクラスタを構成する場合、次の要件に従ってください。
Oracle UCMクラスタでは、すべてのクラスタ・メンバーは同じ構成ディレクトリを指す必要があります。このディレクトリは、クラスタのすべてのメンバーからアクセス可能な共有ディスクに配置されている必要があります。
Oracle URMクラスタでは、すべてのクラスタ・メンバーは同じ構成ディレクトリを指す必要があります。このディレクトリは、クラスタのすべてのメンバーからアクセス可能な共有ディスクに配置されている必要があります。
Oracle IBRでは、IBRクラスタの各メンバーは、独自の個別の構成ディレクトリを持つ必要があります。このディレクトリは、ローカル・ディスクまたは共有ディスクに配置できます。後者の場合、複数のIBRで同じディレクトリを使用することができないので注意が必要です。
UCMとIBRを同じマシンにインストールする場合には注意が必要です。これは、すべての製品の構成ディレクトリが、同一のサブディレクトリ内に存在するためです。デフォルトではこのディレクトリはDOMAIN_HOMEの下ですが、その他の任意のディレクトリに構成できます。
複数のIBRサーバーで/ibrディレクトリを共有すると、2番目のサーバーを起動したときに、次のエラーが表示されます。
<@csRefineryFileSystemLocked=Inbound Refinery {1} on machine {2} cannot start
because the file {3} exists.
この起動エラーのほとんどの原因は、IBRがクラスタ・ノードとして構成されていることです。IBRは、クラスタ化環境をサポートしていません。
このチェックを無効にするには、EnableReserveDirectoryCheck=falseを設定します。ただし、この設定を同じファイル・システムでIBRノードを実行する目的で使用してはいけません。
Oracle RACデータベースを構成してから、ここで説明する手順を完了してください。
リポジトリ作成ユーティリティ(RCU)は、Oracle Fusion Middleware 11gキットの部品として付属する専用のCDに収録されています。
RCUを実行して、Oracle RACデータベース・リポジトリにOracle UCMスキーマを作成するには、任意の使用可能なホストで次の手順を実行します。
次のコマンドを発行します。
prompt> RCU_HOME/bin/rcu &
「ようこそ」画面で「次へ」をクリックします。
「リポジトリの作成」画面で、「作成」操作を選択してコンポーネント・スキーマを既存のデータベースにロードします。
「次へ」をクリックします。
「データベース接続の詳細」画面で、既存のデータベースの接続情報を次のように入力します。
データベース・タイプ: Oracle Database
ホスト名: データベースを実行しているコンピュータの名前。Oracle RACデータベースの場合は、VIP名またはノード名を指定します。例: ECMDBHOST1-VIPまたはECMDBHOST2-VIP
ポート: データベースのポート番号。例: 1521
サービス名: データベースのサービス名。例: ecmha.mycompany.com
ユーザー名: SYS
パスワード: SYSユーザーのパスワード
ロール: SYSDBA
「次へ」をクリックします。
すべての項目が正しく入力されると、操作が完了したことを示す文言のあるダイアログ・ボックスが表示されます。その場合、「OK」をクリックします。それ以外の場合は、「メッセージ」の下に、データベースに接続できないことやユーザー名やパスワードが無効であることを示すエラーが表示されます。
「コンポーネントの選択」画面で、新しい接頭辞を作成して、このデプロイメントに関連するコンポーネントを選択します。
接頭辞の新規作成: ecm
コンポーネント: スキーマを作成するコンポーネントのみを選択します。「Oracle ASリポジトリ・コンポーネント」→「Enterprise Content Management」を選択し、次のコンポーネントを選択します。
Oracle Content Server 11g - 完全
Oracle Universal Records Management 11g
Oracle Imaging and Process Management
「次へ」をクリックします。
すべての項目が正しく入力されると、操作が完了したことを示す文言のあるダイアログ・ボックスが表示されます。その場合、「OK」をクリックします。それ以外の場合は、「メッセージ」の下にエラーが表示されます。これは、続行する前に解決する必要があります。
「スキーマ・パスワード」画面で、「すべてのスキーマに同じパスワードを使用」が選択されていること確認します。このパスワードは、後でContent Serverがこのデータベース・スキーマに接続する手順で使用されます。
「次へ」をクリックします。
「表領域のマップ」画面で「次へ」をクリックします。
警告ダイアログ・ボックスが表示されたときには、「OK」をクリックします。
表領域の作成の結果は、操作が完了したことを示すテキストのあるダイアログに表示されます。「OK」をクリックします。
「サマリー」画面で「作成」をクリックします。
「完了サマリー」画面で「閉じる」をクリックします。
この項では、ECMHOST1のインストールおよび構成手順について説明します。
ECMHOST1で、インストーラ実行可能ファイルを実行して、Oracle WebLogic Serverのインストールを開始します。
最新バージョンのOracle Fusion Middlewareとともに使用するOracle WebLogic Serverのバージョンは、『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』のインストール開始点の概要に関する項を参照してください。
Oracle WebLogic Serverインストーラを起動します。
インストーラが起動したら、次の手順に従ってOracle WebLogic Serverをインストールします。
「ようこそ」画面で「次へ」をクリックします。
「ミドルウェア・ホーム・ディレクトリの選択」画面で、Oracle WebLogicソフトウェアのインストール先となるディレクトリを選択します。
「ミドルウェア・ホーム・ディレクトリ」に、次の値を指定します。
/u01/app/oracle/product/fmw
「次へ」をクリックします。
「セキュリティ更新のための登録」画面で、「My Oracle Support」のユーザー名とパスワードを入力します。
「インストール・タイプの選択」画面では、完全インストールまたはカスタム・インストールのどちらを実行するかを指定するためのプロンプトが表示されます。
「標準」または「カスタム」を選択します。
「次へ」をクリックします。
「製品インストール・ディレクトリの選択」画面で、次の値を指定します。
WebLogic Server:
/u01/app/oracle/product/fmw/wlserver_10.3
Oracle Coherence:
/u01/app/oracle/product/fmw/coherence_3.5.2
「インストール・サマリー」画面に、インストール対象として選択したコンポーネントの一覧と、それらをインストールするために使用されるディスク領域の概算値が表示されます。
「次へ」をクリックします。
「インストール 完了」画面で、「Quickstartの実行」チェック・ボックスの選択を解除します。
「完了」をクリックします。
次の手順に従って、Oracle Enterprise Content Management(Oracle ECM)インストーラを起動します。
UNIXの場合(次の例はLinuxの場合):
./runInstaller -jreLoc file-specification-for-jdk6
前述のコマンドを発行する前に、DISPLAY環境変数が正しく設定されていることを確認します。
Windowsの場合:
setup.exe
JREの場所を指定します(C:\Oracle\Middleware\jdk160_11など)
ECMインストーラで次の手順に従ってOracle Enterprise Content Managementをシステムにインストールします。
初回インストールの場合は、Oracleインベントリの指定画面が表示されます。
デフォルトを受け入れて「OK」をクリックします。
通常の(root以外の)ユーザーとしてインストールする場合、インベントリの場所の確認ダイアログ・ボックスが表示されます。その指示に従うか、ローカル・インベントリでインストールを続行するを選択して「OK」をクリックします。
「ようこそ」画面で「次へ」をクリックします。
「前提条件のチェック」画面で、インストーラによって前提条件のチェックが完了します。チェックに失敗した項目がある場合は、修正してインストールを再開します。
「次へ」をクリックします。
「インストール場所の指定」画面で、次の値を入力します。
「ミドルウェア・ホーム・ディレクトリ」に、次の値を指定します。
/u01/app/oracle/product/fmw
「Oracleホーム・ディレクトリ」で、Oracle ECMをインストールするサブディレクトリの名前を入力します(またはデフォルトを使用します)。次の場所はECM_HOMEと呼ばれます。
/u01/app/oracle/product/fmw/ecm
「次へ」をクリックします。
「インストール・サマリー」画面で、選択内容が正しいことを確認して(正しくない場合は「戻る」をクリックして前の画面に戻り、修正します)、「インストール」をクリックします。
UNIXシステムでは、「インストールの進行状況」画面にoracleRoot.shスクリプトの実行を指示するダイアログ・ボックスが表示されます。ウィンドウを開き、表示される指示に従ってスクリプトを実行します。
「次へ」をクリックします。
「インストール 完了」画面で、「終了」をクリックし、選択を確定して終了します。
|
注意: 第11.3.3.3項「高可用性のドメインの作成」の説明に従って構成ウィザードを実行する前に、Oracle Fusion Middlewareが最新バージョンになるように、最新のOracle Fusion Middlewareパッチ・セットおよびその他の既知のパッチがMiddlewareホームに適用されていることを確認してください。最新バージョンのOracle Fusion Middlewareを取得するために実行する必要のある手順は、『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』のインストール開始点の概要に関する項を参照してください。 |
この項では、Oracle Fusion Middleware構成ウィザードを実行して、アプリケーションおよびライブラリをデプロイできる高可用性のドメインを作成および構成する方法について説明します。
Oracle Fusion Middleware構成ウィザードを起動する手順は次のとおりです。
UNIXの場合(次の例はLinuxの場合):
ECM_HOME/common/bin/config.sh
前述のコマンドを発行する前に、DISPLAY環境変数が正しく設定されていることを確認します。
Windowsの場合:
ECM_HOME/config.cmd
構成ウィザードで次の手順に従ってOracle ECMドメインをコンピュータに作成および構成します。
「ようこそ」画面で、「新しいWebLogicドメインの作成」を選択します。
「次へ」をクリックします。
「ドメイン・ソースの選択」画面で、インストールするアプリケーションを選択します。
たとえば次のように、インストールするアプリケーションを選択します。
Oracle Universal Records Management - 11.1.1.0
Oracle Universal Content Management - Inbound Refinery - 11.1.1.0
Oracle Universal Content Management - Content Server - 11.1.1.0
Oracle Imaging and Process Management - 11.1.1.0
Oracle JRFやOracle Enterprise Managerなどのその他の製品も自動的に選択されます。
「ドメイン名と場所の指定」画面で、次のエントリを作成します。
ドメイン名をecmdomainに変更するか、デフォルトのbase_domainを使用します。次のように、このドメインのディレクトリが作成されます。
MW_HOME/user_projects/domains/ecmdomain
ドメインの場所: デフォルトを受け入れます。
アプリケーションの場所: デフォルトを受け入れます。
「次へ」をクリックします。
「管理者ユーザー名およびパスワードの構成」画面で次の操作を行います。
「ユーザー名」フィールドで、ドメイン管理者のユーザー名を入力するか、デフォルトのユーザー名weblogicを使用します。
「パスワード」フィールドで、8文字以上のユーザーのパスワードを入力します(welcome1など)。
「ユーザー・パスワードの確認」フィールドで、再度ユーザーのパスワードを入力します。
「次へ」をクリックします。
「サーバーの起動モードおよびJDKの構成」画面で次の操作を行います。
WebLogicドメインの起動モード: 「本番モード」を選択します。
JDKの選択: 使用可能なJDKのリストからJDKを選択するか、デフォルトを受け入れます。
「次へ」をクリックします。
「JDBCコンポーネント・スキーマの構成」画面で、次の操作を行います。
両方のスキーマを選択して、Oracle RACとして構成するように選択します。
「コンポーネント・スキーマ」の下にリストされているそれぞれのデータベース・スキーマについて、次の操作を行います。
スキーマの前にあるチェック・ボックスをクリックして、その行を選択します。
上部の入力フィールドの値を確認します。スキーマ名、パスワード、Oracle RACホスト、ポートおよびサービス名を入力します。
「次へ」をクリックします。
「コンポーネント・スキーマのテスト」画面で、前の画面にリストされていたそれぞれのスキーマがテストされます。そのすべてが正しく指定されていると、「ステータス」列にチェックマークが表示されます。正しくない指定があると、「ステータス」列に停止標識が表示され、接続結果ログにエラー・メッセージが記録されます。そのような場合、「前へ」をクリックして前に戻り、問題を解決します。
すべてのスキーマが正しく指定されたら、「次へ」をクリックします。
「JMS分散宛先」、「管理サーバー」および「管理対象サーバー、クラスタ、およびマシン」を選択します。
「JMS分散宛先タイプの選択」画面で、すべてのOracle Fusion MiddlewareコンポーネントのJMSモジュールのドロップダウン・リストからUDDを選択します。
「次へ」をクリックします。
「管理サーバーの構成」画面で、次の値を入力します。
名前: AdminServer
Listen address: ホストまたは仮想ホスト名を入力します。
Listen port: 7001
SSLリスニング・ポート: 適用なし
SSL有効: このチェック・ボックスは選択解除したままにします。
「次へ」をクリックします。
「管理対象サーバーの構成」画面で、既存の各サーバーに対して管理対象サーバーを追加します。たとえば、WLS_UCM1に対応したWLS_UCM2を追加します。2番目の管理対象サーバーのリスニング・ポートは、1番目のポートと同じにする必要があります。すべてのサーバーのリスニング・アドレスは、管理対象サーバーが稼働しているホスト名に設定します。
例:
WLS_UCM1
Listen address: ECMHOST1
Listen port: 16200
WLS_UCM2
Listen address: ECMHOST2
Listen port: 16200
すべての管理対象サーバーに対してこれを実行します。
Oracle I/PMサーバーは、管理対象サーバーのリスニング・アドレスとして仮想ホスト名が必要です。これらの仮想ホスト名および対応する仮想IPは、I/PMコンポーネントのサーバー移行を有効にするために必要です。ECMHOST1ではECMHOST1VHN1、ECMHOST2ではECMHOST2VHN1にVIPマッピングを有効にして、トポロジで使用されるネットワーク・システムでもホスト名を(DNSサーバーまたはhosts解決のいずれかで)正しく解決する必要があります。
Inbound Refineryは、個別のリモート・サーバーに存在するように構成する必要があります(たとえば、ECMHOST3上のIBR_Server1、ECMHOST4上のIBR_Server2など)。
「クラスタの構成」画面で、サーバーの各ペアのクラスタを作成します。たとえば、UCMでは次のように作成します。
名前: UCM_Cluster
クラスタ・メッセージング・モード: unicast
マルチキャスト・アドレス: 適用なし
マルチキャスト・ポート: 適用なし
クラスタ・アドレス: 適用なし
他の製品用に同じように追加: IPM_Cluster、URM_Clusterなど
「次へ」をクリックします。
「サーバーのクラスタへの割当」画面で、新しく作成したクラスタに管理対象サーバーの各ペアを割り当てます。
UCMクラスタ:
WLS_UCM1
WLS_UCM2
この項の前の手順で作成したすべてのクラスタに対して(IPM_Cluster、URM_Cluster、およびIBR_Cluster)これを実行します。
「次へ」をクリックします。
「マシンの構成」画面で「Unixマシン」タブをクリックし、次のマシンを追加します。
ECMHOST1
ECMHOST2
ECMHOST3(Inbound Refineryが構成されている場合)
ECMHOST4(Inbound Refineryが構成されている場合)
「サーバーのマシンへの割当」画面で次の操作を実行します。
ECMHOST1マシンに対して、AdminServerおよびすべての*1サーバー(WLS_UCM1、WLS_IPM1、WLS_URM1)を割り当てます。
ECMHOST2マシンに対して、すべての*2サーバー(WLS_UCM2、WLS_IPM2、WLS_URM2)を割り当てます。
Inbound Refineryを構成する場合、WLS_IBR1をECMHOST3に追加し、WLS_IBR2をECMHOST4に追加します。
「構成のサマリー」画面で、「作成」をクリックしてドメインを作成します。
管理サーバーを起動します。
cd DOMAIN_HOME/bin
startWebLogic.sh &
ノード・マネージャを構成および起動します。
ECMHOST1> MW_HOME/oracle_common/common/bin/setNMProps.sh ECMHOST1> MW_HOME/wlserver 10.3/server/bin/startNodeManager.sh MW_HOME/oracle_common/common/bin/setNMProps.sh MW_HOME/wlserver 10.3/server/bin/startNodeManager.sh
管理コンソール(http://ECMHOST1:7001/console)にアクセスします。管理コンソールで、WLS_UCM1、WLS_URM1、およびWLS_IPM1管理対象サーバーを停止します。
この手順が必要になるのは、管理サーバーとノード・マネージャの間にSSL通信を設定していない場合です。SSLが設定されていない場合、ホスト名の検証を無効にしておかないとエラー・メッセージを受信することになります。
ホスト名の検証は、管理サーバーとノード・マネージャの間にSSL通信を設定したら、再度有効化できます。
ECMHOST1でホスト名の検証を無効化する手順は次のとおりです。
Oracle WebLogic Server管理コンソールで、「サーバー」→「管理サーバー」を選択します。
「SSL」→「詳細」を選択します。
「チェンジ・センター」で、「ロックして編集」をクリックします。
プロンプトが表示されたら、変更内容を保存してアクティブ化します。
「ホスト名の検証」を「なし」に設定します。
「WLS_UCM1」→「SSL」→「詳細」を選択します。
「ホスト名の検証」を「なし」に設定します。
WLS_URM1とWLS_IPM1に対し、ステップ6と7を繰り返します。
管理サーバーおよびすべての管理対象サーバー(WLS_UCM1、WLS_URM1、WLS_IPM1など)を再起動します。
ECMHOST2でホスト名の検証を無効化する手順は次のとおりです。
Oracle WebLogic Server管理コンソールで、「WLS_UCM2」→「SSL」→「詳細」を選択します。
「ホスト名の検証」を「なし」に設定します。
WLS_Portlet2とWLS_Services2に対し、ステップ1と2を繰り返します。
管理サーバーおよびすべての管理対象サーバー(WLS_UCM2、WLS_URM2、WLS_IPM2など)を再起動します。
WLS_UCM1構成ページ(http://ECMHOST1:16200/cs)にアクセスします。
ログインすると、構成ページが開きます。Oracle UCM構成ファイルは、共有ディスクに配置されている必要があります。この例では、共有ディスクを/u01/app/oracle/admin/domainName/ucm_clusterと想定しています。
構成ページの次の項目を、ここで示す値に設定します。
コンテンツ・サーバーのインスタンス・フォルダ: /u01/app/oracle/admin/domainName/ucm_cluster/cs
ネイティブ・ファイル・リポジトリの場所: /u01/app/oracle/admin/domainName/ucm_cluster/cs/vault
Webレイアウト・フォルダ: /u01/app/oracle/admin/domainName/ucm_cluster/cs/weblayout
サーバー・ソケット: ポート4444
ソケット接続アドレス・セキュリティ・フィルタ: ローカル・ホストとHTTP Serverホストのリストをパイプで区切って設定します(127.0.0.1|WEBHOST1|WEBHOST2)。
WebサーバーのHTTPアドレス: ロード・バランサHTTPのホストとポートを設定します(ecm.mycompany.com:80)。
これらの更新を適用するには、「送信」をクリックして、WLS_UCM1管理対象サーバーを再起動します。
WLS_URM1構成ページ(http://ECMHOST1:16250/urm)にアクセスします。
ログインすると、構成ページが開きます。Oracle URM構成ファイルは、共有ディスクに配置されている必要があります。この例では、共有ディスクを/u01/app/oracle/admin/domainName/ucm_clusterと想定しています。
構成ページの次の項目を、ここで示す値に設定します。
コンテンツ・サーバーのインスタンス・フォルダ: /u01/app/oracle/admin/domainName/ucm_cluster/urm
ネイティブ・ファイル・リポジトリの場所: /u01/app/oracle/admin/domainName/ucm_cluster/urm/vault
Webレイアウト・フォルダ: /u01/app/oracle/admin/domainName/ucm_cluster/urm/weblayout
サーバー・ソケット: ポート4445
ソケット接続アドレス・セキュリティ・フィルタ: ローカル・ホストとHTTP Serverホストのリストをパイプで区切って設定します(127.0.0.1|WEBHOST1|WEBHOST2)。
WebサーバーのHTTPアドレス: ロード・バランサHTTPのホストとポートを設定します(ecm.mycompany.com:80)。
これらの更新を行ったら、「送信」をクリックし、WLS_URM1管理対象サーバーを再起動します。
この項では、WEBHOST1で実行するインストールおよび構成手順について説明します。
この項では、WEBHOST1にOracle HTTP Serverをインストールする方法について説明します。
システム、パッチ、カーネルなどの要件が満たされていることを確認します。それらの一覧は、使用しているプラットフォームおよびバージョンのOracle Fusion Middlewareのドキュメント・ライブラリの『Oracle Fusion Middleware Oracle Web Tierインストレーション・ガイド』にあります。
ポート7777がWEBHOST1上のサービスによって使用されていないことを確認するために、使用しているオペレーティング・システムに対して次のコマンドを実行します。ポートが使用されていなければ、コマンドを実行しても何も出力されません。
UNIXの場合:
netstat -an | grep "7777"
Windowsの場合:
netstat -an | findstr :7777
ポートが使用されている(コマンドを実行するとポートを識別する戻り値が表示される)場合は、そのポートを解放する必要があります。
UNIXの場合:
ポート7777のエントリを/etc/servicesファイルから削除し、サービスを再起動するか、コンピュータを再起動します。
Windowsの場合:
ポートを使用しているコンポーネントを停止します。
staticports.iniファイルをDisk1/stage/Responseディレクトリから一時ディレクトリにコピーします。
一時ディレクトリにコピーしたstaticports.iniファイルを編集して、次のカスタム・ポート(Oracle HTTP Serverのポート番号を指定する行は非コメント化)を割り当てます。
# The port for Oracle HTTP server Oracle HTTP Server port = 7777
Oracle Fusion Middleware 11g Web Tier Utilities CDインストールのOracle Universal Installerを、次のように開始します。
UNIXでは、コマンドrunInstallerを発行します。
Windowsでは、setup.exeをダブルクリックします。
runInstallerとsetup.exeの各ファイルは、../install/platformディレクトリにあります。このplatformとは、LinuxやWin32などのプラットフォームです。
「インベントリ・ディレクトリの指定」画面で、Oracleインベントリ・ディレクトリおよびオペレーティング・システムのグループ名に値を入力します。例:
インベントリ・ディレクトリの指定: /u01/app/oraInventory
オペレーティング・システムのグループ名: oinstall
次のメッセージのダイアログ・ボックスが開きます。
「インストールを続行する前に、root権限で特定の処理を実行する必要があります。別のウィンドウで/u01/app/oraInventory/createCentralInventory.shスクリプトを実行してから、「OK」をクリックしてインストールを続行してください。root権限を持たずにインストールを続行する場合は「ローカル・インベントリでインストールを続行」オプションを選択してください」
rootユーザーとしてログインして、/u01/app/oraInventory/createCentralInventory.shを実行します。
これにより、Oracleインベントリ・ディレクトリに必要な権限が設定され、「ようこそ」画面が表示されます。
|
注意: すでにこのホストにOracle製品がインストールされている場合は、Oracleインベントリ画面は表示されません。このインストールでOracleインベントリ画面が表示されない場合は、次の内容を確認してください。
|
「ようこそ」画面で「次へ」をクリックします。
「インストール・タイプの選択」画面で、「インストールと構成」を選択して「次へ」をクリックします。
「前提条件のチェック」画面で、インストーラによって前提条件のチェックが完了します。チェックに失敗した項目がある場合は、修正してインストールを再開します。
「次へ」をクリックします。
「インストール場所の指定」画面で、次の操作を行います。
WEBHOST1で、「場所」を次のように設定します。
/u01/app/oracle/admin
「次へ」をクリックします。
「コンポーネントの構成」画面で、次の操作を行います。
「Oracle HTTP Server」を選択します。
「選択されたコンポーネントとWebLogicドメインの関連付け」を選択します。
「次へ」をクリックします。
「WebLogicドメインの指定」画面で:
Oracle WebLogic Serverをインストールした場所を入力します。管理サーバーが実行されている必要があります。
ドメイン・ホスト名: ECMHOST1
ドメインのポート番号: 7001
ユーザー名: weblogic
パスワード: ******
「次へ」をクリックします。
「コンポーネントの詳細の指定」画面で、次の操作を行います。
WEBHOST1に次の値を入力します。
インスタンス・ホームの場所: /u01/app/oracle/admin/ohs_inst1
インスタンス名: ohs_inst1
OHSコンポーネント名: ohs1
「次へ」をクリックします。
「Web Tierポートの詳細の指定」画面で、次の操作を行います。
「カスタム・ポートを指定」を選択します。カスタム・ポートを指定する場合には、「構成ファイルを使用してポートを指定」を選択してから、「参照」機能を使用してファイルを選択します。
Oracle HTTP Serverポートを入力します(例: 7777)。
「次へ」をクリックします。
「Oracle Configuration Manager」画面で、次のように入力します。
電子メール・アドレス: My Oracle Supportアカウントの電子メール・アドレスを指定します。
My Oracle Supportパスワード: My Oracle Supportアカウントのパスワードを指定します。
セキュリティ・アップデートをMy Oracle Support経由で受け取ります。: このチェック・ボックスを選択します。
「インストール・サマリー」画面で、選択した内容が正しいことを確認します。正しくない場合は、「戻る」をクリックして必要に応じて修正します。選択が適切であれば、「次へ」をクリックします。
UNIXシステムでは、「インストールの進行状況」画面にoracleRoot.shスクリプトの実行を指示するダイアログが表示されます。ウィンドウを開き、表示される指示に従ってスクリプトを実行します。
「次へ」をクリックします。
「構成の進行状況」画面で、複数の構成アシスタントが連続して起動します。このプロセスには時間がかかる可能性があります。
「構成が完了しました」画面で「終了」をクリックして終了します。
Oracle HTTP ServerをWEBHOST1にインストールしたら、次の行をOHS_HOME/instances/ohs_instance1/config/OHS/ohs1/mod_wl_ohs.confファイルに追加します。
# UCM
<Location /cs>
WebLogicCluster ecmhost1:16200,ecmhost2:16200
SetHandler weblogic-handler
WLCookieName JSESSIONID
</Location>
<Location /adfAuthentication>
WebLogicCluster ecmhost1:16200,ecmhost2:16200
SetHandler weblogic-handler
WLCookieName JSESSIONID
</Location>
# URM
<Location /urm>
WebLogicCluster ecmhost1:16250,ecmhost2:16250
SetHandler weblogic-handler
WLCookieName JSESSIONID
</Location>
<Location /urm/adfAuthentication>
WebLogicCluster ecmhost1:16250,ecmhost2:16250
SetHandler weblogic-handler
WLCookieName JSESSIONID
</Location>
# IBR
<Location /ibr>
WebLogicCluster ecmhost1:16300,ecmhost2:16300
SetHandler weblogic-handler
WLCookieName JSESSIONID
</Location>
<Location /ibr/adfAuthentication>
WebLogicCluster ecmhost1:16300,ecmhost2:16300
SetHandler weblogic-handler
WLCookieName JSESSIONID
</Location>
# I/PM Application
<Location /imaging>
SetHandler weblogic-handler
WebLogicCluster ECMHOST1VHN1:16000,ECMHOST2VHN1:16000
</Location>
# AXF WS Invocation
<Location /axf-ws>
SetHandler weblogic-handler
WebLogicCluster ECMHOST1VHN1:16000,ECMHOST2VHN1:16000
</Location>
これらの行では、WEBHOST1上のOracle HTTP Serverを構成して、ECMHOST1およびECMHOST2のクラスタ化されたアプリケーションにリクエストをルーティングします。
|
注意: WLCookieNameの値は、以前のソフトウェア・リリースの値とは異なります。以前のリリースでは、この値はIDCCS_SESSIONIDでしたが、このリリースではJSESSIONIDになります。 |
これらの行を追加したら、Oracle HTTP Serverを再起動し、次を指定してアプリケーションにアクセスできることを確認します。
http://WEBHOST1:7777/cs http://WEBHOST1:7777/urm http://WEBHOST1:7777/imaging
|
注意: アプリケーションの使用方法に応じて、「More Location」タグを追加する必要がある場合があります。たとえば、Oracle UCMはWebDavへのアクセスには/_dav、Webサービスへのアクセスには/idcwsにアクセスする必要があります。詳細は、製品のドキュメントを参照してください。 |
ラウンドロビン・ロード・バランシングを使用して仮想ホスト(ucm.mycompany.com)が使用可能なOracle HTTP Serverにルーティングされるように、ロード・バランサを構成します。
また、各Oracle HTTP ServerでHTTPおよびHTTPSリスニング・ポートを監視するように、ロード・バランサを構成する必要があります。
http://WEBHOST1:7777/csでOracle Content Serverにアクセスできることを確認します。
この項では、ECMHOST2で実行するインストールおよび構成手順について説明します。
ECMHOST2にOracle WebLogic Serverをインストールするには、第11.3.3.1項「ECMHOST1へのOracle WebLogic Serverのインストール」の手順をECMHOST2で実行します。
ECMHOST2にOracle ECMをインストールするには、第11.3.3.2項「ECMHOST1へのOracle ECMのインストール」の手順をECMHOST2で実行します。
packおよびunpackコマンドを使用して、ECMHOST2のWLS_UCM2管理対象サーバーをECMHOST1のECMドメインに参加できるようにします。
最初に、ECMHOST1でpackコマンドを実行します。
pack -managed=true -domain=/u01/app/oracle/product/WLS/11G/user_projects/domains /ecmdomain -template=ecm_template.jar -template_name="my ecm domain"
ecm_template.jarファイルをECMHOST2にコピーした後に、ECMHOST2でunpackコマンドを実行します。
unpack -domain=/u01/app/oracle/product/WLS/11G/user_projects/domains/ecmdomain -template=ecm_template.jar
ECMHOST2でノード・マネージャを起動するには、次のコマンドを使用します。
ECMHOST2> MW_HOME/oracle_common/common/bin/setNMProps.sh ECMHOST2> WL_HOME/wlserver_10.3/bin/startNodeManager.sh
管理コンソール(http://ECMHOST1:7001/console)にアクセスします。管理コンソールで、WLS_UCM2管理対象サーバーを起動します。
管理コンソール(http://ECMHOST2:7001/console)にアクセスします。管理コンソールで、WLS_UCM2、WLS_URM2、およびWLS_IPM2管理対象サーバーを停止します。
WLS_UCM2構成ページ(http://ECMHOST2:16200/cs)にアクセスします。
ログインすると、構成ページが開きます。Oracle UCM構成ファイルは、共有ディスクに配置されている必要があります。この例では、共有ディスクを/orashare/orcl/ucmと想定しています。
構成ページの次の項目を、ここで示す値に設定します。
コンテンツ・サーバーのインスタンス・フォルダ: /orashare/orcl/ucm/cs/
ネイティブ・ファイル・リポジトリの場所: /orashare/orcl/ucm/cs/vault/
Webレイアウト・フォルダ: /orashare/orcl/ucm/cs/weblayout/
サーバー・ソケット: ポート4444
ソケット接続アドレス・セキュリティ・フィルタ: ローカル・ホストとHTTP Serverホストのリストをパイプで区切って設定します(127.0.0.1|WEBHOST1|WEBHOST2)。
WebサーバーのHTTPアドレス: ロード・バランサHTTPのホストとポートを設定します(ucm.mycompany.com:80)。
これらの更新を行ったら、「送信」をクリックしてWLS_UCM2管理対象サーバーを再起動します。
WLS_URM2構成ページ(http://ECMHOST2:16250/urm)にアクセスします。
ログインすると、構成ページが開きます。Oracle URM構成ファイルは、共有ディスクに配置されている必要があります。この例では、共有ディスクを/u01/app/oracle/admin/domainName/ucm_clusterと想定しています。
構成ページの次の項目を、ここで示す値に設定します。
コンテンツ・サーバーのインスタンス・フォルダ: /u01/app/oracle/admin/domainName/ucm_cluster/urm
ネイティブ・ファイル・リポジトリの場所: /u01/app/oracle/admin/domainName/ucm_cluster/urm/vault
Webレイアウト・フォルダ: /u01/app/oracle/admin/domainName/ucm_cluster/urm/weblayout
サーバー・ソケット: ポート4445
ソケット接続アドレス・セキュリティ・フィルタ: ローカル・ホストとHTTP Serverホストのリストをパイプで区切って設定します(127.0.0.1|WEBHOST1|WEBHOST2)。
WebサーバーのHTTPアドレス: ロード・バランサHTTPのホストとポートを設定します(ecm.mycompany.com:80)。
これらの更新を行ったら、「送信」をクリックし、WLS_URM1管理対象サーバーを再起動します。
この項では、WEBHOST2で実行するインストールおよび構成手順について説明します。
この項では、WEBHOST2にOracle HTTP Serverをインストールする方法について説明します。
システム、パッチ、カーネルなどの要件が満たされていることを確認します。それらの一覧は、使用しているプラットフォームおよびバージョンのOracle Fusion Middlewareのドキュメント・ライブラリの『Oracle Fusion Middleware Oracle Web Tierインストレーション・ガイド』にあります。
ポート7777がWEBHOST2上のサービスによって使用されていないことを確認するために、使用しているオペレーティング・システムに対して次のコマンドを実行します。ポートが使用されていなければ、コマンドを実行しても何も出力されません。
UNIXの場合:
netstat -an | grep "7777"
Windowsの場合:
netstat -an | findstr :7777
ポートが使用されている(コマンドを実行するとポートを識別する戻り値が表示される)場合は、そのポートを解放する必要があります。
UNIXの場合:
ポート7777のエントリを/etc/servicesファイルから削除し、サービスを再起動するか、コンピュータを再起動します。
Windowsの場合:
ポートを使用しているコンポーネントを停止します。
staticports.iniファイルをDisk1/stage/Responseディレクトリから一時ディレクトリにコピーします。
一時ディレクトリにコピーしたstaticports.iniファイルを編集して、次のカスタム・ポート(Oracle HTTP Serverのポート番号を指定する行は非コメント化)を割り当てます。
# The port for Oracle HTTP server Oracle HTTP Server port = 7777
Oracle Fusion Middleware 11g Web Tier Utilities CDインストールのOracle Universal Installerを、次のように開始します。
UNIXでは、コマンドrunInstallerを発行します。
Windowsでは、setup.exeをダブルクリックします。
runInstallerとsetup.exeの各ファイルは、../install/platformディレクトリにあります。このplatformとは、LinuxやWin32などのプラットフォームです。
Oracleインベントリの指定画面が表示されます。
「インベントリ・ディレクトリの指定」画面で、Oracleインベントリ・ディレクトリおよびオペレーティング・システムのグループ名に値を入力します。例:
インベントリ・ディレクトリの指定: /u01/app/oraInventory
オペレーティング・システムのグループ名: oinstall
次のメッセージのダイアログ・ボックスが表示されます。
インストールを続行する前に、root権限で特定の処理を実行する必要があります。別のウィンドウで/u01/app/oraInventory/createCentralInventory.shスクリプトを実行してから、「OK」をクリックしてインストールを続行してください。root権限を持たずにインストールを続行する場合は「ローカル・インベントリでインストールを続行」オプションを選択してください」
rootユーザーとしてログインして、/u01/app/oraInventory/createCentralInventory.shを実行します。
これにより、Oracleインベントリ・ディレクトリに必要な権限が設定され、「ようこそ」画面が表示されます。
|
注意: すでにこのホストにOracle製品がインストールされている場合は、Oracleインベントリ画面は表示されません。このインストールでOracleインベントリ画面が表示されない場合は、次の内容を確認してください。
|
「ようこそ」画面で「次へ」をクリックします。
「インストール・タイプの選択」画面で、「インストールと構成」を選択して「次へ」をクリックします。
「前提条件のチェック」画面で、インストーラによって前提条件のチェックが完了します。チェックに失敗した項目がある場合は、修正してインストールを再開します。
「次へ」をクリックします。
「インストール場所の指定」画面で、次の操作を行います。
WEBHOST2で、「場所」を次のように設定します。
/u01/app/oracle/admin
「次へ」をクリックします。
「コンポーネントの構成」画面で、次の操作を行います。
「Oracle HTTP Server」を選択します。
「選択されたコンポーネントとWebLogicドメインの関連付け」を選択します。
「次へ」をクリックします。
「WebLogicドメインの指定」画面で:
Oracle WebLogic Serverをインストールした場所を入力します。管理サーバーが実行されている必要があります。
ドメイン・ホスト名: ECMHOST1
ドメインのポート番号: 7001
ユーザー名: weblogic
パスワード: ******
「次へ」をクリックします。
「コンポーネントの詳細の指定」画面で、次の操作を行います。
WEBHOST2に次の値を入力します。
インスタンス・ホームの場所: /u01/app/oracle/admin/ohs_inst2
インスタンス名: ohs_inst2
OHSコンポーネント名: ohs2
「次へ」をクリックします。
「Web Tierポートの詳細の指定」画面で、次の操作を行います。
「カスタム・ポートを指定」を選択します。カスタム・ポートを指定する場合には、「構成ファイルを使用してポートを指定」を選択してから、「参照」機能を使用してファイルを選択します。
Oracle HTTP Serverポートを入力します(例: 7777)。
「次へ」をクリックします。
「Oracle Configuration Manager」画面で、次のように入力します。
電子メール・アドレス: My Oracle Supportアカウントの電子メール・アドレスを指定します。
My Oracle Supportパスワード: My Oracle Supportアカウントのパスワードを指定します。
セキュリティ・アップデートをMy Oracle Support経由で受け取ります。: このチェック・ボックスを選択します。
「インストール・サマリー」画面で、選択した内容が正しいことを確認します。正しくない場合は、「戻る」をクリックして必要に応じて修正します。選択が適切であれば、「次へ」をクリックします。
UNIXシステムでは、「インストールの進行状況」画面にoracleRoot.shスクリプトの実行を指示するダイアログが表示されます。ウィンドウを開き、表示される指示に従ってスクリプトを実行します。
「次へ」をクリックします。
「構成の進行状況」画面で、複数の構成アシスタントが連続して起動します。このプロセスには時間がかかる可能性があります。
「構成が完了しました」画面で「終了」をクリックして終了します。
WEBHOST2にOracle HTTP Serverをインストールするには、第11.3.4.2項「WEBHOST1でのOracle HTTP Serverの構成」の手順をWEBHOST2で実行します。
この項では、Oracle I/PM JMSのJMS永続ストアの構成方法、トランザクション・リカバリのためのデフォルトの永続ストアの構成方法、およびOracle UCM管理対象サーバーでのOracle I/PM管理対象サーバーの構成方法について説明します。最後に、Oracle I/PM管理対象サーバーのサーバー移行を構成する手順についても説明します。
2つのノードから参照できるディレクトリとして、JMS永続ストアの場所を構成します。デフォルトでは、I/PMで使用されるJMSサーバーに永続ストアは構成されず、WebLogic Serverのストア(ORACLE_BASE/admin/domain_name/mserver/domain_name/servers/server_name/data/store/default)を使用しています。次のように、共有ベースのディレクトリを使用するように、I/PMのJMSサーバーの永続ストアを変更する必要があります。
Oracle WebLogic Server管理コンソールにログインします。
「ドメイン構造」ウィンドウで、「サービス」ノードを開いて永続ストアノードをクリックします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「新規」をクリックしてから、「ファイル・ストアの作成」をクリックします。
名前(例: 「IPMJMSServer1Store」。これにより、作成対象のサービスを特定できます)およびターゲットのWLS_IPM1を入力します。ECMHOST1とECMHOST2の両方からアクセスできる共有記憶域にあるディレクトリを入力します(ORACLE_BASE/admin/domain_name/ipm_cluster/jms)。
「OK」をクリックして、変更をアクティブ化します。
「ドメイン構造」ウィンドウで、「サービス」ノードを開き、「メッセージング」→「JMSサーバー」ノードをクリックします。
表の「名前」列から「IpmJmsServer1 JMS Server」(ハイパーリンクで表示)をクリックします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「永続ストア」ドロップダウン・リストで、「IPMJMSServer1Store」を選択します。
「保存」→「変更のアクティブ化」をクリックします。
手順を繰り返して、IPMJMSServer2のIPMJMSServer2Storeを作成します。
各サーバーにはトランザクション・ログがあり、サーバーによって調整およびコミットされた、未完了の可能性のあるトランザクションについての情報が格納されます。WebLogic Serverは、システム・クラッシュやネットワーク障害のリカバリでこのトランザクション・ログを使用します。クラスタ内のサーバーでトランザクション回復サービスの移行機能を活用するには、サーバーからアクセス可能な場所にトランザクション・ログを格納します。
|
注意: 可能であれば、この場所にはデュアル・ポートのSCSIディスクまたはストレージ・エリア・ネットワーク(SAN)を使用します。 |
WLS_IPM1のデフォルトの永続ストアの場所を設定する手順は次のとおりです。
Oracle WebLogic Server管理コンソールにログインします。
「ドメイン構造」ウィンドウで、「環境」ノードを開いて「サーバー」ノードをクリックします。
「WLS_IPM1」(表の「名前」列にハイパーリンクとして表示)をクリックします。
WLS_IPM1サーバーの設定ページが開き、「構成」タブがアクティブに表示されます。
「サービス」タブをクリックします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
ページの「デフォルト・ストア」セクションに、デフォルトの永続ストアがデータファイルを格納するフォルダのパスを入力します。パスのディレクトリ構造は、次のようになります。
ORACLE_BASE/admin/domain_name/ipm_cluster_name/tlogs
「保存」をクリックして、変更をアクティブ化します。
WLS_IPM2サーバーに対してこの手順を繰り返します。
|
注意: トランザクション回復サービスの移行機能を有効化するには、クラスタ内の他のサーバーで利用可能な永続記憶域ソリューション上の場所を指定します。ECMHOST1とECMHOST2の両方が、このディレクトリにアクセスできる必要があります。このディレクトリは、サーバーを再起動する前にも存在している必要があります。 |
Oracle IP/Mクラスタは、Oracle UCMクラスタにアクセスするように構成する必要があります。
次の手順を実行して、Oracle Content ServerでOracle I/PMを有効にします。
Oracle Content Server(http://ECMHOST1:16200/cs)にログインします。
「管理」トレイまたはメニューを開いて、「管理サーバー」を選択します。
「コンポーネント・マネージャ」をクリックします。
IpmRepositoryコンポーネントを有効にします。
UCMクラスタ内のすべての管理対象サーバーを再起動します。
次の手順を実行して、Oracle Content Serverのデフォルトのファイル・ストアをアップグレードします。
Oracle Content Server(http://ECMHOST1:16200/cs)にログインします。
「管理」トレイまたはメニューを開いて、「プロバイダ」を選択します。
「DefaultFileStore」の「情報」リンクをクリックします。
DefaultFileStoreの「ファイル・ストア・プロバイダ情報」ページが開きます。
「編集」をクリックします。
「更新」をクリックします。
クラスタ内のすべてのコンテンツ・サーバーを再起動します。
次の手順を実行して、WLS_IPM1およびWLS_IPM2管理対象サーバー(それぞれ、ECMHOST1VHN1およびECMHOST2VHN1)のOracle I/PM Serverのリスニング・アドレスをUCMの許可されたホストのリストに追加します。
ファイル/u01/app/oracle/admin/domainName/ucm_cluster/config/config.cfgを編集して、次の行を削除またはコメント・アウトします。
SocketHostAddressSecurityFilter=127.0.0.1|0:0:0:0:0:0:0:1
WLS_IPM1およびWLS_IPM2リスニング・アドレスをUCMへの接続を許可するアドレスのリストに含めるために、次の2行を追加します。
SocketHostNameSecurityFilter=localhost|localhost.mydomain.com|ecmhost1vhn1|ecmhost2vhn1 AlwaysReverseLookupForHost=Yes
UCMサーバーを再起動して、変更を有効にします。
次の手順を実行して、UCMシステムへの接続を作成します。
WLS_IPM1イメージング・コンソール(http://ECMHOST1:16200/ imaging)にログインします。
左側のペインで、「接続の管理」→「Content Server接続の作成」をクリックします。
新しい接続の名前と説明を入力し、「次へ」をクリックします。
「接続設定」画面で、次の操作を実行します。
「ローカルContent Serverの使用」が選択されていることを確認します。
Content Serverポートを4444に設定します。
2つのサーバーを「Content Serverプール」に追加します。
ECMHOST1:4444
ECMHOST2:4444
「次へ」をクリックします。
「接続セキュリティ」画面で、WebLogicユーザーに対するデフォルトの選択をそのまま受け入れて、「次へ」をクリックします。
接続の詳細を確認し、「送信」をクリックします。
Oracle I/PMからBPELシステムに接続する場合、SOAシステムと通信するために必要な資格証明を構成する必要があります。これらの資格証明を追加するには、次の手順を実行します。
(管理サーバーが存在する)ECMHOST1のECM Oracleホームの下のcommon/binにディレクトリを変更します。
ECMHOST1>cd ORACLE_HOME/common/bin
(ORACLE_HOMEは、MW_HOME/ecmの下のECMホームです。)
Oracle WebLogic Scripting Tool(WLST)を実行します。
ECMHOST1>./wlst.sh
connect()を実行して、ユーザー名、パスワード、および管理サーバーのURL(t3://ECMHOST1:7001)を指定します。
wls:/offline> connect()
CSF(資格証明ストア・フレームワーク)資格証明を作成します。この資格証明は、I/PMがBPELシステムへの接続に使用する資格証明です。これをBPEL管理ユーザーにします。CSF資格証明は、「alias」がキーとなり、CSFの「map」という中に保存されるユーザー名/パスワードのペアです。OWSM Webサービスと統合するため、I/PMは現在oracle.wsm.securityという標準のOWSM CSFマップを使用しています。資格証明を作成するには、createCred WLSTコマンドを使用します。
wls:/ecm_domain/serverConfig> createCred(map="oracle.wsm.security", key="basic.credential", user="weblogic", password="password_for_credential")
コマンドの「key」は、I/PM管理ユーザー・インタフェースのBPEL接続定義の「資格証明別名」プロパティに使用される「alias」です(APIのConnection.CONNECTION_BPEL_CSFKEY_KEYプロパティにも使用されます)。OWSMおよびBPELで使用される標準のデフォルト名であるため、この例では別名「basic.credential」を使用します。ただし、別名はマップ内で一意であれば、任意に指定できます。
資格証明のリストコマンドを実行して、資格証明が作成されたことを確認します。
wls:/ecm_domain/serverConfig> listCred(map="oracle.wsm.security", key="basic.credential")
{map=oracle.wsm.security, key=basic.credential}
Already in Domain Runtime Tree
[Name : weblogic, Description : null, expiry Date : null]
PASSWORD: password_for_credential
次の手順を実行して、BPEL接続を構成します。
WLS_IPM1イメージング・コンソール(http://ECMHOST1VHN1:16000/imaging)にログインします。
左側のペインで、「接続の管理」→「ワークフロー接続の作成」をクリックします。
「BPEL接続の作成」ボタンをクリックします。
BPELマシン名、およびオプションで説明を入力します。
「次へ」をクリックします。
「接続設定」画面で、次の操作を実行します。
プロバイダ名フィールドに、2つのSOAサーバー・リスニング・アドレスをカンマで区切って入力します: SOAHOST1VHN2, SOAHOST2VHN1
BPELポートを指定します: 8001
ターゲットBPELシステムに必要な場合、「SSL」オプションを選択します。
「BPEL CSF資格証明の構成」の項で作成した資格証明の別名を指定します。
「接続のテスト」ボタンをクリックして、接続パラメータを確認し、BPELマシンに存在するコンポジットを確かめます。
「次へ」をクリックします。
必要に応じて、付与するセキュリティを変更します。
「次へ」をクリックします。
「送信」をクリックします。
Oracle WebLogic Server I/PMクラスタに対してフロントエンドHTTPのホストとポートを設定する必要があります。
Oracle WebLogic Server管理コンソールにログインします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「ドメイン構造」ウィンドウで、「環境」ノードを開きます。
「クラスタ」をクリックします。
「IPM_Cluster」を選択します。
「HTTP」タブをクリックします。
次の値を設定します。
フロントエンド・ホスト: ecm.mycompany.com
フロントエンドHTTPSポート: 443
フロントエンドHTTPポート: 80(SSLを使用しない場合)
「保存」をクリックします。
管理コンソールの「チェンジ・センター」セクションで「変更のアクティブ化」をクリックします。
サーバーを再起動して、クラスタ内のフロントエンド・ホスト・ディレクティブを有効化します。
この項では、Oracle I/PMインスタンスのサーバー移行を構成する方法について説明します。
次の手順では、Oracle I/PM管理対象サーバーのサーバー移行を有効にします。これにより、サーバーまたはプロセスの障害時に、Oracle I/PM管理対象サーバーは別のノードにフェイルオーバーできます。
WebLogic管理対象サーバーのサーバー移行を構成する手順は、次のとおりです。
ステップ1: サーバー移行leasing表のユーザーと表領域を設定する
ステップ3: ノード・マネージャのプロパティ・ファイルを編集する
ステップ5: サーバー移行ターゲットを構成する
ステップ6: サーバー移行をテストする
次の手順に従って、サーバー移行のleasing表のユーザーと表領域を設定します。
|
注意: 同じドメイン内の他のサーバーがすでにサーバー移行で構成されている場合、同じ表領域とデータ・ソースを使用できます。その場合、データベースleasingのデータ・ソースおよびマルチ・データ・ソースは再作成する必要はありませんが、サーバー移行で構成されているクラスタIPM_Clusterを再度ターゲットに設定する必要があります。 |
leasingという表領域を作成します。たとえば、ユーザーsysdbaでSQL*Plusにログインし、次のコマンドを実行します。
SQL> create tablespace leasing logging datafile 'DB_HOME/oradata/orcl/leasing.dbf' size 32m autoextend on next 32m maxsize 2048m extent management local;
leasingという名前のユーザーを作成し、leasing表領域に割り当てます。
SQL> create user leasing identified by welcome1; SQL> grant create table to leasing; SQL> grant create session to leasing; SQL> alter user leasing default tablespace leasing; SQL> alter user leasing quota unlimited on LEASING;
leasing.ddlスクリプトを使用してleasing表を作成します。
WL_HOME/server/db/oracle/817またはWL_HOME/server/db/oracle/920のいずれかのディレクトリにあるleasing.ddlファイルをデータベース・ノードにコピーします。
データベースにleasingユーザーとして接続します。
leasing.ddlスクリプトをSQL*Plusで実行します。
SQL> @Copy_Location/leasing.ddl;
この項では、Oracle WebLogic Server管理コンソールからleasing表のマルチ・データ・ソースを作成する方法について説明します。マルチ・データ・ソースの設定プロセスで、各Oracle RACデータベース・インスタンスのデータ・ソースを、これらのデータ・ソースとグローバルleasingマルチ・データ・ソースの両方について作成します。データ・ソースを作成する際は、次の考慮事項に留意してください。
このデータ・ソースが非XAデータ・ソースであることを確認します。
マルチ・データ・ソースの名前の形式は、<MultiDS>-rac0、<MultiDS>-rac1などです。
Oracleのドライバ(Thin)バージョン9.0.1、9.2.0、10、11を使用します。
データ・ソースは、グローバル・トランザクションのサポートを必要としません。したがって、データ・ソースに対して、どのようなタイプの分散トランザクション・エミュレーション/参加アルゴリズムも使用しない(「グローバル・トランザクションのサポート」オプション、または「グローバル・トランザクションのサポート」オプションの「ロギング・ラスト・リソース」、「2フェーズ・コミットのエミュレート」または「1フェーズ・コミット」オプションを選択しない)で、データベースのサービス名を指定します。
これらのデータ・ソースをI/PMクラスタにターゲット指定します。
データ・ソースの初期接続プール容量が0(ゼロ)に設定されていることを確認します。そのためには、「サービス」→「JDBC」→「データ・ソース」を選択します。「データ・ソース」画面で、「データ・ソース名」→「接続プール」タブをクリックし、「初期容量」フィールドに0を入力します。
マルチ・データ・ソースの作成
マルチ・データ・ソースを作成するには、次の手順を実行します。
Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「サービス」ノードを開き、「データ・ソース」をクリックします。「JDBCデータ・ソースのサマリー」ページが表示されます。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「新規」→「マルチ・データ・ソース」をクリックします。「新しいJDBCマルチ・データ・ソースの作成」ページが表示されます。
名前として、leasingと入力します。
JNDI名として、jdbc/leasingと入力します。
アルゴリズムとして、「フェイルオーバー」(デフォルト)を選択します。
「次へ」をクリックします。
ターゲットとして、Oracle I/PMクラスタを選択します。
「次へ」をクリックします。
「非XAドライバ」(デフォルト)を選択します。
「次へ」をクリックします。
「新しいデータ・ソースの作成」をクリックします。
名前として、leasing-rac0と入力します。JNDI名として、jdbc/leasing-rac0と入力します。データベースのタイプとして、oracleと入力します。ドライバのタイプとして、「Oracle Driver (Thin) for RAC server-Instance connection Version 10,11」を選択します。
|
注意: leasing表のマルチ・データ・ソースを作成するときに、名前を<MultiDS>-rac0、<MultiDS>-rac1などの形式で入力します。 |
「次へ」をクリックします。
「グローバル・トランザクションのサポート」の選択を解除します。
「次へ」をクリックします。
leasingスキーマのサービス名、データベース名(これは実際には、racdb1、racdb2など、RACノードのインスタンス名です)、ホスト・ポートおよびパスワードを入力します。
「次へ」をクリックします。
「構成のテスト」をクリックして、接続が機能しているかどうかを確認します。
「次へ」をクリックします。
データ・ソースをI/PMクラスタにターゲット指定します。
データ・ソースを選択して、右の画面に追加します。
Oracle RACデータベースの2つ目のインスタンスについて「新しいデータ・ソースの作成」をクリックして、そのターゲットをIPM_Clusterに設定してから、Oracle RACデータベースの2つ目のインスタンスについても同じ手順を繰り返します。
2つ目のデータ・ソースをマルチ・データ・ソースに追加します。
「変更のアクティブ化」をクリックします。
この項では、ノード・マネージャのプロパティ・ファイルnodemanager.propertiesの編集方法について説明します。これは、サーバーの移行を構成する両方のノードのノード・マネージャに対して実行する必要があります。
Interface=eth0 NetMask=255.255.255.0 UseMACBroadcast=true
Interface: このプロパティは、浮動IPのインタフェース名(たとえば、Linuxではeth0)を指定します。
|
注意: サブ・インタフェース(eth0:1、eth0:2など)を指定しないでください。このインタフェースは、:0または:1なしに使用されます。ノード・マネージャのスクリプトは、別の:X対応のIPを移動して、追加または削除するものを決定します。たとえば、Linux環境で有効な値は、構成済のインタフェースの数に応じて、eth0、eth1、eth2、eth3、ethnとなります。 |
|
注意: Windowsの場合、Interfaceには、ネットワーク・インタフェース名を設定する必要があります。例:Interface="Local Area Connection" |
NetMask: このプロパティでは、インタフェースの浮動IPのネット・マスクを指定します。ネット・マスクは、インタフェース上のネット・マスクと同じである必要があります。このドキュメントの例では、255.255.255.0が使用されています。
UseMACBroadcast: このプロパティでは、ARPパケットの送信時にノードのMACアドレスを使用するかどうか、すなわち、arpingコマンドで-bフラグを使用するかどうかを指定します。
これらのプロパティが使用されているか、または移行中に問題が発生していないかを、ノード・マネージャの出力(ノード・マネージャが起動されているシェル)で確認します。ノード・マネージャの出力は、次のように表示されます。
... StateCheckInterval=500 Interface=eth0 (Linux) or Interface="Local Area Connection" (Windows) NetMask=255.255.255.0 ...
|
注意: 次の手順は、サーバー・プロパティ(起動プロパティ)が適切に設定されていて、ノード・マネージャがリモートでサーバーを起動できる場合には不要です。 |
nodemanager.propertiesファイルで次のプロパティを設定します。
StartScriptEnabled: このプロパティをtrueに設定します。これは、ノード・マネージャが起動スクリプトを使用して管理対象サーバーを起動するために必要です。
WL_HOME/server/binディレクトリにあるstartNodeManager.shスクリプトを実行して、ECMHOST1とECMHOST2でノード・マネージャを起動します。
|
注意: 共有記憶域インストールからノード・マネージャを実行する場合、同じnodemanager.propertiesファイルを使用して複数のノードが起動します。ただし、各ノードでは、別のNetMaskまたはInterfaceプロパティが必要なことがあります。この場合、環境変数を使用して、ノードごとに個々のパラメータを指定します。たとえば、ECMHOSTnで異なるインタフェース(eth3)を使用するには、インタフェース環境変数を「ECMHOSTn> export JAVA_OPTIONS=-DInterface=eth3」のように使用して、この変数がシェル内で設定された後にノード・マネージャを起動します。 |
この項では、wlsifconfig.shスクリプトの環境とスーパーユーザー権限を設定する方法について説明します。
|
注意: Windowsでは、そのスクリプトの名前はwlsifconfig.cmdであり、それを実行できるのは管理者権限を持つユーザーです。 |
PATH環境変数に次のファイルが含まれていることを確認します。
wlsifconfig.shスクリプトに対するsudo構成権限を付与します。
パスワード・プロンプトを使用しないで機能するsudoを構成します。
セキュリティ上の理由から、sudoをwlsifconfig.shスクリプトの実行に必要なコマンドのサブセットに限定する必要があります。たとえば、wlsifconfig.shスクリプトの環境とスーパーユーザー権限を設定するには、次の手順を実行します。
WebLogicユーザー(oracle)に、パスワードなしのsudo権限を付与し、/sbin/ifconfigと/sbin/arpingのバイナリの実行権限を付与します。
スクリプトがWebLogicユーザー(oracle)によって実行可能であることを確認してください。/etc/sudoers内の次のエントリ例では、oracleのsudo実行権限を、ifconfigとarpingに対しても付与しています。
Defaults:oracle !requiretty oracle ALL=NOPASSWD: /sbin/ifconfig,/sbin/arping
|
注意: この手順で使用できるsudoとシステム権限はシステム管理者にお問い合せください。 |
この項では、サーバー移行ターゲットを構成する方法について説明します。まず、クラスタのメンバーに対して使用可能なすべてのノードを割り当て、サーバー移行で構成される各サーバー用の候補サーバーを(適切な順に)指定します。クラスタ内の移行でクラスタ移行を構成するには、次の手順を実行します。
Oracle WebLogic Server管理コンソール(http://Host:Admin_Port/console)にログインします。通常、Admin_Portは7001(デフォルト)です。
「ドメイン構造」ウィンドウで、「環境」を開き、「クラスタ」を選択します。
移行を構成するクラスタ(IPM_Cluster)を、表の「名前」列でクリックします。
「移行」タブをクリックします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印ボタンをクリックします。この場合は、「ECMHOST1」と「ECMHOST2」を選択します。
自動移行に使用するデータ・ソースを選択します。この場合は、leasingデータ・ソースを選択します。
「保存」をクリックします。
「変更のアクティブ化」をクリックします。
サーバー移行の候補マシンを設定します。管理対象サーバーすべてについてこのタスクを次のように実行する必要があります。
Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」を開いて、「サーバー」を選択します。
|
ヒント: サーバーが実行されているマシンを表示するには、「サーバーのサマリー」ページで「この表のカスタマイズ」をクリックし、「現在のマシン」を「使用可能」ウィンドウから「選択済み」ウィンドウに移動します。サーバーが自動的に移行される場合、これはこの構成とは異なります。 |
移行を構成するサーバーを選択します。
「移行」タブをクリックします。
「移行の構成」セクションの「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印ボタンをクリックします。WLS_IPM1には「ECMHOST2」を選択します。WLS_IPM2には「ECMHOST1」を選択します。
「サーバーの自動移行を有効化」を選択します。これにより、ノード・マネージャが、障害の発生したサーバーをターゲット・ノード上で自動的に起動できるようになります。
「保存」をクリックします。
「変更のアクティブ化」をクリックします。
管理サーバー、ノード・マネージャ、およびサーバー移行が構成されたサーバーを再起動します。
最後の手順は、サーバー移行をテストすることです。サーバー移行が適切に機能していることを確認するには、次の手順を実行します。
ECMHOST1から次の処理を実行します。
管理対象サーバーWLS_IPM1を停止します。これを行うには、このコマンドを実行します:
ECMHOST1> kill -9 pid
pidには、管理対象サーバーのプロセスIDを指定します。次のコマンドを実行すると、ノード内のpidを確認できます。
ECMHOST1> ps -ef | grep WLS_IPM1
|
注意: Windowsの場合は、taskkillコマンドを使用して管理対象サーバーを終了できます。例:
taskkill /f /pid <pid> <pid>は、管理対象サーバーのプロセスIDを表します。 管理対象サーバーのプロセスIDを調べるには、次のコマンドを実行して、管理対象サーバーWLS_IPMnのpidを確認します。 MW_HOME\jrockit_160_20_D1.0.1-2124\bin\jps -l -v |
ノード・マネージャのコンソールを確認します。WLS_IPM1の浮動IPが無効になっていることを示すメッセージが表示されることを確認します。
ノード・マネージャがWLS_IPM1の2回目の再起動を試行するのを待ちます。この再起動を試行するまでに30秒間待機します。
ノード・マネージャがサーバーを再起動した後で、そのサーバーをもう一度停止します。サーバーが再びローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されるようになります。
ECMHOST2から次の処理を実行します。
ローカルのノード・マネージャのコンソールを確認します。ECMHOST1で最後にWLS_IPM1の再起動が最後に試行されてから30秒経過した後、ECMHOST2のノード・マネージャによって、WLS_IPM1の浮動IPが有効化されていること、およびこのノードでサーバーが再起動されていることが表示されます。
同じIPのsoa-infraコンソールにアクセスします。
管理コンソールからの検証
管理コンソールで移行を検証する手順は、次のとおりです。
管理コンソールにログインします。
左側のコンソールで、「ドメイン」をクリックします。
「監視」タブ→「移行」サブタイプをクリックします。
「移行の状態」表に、移行の状態に関する情報が表示されます(図11-6)。
|
注意: サーバーの移行後、そのサーバーを元のノード/マシンにフェイルオーバーするには、Oracle WebLogic管理コンソールから管理対象サーバーを停止し、再起動します。適切なノード・マネージャが、もともと割り当てられていたマシン上の管理対象サーバーを起動します。 |
この項では、Inbound Refineryの構成情報について説明します。
Inbound Refineryインスタンスはクラスタ化できません。このインスタンスは、完全に個別に動作します。複数のInbound Refineryインスタンスを同じWebLogicドメインに追加できますが、次の制限を遵守する必要があります。
マシンごとのドメインごとに複数のInbound Refineryをインストールできません。
個別のマシン上のInbound Refineryインスタンスは、その構成を共有ディスク上でなくすべてローカルで行う必要があります。
ローカル・コンテンツの要件は、Content Serverインストールが存在するマシン上にInbound Refineryインスタンスをインストールする場合に重要になります。Content Serverクラスタの構成は共有する必要がありますが、Inbound Refineryインスタンスの構成情報は他のInbound Refineryインスタンスと共有することはできません。
1つ以上のInbound Refineryインスタンスを使用するようにContent Serverを構成することも、同一のInbound Refineryが1つ以上のContent Serverに対するプロバイダとして機能するように構成することもできます。Inbound Refineryインスタンスを構成するには、Oracle Fusion Middleware変換についての管理者ガイドを参照してください。
前の構成で作成されたすべてのInbound Refineryは、UCMまたはURMクラスタに追加することをお薦めします。そうすることで多対多の関係が構築され、UCM/URMクラスタのすべてのメンバーはIBRクラスタの任意のメンバーからの変換をリクエストできます。
Inbound Refineryインスタンスは、独自のドメインにインストールすることも、既存のドメインの拡張としてインストールすることもできます。
