| Oracle® Fusion Middleware高可用性ガイド 11gリリース2(11.1.2) B69538-02 |
|
 前 |
 次 |
Oracle WebCenter Contentは、Oracle Fusion Middlewareコンポーネントの1つで、コンテンツを管理するために設計された統合的な製品スイートです。業界最先端のドキュメント管理、Webコンテンツ管理、デジタル資産管理およびレコード管理機能を利用して、ビジネス・アプリケーションを構築できます。コンテンツおよびアプリケーションの戦略的なエンタープライズ・コンテンツ管理インフラストラクチャを構築することで、コストの削減、エンタープライズを横断する容易なコンテンツの共有、リスクの最小化、時間を浪費する高価な手動プロセスの自動化、および複数のWebサイトの単一のプラットフォームへの統合化を支援します。
Oracle WebCenter Contentには次のような利点があります。
優れたユーザビリティ: エンド・ユーザー、ワークグループ、コンテンツ・エキスパート、プロセスの所有者、管理者、およびWebマスターに対する組込みのサポート
最適化された管理: ドキュメント、ファイル、Webコンテンツ、およびデジタル資産を安全に管理するための統合されたアーキテクチャ
ホットプラガブル: Oracleおよびサード・パーティのリポジトリ、セキュリティ・システム、およびエンタープライズ・アプリケーションに対するインストール時からのサポート
この章では、Oracle WebCenter Contentコンポーネントについて、高可用性の観点から説明します。この章では、高可用性を備えたデプロイメントの設計に重要な単一インスタンスの概念について概要を説明します。
この章の項目は次のとおりです。
この項では、Oracle WebCenter Content: Imaging (Imaging)の概要、およびImagingの高可用性環境の設計とデプロイ方法について説明します。
Imagingでは、プロセス指向のイメージング・アプリケーション、およびOracle E-Business SuiteやPeopleSoft Enterpriseなどのイメージ対応のビジネス・アプリケーションに焦点を当てたスケーラブルなソリューションを組織に提供します。これにより、イメージの注釈およびマークアップの対応、ルーティングおよび承認の自動化、大量のアイテムに対応する高容量アプリケーションのサポートを実現します。
Imagingは、ビジネス・トランザクションまたはプロセスの一環としてそれぞれのドキュメントを管理する、トランザクション・コンテンツ管理ツールです。トランザクション・ドキュメントは、通常は比較的短期間のトランザクションの発生時に重要になります。
図11-1は、Imagingの内部コンポーネント(Imagingパッケージ内のコンポーネント)を示しています。
Imagingの構成の設定を開始する前に、次の点に注意してください。
Imagingは、Oracle Universal Content Manager(WebCenter Content)リポジトリの最上位にある比較的薄い機能層です。Imagingでは、WebCenter Contentでのイメージ・ファサードを提供します。リポジトリによって、リソース利用の大部分が実行されます。そのため、すべてのImagingインスタンスにWebCenter Contentインスタンスを配置することでWebCenter Contentを構成するようにお薦めします。この構成によって、ハードウェアを最適に利用できます。
Imagingの最大のパフォーマンス要素は、ドキュメント・コンテンツの移動です。通常、Imagingは、毎日数十万ものドキュメントを収集するような大容量シナリオで使用されます。これらのドキュメントは、一日中、頻繁に検索、取得および表示されます。システム内外とのドキュメント・コンテンツのやりとりは、パフォーマンスに大きく影響します。Imagingでは、平均25KバイトのサイズのTIFドキュメントを保存します。ただし、TIFドキュメントには複数のページが含まれていることがあり、それによってドキュメントのサイズは増加します。さらに、Imagingでは、その他にも様々なサイズの400のファイル形式をサポートしています。これらのファイルには、より大きなサイズのものもあります。
Imagingは、WebLogic Server管理対象サーバー環境で稼働するJava EEアプリケーションです。これには、次のコンポーネントおよびサブコンポーネントが含まれます。
サーブレット: Imagingには、REST APIおよびImagingアプレット・ビューアがシステムのパブリックAPI関数にアクセスするメカニズムを提供する、内部で使用するためのサーブレットがあります。
EJB: Imagingでは、内部的にいくつかのEJBの概念を利用していますが、外向きのEJBはありません。
Imagingでは、JMSを使用してその入力エージェントとそのBPELエージェント・メッセージ駆動Bean(MDB)の両方を駆動します。図11-1で、BPELエージェントはBPEL MDBの集合です。これらのキューは永続するため、配信は保証されます。これによりクラスタ間でも作業が配信されます。
Imagingでは、JAX-WSおよびJAX-Bを使用して、そのWebサービスおよびシリアライズ・メカニズムを実装します。
Imagingでは、定義の保存および構成にTopLinkを使用します。この目的は、一般的にはアプリケーションおよび検索を定義することです。また、TopLinkはユーザーおよびシステム・プリファレンスの取得にも使用されます。
Imagingでは、リポジトリからのドキュメントの取得や表示するドキュメントの処理に内部キャッシュとしてJava Object Cache(JOC)を使用します。これらのキャッシュはローカルにのみ存在し、サーバー間で共有することはありません。
AXFとBPEL間の相互作用は、EJBを介してRMIを使用するBPELリモートAPIによって実行されます。
|
注意: Imagingでは、複数コンポーネントのトランザクションをサポートしないため、Java Transaction API(JTA)を使用しません。 |
ImagingにはステートフルなUIを備えていますが、セッション・レプリケーションをサポートしていないため、スティッキーなロード・バランシング・ルーターが必要になります。
Imaging APIを使用したImagingサービスの呼出しは、ステートレスです。
Imagingのコアでは、中央API、UI、およびWebサービス・インタフェースを含むサービスベースのアーキテクチャを使用します。このADFベースのUIは、ImagingのパブリックAPIを使用して、コア・サービスにアクセスします。エンド・ユーザーは、Webサービスを開始してこのAPIにアクセスします。Java開発者には、より便利なパッケージでこれらのWebサービスを公開するシンJavaクライアント・ライブラリも提供します。
Imagingには、バックグラウンド処理を実行するための次のエージェントがあります。
入力エージェントは、インジェストするドキュメントの受信リストの入力ディレクトリを監視します。
BPELエージェントは、ドキュメント作成イベントに応答して、そのドキュメントおよびURLからメタデータを含む新しいBPELプロセス・インスタンスをアタッチするドキュメントに作成します。図11-1で、BPELエージェントはBPEL MDBの集合です。
チケット・エージェントは、タイマーなしで呼び出されるステートレスのEJBです。これは、図11-1には示されていません。チケット・エージェントは、有効期限が切れたURLチケットの特定および削除を行います。これらのチケットは、パラメータを使用しないクリーンなURLを作成するために使用されます。
Imagingサービスでは、スキャン・ドキュメントの保存にWebCenter Contentドキュメント・リポジトリを使用します。WebCenter Contentリポジトリは、RIDCと呼ばれるWebCenter Contentで提供されるTCP/IPストックベースの接続メカニズムを介してImagingと通信するスタンドアロン製品です。
これは特定の障害検出を提供するものではありませんが、WebLogic Serverノード・マネージャを使用して継続的にサーバーを稼働することができます。
Imagingプロセス・ライフサイクルのステップは次のとおりです。
Imagingは、ほとんどの場合、ドメイン構成が行われた後、初期化されます。Imagingが起動して最初のユーザーがログオンすると、残りの初期化が実行されます。
最初のユーザーがログオンしたときに、そのユーザーはそれ以降の他のユーザーに権限を付与できるという前提の下で、完全なセキュリティ権限が付与されます。Imagingは、セルフ・シード・データベース・セキュリティ・メカニズムを提供します。Imagingが起動したときにセキュリティが定義されていない場合、システムに最初にログインしたユーザーはすべてのものにアクセスする権限が付与されます。
Imagingが初めて起動した直後は、Imagingは「空」です。WebCenter Contentドキュメント・リポジトリおよびBPELサーバーへの接続は、管理ユーザーの責任で作成します。
最初のUCM接続が作成されると、Imagingで使用するWebCenter Contentリポジトリは初期化されます。
ここで、アプリケーション、検索、入力などを含む適切なビジネス・オブジェクトを作成する必要があります。管理ユーザーは、これらをゼロから作成するかわりに、そのビジネス・オブジェクトをインポートすることもできます。
ステップ1でエージェント・ユーザーが指定された場合、エージェントはサーバーが再起動した後JMSキュー・イベントがその処理を開始するのを待ちます。
サーバーが稼働してJAX-WSメカニズムの準備ができたら、Imagingはクライアント・リクエストを受信できます。
Imagingには、次のような構成アーティファクトがあります。
すべてのImaging構成データは、Imagingデータベースの中に保存されます。構成は、ローカル・ファイルには保存されません。構成パラメータは、(Enterprise ManagerまたはWLSTから使用できる)適切なMBeanまたはImagingのUIを介して公開されます。
その他のImaging構成アーティファクトは、第11.1.1.1.5項「Imagingの外部依存性」で説明されている定義オブジェクトです。
Imagingでは、WebCenter Contentメカニズムを使用して、UCMプロファイルおよび情報フィールドの管理を含め、Imagingで使用するためにWebCenter Contentをカスタマイズします。
Imagingには、次の外部依存性があります。
Imagingには、構成を格納するためのデータベースが必要です。データベースは最初にRCUを介して作成され、WebLogic Server JDBCデータ・ソースを介して管理されます。データベースには、TopLinkを介してアクセスします。
Imagingでは、JAX-WS、JAX-B、ADF、TopLink、JMSなどの様々なOracleおよびJavaテクノロジを活用します。これらはインストールに含まれ、外部構成は不要です。
Imagingには、構成用のMbeanが用意されています。これらは、WLSTおよびEM Mbeanブラウザを介して使用できます。Imagingには、いくつかのカスタムWLSTコマンドが用意されています。
Imagingは、WebCenter Contentリポジトリが存在するかどうかに依存しています。
次のクライアントはImagingに依存します。
Imaging UIは、パブリック・ツールキット(Imaging API)で構築されます。UIおよびコアAPIは、同じEARファイルで配信されます。
Imagingには他の製品と統合するためのWebサービスが用意されており、他の製品と統合するためのJavaの便利な機能としてこれらのWebサービスをラップするJavaクラスのセットも用意されています。
Imagingには、他のアプリケーションとImagingの検索およびコンテンツとの相互作用を円滑にするURLツールキットが用意されています。
Imagingには、Webプレゼンテーションのドキュメントの個々のページを参照するためのRESTツールキットが用意されています。
クライアントは、次のいずれかを介してImagingに接続します。
WebサービスまたはJavaクライアント用のJAX-WSを介した接続。これらの接続はステートレスで、単一の機能を実行します。
次のような、URLにアクセスするためのHTTPおよびRESTツール。
RESTリクエストはステートレスで、単一の機能を実行します。
URLツールはImaging UIにログインして、関連するUIコンポーネントを含むよりステートフルな体験を提供します。
この項では、Imagingを2ノードのクラスタ構成による高可用性で使用する場合の概要について説明します。
図11-2は、Imagingの高可用性アーキテクチャを示しています。
Imagingは、標準的な2ノードのアクティブ/アクティブの高可用性構成で構成できます。ImagingのUI層はアクティブ・サーバー間でフェイルオーバーされませんが、その他のバックグラウンド・プロセスはフェイルオーバーされます。
図11-2は、Imagingの高可用性構成を示しています。
Imagingノードは、お互いに同一なレプリカです。高可用性構成のすべてのノードは、同一のサービスを実行し、中央の構成データベースで構成されます。すべてのサーバーはこのデータベースからその構成を取得します。
Imagingノードのフロントエンドには、スティッキーなセッション・ルーティングを持つロード・バランシング・ルーターを使用する必要があります。この目的のためにOracle HTTP Serverを使用できます。
Imagingは、WebLogic Serverクラスタ内でもクラスタなしでも実行できます。
すべてのImagingインスタンスは、同じデータベース接続を共有する必要があります。そうすることで、Oracle RACの高可用性の潜在機能が高まります。Imagingは、データベース処理にTopLinkを使用します。
Imagingには共通の共有ディレクトリが必要で、入力エージェントはインジェスト用にステージングされたインバウンド・データファイルをここから取得します。入力エージェントが入力定義ファイルを取得したら、関連する入力ファイルおよびイメージの処理は、そのWebLogic Serverインスタンスから分離されます。
Imagingのエージェント(入力エージェント、BPELエージェント)は、クラスタ内のWebLogic Serverに存在するImagingアプリケーションの不可欠な機能として起動します。JMSキューの未処理の作業(これらは障害を越えて永続的に保存されます)に基づいて、即座に処理が開始されます。入力エージェントは、インバウンド・ファイル・ディレクトリでも作業を検索します。処理対象のファイルがある場合、それらは対応するJMSキューにプッシュされ、クラスタ内のサーバーはそれを使用して関連するイメージを処理します。WebLogic Serverワークロード・マネージャは、BPELエージェントおよび入力エージェント専用のスレッドの数を制御します。
クラスタ内のサーバーが停止すると、エージェントはそのアクティビティを終了します。BPELエージェントの実行サイクルは短く、すべての処理はシャットダウン前に完了することが見込まれます。進行中のBPEL呼出しは3回再試行され、JMSログは保留中の操作を保存します。入力エージェントは大規模なサイズのファイルを処理できます(大きな入力ファイルの場合、処理に数時間かかる場合があります)。停止後に保留された作業の量は、関連するJMS永続ストアに保存されます。入力エージェントをホストするサーバーを再起動すると、エージェントは残されていた処理を開始します。イメージ・ファイルの処理は、再起動またはサーバーの移行後に、対応する入力ファイルを最初に使用するサーバーで継続されます。
Imagingの高可用性構成を障害から保護するには、次の手順を実行します。
Imagingノードのフロントエンドには、スティッキーなセッション・ルーティングを持つロード・バランシング・ルーターを使用します。この目的のためにOracle HTTP Serverを使用できます。
Imagingでアップロードまたは取得される表示用のドキュメントのサイズに基づいて、ロード・バランシング・ルーターのタイムアウトを構成します。
また、次の機能もImagingの高可用性構成での障害からの保護に役立ちます。
JMSフェイルオーバーは、WebLogic ServersのJMS実装で提供されます。
TopLinkには、データベースの再試行ロジックが用意されています。
WebCenter Contentに接続する際に、ネットワーク障害の解決を即座に再試行するために、再試行ロジックが存在します。Imagingには、クラスタ内の他のWebCenter Contentサーバーを検索するフェイルオーバー・メカニズムが用意されています。ImagingとWebCenter Contentの間にロード・バランサを使用して、ロード・バランシング/フェイルオーバーの目的を実現できます。
BPELに接続する際に、Imagingは即座に再試行を実行し、タイムアウト時間(5分間)を超えたら失敗したアイテムを関連する再試行用のJMSキューに押し戻します。このJMS再試行メカニズムは、3回実行されます。失敗し続けるオブジェクトは、ユーザー操作用の保存キューに格納されます。
APIレベル統合(JPSなど)は再試行されず、内部的な再試行ロジックで処理されます。
ノード障害
Oracle/IPMノードで障害が発生すると、そのノードのエージェント・プロセスに影響します。未完了のトランザクションは、廃棄されて失われます。フェイルオーバー時に、そのノードのImaging UIのユーザー・セッションは失われます。ユーザーは、再度ログインして再起動する必要があります。それぞれのImagingクラスタ・ノードは独立しているので、フェイルオーバーはロード・バランシング・ルーターで管理され、Imagingで直接管理されることはありません。
すべてのImaging構成情報はデータベースに保存され、すべてのノードはお互いにレプリカになるため、構成情報はフェイルオーバー後に新しいノードで即座に使用できます。
外部リソースでのImagingノード障害の影響は次のとおりです。
JMSトランザクションでは、JMSに対して実行されたアトミック・アクションは内部的にトランザクション処理され、未完了のキューから受信したすべてのメッセージは再送信されることが想定されています。BPELエージェントおよび入力エージェントの障害回復は、ローカル・メッセージのファイル・システムへの永続性に依存します。メッセージがローカル・ノードに存在するイベントは、そのノードの起動時に続行されます。その他のメッセージは、稼働しているノードで取得されます。
データベース・トランザクションでは、接続が切断されたときに暗黙的なロールバック処理を強制する場合を除いて、データベースがクライアントの障害に対処することはありません。データベース障害時のデータベース・トランザクションは、必要なデータベース機能により管理されます(たとえば、Oracle RACデータベースが使用されていればフェイルオーバーが行われ、単一ノードのデータベースが使用されていればフェイルオーバーは行われません)。データベースへのアクセス中にノード障害が発生すると、多くの場合、ユーザーは再度ログインして、UI操作を再試行することになります。
Imagingサーバーの障害発生時は、Imaging内のユーザー・セッションは失われます。Imaging UIを介してドキュメントをアップロードしているときにImagingサーバーの障害が発生すると、手動のドキュメントのアップロードが成功したという確認通知が受信されない場合があります。その場合、それを再度アップロードする前に、サーバー障害発生時にアップロードしていたドキュメントがあるかどうか探してみることをお薦めします。そうすることで、ドキュメントの重複作成が回避されます。
外部アプリケーションがWebService呼出しを使用してImagingクラスタにアクセスする場合、Imagingサーバーに障害が発生すると、フロントエンド・ロード・バランサで適切なフェイルオーバー・ロジックが提供されることが想定されます。入力ディレクトリにファイルを直接プッシュすることでアプリケーションがImagingシステムと相互作用する場合、ファイル・システムで障害が発生したときの再試行は、アプリケーションで処理します。
障害発生時に入力定義ファイルが処理中の場合、Imagingはファイルの詳細を保持し、その特定のノードの再起動時に、ローカルJMSキューでその再試行するJMSメッセージを再作成します。再試行時に、入力インジェスタはシャットダウンが発生したときのファイル内の場所の特定を試みて、バッチのドキュメントが失われないように未処理の場所を取得します。定義ファイルを処理していたノードが完全に再起動してファイルの処理が終了するまで、定義ファイルはStageディレクトリに保持されます。
入力ファイルは、入力エージェントがスケジュール設定および処理できる作業の最小単位です。最高のパフォーマンス、スケーラビリティ、および可用性を実現するために、いくつかの考慮事項があります。
Imagingクラスタ内のすべてのマシンは、共通の入力ディレクトリを共有します。
このディレクトリからの入力ファイルは、JMSキューを介してそれぞれのマシンに配信されます。
このディレクトリで新しいファイルをポーリングする頻度は、CheckInterval MBean構成設定を使用して構成できます。
それぞれのマシンには、指定された数の入力インジェスタが配置されます。入力インジェクタは、入力定義ファイルの解析を行います。インジェスタの数は、InputAgentのワークロード・マネージャを介して制御し、WebLogic Serverで管理します。
次のような場合に最適なパフォーマンスを実現できます。
それぞれのImagingクラスタ・ノードに、ユーザー・インタフェースやWebサービスなどの他のImagingアクティビティのパフォーマンスを損ねることなく、ワーク・マネージャを介して構成された最適な最大数の解析エージェントがある場合。
ドキュメントのインバウンド・フローは、最適な数のドキュメントを含む入力ファイルに分割されます。平均では、クラスタ内の解析エージェントごとに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ドキュメントの処理が完了するようになります。また、1つのサーバーで障害が発生した場合、処理が正常に終了するまでもう一方のサーバーで解析エージェントに残っている処理を続行できます。
Imagingが依存するコンポーネントの障害
ImagingはOracle SOA Suiteと統合します。SOAサーバーが停止すると、Imagingでは障害が発生します。Imagingでは、再試行が3回行われます。それぞれの試行を繰り返す前に、構成可能な遅延時間が後に続きます。3回の試行の後もアクションが完了できない場合、これらのリクエストはデータベース・テーブルのキューに格納され、後で再送信されます。再送信は、WLSTコマンドを使用して実行します。
ImagingはOracle WebCenterポータルに依存していません。
その他のOracle ADFアプリケーションは、Imagingの操作には影響しません。
Imaging UIでは、接続先となるWebCenter Contentサーバーのリストを指定できます。これは、プライマリ・サーバーを使用して、複数のセカンダリ・サーバーに接続して指定できます。プライマリUCMサーバーで障害が発生すると、Imagingはリストの次のUCMサーバーを再試行します。すべてのUCMサーバーが停止した場合、例外が返され、Imagingサーバーのログにトレースされます。
検索、入力、アプリケーション(すべてImaging構造構成)は、Imagingデータベースの中に保存されます。これらは、Web UI層を含め、クラスタ内のすべてのマシンで即座に使用可能になります。新しいエントリがクラスタ内の別のImagingサーバーまたは別のユーザー・セッションの同じサーバーで作成された場合、Web UIは自動的にはリフレッシュしませんが、Webブラウザをリフレッシュしてイメージ・アプリケーションのナビゲーション・バーをリフレッシュすることはできます。
この項では、高可用性環境でImagingサーバー、アドバンスト・ビューア、入力エージェントをトラブルシューティングする方法について説明します。
追加のImagingトラブルシューティング情報は、Oracle WebCenter Content for Imaging管理者ガイドに記載されています。
Imagingサーバーのトラブルシューティング
Oracle/IPMは、WebLogic ServerにデプロイされたJava EEアプリケーションです。ログ・メッセージはすべて、アプリケーションがデプロイされるWebLogic Serverのサーバー・ログ・ファイルに記録されます。
診断ログ・ファイルのデフォルトの場所は次のとおりです。
WL_HOME/user_projects/domains/domainName/servers/serverName/logs/serverName-diagnostic.log
Oracle Enterprise Managerを使用して、これらのログ・ファイルの検索および解析を簡単に行えます。
アドバンスト・ビューアのトラブルシューティング
Imagingでは、主にサーバー側でロギング機能を提供しますが、クライアント側にアドバンスト・ビューアというコンポーネントもあります。このJavaアプレットでは、標準的なロギング・ユーティリティを使用します。ただし、これらのユーティリティは、クライアントでは無効です。Javaプラグインのlogging.propertiesファイルを適切に変更して、ログの出力をファイルまたはJavaコンソールのいずれかに送信するようにこれらのユーティリティを構成できます。
入力エージェントのトラブルシューティング
Imagingの入力エージェントでドキュメントをアップロードするときに、Oracle WebCenter Contentで障害が発生すると、次のようなメッセージが生成されます。
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 WebCenter Content(WebCenter Content)の概要、およびWebCenter Contentの高可用性環境の設計とデプロイ方法について説明します。
図11-3は、WebCenter Contentの単一インスタンスのアーキテクチャを示しています。
図11-3 Oracle WebCenter Contentの単一インスタンス・アーキテクチャ
WebCenter Contentのインスタンスは、Oracle WebLogic管理対象サーバー環境内で稼働します。WebLogic Serverは、アプリケーションの起動と停止など、WebCenter Contentアプリケーションのライフサイクルを管理します。
WebCenter Contentアプリケーションへのエントリ・ポイントは2つあります。1つはリスニングTCPソケットであり、このソケットは、ImagingやOracle WebCenterポータルなどのクライアントからの接続を受理できます。もう1つはHTTPリスニング・ポートです。これは、Webサービス呼出しを受理できます。HTTPポートは、管理対象サーバーのリスニング・ポートと同じポートです。
UCMサーバーには、いくつかの埋込みアプリケーションも含まれています。これらは、クライアント・ブラウザ内でアプレットとして実行できます。これらには、ファイル管理および索引機能のリポジトリ・マネージャ(RM)およびユーザー・ワークフローを設定するためのワークフロー管理などがあります。これらのアプリケーションの詳細は、Oracle Fusion Middleware Content Serverアプリケーション管理者ガイドを参照してください。
UCM Serverには、3タイプの永続ストアがあります。それらのタイプは、リポジトリ(Oracle Databaseに格納可能)、検索索引(Oracle Databaseに格納可能)、メタデータおよびWebレイアウト情報(ファイル・システムに格納可能)です。
WebCenter Contentは、WebLogic Serverに存在するサーブレットです。サーブレット・リクエストは、UCMリクエストのラッパーです。
WebCenter Contentには、BatchLoaderやIdcAnalyzerなどの様々なスタンドアロンの管理ユーティリティが含まれます。
JMSおよびJTAは、WebCenter Contentでは使用されません。
WebCenter Contentのリクエストはステートレスです。認証情報を保持するために、セッションをデータベースに保存できます。
WebCenter Contentは、サービス指向アーキテクチャを採用しています。それぞれのリクエストは、サービスとしてシステムに受け入れられます。共有サービス層では、リクエストを解析し、そのリクエストを正しいハンドラに渡します。通常、ハンドラは基になるリポジトリにアクセスして、リクエストを処理します。3種類のリポジトリとそれぞれで保存するデータを図11-3に示します。
WebCenter Contentは、WebLogic Server管理対象サーバーとして起動および停止できます。UCM管理サーバーも、UCMインスタンスの起動、停止、および構成に使用できます。UCM管理サーバーは、WebLogic管理コンソールが採用されているため非推奨ですが、従来どおりWebLogic Server環境で機能します。ロード・バランサは、PING_SERVERサービスを使用して、UCMインスタンスのステータスを監視できます。
起動時に、WebCenter Contentは初期化ファイルおよびデータ定義をロードして、データベース接続を初期化し、ローカライゼーション文字列をロードします。WebCenter Content内部コンポーネント・アーキテクチャを介して、起動シーケンスでシステムにインストールおよび有効化されている内部コンポーネントを検出し、それらのコンポーネントを初期化します。検索/索引エンジンおよびファイル・ストレージ・インフラストラクチャも初期化されます。
通常、クライアント・リクエストは1つのWebCenter Contentインスタンスですべて処理されます。クラスタ内に他のインスタンスが存在しても、クライアント・リクエストには影響しません。
初期化ファイルは、ファイル・システムで保存され、WebCenter Contentシステム・ディレクトリに格納されます。
WebCenter Contentでは、nostageデプロイメントを使用します。つまり、すべてのデプロイメント・ファイルはローカルです。
WebCenter Contentには、WebLogic Serverおよび外部Oracle Databaseが必要です。
次のクライアントはWebCenter Contentに依存します。
Oracle WebCenter Content: Records(Records)
Oracle WebCenter Content: Imaging(Imaging)
Oracle WebCenterポータル
クライアントからの接続は短時間で、セッションレス・サービスの期間にのみ必要です。
クライアントは、HTTP、SOAP/Web Services、JCR、およびVCRプロトコルを使用して、WebCenter Contentに接続できます。
WebCenter Contentは、WebLogic ServerにデプロイされたJ2EEアプリケーションです。ログ・メッセージは、アプリケーションがデプロイされるWebLogic Serverのサーバー・ログ・ファイルに記録されます。デフォルトのサーバー・ログの場所は次のとおりです。
WL_HOME/user_projects/domains/domainName/servers/serverName/logs/serverName-diagnostic.log
WebCenter Contentは、次の場所にもログを記録します。
WebLayoutDir/groups/secure/logs
WebCenter Contentトレース・ファイルは、次の場所に記録および格納するように構成できます。
IntraDocDir/data/trace
WebCenter ContentのGUIを使用してログ・ファイルを表示するには、「UCM」メニュー→「管理」→「ログ」を選択します。
WebCenter ContentのGUIを使用してトレース・ファイルを表示するには、「UCM」メニュー→「システム監査情報」を選択します。「サーバー出力の表示」および「捕捉された出力の表示」リンクをクリックすると、現在のトレースおよび記録されたトレースが表示されます。
この項では、WebCenter Contentを2ノードのクラスタ構成による高可用性で使用する場合の概要について説明します。
図11-4は、2ノードのアクティブ/アクティブOracle WebCenter Contentクラスタを示しています。
図11-4は、WebCenter Contentの高可用性構成を示しています。
それぞれのノードは、共有ファイル・システム、同じデータベース・スキーマ、同じ検索索引に対して独立に稼働します。クライアント・リクエストは、すべて単一ノードで処理されます。
WebCenter Contentは、WebLogic Serverクラスタまたは外部ロード・バランサで稼働できます。WebCenter Contentは、Oracle RACおよび複数のデータ・ソース構成に対しても透過的です。
WebCenter Contentは、独立にスケーラビリティを持つことができ、ノード間の通信は限定的です。ノードどうしは、共有ファイル・システムへの読書きを介して通信します。この共有ファイル・システムは、書込み操作の同期化をサポートする必要があります。
クラスタが起動すると、それぞれのWebCenter Contentノードは通常の初期化シーケンスが実行され、初期化シーケンスでは、リソースの解析、準備、およびキャッシュ処理、および接続の準備などが行われます。ノードがクラスタの一部である場合、他のクラスタ・メンバーが使用可能であれば、メモリー内のレプリケーションが開始されます。1つまたすべてのクラスタ・メンバーを同時に起動することができます。
クラスタ・メンバーをシャットダウンすると、そのクラスタ・メンバーはリクエストに対応できなくなります。サーバーを正常にシャットダウンすると、現在のリクエストの処理を終了して、使用不可になることを通知し、すべての共有リソースを開放して、そのファイルおよびデータベース接続を閉じます。すべてのセッション状態はレプリケートされ、このクラスタ・メンバーに接続されていたユーザーは、他のクラスタ・メンバーにフェイルオーバーされます。
クラスタ・レベルでは、WebCenter Contentの内部コンポーネントを使用した新しいWebCenter Contentの機能や動作のカスタマイズ機能が導入されました。新しい変更を取得するには、ノードを再起動する必要があります。
たとえば、メタデータ・モデルでシステム全体を変更できます(メタデータ・フィールドの追加、変更、削除など)。これらのメタデータ・フィールドで駆動されたシステムの動作は変更できます。この変更は、ノード間の通知を介して、クラスタ・ノートで自動的に取得されます。
各クラスタ・メンバーで変更を適用するには、最初のノードで共有フォルダを構成する必要があります。それぞれのクラスタ・ノードのすべての共有フォルダが同じマウント・ポイントを持っていれば、他のノードでWebLogic Serverのpack/unpackを使用して手動で変更を行う必要はありません。
WebCenter Contentを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リストから手動で削除します。
RecordsとWebCenter Contentは、同じアーキテクチャを共有します。そのため、WebCenter Contentに適用されるすべての高可用性に関する考慮事項は、WebCenter Contentにも適用されます。
高可用性を構成する場合、WebCenter ContentとRecordsでは注意する相違点が2つあります。
Recordsは、WebCenter Contentと異なるディレクトリに、ファイル・システム・メタデータを保存します。
Recordsクラスタの前面のHTTPサーバーを構成する場合、WebCenter Contentと異なるセッションCookie名を使用する必要があります。
これら2つの構成の違いの詳細は、後述する「Oracle WebCenter Contentの高可用性の構成手順」を参照してください。
次の機能は、WebCenter Contentノードの障害からの保護に役立ちます。
外部ロード・バランサを使用することで、ロード・バランシングを実現できます。セッションには、認証情報よりさらにスティッキーな状態データは不要です。
ロード・バランサは、WebCenter Contentの前面に構成できます。Oracle RACをサポートするWebCenter Contentで、複数のデータ・ソースを構成できます。タイムアウトおよび再試行もサポートされます。
WebCenter Contentでは、標準のWebLogic Server永続セッションを使用します。
WebCenter ContentではEJBを使用しません。
WebCenter Content PING_SERVERサービスを使用して、障害を検出します。ノードを再起動するときに、クラスタ内の他のノードに影響することはありません。
フェイルオーバーは、WebCenter Contentノードの前面のロード・バランサまたはApacheのWLSモジュールによって処理されます。クライアントからの処理中のリクエストは失敗しますが、後続のリクエストはアクティブ・ノードにルーティングされます。終了していないトランザクションは完了しません。
ノードからの構成情報は、共有ファイル・システムおよびデータベースに保存されているので、失われます。
ノードに障害が発生すると、データベースはノードとデータベース間の接続を再要求します。
通常、インスタンスはハングしませんが、WebCenter Content製品またはWebCenter Contentのカスタマイズされたバージョンでの不明のデッドロック状態が原因でハングすることがあります。
アクティブ・セッションがあるユーザーは、セッションがアクティブ・サーバーにフェイルオーバーされるため、ダウンタイムが発生することはありません。これは、UCM管理アプレットを開いているユーザーも含まれます。
WebCenter Contentのインストールが完了したら、config.cfgファイルに次の値を設定する必要があります。これによって、Oracle RACフェイルオーバー中の再試行ロジックが有効になります。
ServiceAllowRetry=true
この値が設定されていない場合、フェイルオーバーが開始されたときに、ユーザーは処理中の任意の操作を手動で再試行する必要があります。
値は、次のURLにあるWebCenter Content用の管理コンソールを使用して設定できます。
http://<hostname>:<port>/cs
「管理」→「管理サーバー」→「一般構成」を選択し、ServiceAllowRetry=trueを「追加の構成変数」に追加します。保存して、すべてのUCM管理対象サーバーを再起動します。新しい値がconfig.cfg内の次の位置に表示されます。
SHARED_DISK_LOCATION_FOR_UCM/ucm/cs/config/config.cfg
WebCenter Contentをトラブルシューティングするには、ログ・ファイルを調べてからトレース・ファイルを調べます。
WebCenter Contentのログ・ファイルおよびトレース・ファイルの場所、およびWebCenter ContentのGUIを使用してログ・ファイルおよびトレース・ファイルを表示する方法の詳細は、第11.2.1.1.7項「WebCenter Contentのログ・ファイルの場所」を参照してください。
図11-5のような高可用性環境の場合、Oracle WebCenter Content製品は、クラスタ・デプロイメントで設定することをお薦めします(そうすることで、クラスタ化されたインスタンスはOracle Real Applications Cluster(Oracle RAC)データベースのコンテンツ・リポジトリにアクセスし、共通の構成を保存するために共有ディスクが使用されます)。
ハードウェア・ロード・バランサは、リクエストを複数のOracle HTTP Serverインスタンスにルーティングしてから、クラスタ化されたOracle WebCenter Contentサーバーにルーティングします。
この項では、図11-5で示されるOracle WebCenter Contentの高可用性構成のインストールおよび構成手順について説明します。
次の項目が含まれます。
|
注意: 設定プロセスを開始する前に、リリース・ノートを読んで、インストールとデプロイメントに関して追加の考慮事項がないか確認することを強くお薦めします。 |
構成には次の製品が含まれます。
Imaging
WebCenter Content
Oracle Universal Records Manager(URM)
Oracle WebCenter Content: Inbound Refinery(Inbound Refinery)
すべての製品は同じマシン上にインストールされますが、Inbound Refineryだけはリモート・マシン上に想定されています。
ImagingまたはRecordsをインストールしない場合は、構成手順の当該製品の箇所を無視してください。
クラスタ・メンバーは、同じ構成ファイルにアクセスするために、共有記憶域を必要とします。これは、クラスタのすべてのノードからアクセスできるように設定する必要があります。
WebCenter ContentやURMクラスタを構成する場合、次の要件に従ってください。
WebCenter Contentクラスタでは、すべてのクラスタ・メンバーは同じ構成ディレクトリを指す必要があります。このディレクトリは、クラスタのすべてのメンバーからアクセス可能な共有ディスクに配置されている必要があります。
Recordsクラスタでは、すべてのクラスタ・メンバーは同じ構成ディレクトリを指す必要があります。このディレクトリは、クラスタのすべてのメンバーからアクセス可能な共有ディスクに配置されている必要があります。
Oracle RACデータベースを構成してから、ここで説明する手順を完了してください。
リポジトリ作成ユーティリティ(RCU)は、Oracle Fusion Middleware 11gキットの部品として付属する専用のCDに収録されています。
RCUを実行して、Oracle RACデータベース・リポジトリにWebCenter Contentスキーマを作成するには、任意の使用可能なホストで次の手順を実行します。
次のコマンドを発行します。
prompt> RCU_HOME/bin/rcu &
「ようこそ」画面で「次へ」をクリックします。
「リポジトリの作成」画面で、「作成」操作を選択してコンポーネント・スキーマを既存のデータベースにロードします。
「次へ」をクリックします。
「データベース接続の詳細」画面で、既存のデータベースの接続情報を次のように入力します。
データベース・タイプ: Oracle Database
ホスト名: データベースを実行しているコンピュータの名前。Oracle RACデータベースの場合は、VIP名またはノード名を指定します。例: WCCDBHOST1-VIPまたはWCCDBHOST2-VIP
ポート: データベースのポート番号。例: 1521
サービス名: データベースのサービス名。例: wccdb.mycompany.com
ユーザー名: SYS
パスワード: SYSユーザーのパスワード
ロール: SYSDBA
「次へ」をクリックします。
すべての項目が正しく入力されると、「操作が完了しました。」というメッセージがダイアログ・ボックスに表示されます。その場合、「OK」をクリックします。それ以外は、「メッセージ」の下に、「データベースに接続できません。」や「無効なユーザー名/パスワード」などのエラーが表示されます。
「コンポーネントの選択」画面で、新しい接頭辞を作成して、このデプロイメントに関連するコンポーネントを選択します。
接頭辞の新規作成: DEVなど
コンポーネント: スキーマを作成するコンポーネントのみを選択します。「Oracle ASリポジトリ・コンポーネント」→「WebCenter Content」を選択し、次のコンポーネントを選択します。
Oracle WebCenter Content Server 11g - Complete
Oracle WebCenter Content: Records 11g
「次へ」をクリックします。
すべての項目が正しく入力されると、操作が完了したことを示す文言のあるダイアログ・ボックスが表示されます。その場合、「OK」をクリックします。それ以外の場合は、「メッセージ」の下にエラーが表示されます。これは、続行する前に解決する必要があります。
「スキーマ・パスワード」画面で、「すべてのスキーマに同じパスワードを使用」が選択されていること確認します。このパスワードは、後でContent Serverがこのデータベース・スキーマに接続する手順で使用されます。
「次へ」をクリックします。
「表領域のマップ」画面で「次へ」をクリックします。
警告ダイアログ・ボックスが表示されたときには、「OK」をクリックします。
表領域の作成の結果が、「操作が完了しました」というテキストとともにダイアログに表示されることを確認します。「OK」をクリックします。
「サマリー」画面で「作成」をクリックします。
「完了サマリー」画面で「閉じる」をクリックします。
この項では、WCCHOST1のインストールおよび構成手順について説明します。
WCCHOST1で、インストーラ実行可能ファイルを実行して、Oracle WebLogic Serverのインストールを開始します。
最新バージョンのOracle Fusion Middlewareとともに使用する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 WebCenter Contentインストーラを起動するには、次の手順を実行します。
|
注意: UNIXでrunInstallerコマンドを実行する前に、DISPLAY環境変数が正しく設定されていることを確認します。 |
UNIXの場合(次の例はLinuxの場合):
./runInstaller -jreLoc file-specification-for-jdk6
Windowsの場合:
setup.exe
JREの場所を指定します(C:\Oracle\Middleware\jdk160_11など)
インストーラで次の手順に従ってOracle WebCenter Contentをシステムにインストールします。
初回インストールの場合は、Oracleインベントリの指定画面が表示されます。
デフォルトを受け入れて「OK」をクリックします。
通常の(root以外の)ユーザーとしてインストールする場合、「インベントリの場所の確認」ダイアログ・ボックスが表示されます。その指示に従うか、ローカル・インベントリでインストールを続行するを選択して「OK」をクリックします。
「ようこそ」画面で「次へ」をクリックします。
「前提条件のチェック」画面で、インストーラによって前提条件のチェックが完了します。チェックに失敗した項目がある場合は、修正してインストールを再開します。
「次へ」をクリックします。
「インストール場所の指定」画面で、次の値を入力します。
「ミドルウェア・ホーム・ディレクトリ」に、次の値を指定します。
/u01/app/oracle/product/fmw
「Oracleホーム・ディレクトリ」に、Oracle WebCenter Contentをインストールするサブディレクトリの名前を入力するか、デフォルトを使用します。次の場所はWCC_HOMEと呼ばれます。
/u01/app/oracle/product/fmw/wcc
「次へ」をクリックします。
「インストール・サマリー」画面で、選択した内容が正しいことを確認します。正しくない場合は、「戻る」をクリックして前の画面で選択内容を変更し、「インストール」をクリックします。
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の場合):
WCC_HOME/common/bin/config.sh
前述のコマンドを発行する前に、DISPLAY環境変数が正しく設定されていることを確認します。
Windowsの場合:
WCC_HOME/config.cmd
Oracle WebCenter Contentドメインをコンピュータ上に作成および構成する手順は、次のとおりです。
「ようこそ」画面で、「新しいWebLogicドメインの作成」を選択します。
「次へ」をクリックします。
「ドメイン・ソースの選択」画面で、インストールするアプリケーションを選択します。
Oracle WebCenter Content Imaging - 11.1.1.0
Oracle WebCenter Content: Records - 11.1.1.0
Oracle WebCenter Content - Inbound Refinery - 11.1.1.0
Oracle WebCenter Content: Imaging - 11.1.1.0
Oracle JRFやOracle Enterprise Managerなどのその他の製品も自動的に選択されます。
「ドメイン名と場所の指定」画面で、次のエントリを作成します。
ドメイン名をwccdomainに変更するか、デフォルトのbase_domainを使用します。次のように、このドメインのディレクトリが作成されます。
MW_HOME/user_projects/domains/wccdomain
ドメインの場所: デフォルトを受け入れます。
アプリケーションの場所: デフォルトを受け入れます。
「次へ」をクリックします。
「管理者ユーザー名およびパスワードの構成」画面で次の操作を行います。
「ユーザー名」フィールドで、ドメイン管理者のユーザー名を入力するか、デフォルトのユーザー名weblogicを使用します。
「パスワード」フィールドで、8文字以上のユーザーのパスワードを入力します(welcome1など)。
「ユーザー・パスワードの確認」フィールドで、再度ユーザーのパスワードを入力します。
「次へ」をクリックします。
「サーバーの起動モードおよびJDKの構成」画面で次の操作を行います。
WebLogicドメインの起動モード: 「本番モード」を選択します。
JDKの選択: 使用可能なJDKのリストからJDKを選択するか、デフォルトを受け入れます。
「次へ」をクリックします。
「JDBCコンポーネント・スキーマの構成」画面で、次の操作を行います。
下部にある表に表示されるコンポーネント・スキーマ(UCMスキーマ、IPMスキーマおよびURMスキーマ)をすべて選択します。
「コンポーネント・スキーマのRAC構成」については、「GridLinkへ変換」または「RACマルチ・データ・ソースへ変換」を選択します。単一のデータベース構成の場合は、「変換しない」を選択します。
画面に次のデータ・ソースが表示されていることを確認します。表11-1に示されているユーザー名は、RCUからのスキーマ作成で、接頭辞にDEVが使用されていることを想定しています。
Oracle RACでのGridLinkデータ・ソースの構成の詳細は、第4.1.2項「GridLinkデータ・ソースおよびOracle RAC」を参照してください。
Oracle RACおよびMDSリポジトリでのマルチ・データ・ソースの構成の詳細は、第4.1.3項「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。
「次へ」をクリックします。
次の各フィールドに値を入力して、RCUでシードされたOracle RACデータベースの接続情報を指定します。
マルチ・データ・ソースの場合は、次のフィールドに値を入力します。
GridLinkデータ・ソースの場合は、次のフィールドに値を入力します。
ドライバ: RACの場合には、OracleのRACサービス・インスタンス接続用ドライバ(Thin)、バージョン:10、11を選択します。GridLinkの場合は、OracleのGridLink接続用ドライバ(Thin)、バージョン:10以降を選択します。
サービス名 : データベースのサービス名を入力します。GridLinkデータ・ソースの場合は、RACサービス名を小文字で入力し、その後にドメイン名example.comを入力する必要があります。たとえば、<mydbservice>.example.comと入力します。
|
注意: Oracle RACサービス名はデータベースで定義されており、固定名ではありません。データベース・ドメイン名(例: example.com)を含むRACサービス名を登録または追加することをお薦めします。 |
ユーザー名接頭辞: スキーマの接頭辞を入力します。表11-1に示されているユーザー名は、RCUからのスキーマ作成で、接頭辞にDEVが使用されていることを想定しています。
「パスワード」と「パスワードの確認」: スキーマにアクセスするときのパスワードを入力します。
GridLinkデータ・ソースの場合は、SCANアドレスをリスナー・アドレス・フィールドに入力し、「ポート」フィールドにSCANポートを入力します。「ONSホスト」と「ポート」の各フィールドに、ONSホストおよびポート情報を入力します。
|
注意: WebLogicコンソールでTNSリスナーとONSリスナーの両方にホストおよびポートを指定するには、SCANアドレスを使用することをお薦めします。Oracle RACノードを追加または削除する場合、SCANアドレスを含むGridLinkデータ・ソースを更新する必要はありません。ご使用の環境に対して適切に構成されたSCAN URLについては、ネットワーク管理者に問い合せてください。『Oracle Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの構成と管理』ガイドのSCANアドレスに関する説明を参照してください。 |
マルチ・データ・ソースの場合は、「追加」をクリックします。Oracle RACインスタンスの詳細を入力します。
一度に1つのデータ・ソースを選択し、適切な詳細を追加することにより、各スキーマを更新します。
すべてのスキーマ(UCMスキーマ、IPMスキーマおよびURMスキーマ)に情報が入力されていることを確認します。
「次へ」をクリックします。
「JDBCデータ・ソースのテスト」画面で、接続が自動的にテストされます。「ステータス」列に結果が表示されます。すべての接続が成功したことを確認します。正常に接続できない場合は、「前へ」をクリックしてエントリを修正します。
すべてのスキーマが正しく指定されたら、「次へ」をクリックします。
「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: WCCHOST1
Listen port: 16200
WLS_UCM2
Listen Address: WCCHOST2
Listen port: 16200
すべての管理対象サーバーに対してこれを実行します。
Imagingサーバーは、管理対象サーバーのリスニング・アドレスとして仮想ホスト名が必要です。これらの仮想ホスト名および対応する仮想IPは、Imagingコンポーネントのサーバー移行を有効にするために必要です。WCCHOST1ではWCCHOST1VHN1、WCCHOST2ではWCCHOST2VHN1にVIPマッピングを有効にして、トポロジで使用されるネットワーク・システムでもホスト名を(DNSサーバーまたはhosts解決のいずれかで)正しく解決する必要があります。
Inbound Refineryは、個別のリモート・サーバーに存在するように構成する必要があります(たとえば、WCCHOST3上のIBR_Server1、WCCHOST4上のIBR_Server2など)。
「クラスタの構成」画面で、サーバーの各ペアのクラスタを作成します。たとえば、UCMでは次のように作成します。
名前: UCM_Cluster
クラスタ・メッセージング・モード: unicast
マルチキャスト・アドレス: 適用なし
マルチキャスト・ポート: 適用なし
クラスタ・アドレス: 適用なし
他の製品用に同じように追加: IPM_Cluster、URM_Clusterなど
「次へ」をクリックします。
「サーバーのクラスタへの割当」画面で、新しく作成したクラスタに管理対象サーバーの各ペアを割り当てます。
UCMクラスタ:
WLS_UCM1
WLS_UCM2
この項の前の手順で作成したすべてのクラスタに対して(IPM_Cluster、URM_Cluster、およびIBR_Cluster)これを実行します。
「次へ」をクリックします。
「マシンの構成」画面で「Unixマシン」タブをクリックし、次のマシンを追加します。
WCCHOST1
WCCHOST2
WCCHOST3(Inbound Refineryが構成されている場合)
WCCHOST4(Inbound Refineryが構成されている場合)
「サーバーのマシンへの割当」画面で次の操作を実行します。
WCCHOST1マシンに対して、AdminServerおよびすべての*1サーバー(WLS_UCM1、WLS_IPM1、WLS_URM1)を割り当てます。
WCCHOST2マシンに対して、すべての*2サーバー(WLS_UCM2、WLS_IPM2、WLS_URM2)を割り当てます。
Inbound Refineryを構成する場合、WLS_IBR1をWCCHOST3に追加し、WLS_IBR2をWCCHOST4に追加します。
「構成のサマリー」画面で、「作成」をクリックしてドメインを作成します。
管理サーバーを起動します。
cd DOMAIN_HOME/bin
startWebLogic.sh &
ノード・マネージャを構成および起動します。
WCCHOST1> MW_HOME/oracle_common/common/bin/setNMProps.sh WCCHOST1> 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://WCCHOST1:7001/console)にアクセスします。管理コンソールで、WLS_UCM1、WLS_URM1、およびWLS_IPM1管理対象サーバーを停止します。
この手順が必要になるのは、管理サーバーとノード・マネージャの間にSSL通信を設定していない場合です。SSLが設定されていない場合、ホスト名の検証を無効にしておかないとエラー・メッセージを受信することになります。
ホスト名の検証は、管理サーバーとノード・マネージャの間にSSL通信を設定したら、再度有効化できます。
WCCHOST1でホスト名の検証を無効化するには、次の手順を実行します。
管理コンソールで、「サーバー」、「AdminServer」の順に選択します。
「SSL」→「詳細」を選択します。
「チェンジ・センター」で、「ロックして編集」をクリックします。
プロンプトが表示されたら、変更内容を保存してアクティブ化します。
「ホスト名の検証」を「なし」に設定します。
「WLS_UCM1」→「SSL」→「詳細」を選択します。
「ホスト名の検証」を「なし」に設定します。
WLS_URM1とWLS_IPM1に対し、ステップ6と7を繰り返します。
管理サーバーおよびすべての管理対象サーバー(WLS_UCM1、WLS_URM1、WLS_IPM1など)を再起動します。
WCCHOST2でホスト名の検証を無効化するには、次の手順を実行します。
管理コンソールで、「WLS_UCM2」、「SSL」、「詳細」の順に選択します。
「ホスト名の検証」を「なし」に設定します。
WLS_URM2とWLS_IPM2に対し、ステップ1と2を繰り返します。
管理サーバーおよびすべての管理対象サーバー(WLS_UCM2、WLS_URM2、WLS_IPM2など)を再起動します。
WLS_UCM1構成ページ(http://WCCHOST1:16200/cs)にアクセスします。
ログインすると、構成ページが開きます。WebCenter Content構成ファイルは、共有ディスクに配置されている必要があります。この例では、共有ディスクを/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のホストとポートを設定します(wcc.mycompany.com:80)。
これらの更新を適用するには、「送信」をクリックして、WLS_UCM1管理対象サーバーを再起動します。
WLS_URM1構成ページ(http://WCCHOST1:16250/urm)にアクセスします。
ログインすると、構成ページが開きます。Records構成ファイルは、共有ディスクに配置されている必要があります。この例では、共有ディスクを/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
「コンテンツ・サーバーの新規インスタンス」チェック・ボックスが選択されていないことを確認します。
これらの更新を行ったら、「送信」をクリックし、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ドメインの指定」画面で:
WebLogic Serverをインストールした場所を入力します。管理サーバーが実行されている必要があります。
ドメイン・ホスト名: WCCHOST1
ドメインのポート番号: 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 wcchost1:16200,wcchost2:16200
SetHandler weblogic-handler
WLCookieName JSESSIONID
</Location>
<Location /adfAuthentication>
WebLogicCluster wcchost1:16200,wcchost2:16200
SetHandler weblogic-handler
WLCookieName JSESSIONID
</Location>
# URM
<Location /urm>
WebLogicCluster wcchost1:16250,wcchost2:16250
SetHandler weblogic-handler
WLCookieName JSESSIONID
</Location>
<Location /urm/adfAuthentication>
WebLogicCluster wcchost1:16250,wcchost2:16250
SetHandler weblogic-handler
WLCookieName JSESSIONID
</Location>
# IBR
<Location /ibr>
WebLogicCluster wcchost1:16300,wcchost2:16300
SetHandler weblogic-handler
WLCookieName JSESSIONID
</Location>
<Location /ibr/adfAuthentication>
WebLogicCluster wcchost1:16300,wcchost2:16300
SetHandler weblogic-handler
WLCookieName JSESSIONID
</Location>
# Imaging Application
<Location /imaging>
SetHandler weblogic-handler
WebLogicCluster WCCHOST1VHN1:16000,WCCHOST2VHN1:16000
</Location>
# AXF WS Invocation
<Location /axf-ws>
SetHandler weblogic-handler
WebLogicCluster WCCHOST1VHN1:16000,WCCHOST2VHN1:16000
</Location>
これらの行では、WEBHOST1上のOracle HTTP Serverを構成して、WCCHOST1およびWCCHOST2のクラスタ化されたアプリケーションにリクエストをルーティングします。
|
注意:
|
これらの行を追加したら、Oracle HTTP Serverを再起動し、次を指定してアプリケーションにアクセスできることを確認します。
http://WEBHOST1:7777/cs http://WEBHOST1:7777/urm http://WEBHOST1:7777/imaging
|
注意: アプリケーションの使用方法に応じて、「More Location」タグを追加する必要がある場合があります。たとえば、WebCenter ContentはWebDavへのアクセスには/_dav、Webサービスへのアクセスには/idcwsにアクセスする必要があります。詳細は、製品のドキュメントを参照してください。 |
ラウンドロビン・ロード・バランシングを使用して仮想ホスト(ucm.mycompany.com)が使用可能なOracle HTTP Serverにルーティングされるように、ロード・バランサを構成します。
また、各Oracle HTTP ServerでHTTPおよびHTTPSリスニング・ポートを監視するように、ロード・バランサを構成する必要があります。
http://WEBHOST1:7777/csでOracle WebCenter Content Serverにアクセスできることを確認します。
この項では、WCCHOST2で実行するインストールおよび構成手順について説明します。
WCCHOST2にOracle WebLogic Serverをインストールするには、第11.3.3.1項「WCCHOST1へのOracle WebLogic Serverのインストール」の手順をWCCHOST2で実行します。
WCCHOST2にOracle WebCenter Contentをインストールするには、第11.3.3.2項「WCCHOST1へのOracle WebCenter Contentのインストール」の手順をWCCHOST2で実行します。
packおよびunpackコマンドを使用して、WCCHOST2のWLS_UCM2管理対象サーバーをWCCHOST1のOracle WebCenter Contentドメインに参加できるようにします。
最初に、WCCHOST1でpackコマンドを実行します。
pack -managed=true -domain=/u01/app/oracle/product/WLS/11G/user_projects/domains /wccdomain -template=wcc_template.jar -template_name="my wcc domain"
wcc_template.jarファイルをWCCHOST2にコピーした後に、WCCHOST2でunpackコマンドを実行します。
unpack -domain=/u01/app/oracle/product/WLS/11G/user_projects/domains/wccdomain -template=wcc_template.jar
WCCHOST2でノード・マネージャを起動するには、次のコマンドを使用します。
WCCHOST2> MW_HOME/oracle_common/common/bin/setNMProps.sh WCCHOST2> WL_HOME/wlserver_10.3/bin/startNodeManager.sh
管理コンソール(http://WCCHOST1:7001/console)にアクセスします。管理コンソールで、WLS_UCM2管理対象サーバーを起動します。
管理コンソール(http://WCCHOST2:7001/console)にアクセスします。管理コンソールで、WLS_UCM2、WLS_URM2、およびWLS_IPM2管理対象サーバーを停止します。
WLS_UCM2構成ページ(http://WCCHOST2:16200/cs)にアクセスします。
ログインすると、構成ページが開きます。WebCenter Content構成ファイルは、共有ディスクに配置されている必要があります。この例では、共有ディスクを/orashare/orcl/ucmと想定しています。
構成ページの次の項目を、ここで示す値に設定します。
コンテンツ・サーバーのインスタンス・フォルダ: /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
「コンテンツ・サーバーの新規インスタンス」チェック・ボックスが選択されていないことを確認します。
これらの更新を行ったら、「送信」をクリックしてWLS_UCM2管理対象サーバーを再起動します。
WLS_URM2構成ページ(http://WCCHOST2:16250/urm)にアクセスします。
ログインすると、構成ページが開きます。Records構成ファイルは、共有ディスクに配置されている必要があります。この例では、共有ディスクを/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
「コンテンツ・サーバーの新規インスタンス」チェック・ボックスが選択されていないことを確認します。
これらの更新を行ったら、「送信」をクリックし、WLS_URM2管理対象サーバーを再起動します。
この項では、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ドメインの指定」画面で:
WebLogic Serverをインストールした場所を入力します。管理サーバーが実行されている必要があります。
ドメイン・ホスト名: WCCHOST1
ドメインのポート番号: 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で実行します。
この項では、Imaging JMSのJMS永続ストア、トランザクション・リカバリのためのデフォルトの永続ストア、およびWebCenter Content管理対象サーバーでのImaging管理対象サーバーの各構成方法について説明します。
この項では、次の項目について説明します。
2つのノードから参照できるディレクトリとして、JMS永続ストアの場所を構成します。デフォルトでは、Imagingで使用されるJMSサーバーに永続ストアは構成されず、WebLogic Serverのストア(ORACLE_BASE/admin/domain_name/mserver/domain_name/servers/server_name/data/store/default)を使用しています。次のように、共有ベースのディレクトリを使用するように、ImagingのJMSサーバーの永続ストアを変更する必要があります。
管理コンソールにログインします。
「ドメイン構造」ウィンドウで、「サービス」ノードを開いて「永続ストア」ノードをクリックします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「新規」をクリックしてから、「ファイル・ストアの作成」をクリックします。
名前(たとえば「IPMJMSServer1Store」により、作成対象のサービスを特定できます)およびターゲットのWLS_IPM1を入力します。WCCHOST1とWCCHOST2の両方からアクセスできる共有記憶域にあるディレクトリを入力します(ORACLE_BASE/admin/domain_name/ipm_cluster/jms)。
「OK」をクリックして、変更をアクティブ化します。
「ドメイン構造」ウィンドウで、「サービス」ノードを開き、「メッセージング」→「JMSサーバー」ノードをクリックします。
表の「名前」列から「IpmJmsServer1 JMS Server」(ハイパーリンクで表示)をクリックします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「永続ストア」ドロップダウン・リストで、「IPMJMSServer1Store」を選択します。
「保存」→「変更のアクティブ化」をクリックします。
手順を繰り返して、IPMJMSServer2のIPMJMSServer2Storeを作成します。
各サーバーにはトランザクション・ログがあり、サーバーによって調整およびコミットされた、未完了の可能性のあるトランザクションについての情報が格納されます。WebLogic Serverは、システム障害やネットワーク障害のリカバリでこのトランザクション・ログを使用します。クラスタ内のサーバーでトランザクション回復サービスの移行機能を活用するには、サーバーからアクセス可能な場所にトランザクション・ログを格納します。
|
注意: 可能であれば、この場所にはデュアル・ポートのSCSIディスクまたはストレージ・エリア・ネットワーク(SAN)を使用します。 |
WLS_IPM1のデフォルト永続ストアの場所を設定する手順は次のとおりです。
管理コンソールにログインします。
「ドメイン構造」ウィンドウで、「環境」ノードを開いて「サーバー」ノードをクリックします。
「WLS_IPM1」(表の「名前」列にハイパーリンクとして表示)をクリックします。
「サービス」タブをクリックします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
ページの「デフォルト・ストア」セクションに、デフォルトの永続ストアがデータファイルを格納するフォルダのパスを入力します。そのパス・ディレクトリ構造は次のとおりです。
ORACLE_BASE/admin/domain_name/ipm_cluster_name/tlogs
「保存」をクリックして、変更をアクティブ化します。
WLS_IPM2サーバーに対してこの手順を繰り返します。
|
注意: トランザクション回復サービスの移行機能を有効化するには、クラスタ内の他のサーバーで利用可能な永続記憶域ソリューション上の場所を指定します。WCCHOST1およびWCCHOST2の両方からこのディレクトリにアクセスできる必要があり、サーバーの再起動前に、このディレクトリが存在している必要があります。 |
Oracle IP/Mクラスタは、WebCenter Contentクラスタにアクセスするように構成する必要があります。
Oracle WebCenter Content ServerでImagingを有効化するには、次の手順を実行します。
Oracle WebCenter Content Server(http://WCCHOST1:16200/cs)にログインします。
「管理」トレイまたはメニューを開いて、「管理サーバー」を選択します。
「コンポーネント・マネージャ」をクリックします。
IpmRepositoryコンポーネントを有効にします。
UCMクラスタ内のすべての管理対象サーバーを再起動します。
次の手順を実行して、Oracle WebCenter Content Serverのデフォルトのファイル・ストアをアップグレードします。
Oracle WebCenter Content Server(http://WCCHOST1:16200/cs)にログインします。
「管理」トレイまたはメニューを開いて、「プロバイダ」を選択します。
「DefaultFileStore」の「情報」リンクをクリックします。
「編集」をクリックし、「更新」をクリックします。
クラスタ内のすべてのコンテンツ・サーバーを再起動します。
WLS_IPM1およびWLS_IPM2管理対象サーバー(それぞれ、WCCHOST1VHN1およびWCCHOST2VHN1)のImagingサーバーのリスニング・アドレスを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|wcchost1vhn1|wcchost2vhn1 AlwaysReverseLookupForHost=Yes
UCMサーバーを再起動して、変更を有効にします。
次の手順を実行して、UCMシステムへの接続を作成します。
WLS_IPM1イメージング・コンソール(http://WCCHOST1:16200/ imaging)にログインします。
左側のペインで、「接続の管理」→「Content Server接続の作成」をクリックします。
新しい接続の名前と説明を入力し、「次へ」をクリックします。
「接続設定」画面で、次の操作を実行します。
「ローカルContent Serverの使用」が選択されていることを確認します。
Content Serverポートを4444に設定します。
2つのサーバーを「Content Serverプール」に追加します。
WCCHOST1:4444
WCCHOST2:4444
「次へ」をクリックします。
「接続セキュリティ」画面で、WebLogicユーザーに対するデフォルトの選択をそのまま受け入れて、「次へ」をクリックします。
接続の詳細を確認し、「送信」をクリックします。
ImagingからBPELシステムに接続する場合、SOAシステムと通信するために必要な資格証明を構成する必要があります。これらの資格証明を追加する手順は次のとおりです。
(管理サーバーが存在する)WCCHOST1のOracle WebCenter Content Oracleホームの下のcommon/binにディレクトリを変更します。
WCCHOST1>cd ORACLE_HOME/common/bin
(ORACLE_HOMEは、MW_HOME/wccの下のOracle WebCenter Contentホームです。)
Oracle WebLogic Scripting Tool(WLST)を実行します。
WCCHOST1>./wlst.sh
connect()を実行して、ユーザー名、パスワード、および管理サーバーのURL(t3://WCCHOST1:7001)を指定します。
wls:/offline> connect()
CSF(資格証明ストア・フレームワーク)資格証明を作成します。この資格証明は、ImagingがBPELシステムへの接続に使用する資格証明です。これをBPEL管理ユーザーにします。CSF資格証明は、「alias」がキーとなり、CSFの「map」という中に保存されるユーザー名/パスワードのペアです。OWSM Webサービスと統合するため、Imagingは現在oracle.wsm.securityという標準のOWSM CSFマップを使用しています。資格証明を作成するには、createCred WLSTコマンドを使用します。
wls:/wcc_domain/serverConfig> createCred(map="oracle.wsm.security", key="basic.credential", user="weblogic", password="password_for_credential")
コマンドの「key」は、Imaging管理ユーザー・インタフェースのBPEL接続定義の「資格証明別名」プロパティに使用される「alias」です(APIのConnection.CONNECTION_BPEL_CSFKEY_KEYプロパティにも使用されます)。OWSMおよびBPELで使用される標準のデフォルト名であるため、この例では別名「basic.credential」を使用します。ただし、別名はマップ内で一意であれば、任意に指定できます。
資格証明のリストコマンドを実行して、資格証明が作成されたことを確認します。
wls:/wcc_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://WCCHOST1VHN1:16000/imaging)にログインします。
左側のペインで、「接続の管理」→「ワークフロー接続の作成」をクリックします。
「BPEL接続の作成」をクリックします。
BPELマシン名、およびオプションで説明を入力します。
「次へ」をクリックします。
「接続設定」画面で、次の操作を実行します。
プロバイダ名フィールドに、2つのSOAサーバー・リスニング・アドレスをカンマで区切って入力します: SOAHOST1VHN2, SOAHOST2VHN1
BPELポートを指定します: 8001
ターゲットBPELシステムに必要な場合、「SSL」オプションを選択します。
「BPEL CSF資格証明の構成」の項で作成した資格証明の別名を指定します。
「接続のテスト」ボタンをクリックして、接続パラメータを確認し、BPELマシンに存在するコンポジットを確かめます。
「次へ」をクリックします。
必要に応じて、付与するセキュリティを変更します。
「次へ」をクリックしてから、「送信」をクリックします。
WebLogic Server ImagingクラスタのフロントエンドHTTPホストおよびポートを設定する必要があります。
管理コンソールにログインします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「ドメイン構造」ウィンドウで、「環境」ノードを開きます。
「クラスタ」をクリックします。
「IPM_Cluster」を選択します。
「HTTP」タブをクリックします。
次の値を設定します。
フロントエンド・ホスト: wcc.mycompany.com
フロントエンドHTTPSポート: 443
フロントエンドHTTPポート: 80(SSLを使用しない場合)
「保存」をクリックします。
管理コンソールの「チェンジ・センター」セクションで「変更のアクティブ化」をクリックします。
サーバーを再起動して、クラスタ内のフロントエンド・ホスト・ディレクティブを有効化します。
この項では、Imagingインスタンスのサーバー移行を構成する方法について説明します。
次の手順では、Imaging管理対象サーバーのサーバー移行を有効にします。これにより、サーバーまたはプロセスの障害時に、Imaging管理対象サーバーは別のノードにフェイルオーバーできます。
WebLogic管理対象サーバーに対してサーバー移行を構成する手順は次のとおりです。
ステップ1: サーバー移行leasing表のユーザーと表領域を設定する
ステップ2: Oracle WebLogic管理コンソールを使用してGridLinkデータ・ソースまたはマルチ・データ・ソースを作成する
ステップ3: ノード・マネージャのプロパティ・ファイルを編集する
ステップ5: サーバー移行ターゲットを構成する
ステップ6: サーバー移行をテストする
マルチ・データ・ソースの設定プロセスで、各Oracle RACデータベース・インスタンスのデータ・ソースを、これらのデータ・ソースとグローバルleasingマルチ・データ・ソースの両方について作成します。データ・ソースを作成するときには、次の点に留意してください。
このデータ・ソースが非XAデータ・ソースであることを確認します。
Oracleのドライバ(Thin)バージョン9.0.1、9.2.0、10、11を使用します。
データ・ソースは、グローバル・トランザクションのサポートを必要としません。したがって、データ・ソースに対して、どのようなタイプの分散トランザクション・エミュレーション/参加アルゴリズムも使用しない(「グローバル・トランザクションのサポート」オプション、または「グローバル・トランザクションのサポート」オプションの「ロギング・ラスト・リソース」、「2フェーズ・コミットのエミュレート」または「1フェーズ・コミット」オプションを選択しない)で、データベースのサービス名を指定します。
これらのデータ・ソースをクラスタにターゲット指定します。
データ・ソースの接続プールの初期容量が0(ゼロ)に設定されていることを確認します。そのためには、「サービス」→「JDBC」→「データ・ソース」を選択します。「データ・ソース」画面で、「データソース名」、「接続プール」タブの順にクリックし、「初期容量」フィールドに0(ゼロ)を入力します。
ONSデーモンがデータベース・サーバーで常に実行中であることを確認します。ONSデーモンをデータベース・サーバーで起動するには、onsctlコマンド(start)を実行します。
GridLinkデータソースの作成
GridLinkデータ・ソースを作成する手順は次のとおりです。
管理コンソールにログインします。
まだ行っていない場合は、管理コンソールの「チェンジ・センター」で、「ロックして編集」をクリックします。
「ドメイン構造」ツリーで「サービス」を開き、「データ・ソース」を選択します。
「データ・ソースの概要」ページで、「新規」をクリックして「GridLinkデータ・ソース」を選択します。
次の情報を入力します。
「名前」フィールドで、データ・ソースの論理名を入力します。たとえば、gridlinkと入力します。
JNDIの名前を入力します。たとえば、jdbc/gridlinkと入力します。
「次へ」をクリックします。
「トランザクション・オプション」ページで、「グローバル・トランザクションのサポート」を選択解除して「次へ」をクリックします。
「個別のリスナー情報の入力」を選択して、「次へ」をクリックします。
次の接続プロパティを入力します。
サービス名: データベースのサービス名を入力します。GridLinkデータ・ソースの場合は、RACサービス名を小文字で入力し、その後にドメイン名example.comを入力する必要があります。たとえば、<mydbservice>.example.comと入力します。
|
注意: Oracle RACサービス名はデータベースで定義されており、固定名ではありません。データベース・ドメイン名(例: example.com)を含むRACサービス名を登録または追加することをお薦めします。 |
ホスト名: データベースをホストするサーバーのDNS名またはIPアドレス。Oracle GridLinkサービスとインスタンス間の接続の場合、特定のマルチ・データ・ソースの各データ・ソースで同じ名前にする必要があります。
Port: データベース・サーバーが接続リクエストをリスニングするポート。
データベース・ユーザー名: データベース・ユーザー名。たとえば、myDataBaseと入力します。
パスワード: パスワード。たとえば、myPassword1です。
パスワードを確認して、「次へ」をクリックします。
|
ヒント: 詳細は、Oracle Fusion Middleware管理コンソール・オンラインに関するヘルプを参照してください。 |
コンソールにより、完全なJDBC URLが自動的に生成されます。例:
jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=left)(PORT=1234))(ADDRESS=(PROTOCOL=TCP)(HOST=right)(PORT=1234))(ADDRESS=(PROTOCOL=TCP)(HOST=center)(PORT=1234)))(CONNECT_DATA=(SERVICE_NAME=myService)))
「GridLinkデータベース接続のテスト」ページで、接続パラメータを確認して、「すべてのリスナーのテスト」をクリックします。
Oracle WebLogicにより、管理サーバーからデータベースへの接続の作成が試行されます。接続テストの結果がページの上部に表示されます。テストに失敗した場合は、構成エラーをすべて修正してテストを再試行します。
「次へ」をクリックします。
「ONSクライアント構成」ページで、次の手順を実行します。
「FANの有効化」を選択してOracle FANイベントに登録し、それらのイベントを処理できるようにします。
「ONSホストとポート」で、ONSベースのFANイベントを受け取るためにONSデーモンが接続するリスニング・アドレスとリスニング・ポートのカンマ区切りのリストを入力します。単一クライアント・アクセス名(SCAN)アドレスを使用すると、FAN通知にアクセスできます。
「次へ」をクリックします。
「ONSクライアント構成のテスト」ページで、接続パラメータを確認して、「すべてのONSノードのテスト」をクリックします。
「次へ」をクリックします。
「ターゲットの選択」ページで「Dept1_Cluster1」をターゲットとして選択し、「クラスタのすべてのサーバー」を選択します。
「終了」をクリックします。
「変更のアクティブ化」をクリックします。
マルチ・データ・ソースの作成
マルチ・データ・ソースを作成する手順は、次のとおりです。
管理者資格証明を使用して、管理コンソールにログインします。
「ドメイン構造」ウィンドウで「サービス」ノードを開き、次に、「データ・ソース」ノードを開きます。
「チェンジ・センター」で「ロックして編集」をクリックします。
「新規」をクリックしてから、「マルチ・データ・ソース」をクリックします。
名前として、leasingと入力します。JNDI名として、jdbc/leasingと入力します。
アルゴリズムとして、「フェイルオーバー」(デフォルト)を選択します。「次へ」をクリックします。
ターゲット・クラスタを選択します。「次へ」をクリックします。
「非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ノードのインスタンス名)、ホスト・ポートおよびパスワードを入力します。
「次へ」をクリックします。
「構成のテスト」をクリックして、接続が機能しているかどうかを確認します。「次へ」をクリックします。
データ・ソースをクラスタにターゲット指定します。
データ・ソースを選択して、右の画面に追加します。
Oracle RACデータベースの2番目のインスタンスについて「新しいデータ・ソースの作成」をクリックして、そのターゲットをクラスタに設定してから、Oracle RACデータベースの2番目のインスタンスについても同じ手順を繰り返します。
2つ目のデータ・ソースをマルチ・データ・ソースに追加します。
保存して、「変更のアクティブ化」をクリックします。
最後の手順は、サーバー移行をテストすることです。サーバー移行が適切に機能していることを確認するには、次の手順を実行します。
WCCHOST1から次の処理を実行します。
管理対象サーバーWLS_IPM1を停止します。これを行うには、このコマンドを実行します:
WCCHOST1> kill -9 pid
pidには、管理対象サーバーのプロセスIDを指定します。次のコマンドを実行すると、ノード内のpidを確認できます。
WCCHOST1> ps -ef | grep WLS_IPM1
|
注意: Windowsの場合は、 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秒間待機します。
ノード・マネージャがサーバーを再起動した後で、そのサーバーをもう一度停止します。サーバーが再びローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されるようになります。
WCCHOST2から次の処理を実行します。
ローカルのノード・マネージャのコンソールを確認します。WCCHOST1で最後にWLS_IPM1の再起動が最後に試行されてから30秒経過した後、WCCHOST2のノード・マネージャによって、WLS_IPM1の浮動IPが有効化されていること、およびこのノードでサーバーが再起動されていることが表示されます。
同じIPのsoa-infraコンソールにアクセスします。
管理コンソールからの検証
「移行ステータス」表に、移行の状態に関する情報が表示されます。
管理コンソールで移行を検証する手順は、次のとおりです。
|
注意: サーバーの移行後、そのサーバーを元のノード/マシンにフェイルオーバーするには、管理コンソールから管理対象サーバーを停止し、再起動します。適切なノード・マネージャが、もともと割り当てられていたマシン上の管理対象サーバーを起動します。 |
この項では、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クラスタのすべてのメンバーはInbound Refineryクラスタの任意のメンバーからの変換をリクエストできます。
Inbound Refineryインスタンスは、独自のドメインにインストールすることも、既存のドメインの拡張としてインストールすることもできます。
