| Oracle® Fusion Middleware高可用性ガイド 11gリリース1 (11.1.1) B55898-11 |
|
 前 |
 次 |
この章では、Oracle WebCenter Contentコンポーネントについて高可用性の観点から説明します。Oracle WebCenter Contentは、Oracle Fusion Middlewareコンポーネントの1つで、コンテンツを管理するために設計された統合的な製品スイートです。業界最先端のドキュメント管理、Webコンテンツ管理、デジタル資産管理およびレコード管理機能を利用して、ビジネス・アプリケーションを構築できます。
Oracle WebCenter Contentには次のような利点があります。
優れたユーザビリティ: エンド・ユーザー、ワークグループ、コンテンツ・エキスパート、プロセスの所有者、管理者、およびWebマスターに対する組込みのサポート
最適化された管理: ドキュメント、ファイル、Webコンテンツ、およびデジタル資産を安全に管理するための統合されたアーキテクチャ
ホットプラガブル: Oracleおよびサード・パーティのリポジトリ、セキュリティ・システム、およびエンタープライズ・アプリケーションに対するインストール時からのサポート
この章の項目は次のとおりです。
この項では、Oracle WebCenter Content (WebCenter Content)の概要、およびWebCenter Contentの高可用性環境の設計とデプロイ方法について説明します。
この項の内容は次のとおりです。
図11-1は、WebCenter Contentの単一インスタンスのアーキテクチャを示しています。
図11-1 Oracle WebCenter Contentの単一インスタンス・アーキテクチャ
WebCenter Contentのインスタンスは、管理対象サーバー環境で稼働します。管理対象サーバーは、WebCenter Contentアプリケーションのライフサイクルを管理します。
WebCenter Contentアプリケーションへのエントリ・ポイントは2つあります。1つはリスニングTCPソケットであり、このソケットは、ImagingやOracle WebCenter Portalなどのクライアントからの接続を受理できます。もう1つはHTTPリスニング・ポートです。これは、Webサービス呼出しを受理できます。HTTPポートは、管理対象サーバーのリスニング・ポートと同じポートです。
管理対象サーバーは、クライアント・ブラウザのアプレットとして実行できるいくつかの埋込みアプリケーションも持っています。これらには、ファイル管理および索引機能のリポジトリ・マネージャ(RM)およびユーザー・ワークフローを設定するためのワークフロー管理などがあります。詳細は、Oracle Fusion Middleware Oracle WebCenter Contentの管理を参照してください。
管理対象サーバーには、3タイプの永続ストアがあります。それらのタイプは、リポジトリ(Oracle Databaseに格納可能)、検索索引(Oracle Databaseに格納可能)、メタデータおよびWebレイアウト情報(ファイル・システムに格納可能)です。
WebCenter Contentは、WebLogic Serverに存在するサーブレットです。サーブレット・リクエストは、WebCenter Contentリクエストのラッパーです。
WebCenter Contentには、BatchLoaderやIdcAnalyzerなどの様々なスタンドアロンの管理ユーティリティが含まれます。JMSおよびJTAは、WebCenter Contentでは使用されません。
WebCenter Contentのリクエストはステートレスです。認証情報を保持するために、セッションをデータベースに保存できます。
WebCenter Contentは、サービス指向アーキテクチャを採用しています。それぞれのリクエストは、サービスとしてシステムに受け入れられます。共有サービス層では、リクエストを解析し、そのリクエストを正しいハンドラに渡します。通常、ハンドラは基になるリポジトリにアクセスして、リクエストを処理します。図11-1は、3種類のリポジトリとそれぞれで保存するデータを示しています。
起動時に、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
Oracle WebCenter Portal
クライアントからの接続は短時間で、セッションレス・サービスの期間にのみ必要です。
クライアントは、HTTP、SOAP/Oracle Web Services、JCR、およびVCRプロトコルを使用して、WebCenter Contentに接続できます。
WebCenter Contentは、WebLogic ServerにデプロイされたJ2EEアプリケーションです。ログ・メッセージは、アプリケーションがデプロイされるWebLogic Serverのサーバー・ログ・ファイルに記録されます。サーバー・ログのデフォルトの場所は次のとおりです。
MW_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-2は、2ノードのアクティブ/アクティブOracle WebCenter Contentクラスタを示しています。
図11-2の詳細は次のとおりです。
それぞれのノードは、共有ファイル・システム、同じデータベース・スキーマ、同じ検索索引に対して独立に稼働します。クライアント・リクエストは、すべて単一ノードで処理されます。
WebCenter Contentは、WebLogic Serverクラスタまたは外部ロード・バランサで稼働できます。WebCenter Contentは、Oracle RACおよび複数のデータ・ソース構成に対しても透過的です。
WebCenter Contentは、独立にスケーラビリティを持つことができ、ノード間の通信は限定的です。ノードどうしは、共有ファイル・システムへの読書きを介して通信します。この共有ファイル・システムは、書込み操作の同期化をサポートする必要があります。
クラスタが起動すると、それぞれのWebCenter Contentノードは通常の初期化シーケンスが実行されます。ノードがクラスタの一部である場合、他のクラスタ・メンバーが使用可能であれば、メモリー内のレプリケーションが開始されます。1つまたすべてのクラスタ・メンバーを同時に起動することができます。
クラスタ・メンバーをシャットダウンすると、そのクラスタ・メンバーはリクエストに対応できなくなります。サーバーを正常にシャットダウンすると、現在のリクエストの処理を終了して、使用不可になることを通知し、すべての共有リソースを開放して、そのファイルおよびデータベース接続を閉じます。すべてのセッション状態はレプリケートされ、このクラスタ・メンバーに接続されていたユーザーは、他のクラスタ・メンバーにフェイルオーバーされます。
クラスタ・レベルでは、WebCenter Contentの内部コンポーネントを使用した新しいWebCenter Contentの機能や動作のカスタマイズ機能が追加されました。新しい変更を取得するには、ノードを再起動する必要があります。
たとえば、メタデータ・モデルでシステム全体を変更できます(メタデータ・フィールドの追加、変更、削除など)。これらのxumetadataフィールドで駆動されたシステムの動作は変更できます。この変更は、ノード間の通知を介して、クラスタ・ノートで自動的に取得されます。
各クラスタ・メンバーで変更を適用するには、最初のノードで共有フォルダを構成する必要があります。それぞれのクラスタ・ノードのすべての共有フォルダが同じマウント・ポイントを持っていれば、他のノードでWebLogic Serverのpack/unpackを使用して手動で変更を行う必要はありません。
WebCenter Contentを1つ以上のInbound Refineryインスタンスで構成して、ドキュメントの変換を行います。
Inbound Refineryは、電子ドキュメントのファイルの変換を管理します。また、ドキュメントおよびイメージのサムネイル機能、デジタル・イメージからEXIFを抽出および使用する機能、Adobe Photoshopなどのプログラムから生成された電子ファイルからXMPデータを抽出および使用する機能、およびビデオのストーリーボード作成機能も用意されています。詳細は、Oracle Fusion Middleware Oracle WebCenter Contentの管理を参照してください。
インストールが必要なInbound Refineryインスタンス数は、サポートが必要な変換の量によって異なります。可用性を高めるために、少なくとも2つのInbound Refineryインスタンスをインストールすることをお薦めします。すべてのInbound Refineryインスタンスは、プロバイダとして、WebCenter ContentクラスタのOracle WebCenter Content Serverインスタンスから使用できる必要があります。
Content ServerとInbound Refinery間のすべての通信は、Content Serverで開始されます。開始処理には次のような処理が含まれます。
ステータスを決定するための、使用可能なすべてのInbound Refineryインスタンスの定期的なチェック。
ジョブ・リクエストの開始
完了したジョブの取得
ステータスには、Inbound Refineryがリクエストを受理できるかどうかを示す情報が含まれます。使用できるInbound Refineryインスタンスがない場合、リクエストは再試行されます。
ジョブが完了すると、Content Serverのステータス・リクエストの一部としてこの情報が表示されます。そのような場合、Content Serverは完了したジョブのダウンロードを開始します。
WebCenter Contentクラスタでは、クラスタ・メンバーが使用可能なInbound Refineryインスタンスのリストを共有します。つまり、新しいInbound Refineryインスタンスが追加されると、それは任意のWebCenter ContentクラスタのContent Serverインスタンスで使用できるようになります。
ただし、各Content Serverは使用可能なすべてのInbound Refineryインスタンスと独立的に通信します。WebCenter Contentクラスタには、共有Inbound Refineryステータスはありません。
同様に、すべての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に適用される高可用性に関する考慮事項は、Recordsにも適用されます。
高可用性を構成する場合、WebCenter ContentとRecordsでは注意する相違点が2つあります。
Recordsは、WebCenter Contentと異なるディレクトリに、ファイル・システム・メタデータを保存します。
Recordsクラスタの前面のHTTPサーバーを構成する場合、WebCenter Contentと異なるセッションCookie名を使用する必要があります。
これらの構成の違いの詳細は、第11.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ノードの前面のロード・バランサまたはWLSモジュールによって処理されます。クライアントからの処理中のリクエストは失敗しますが、後続のリクエストはアクティブ・ノードにルーティングされます。終了していないトランザクションは終了しません。
ノードからの構成データは、共有ファイル・システムおよびデータベースに保存されているため、失われることはありません。
アクティブ・セッションがあるユーザーは、セッションがアクティブ・サーバーにフェイルオーバーされるため、ダウンタイムが発生することはありません。これは、管理アプレットを開いているユーザーも含まれます。
WebCenter Contentのインストールが完了したら、config.cfgファイルに次の値を設定し、Oracle RACフェイルオーバー中の再試行ロジックを有効にします。
ServiceAllowRetry=true
この値を設定しない場合、フェイルオーバーが開始されたときに、処理中の任意の操作を手動で再試行する必要があります。
次のURLにあるContent Server用の管理コンソールを使用して、値を設定します。
http://hostname:port/cs
「管理」→「管理サーバー」→「一般構成」を選択し、ServiceAllowRetry=trueを「追加の構成変数」に追加します。これを保存して、すべての管理対象サーバーを再起動します。新しい値がconfig.cfg内の次の位置に表示されます。
SHARED_DISK_LOCATION_FOR_UCM/ucm/cs/config/config.cfg
WebCenter Contentをトラブルシューティングするには、ログ・ファイルを調べてからトレース・ファイルを調べます。
WebCenter Contentのログ・ファイルおよびトレース・ファイルの場所、およびWebCenter ContentのGUIを使用してログ・ファイルおよびトレース・ファイルを表示する方法の詳細は、第11.1.1.1.7項「WebCenter Contentのログ・ファイルの場所」を参照してください。
アクティブ・サーバーを停止してからドキュメントをチェックインしようとすると、次のエラーが発生します。
The content item was not successfully checked in. The authorization token is invalid. It has either expired or is not appropriate for the current request. You may need to reload an earlier page in order to proceed.
ページをリフレッシュして、更新されたトークンを取得し、チェックインで続行します。
高可用性環境の場合、Oracle WebCenter Content製品は、クラスタ・デプロイメントで設定することをお薦めします(そうすることで、クラスタ化されたインスタンスはOracle Real Applications Cluster (Oracle RAC)データベースのコンテンツ・リポジトリにアクセスし、共有ディスクに共通の構成が保存されます)。
ハードウェア・ロード・バランサは、リクエストを複数のOracle HTTP Serverインスタンスにルーティングしてから、クラスタ化された管理対象サーバーにルーティングします。
この項では、図11-3で示されるOracle WebCenter Contentの高可用性構成のインストールおよび構成手順について説明します。
内容は次のとおりです。
|
注意: 設定プロセスを開始する前に、リリース・ノートを読をことを強くお薦めします。 |
構成には、次の製品が含まれています。
Imaging
WebCenter Content
Records
Oracle WebCenter Content: Inbound Refinery (Inbound Refinery)
すべての製品は同じマシン上にインストールされますが、Inbound Refineryだけはリモート・マシン上に想定されています。
ImagingまたはRecordsをインストールしない場合は、構成手順の当該製品の箇所を無視してください。
クラスタ・メンバーは、同じ構成ファイルにアクセスするために、共有記憶域を必要とします。これは、クラスタのすべてのノードからアクセスできるように設定します。
WebCenter ContentやRecordsクラスタを構成する場合、次の要件に従ってください。
WebCenter Contentクラスタでは、すべてのクラスタ・メンバーは同じ構成ディレクトリを指す必要があります。このディレクトリは、クラスタのすべてのメンバーからアクセス可能な共有ディスクに配置されている必要があります。
Recordsクラスタでは、すべてのクラスタ・メンバーは同じ構成ディレクトリを指す必要があります。このディレクトリは、すべてのクラスタ・メンバーからアクセス可能な共有ディスクに配置されている必要があります。
Oracle RACデータベースを構成してから、ここで説明する手順を完了してください。
リポジトリ作成ユーティリティ(RCU)は、Oracle Fusion Middleware 11gキットの部品として付属する専用のCDに収録されています。
RCUを実行して、Oracle RACデータベース・リポジトリにWebCenter Contentスキーマを作成する手順:
次のコマンドを発行します。
RCU_HOME/bin/rcu &
「ようこそ」画面で「次へ」をクリックします。
「リポジトリの作成」画面で、「作成」を選択して、コンポーネント・スキーマを既存のデータベースにロードします。
「次へ」をクリックします。
「データベース接続の詳細」画面で、既存のデータベースの接続情報を入力します。
データベース・タイプ: Oracle Database
ホスト名: データベースを実行しているコンピュータの名前。Oracle RACデータベースの場合は、VIP名またはノード名を指定します。例: WCCDBHOST1-VIPまたはWCCDBHOST2-VIP
ポート: データベースのポート番号。例: 1521
サービス名: データベースのサービス名。例: wccdb.example.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」をクリックします。
「サマリー」画面で「作成」をクリックします。
「完了サマリー」画面で「閉じる」をクリックします。
この項では、Oracle WebCenter Content WCCHOST1のインストールおよび構成手順について説明します。
この項の内容は次のとおりです。
WCCHOST1で、インストーラ実行可能ファイルを実行して、Oracle WebLogic Serverのインストールを開始します。
最新バージョンのOracle Fusion Middlewareとともに使用するOracle WebLogic Serverのバージョンは、『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』のインストール開始点の理解に関する項を参照してください。
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.2.3.3項「高可用性のドメインの作成」の説明に従って構成ウィザードを実行する前に、Oracle Fusion Middlewareが最新バージョンになるように、最新のOracle Fusion Middlewareパッチ・セットおよびその他の既知のパッチが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 Universal Content Management -Content Server
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 Fusion Middleware Controlなどのその他の製品も自動的に選択されます。
|
注意: Oracle Database File SystemをUCMに使用する場合は、intradoc.cfgファイルのエントリ |
「ドメイン名と場所の指定」画面で、次のエントリを作成します。
ドメイン名を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データ・ソースの構成の詳細は、第5.1.2項「GridLinkデータ・ソースおよびOracle RAC」を参照してください。
Oracle RACおよびMDSリポジトリでのマルチ・データ・ソースの構成の詳細は、第5.1.3項「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。
「次へ」をクリックします。
次の各フィールドに値を入力して、RCUでシードされたOracle RACデータベースの接続情報を指定します。
ドライバ: RACの場合には、OracleのRACサービス・インスタンス接続用ドライバ(Thin)、バージョン:10、11を選択します。GridLinkの場合は、OracleのGridLink接続用ドライバ(Thin)、バージョン:10以降を選択します。
サービス名: データベース・サービス名を入力します。GridLinkデータ・ソースの場合は、RACサービス名を小文字で入力し、その後にドメイン名を入力する必要があります。例: mydbservice.example.com
|
注意: Oracle 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_Cluster
クラスタ・メッセージング・モード: unicast
マルチキャスト・アドレス: 適用なし
マルチキャスト・ポート: 適用なし
クラスタ・アドレス: 適用なし
他の製品(Imaging_Cluster、URM_Clusterなど)についても同様に追加します。
「次へ」をクリックします。
「サーバーのクラスタへの割当」画面で、新しく作成したクラスタに管理対象サーバーの各ペアを割り当てます。
UCMクラスタ:
WLS_UCM1
WLS_UCM2
この項の前の手順で作成したすべてのクラスタ(Imaging_Cluster、URM_ClusterおよびIBR_Cluster)に対してこれを実行します。
「次へ」をクリックします。
「マシンの構成」画面で、「Unixマシン」タブをクリックします。次のマシンを追加します。
WCCHOST1
WCCHOST2
WCCHOST3 (Inbound Refineryが構成されている場合)
WCCHOST4 (Inbound Refineryが構成されている場合)
「サーバーのマシンへの割当」画面で次の操作を実行します。
WCCHOST1マシンに対して、AdminServerおよびすべての*1サーバー(WLS_UCM1、WLS_Imaging1、WLS_URM1)を割り当てます。
WCCHOST2マシンに対して、すべての*2サーバー(WLS_UCM2、WLS_Imaging2、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_Imaging1管理対象サーバーを起動します。
この手順が必要になるのは、管理サーバーとノード・マネージャの間にSSL通信を設定していない場合です。SSLが設定されていない場合、ホスト名の検証を無効にしておかないとエラー・メッセージを受信することになります。
ホスト名の検証は、管理サーバーとノード・マネージャの間にSSL通信を設定したら、再度有効化できます。
WCCHOST1でホスト名の検証を無効化するには、次の手順を実行します。
管理コンソールで、「サーバー」、「AdminServer」の順に選択します。
「SSL」→「詳細」を選択します。
「チェンジ・センター」で、「ロックして編集」をクリックします。
プロンプトが表示されたら、変更内容を保存してアクティブ化します。
「ホスト名の検証」を「なし」に設定します。
「WLS_UCM1」→「SSL」→「詳細」を選択します。
「ホスト名の検証」を「なし」に設定します。
WLS_URM1とWLS_Imaging1に対し、手順6と7を繰り返します。
管理サーバーとすべての管理対象コンソール(たとえば、WLS_UCM1、WLS_URM1とWLS_Imaging1)を再起動します。
WCCHOST2でホスト名の検証を無効化するには、次の手順を実行します。
管理コンソールで、「WLS_UCM2」、「SSL」、「詳細」の順に選択します。
「ホスト名の検証」を「なし」に設定します。
WLS_URM2とWLS_Imaging2に対し、手順1と2を繰り返します。
管理サーバーとすべての管理対象コンソール(たとえば、WLS_UCM2、WLS_URM2およびWLS_Imaging2)を再起動します。
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
ユーザー・プロファイル・フォルダ: /u01/app/oracle/admin/domainName/ucm_cluster/cs/profile
サーバー・ソケット: ポート4444
ソケット接続アドレス・セキュリティ・フィルタ: ローカル・ホストとOHSホストのリストをパイプで区切って設定します(127.0.0.1|WEBHOST1|WEBHOST2)。
WebサーバーのHTTPアドレス: ロード・バランサHTTPのホストとポートを設定します(wcc.example.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
ユーザー・プロファイル・フォルダ: /u01/app/oracle/admin/domainName/ucm_cluster/urm/profile
「コンテンツ・サーバーの新規インスタンス」チェック・ボックスが選択されていないことを確認します。
これらの更新を行ったら、「送信」をクリックし、WLS_URM1管理対象サーバーを再起動します。
この項では、WEBHOST1でのインストールおよび構成手順について説明します。
この項では、WEBHOST1にOracle HTTP Serverをインストールする方法について説明します。
システム、パッチ、カーネルなどの要件が満たされていることを確認します。それらの一覧は、使用しているプラットフォームおよびバージョンのOracle Fusion Middlewareのドキュメント・ライブラリの『Oracle Fusion Middleware Oracle Web Tierインストレーション・ガイド』にあります。
WEBHOST1実行上のいかなるサービスによってもポート7777が使用中でないことを確認します。
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をインストールした場所を入力します。管理サーバーが実行されている必要があります。
ドメイン・ホスト名: 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
|
注意: アプリケーションの使用方法に応じて、「場所」タグを追加する必要がある場合があります。たとえば、WebCenter ContentはWebDavアクセスについて/_davへのアクセス権も必要とします。/ idcwsへのアクセス件も必要とします。詳細は、製品のドキュメントを参照してください。 |
ラウンドロビン・ロード・バランシングを使用して仮想ホスト(たとえば、ucm.example.com)が使用可能なOracle HTTP Serverにルーティングされるように、ロード・バランサを構成します。
また、各Oracle HTTP ServerでHTTPおよびHTTPSリスニング・ポートを監視するように、ロード・バランサを構成する必要があります。
Oracle Content Serverにアクセスできることを検証します(http://WEBHOST1:7777/cs)。
この項では、WCCHOST2で実行するインストールおよび構成手順について説明します。
WCCHOST2にOracle WebLogic Serverをインストールするには、第11.2.3.1項「WCCHOST1へのOracle WebLogic Serverのインストール」の手順をWCCHOST2で実行します。
WCCHOST2にOracle WebCenter Contentをインストールするには、第11.2.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> MW_HOME/wlserver_10.3/server/bin/startNodeManager.sh
管理コンソール(http://WCCHOST1:7001/console)にアクセスします。管理コンソールで、WLS_UCM2管理対象サーバーを起動します。
管理コンソール(http://WCCHOST2:7001/console)にアクセスします。管理コンソールで、WLS_UCM2、WLS_URM2およびWLS_Imaging2管理対象サーバーを起動します。
WLS_UCM2構成ページ(http://WCCHOST2: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
「コンテンツ・サーバーの新規インスタンス」チェック・ボックスが選択されていないことを確認します。
これらの更新を行ったら、「送信」をクリックして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インベントリ・ディレクトリおよびオペレーティング・システムのグループ名に値を入力します。例:
インベントリ・ディレクトリの指定: /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をインストールした場所を入力します。管理サーバーが実行されている必要があります。
ドメイン・ホスト名: 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.2.4.2項「WEBHOST1でのOracle HTTP Serverの構成」の手順をWEBHOST2で実行します。
Oracle WebCenter Contentのセキュリティ・ストアとOracle Database 11gリリース2 (11.2)のOPSSセキュリティ・ストアを再関連付けることをお薦めします。この変更を行うには、『Oracle Fusion Middleware Oracle WebCenter Contentエンタープライズ・デプロイメント・ガイド』のドメインとOracle DatabaseのOPSSセキュリティ・ストアの再関連付けに関する項を参照してください。
この項の内容は次のとおりです。
2つのノードから参照できるディレクトリとして、JMS永続ストアの場所を構成します。デフォルトでは、Imagingで使用されるJMSサーバーに永続ストアは構成されず、WebLogic Serverのストア(ORACLE_BASE/admin/domain_name/mserver/domain_name/servers/server_name/data/store/default)を使用しています。次のように、共有ベースのディレクトリを使用するように、ImagingのJMSサーバーの永続ストアを変更する必要があります。
管理コンソールにログインします。
「ドメイン構造」ウィンドウで、「サービス」ノードを開いて「永続ストア」ノードをクリックします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「新規」をクリックしてから、「ファイル・ストアの作成」をクリックします。
名前(たとえば「ImagingJMSServer1Store」と入力することにより、作成対象のサービスを特定できます)およびターゲットのWLS_Imaging1を入力します。WCCHOST1とWCCHOST2の両方からアクセスできる共有記憶域にあるディレクトリを入力します(ORACLE_BASE/admin/domain_name/Imaging_cluster/jms)。
「OK」をクリックして、変更をアクティブ化します。
「ドメイン構造」ウィンドウで、「サービス」ノードを開き、「メッセージング」→「JMSサーバー」ノードをクリックします。
表の「名前」列から「ImagingJmsServer1 JMS Server」 (ハイパーリンクで表示)をクリックします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「永続ストア」ドロップダウン・リストで、「ImagingJMSServer1Store」を選択します。
「保存」→「変更のアクティブ化」をクリックします。
手順を繰り返して、ImagingJMSServer2のImagingJMSServer2Storeを作成します。
Imagingクラスタ(Imaging_Cluster)を、WebCenter Content Clusterにアクセスするように構成します。
WebCenter Contentクラスタ(UCM_Cluster)でImagingリポジトリを有効化する手順:
Content Server (http://WCCHOST1:16200/cs)にログインします。
「管理」トレイまたはメニューを開いて、「管理サーバー」を選択します。
「コンポーネント・マネージャ」をクリックします。
ImagingRepositoryコンポーネントを有効にします。
WebCenter Contentクラスタ内のすべての管理対象サーバーを再起動します。
Content Serverでデフォルトのファイル・ストアをアップグレードする手順:
Content Server (http://WCCHOST1:16200/cs)にログインします。
「管理」トレイまたはメニューを開いて、「プロバイダ」を選択します。
「DefaultFileStore」の「情報」リンクをクリックします。
「編集」をクリックし、「更新」をクリックします。
クラスタ内のすべてのコンテンツ・サーバーを再起動します。
WLS_Imaging1およびWLS_Imaging2管理対象サーバー(それぞれ、WCCHOST1VHN1およびWCCHOST2VHN1)のImagingサーバーのリスニング・アドレスをWebCenter Contentで許可されたホストのリストに追加する手順は、次のとおりです。
ファイル/u01/app/oracle/admin/domainName/ucm_cluster/config/config.cfgを編集して、次の行を削除またはコメント・アウトします。
SocketHostAddressSecurityFilter=127.0.0.1|0:0:0:0:0:0:0:1
WLS_Imaging1およびWLS_Imaging2リスニング・アドレスをWebCenter Contentに接続できるアドレスのリストに含めるために、次の2行を追加します。
SocketHostNameSecurityFilter=localhost|localhost.mydomain.com|wcchost1vhn1|wcchost2vhn1 AlwaysReverseLookupForHost=Yes
変更を有効にするには、WebCenter Content管理対象サーバーを再起動します。
Content Serverへの接続手順は次のとおりです。
http://WCCHOST1:16200/ imagingから、WLS_Imaging1イメージング・コンソールにログインします。
左側のペインで、「接続の管理」→「Content Server接続の作成」をクリックします。
新しい接続の名前と説明を入力し、「次へ」をクリックします。
「接続設定」画面で、次の操作を実行します。
「ローカルContent Serverの使用」が選択されていることを確認します。
Content Serverポートを4444に設定します。
2つのサーバーを「Content Serverプール」に追加します。
WCCHOST1:4444
WCCHOST2:4444
「次へ」をクリックします。
「接続セキュリティ」画面で、WebLogicユーザーに対するデフォルトの選択をそのまま受け入れて、「次へ」をクリックします。
接続の詳細を確認し、「送信」をクリックします。
ImagingからBPEL PMシステムに接続する場合、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 PMシステムへの接続に使用する資格証明です。これをBPEL PM管理ユーザーにします。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 PM接続定義の「資格証明別名」プロパティに使用される「alias」です(APIのConnection.CONNECTION_BPEL_CSFKEY_KEYプロパティにも使用されます)。OWSMおよびBPEL PMで使用される標準のデフォルト名であるため、この例では別名「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 PM接続を構成する手順は次のとおりです。
http://WCCHOST1VHN1:16000/imagingから、WLS_Imaging1イメージング・コンソールにログインします。
左側のペインで、「接続の管理」→「ワークフロー接続の作成」をクリックします。
「BPEL接続の作成」をクリックします。
BPEL PMマシン名、およびオプションで説明を入力します。
「次へ」をクリックします。
「接続設定」画面で、次の操作を実行します。
プロバイダ名フィールドに、2つのSOAサーバー・リスニング・アドレスをカンマで区切って入力します: SOAHOST1VHN2, SOAHOST2VHN1
BPELポートを指定します: 8001
ターゲットBPEL PMシステムに必要な場合、「SSL」オプションを選択します。
「BPEL CSF資格証明の構成」の項で作成した資格証明の別名を指定します。
「接続のテスト」ボタンをクリックして、接続パラメータを確認し、BPEL PMマシンに存在するコンポジットを確かめます。
「次へ」をクリックします。
必要に応じて、付与するセキュリティを変更します。
「次へ」をクリックしてから、「送信」をクリックします。
Oracle WebLogic Server ImagingクラスタのフロントエンドHTTPホストおよびポートを設定する必要があります。
管理コンソールにログインします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「ドメイン構造」ウィンドウで、「環境」ノードを開きます。
「クラスタ」をクリックします。
「Imaging_Cluster」を選択します。
「HTTP」タブをクリックします。
次の値を設定します。
フロントエンド・ホスト: wcc.example.com
フロントエンドHTTPSポート: 443
フロントエンドHTTPポート: 80 (SSLを使用しない場合)
「保存」をクリックします。
管理コンソールの「チェンジ・センター」セクションで「変更のアクティブ化」をクリックします。
サーバーを再起動して、クラスタ内のフロントエンド・ホスト・ディレクティブを有効化します。
この項では、Imaging管理対象サーバーのサーバー移行を構成する方法について説明します。
次の手順では、Imaging管理対象サーバーのサーバー移行を有効にします。これにより、サーバーまたはプロセスの障害時に、Imaging管理対象サーバーは別のノードにフェイルオーバーできます。
Imaging管理対象サーバーに対してサーバー移行を構成する手順は次のとおりです。
ステップ1: サーバー移行leasing表のユーザーと表領域を設定する
ステップ2: 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データベース接続のテスト」ページで、接続パラメータを確認して、「すべてのリスナーのテスト」をクリックします。
管理サーバーからデータベースへの接続を作成できるかどうかが試行されます。接続試験の結果がページ最上部に表示されます。テストに失敗した場合は、構成エラーをすべて修正してテストを再試行します。
「次へ」をクリックします。
「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」を選択します。
|
注意: リース表のマルチ・データ・ソースを作成する場合は、名前をMultiDS-rac0やMultiDS-rac1などの形式で入力します。 |
「次へ」をクリックします。
「グローバル・トランザクションのサポート」の選択を解除します。「次へ」をクリックします。
leasingスキーマのサービス名、データベース名(racdb1やracdb2などのRACノードのインスタンス名)、ホスト・ポートおよびパスワードを入力します。
「次へ」をクリックします。
「構成のテスト」をクリックして、接続が機能しているかどうかを確認します。「次へ」をクリックします。
データ・ソースをクラスタにターゲット指定します。
データ・ソースを選択して、右の画面に追加します。
Oracle RACデータベースの2番目のインスタンスについて「新しいデータ・ソースの作成」をクリックして、そのターゲットをクラスタに設定してから、Oracle RACデータベースの2番目のインスタンスについても同じ手順を繰り返します。
2つ目のデータ・ソースをマルチ・データ・ソースに追加します。
保存して、「変更のアクティブ化」をクリックします。
最後の手順は、サーバー移行をテストすることです。サーバー移行が適切に機能していることを確認するには、次の手順を実行します。
WCCHOST1から次の処理を実行します。
管理対象サーバーWLS_Imaging1を停止します。
WCCHOST1> kill -9 pid
pidには、管理対象サーバーのプロセスIDを指定します。次のコマンドを実行すると、ノード内のpidを確認できます。
WCCHOST1> ps -ef | grep WLS_Imaging1
|
注意: Windowsの場合は、
taskkill /f /pid pid
pidは、管理対象サーバーのプロセスIDを表します。 管理対象サーバーのプロセスIDを調べるには、次のコマンドを実行して、管理対象サーバーWLS_Imagingのpidを確認します。 MW_HOME\jrockit_160_20_D1.0.1-2124\bin\jps -l -v |
ノード・マネージャ・コンソールに、WLS_Imaging1の浮動IPが無効になったことを示すメッセージが表示されます。
ノード・マネージャがWLS_Imaging1の2回目の再起動を試行するのを待ちます。この再起動を試行するまでに30秒間待機します。
ノード・マネージャがサーバーを再起動した後で、そのサーバーをもう一度停止します。サーバーが再びローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されるようになります。
WCCHOST2から次の処理を実行します。
ローカルのノード・マネージャのコンソールを確認します。WCCHOST1で、最後にWLS_Imaging1の再起動が試行されてから30秒経過した後、WCCHOST2のノード・マネージャによって、WLS_Imaging1の浮動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 Oracle WebCenter Contentのマネージング』を参照してください。
前の構成で作成されたすべてのInbound Refineryは、WebCenter ContentまたはRecordsクラスタに追加することをお薦めします。そうすることで多対多の関係が構築され、WebCenter ContentクラスタまたはRecordsクラスタのすべてのメンバーは任意の接続先Inbound Refineryサーバーからの変換をリクエストできます。
Inbound Refineryインスタンスは、独自のドメインにインストールすることも、既存のドメインの拡張としてインストールすることもできます。
Inbound RefineryにはOHSを介して1回のみアクセスして、その構成を初期化する必要があります。これは、管理対象サーバーのリスニング・アドレスで直接実行できます。Inbound Refineryは、OHSインスタンスの背後に配置しないでください。
Inbound Refineryへのすべての後続のアクセスは、ソケット・リスナーを介して行われます。
WebCenter Contentユーザー・インタフェース・アプリケーションの高可用性を有効にするには、『Oracle Fusion Middleware Oracle WebCenter Contentエンタープライズ・デプロイメント・ガイド』のWebCenter Contentユーザー・インタフェースのインストールおよび構成に関する項を参照してください。
この項では、Oracle WebCenter Content: Imaging (Imaging)の概要、およびImagingの高可用性環境の設計とデプロイ方法について説明します。
この項の内容は次のとおりです。
Imagingでは、プロセス指向のイメージング・アプリケーションおよびイメージ対応のビジネス・アプリケーションに焦点を当てたスケーラブルなソリューションを提供します。これにより、イメージの注釈およびマークアップの対応、ルーティングおよび承認の自動化、大量のアイテムに対応する高容量アプリケーションのサポートを実現します。
図11-4は、Imagingの内部コンポーネント(Imagingパッケージ内のコンポーネント)を示しています。
Imagingの構成の設定を開始する前に、次の点に注意してください。
Imagingは、Oracle WebCenter Content (WebCenter Content)リポジトリの最上位にある比較的薄い機能層です。Imagingでは、WebCenter Contentでのイメージ・ファサードを提供します。リポジトリによって、リソース利用の大部分が実行されます。そのため、すべてのImagingインスタンスにWebCenter Contentインスタンスを配置することでWebCenter Contentを構成するようにお薦めします。この構成によって、ハードウェアを最適に利用できます。
Imagingの最大のパフォーマンス要素は、ドキュメント・コンテンツの移動です。通常、Imagingは、毎日数十万ものドキュメントを収集するような大容量シナリオで使用されます。これらのドキュメントは、頻繁に検索、取得および表示されます。システム内外とのドキュメント・コンテンツのやりとりは、パフォーマンスに大きく影響します。Imagingでは、平均25KBのサイズのTIFドキュメントを保存しますが、TIFドキュメントには複数のページが含まれていることがあり、それによってドキュメントのサイズは増加します。さらに、Imagingでは、その他にも様々なサイズの400のファイル形式をサポートしています。
この項の内容は次のとおりです。
Imagingは、管理対象サーバー環境で稼働するJava EEアプリケーションです。これには、次のコンポーネントおよびサブコンポーネントが含まれます。
サーブレット: Imagingには、REST APIおよびImagingアプレット・ビューアがシステムのパブリックAPI関数にアクセスするメカニズムを提供する、内部で使用するためのサーブレットがあります。
EJB: Imagingでは、内部的にいくつかのEJBの概念を利用していますが、外向きのEJBはありません。
JMSを使用してその入力エージェントとそのBPELエージェント・メッセージ駆動Bean(MDB)の両方を駆動します。図11-4で、BPELエージェントはBPEL MDBの集合です。これらのキューは永続するため、配信が保証され、クラスタ間でも作業が配信されます。
JAX-WSおよびJAX-Bを使用して、そのWebサービスおよびシリアライズ・メカニズムを実装します。
定義の保存および構成にTopLinkを使用します。この目的は、一般的にはアプリケーションおよび検索を定義することです。また、TopLinkはユーザーおよびシステム・プリファレンスの取得にも使用されます。
リポジトリからのドキュメントの取得や表示するドキュメントの処理に内部キャッシュとしてJava Object Cache (JOC)を使用します。これらのキャッシュはローカルにのみ存在します。
AXFとBPEL PM間の相互作用は、EJBを介してRMIを使用するBPEL PMリモートAPIによって実行されます。
|
注意: Imagingでは、複数コンポーネントのトランザクションをサポートしないため、Java Transaction API (JTA)を使用しません。 |
この項の内容は次のとおりです。
ImagingにはステートフルなUIを備えていますが、セッション・レプリケーションをサポートしていないため、スティッキーなロード・バランシング・ルーターが必要になります。
Imaging APIを使用したImagingサービスの呼出しは、ステートレスです。
Imagingのコアでは、中央API、UI、およびOracle Webサービス・インタフェースを含むサービスベースのアーキテクチャを使用します。Oracle Application Development Framework (Oracle ADF)ベースのユーザー・インタフェースでは、ImagingのパブリックAPIを使用して、コア・サービスにアクセスします。エンド・ユーザーは、Oracle Web Servicesを介してこのAPIにアクセスします。Java開発者には、より便利なパッケージでこれらのWebサービスを公開するシンJavaクライアント・ライブラリも提供します。
バックグラウンド処理を実行するImagingエージェントには、次のものがあります。
入力エージェント: インジェストするドキュメントの受信リストの入力ディレクトリを監視します。
BPELエージェント: ドキュメント作成イベントに応答して、そのドキュメントおよびURLからメタデータを含む新しいBPEL PMプロセス・インスタンスをアタッチするドキュメントに作成します。図11-4で、BPELエージェントはBPEL MDBの集合です。
チケット・エージェント: タイマーなしで呼び出されるステートレスのEJBです。これは、図11-4には示されていません。チケット・エージェントは、パラメータを使用しないクリーンなURLを作成するために使用されるURLチケットのうち、有効期限が切れたURLチケットの特定および削除を行います。
Imagingサービスでは、スキャン・ドキュメントの保存にWebCenter Contentドキュメント・リポジトリを使用します。WebCenter Contentリポジトリは、WebCenter Contentで提供されるTCP/IPソケットベース接続メカニズム(Remote Intradoc Client (RIDC))を介してImagingと通信するスタンドアロン製品です。
Imagingは特定の障害検出を提供するものではありませんが、ノード・マネージャを使用して継続的にサーバーを稼働することができます。
Imagingプロセス・ライフサイクルのステップは次のとおりです。
Imagingは、ほとんどの場合、ドメイン構成後に初期化されます。Imagingが起動して最初のユーザーがログオンすると、残りの初期化が実行されます。
最初のユーザーがログオンしたときに、そのユーザーはそれ以降の他のユーザーに権限を付与できるという前提の下で、完全なセキュリティ権限が付与されます。Imagingは、セルフ・シード・データベース・セキュリティ・メカニズムを提供します。Imagingが起動したときにセキュリティが定義されていない場合、システムに最初にログインしたユーザーはすべてのものにアクセスする権限が付与されます。
Imagingが初めて起動した直後は、Imagingは「空」です。WebCenter Contentドキュメント・リポジトリおよびBPEL PMサーバーへの接続は、管理ユーザーの責任で作成します。
最初のWebCenter Content接続が作成されると、Imagingで使用するWebCenter Contentリポジトリは初期化されます。
ここで、アプリケーション、検索、入力などを含む適切なビジネス・オブジェクトを作成する必要があります。管理ユーザーは、ビジネス・オブジェクトをインポートできます。
ステップ1でエージェント・ユーザーが指定された場合、エージェントはサーバーが再起動した後JMSキュー・イベントがその処理を開始するのを待ちます。
サーバーが稼働してJAX-WSメカニズムの準備ができたら、Imagingはクライアント・リクエストを受信できます。
Imagingには、次のような構成アーティファクトがあります。
すべてのImaging構成データは、Imagingデータベースの中に保存されます。構成は、ローカル・ファイルには保存されません。構成パラメータは、適切なMBean (Oracle Enterprise Manager Fusion Middleware ControlまたはWLSTから使用できる)またはImagingユーザー・インタフェースを介して公開されます。
|
注意: 両方のノードのMBean値を変更しても、MBean値は同期されません。最後に行った変更は、サーバーを再起動するとすべてのノードに伝搬するため、異なる値になる場合があります。 たとえば、ノード1 ViewerCacheDaysの値を25に変更し、後でノード2 ViewerCacheDaysの値を20に変更すると、ノード1のユーザーには常に25の値が表示され、ノード2のユーザーには常に20の値が表示されます。最後に設定したのはノード2上の値のため、サーバーを再起動すると、どちらのユーザーにも、両方のサーバー上で20の値が表示されます。 |
定義オブジェクト(第11.3.1.1.5項「Imagingの外部依存性」を参照)。
Imagingでは、WebCenter Contentメカニズムを使用して、WebCenter Contentプロファイルおよび情報フィールドの管理を含め、Imagingで使用するためにWebCenter Contentをカスタマイズします。
Imagingには、次の外部依存性があります。
Imagingには、構成を格納するためのデータベースが必要です。Imaging用のスキーマはRCUによってデータベースに作成され、WebLogic Server JDBCデータ・ソースを介して管理されます。データベースには、TopLinkを介してアクセスします。
Imagingでは、JAX-WS、JAX-B、Oracle ADF、TopLink、JMSなどの様々なOracleおよびJavaテクノロジを活用します。これらはインストールに含まれ、外部構成は不要です。
Imagingには、構成用のMBeanが用意されています。これらは、WLSTおよびFusion Middleware ControlシステムMBeanブラウザを介して使用できます。Imagingには、いくつかのカスタムWLSTコマンドが用意されています。
Imagingは、WebCenter Contentリポジトリが存在するかどうかに依存しています。
クライアントは、次のいずれかを介してImagingに接続します。
WebサービスまたはJavaクライアント用のJAX-WSを介した接続。これらの接続はステートレスで、単一の機能を実行します。
次のような、URLにアクセスするためのHTTPおよびRESTツール。
RESTリクエストはステートレスで、単一の機能を実行します。
URLツールはImaging UIにログインして、関連するUIコンポーネントを含むよりステートフルな体験を提供します。
メッセージはすべて、アプリケーションがデプロイされるWebLogic Serverのサーバー・ログ・ファイルに記録されます。
診断ログ・ファイルのデフォルトの場所は次のとおりです。
MW_HOME/user_projects/domains/domainName/servers/serverName/logs/serverName-diagnostic.log
Oracle Enterprise Manager Fusion Middleware Controlを使用して、これらのログ・ファイルを検索および解析します。
この項では、Imagingを2ノードのクラスタ構成による高可用性で使用する場合の概要について説明します。
図11-5は、Imagingの高可用性アーキテクチャを示しています。
Imagingは、標準的な2ノードのアクティブ/アクティブの高可用性構成で構成できます。ImagingのUI層はアクティブ・サーバー間でフェイルオーバーされませんが、その他のバックグラウンド・プロセスはフェイルオーバーされます。
図11-5は、Imagingの高可用性構成を示しています。
Imagingノードは、お互いに同一なレプリカです。高可用性構成のすべてのノードは、同一のサービスを実行し、中央の構成データベースで構成されます。すべてのサーバーはこのデータベースからその構成を取得します。
Imagingノードのフロントエンドには、スティッキーなセッション・ルーティングを持つロード・バランシング・ルーターを使用する必要があります。この目的のためにOracle HTTP Serverを使用できます。
Imagingは、WebLogic Serverクラスタ内でもクラスタなしでも実行できます。
すべてのImagingインスタンスは、同じデータベース接続を共有する必要があります。そうすることで、Oracle RACの高可用性の潜在機能が高まります。Imagingは、データベース処理にTopLinkを使用します。
Imagingには共通の共有ディレクトリが必要で、入力エージェントはインジェスト用にステージングされたインバウンド・データファイルをここから取得します。入力エージェントが入力定義ファイルを取得すると、関連する入力ファイルおよびイメージの処理は、そのWebLogic Serverインスタンスから分離されます。
Imagingのエージェント(入力エージェント、BPELエージェント)は、クラスタ内の管理対象サーバーに存在するImagingアプリケーションの不可欠な機能として起動します。JMSキューの未処理の作業(これらは障害を越えて永続的に保存されます)に基づいて、すぐに処理が開始されます。入力エージェントは、インバウンド・ファイル・ディレクトリでも作業を検索します。処理対象のファイルがある場合、それらは対応するJMSキューにプッシュされ、クラスタ内のサーバーはそれを使用して関連するイメージを処理します。WebLogic Serverワークロード・マネージャは、BPELエージェントおよび入力エージェント専用のスレッドの数を制御します。
クラスタ内のサーバーが停止すると、エージェントはそのアクティビティを終了します。BPELエージェントの実行サイクルは短く、すべての処理はシャットダウン前に完了することが見込まれます。進行中のBPEL PM呼出しは3回再試行され、JMSログは保留中の操作を保存します。入力エージェントは大規模なサイズのファイルを処理できます(大きな入力ファイルの場合、処理に数時間かかる場合があります)。停止後に保留された作業の量は、関連するJMS永続ストアに保存されます。入力エージェントをホストするサーバーを再起動すると、エージェントは残されていた処理を開始します。イメージ・ファイルの処理は、再起動またはサーバーの移行後に、対応する入力ファイルを最初に使用するサーバーで継続されます。
Imagingの高可用性構成を障害から保護するには、次の手順を実行します。
Imagingノードのフロントエンドには、スティッキーなセッション・ルーティングを持つロード・バランシング・ルーターを使用します。この目的のためにOracle HTTP Serverを使用できます。
Imagingでアップロードまたは取得される表示用のドキュメントのサイズに基づいて、ロード・バランシング・ルーターのタイムアウトを構成します。
また、次の機能もImagingの高可用性構成を障害から保護します。
JMSフェイルオーバーは、WebLogic ServersのJMS実装で提供されます。
TopLinkには、データベースの再試行ロジックが用意されています。
WebCenter Contentに接続する際に、ネットワーク障害の解決をすぐに再試行するために、再試行ロジックが存在します。Imagingには、クラスタ内の他の管理対象サーバーを検索するフェイルオーバー・メカニズムが用意されています。ImagingとWebCenter Contentの間にロード・バランサを使用して、ロード・バランシング/フェイルオーバーの目的を実現できます。
BPELに接続する際に、Imagingは即座に再試行を実行します。タイムアウト時間(5分間)を超えたら失敗したアイテムを関連する再試行用のJMSキューに押し戻します。このJMS再試行メカニズムは、3回実行されます。失敗し続けるオブジェクトは、ユーザー操作用の保存キューに格納されます。
APIレベル統合(JPSなど)は再試行されず、内部的な再試行ロジックで処理されます。
ノード障害
Imagingノードで障害が発生すると、そのノードのエージェント・プロセスに影響します。未完了のトランザクションは、廃棄されて失われます。フェイルオーバー時に、そのノードの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と統合します。Oracle SOA Suite管理対象サーバーが停止した場合、Imagingに障害があります。Imagingでは、再試行が3回行われます。それぞれの試行を繰り返す前に、構成可能な遅延時間が後に続きます。3回の試行の後もアクションが完了できない場合、これらのリクエストはデータベース表のキューに格納され、後で再送信されます。再送信は、WLSTコマンドを使用して実行します。
ImagingはOracle WebCenter Portalに依存していません。その他のOracle ADFアプリケーションは、Imagingの操作には影響しません。
Imaging UIでは、接続先となる管理対象サーバーのリストを指定できます。これは、プライマリ・サーバーを使用して、複数のセカンダリ・サーバーに接続して指定できます。プライマリ管理対象サーバーで障害が発生すると、Imagingはリストの次の管理対象サーバーを再試行します。すべての管理対象サーバーが停止した場合、例外が返され、Imagingサーバーのログにトレースされます。
検索、入力、アプリケーション(すべてImaging構造構成)は、Imagingデータベースの中に保存されます。これらは、Web UI層を含め、クラスタ内のすべてのマシンですぐに使用可能になります。新しいエントリがクラスタ内の別のImagingサーバーまたは別のユーザー・セッションの同じサーバーで作成された場合、Web UIは自動的にはリフレッシュしませんが、Webブラウザをリフレッシュしてイメージ・アプリケーションのナビゲーション・バーをリフレッシュすることはできます。
この項では、高可用性環境でImagingサーバー、アドバンスト・ビューア、入力エージェントをトラブルシューティングする方法について説明します。
Imagingのトラブルシューティングの詳細は、『Oracle Fusion Middleware Oracle WebCenter Content: Imagingの管理』を参照してください。
Imagingサーバーのトラブルシューティング
Imagingは、WebLogic Server上にデプロイされたJava EEアプリケーションです。ログ・メッセージはすべて、アプリケーションがデプロイされるWebLogic Serverのサーバー・ログ・ファイルに記録されます。
診断ログ・ファイルのデフォルトの場所は次のとおりです。
MW_HOME/user_projects/domains/domainName/servers/serverName/logs/serverName-diagnostic.log
Oracle Enterprise Manager Fusion Middleware Controlを使用して、これらのログ・ファイルを簡単に検索および解析できます。
アドバンスト・ビューアのトラブルシューティング
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 Enterprise Capture (Capture)の概要およびCaptureの高可用性環境の設計とデプロイ方法について説明します。
この項の内容は次のとおりです。
Captureの追加情報については、次のガイドを参照してください。
Oracle Fusion Middleware Oracle WebCenter Enterprise Captureのアドミニストレーション
Oracle Fusion Middleware Oracle WebCenter Contentエンタープライズ・デプロイメント・ガイド
Oracle Fusion Middleware Oracle WebCenter Contentの理解
WebCenter Enterprise Captureは、プロセス指向のイメージング・アプリケーションやイメージ対応のエンタープライズ・アプリケーションを中心に、拡張性の高いドキュメント・キャプチャを提供します。集中環境および分散環境向けのWebインタフェースが用意されており、紙ドキュメントと電子ドキュメントのキャプチャ・プロセスを合理化できます。Oracle ImagingおよびOracle WebCenter Contentとの完全な統合により、重要なビジネス・コンテンツのキャプチャ、格納、管理、取得の各機能を単一のシステムで企業に提供します。
Captureの詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentの理解』のOracle WebCenter Captureについてに関する項を参照してください。
図11-6は、Captureの内部コンポーネント(Captureパッケージ内のコンポーネント)を示しています。
WebCenter Captureは、WebLogic Server管理対象サーバー環境で稼働するJava EEアプリケーションです。Captureコンポーネントおよびサブコンポーネントには、次のものが含まれます。
クライアント・アプレット: エンドユーザーは、Captureクライアントを使用して、キャプチャ・ワークスペース内のバッチの作成、ドキュメントのスキャン/インポート、ドキュメントの索引付けを行います。
クライアント・サービス: クライアント・アプレットがCaptureサーバーとの通信に使用する内部のRESTful Oracle Web Services。
ワークスペース・コンソール: ワークスペース・マネージャがワークスペース内のCapture要素の構成に使用するWebアプリケーション。
MBean: システム管理者は、Oracle Enterprise Manager Fusion Middleware ControlおよびWeblogic WLSTコマンドでCaptureのマネージドBeanを使用して、Captureアプリケーションの構成および管理を行います。
Captureコア: Captureアプリケーションのコア・システム・ロジックを表すJava Enterprise Bean (EJB)。Captureコアでは、アプリケーションのセキュリティ管理にOracle Platform Security Services (OPSS)を使用します。また、Captureは、外部システムのセキュリティ資格証明を安全に管理するために、Oracle資格証明ストア・フレームワーク(CSF)を使用します。
Captureデータ・モデル: Captureの構成、メタデータ、およびドキュメントのバッチはすべてデータベース内で管理されます。Captureデータ・モデルでは、Captureアプリケーションのデータ・レイヤーの管理にEclipseLink JPAを使用します。
メッセージドリブンBean (MDB): Captureアプリケーションは、システムおよびバッチの操作を実行するために、複数のJMSキューを使用します。Capture JMSキューは永続的であり、クラスタ全体で分散と移行をサポートする必要があります。
Captureのセッションは、Cookie情報を除いてほぼステートレスです。そのため、クラスタ環境のCaptureでは、ロード・バランサを経由したスティッキー・セッションが必要になります。
Captureは、サービスベースのアーキテクチャを採用しています。クライアント・アプレットは、JAX-RSを使用してCaptureコアのサービスを実行します。Captureアプリケーション内のJMSキューおよび実行中のMDBによって、数多くの操作がバックグラウンドで実行されます。
Captureのバックエンド・プロセッサには、次のものが含まれます。
コミット・プロセッサ: WebCenter Content、Imagingまたはファイル・システムに対して、バッチをコミットします。
認識プロセッサ: ドキュメントの編成および索引付けのために、バッチのバー・コードおよびパッチ・コード認識を実行します。
ドキュメント変換プロセッサ: イメージ以外のドキュメントをイメージ形式に変換します。
インポート・プロセッサ: 電子メール、ファイル・システム・フォルダ、リスト・ファイルから、自動的にドキュメントをインポートします。
アウトバウンド電子メール: Captureアプリケーションから電子メールを送信します。
Captureは、管理対象サーバーとして起動および停止できます。
Captureプロセスのライフサイクルのステップは次のとおりです。
Captureアプリケーションを起動すると、その構成がCaptureによって初期化されます。
Captureが初めて起動した直後は、Captureは「空」です。ユーザーがキャプチャ・ワークスペースを作成できるように、システム管理者はキャプチャ・ワークスペース・マネージャ権限をユーザーに付与する必要があります。
ユーザーがキャプチャ・ワークスペースを作成すると、ワークスペース・マネージャによって、ワークスペース内のユーザー・アクセス、メタデータ、クライアント・プロファイルおよびプロセッサ・ジョブが定義されます。
アプリケーションが完全に初期化された後、JMSイベントを処理するプロセッサが使用可能になります。
クライアント・プロファイルが定義されると、ユーザーはクライアント・アプレットを使用して、システムにドキュメントをキャプチャできるようになります。
コミット・プロファイルがワークスペース内で定義されると、WebCenter Content、Imagingまたはファイル・システムに対して、Captureからドキュメントをコミットできるようになります。
Captureのすべての構成データはCaptureデータベースに格納されます(構成はローカル・ファイルには保存されません)。システム構成パラメータは、適切なMBean (Oracle Enterprise Manager Fusion Middleware ControlまたはWLSTコマンドから使用できる)によって公開されます。キャプチャ・ワークスペースは、メタデータ、構成プロファイル、処理ジョブ、およびすべてのバッチとドキュメント・データを含む完全なキャプチャ環境です。
Captureには、次の外部依存性があります。
構成を格納し、バッチとドキュメントを保持するためのデータベース。データベース内のCaptureのスキーマは、Oracleリポジトリ作成ユーティリティ(RCU)によって作成され、管理対象サーバーJDBCデータ・ソースを介して管理されます。CaptureからデータベースへのアクセスにはEclipseLinkを使用します。
高可用性環境では、Oracle DatabaseまたはOracle Internet Directory (OID)を使用するために、OPSSポリシー・ストアを構成する必要があります。
Captureが使用するJNDIリソースは、それぞれのCaptureサーバーで同じ構成にする必要があります。たとえば、キャプチャ・ワークスペースに定義されているデータベース選択リストとデータベース参照で、JNDI参照を使用して、これらの外部データベース・リソースにアクセスするとします。その場合、キャプチャ・ワークスペースによって使用されるJNDIリソースは、クラスタ内のすべてのサーバーから使用できる必要があります。
インポート・プロセッサ・ジョブは、電子メール、フォルダ、リスト・ファイルからドキュメントをインポートします。次の要件に注意してください。
電子メール・サーバー: クラスタ内のすべてのCaptureサーバーは、電子メール・サーバーにアクセスできる必要があります。
フォルダおよびリスト・ファイル: フォルダからインポートする場合、インポート・ジョブで定義するフォルダ・パスは、クラスタ内のすべてのCaptureサーバーからアクセスできる必要があります。ここでは、すべてのサーバーからアクセスできる共通のネットワーク共有を使用することをお薦めします。ローカル・パスを使用する場合は、すべてのCaptureサーバーがクラスタ内に存在している必要があります。
WebCenter ContentおよびImaging: Captureでは、キャプチャ・ワークスペース内にあるコミット・プロファイルがWebCenter ContentおよびImagingに対する接続情報を定義します。バッチ・コミットを実行するすべてのCaptureサーバーは、同じ接続情報を使用して、Oracle WebCenter Content ServerおよびImagingにアクセスします。
Imaging: クラスタ内に構成されている場合、Oracle HTTP Server URLを使用してImagingにアクセスします。
Content Server: クラスタ内に構成されている場合、LBR URLを使用してWebCenter Contentにアクセスします。
ファイル・システムのコミット: ファイル・システムに対してドキュメントをコミットするように、Captureコミット・プロファイルを構成できます。バッチ・コミットを実行するすべてのCaptureサーバーは、コミット・プロファイルに定義されているファイル・システム・リソースにアクセスできる必要があります。
Captureクライアント・アプレット: JAX-RSを使用してCaptureに接続します。WebLogic Serverの構成では、クライアント・アクセスにSSLを使用することをお薦めします。
この項では、Captureを2ノードのクラスタ構成による高可用性で使用する場合の概要について説明します。この項では、次の項目について説明します。
図11-5は、Captureの高可用性構成アーキテクチャを示しています。
Captureは、標準的な2ノードのアクティブ/アクティブの高可用性構成で構成できます。クラスタ内でセッション・レプリケーションを有効にしている場合は、Captureクライアント・アプレットの自動フェイルオーバーがサポートされます。
図11-5は、Captureの高可用性構成を示しています。
Captureノードは、お互いに同一なレプリカです。高可用性構成のすべてのノードは、同一のサービスを実行し、Captureデータベースで構成されます(すべてのサーバーはこのデータベースから構成を取得します)。
Captureノードのフロントエンドには、スティッキーなセッション・ルーティングを持つロード・バランシング・ルーターを使用する必要があります。セッションには、認証情報よりさらにスティッキーな状態データは不要です。この目的のためにOracle HTTP Server (OHS)を使用できます。
すべてのCaptureインスタンスは、同じデータベースを共有する必要があります。システムの高可用性をさらに向上するために、Oracle RAC高可用性データベースの使用をお薦めします。
Captureのバッチ・プロセッサ(インポート、ドキュメント変換、認識およびコミット)は、クラスタ内の管理対象サーバーに存在するCaptureアプリケーションの必須機能として起動します。JMSキューの未処理の作業(これらは障害を越えて永続的に保存されます)に基づいて、バッチ・プロセッサがすぐに処理を開始します。
次の機能は、Captureシステムの障害からの保護に役立ちます。
外部ロード・バランサを使用することで、ロード・バランシングおよびクライアント・フェイルオーバーを実現できます。セッションには、認証情報よりさらにスティッキーな状態データは不要です。
|
注意: アップロードまたは取得するドキュメントのサイズに基づいて、ロード・バランシング・ルーターのタイムアウトを構成します。 |
WebLogic Serverセッション・レプリケーションの使用により、アクティブ・ノードに対してCaptureクライアントおよびCaptureコンソール・ユーザーのシームレスなフェイルオーバーがサポートされます。
管理対象サーバーのJMS移行機能を使用して、JMSのフェイルオーバーが可能です。
Captureバッチ・プロセッサは処理の状態情報を保持しているため、ノードやシステムの外部依存性の障害が発生しても、システムを中断することなくリカバリできます。
EclipseLinkには、データベースの再試行ロジックが用意されています。
Captureデータベースには、キャプチャ・ワークスペースと、ワークスペース内のすべての要素が格納されます。他のCaptureユーザーが要素を新規作成したり、要素を変更した場合、WebCenterコンソールのUIは自動的に更新されません。Captureクライアントで新しく追加されたクライアント・プロファイルを表示するには、ユーザーが各自のブラウザを更新する必要があります。
この項では、高可用性環境でのCaptureサーバーのトラブルシューティング方法について説明します。Oracle WebCenter Enterprise Capture管理者ガイドを参照してください。
WebCenter Captureは、WebLogic Server上にデプロイされるJava EEアプリケーションです。ログ・メッセージはすべて、アプリケーションがデプロイされる管理対象サーバーのサーバー・ログ・ファイルに記録されます。
診断ログ・ファイルのデフォルトの場所は次のとおりです。
MW_HOME/user_projects/domains/domainName/servers/serverName/logs/serverName-diagnostic.log
Oracle Enterprise Manager Fusion Middleware Controlを使用して、これらのログ・ファイルの検索および解析とシステム・パフォーマンスの監視を行います。Captureでは、Oracle DMS APIを使用してパフォーマンス・メトリックのトラッキングを行います。
この項では、Captureの高可用性の構成手順について説明します。Captureの構成は次の手順で行います。
Captureクラスタの構成手順は、若干の違いはありますが標準クラスタの手順とほぼ同じです。Captureクラスタを構成する場合、第11.2.3.3項「高可用性のドメインの作成」の手順に従い、次の部分を変更します。
CaptureのOHSを構成するには、次の行をOHS_HOME/instances/ohs_instance1/config/OHS/ohs1/mod_wl_ohs.confファイルに追加します。Oracle HTTP ServerはWEBHOST1上にインストールする必要があります。
# Capture <Location /dc-console> SetHandler weblogic-handler WebLogicCluster adc6170643:16400,adc2120608:16400 WLCookieName JSESSIONID </Location> <Location /dc-client> WebLogicCluster adc6170643:16400,adc2120608:16400 SetHandler weblogic-handler WLCookieName JSESSIONID </Location>
フロントエンドHTTPのホストおよびポートを設定するには、第11.2.9.5項「フロントエンドHTTPのホストおよびポートの設定」の手順に従い、手順5でCapture_Clusterを選択します。
WebCenter Contentクラスタの場合、ロード・バランサURLはWebCenter Content管理対象サーバーのフロントエンドになるように構成されます。
WebCenter Content接続を設定するには、WebCenter ContentクラスタのRemote Intradoc Client (RIDC)ロード・バランサのURLを入力します。WebCenter Contentリポジトリはスタンドアロン製品で、Captureは、シン通信APIを提供するRIDCを使用して通信します。『Oracle Fusion Middleware Oracle WebCenter Contentでの開発』のRemote Intradoc Clientの概要に関する項を参照してください。
次の各トピックでは、WebCenter Content接続とImagingを構成する方法を説明します。
Captureに対するWebCenter Content接続の構成
Captureに対するWebCenter Content接続の構成
Captureワークスペース・コンソールの「コミット」ページに移動します。
「新規コミット・プロファイルの作成」を選択します。
「一般設定」ページで、次の手順を実行します。
「コミット・プロファイル名」を入力します。
「コミット・ドライバ」メニューから「WebCenter Content」を選択します。
「ドキュメント出力書式」メニューからオプションを選択します。
該当する場合、「コミットをドキュメント・プロファイルに制限」オプションを選択します。
「次へ」を選択します。
「コミット・ドライバ設定」ページで、次の手順を実行します。
ImagingサーバーのユーザーIDとパスワードを入力します。
「Imaging WebService URL」フィールドに、次の書式でRIDCのロード・バランサURLを入力します。
idc:wcc-aa-capture.us.example.com:ポート番号
|
注意: WebCenter Contentでは、通常、RIDCプロトコルはポート4444を使用します。 |
「接続」を選択し、管理対象サーバーに接続します。
「ステータス」フィールドで接続のステータスを確認します。
Captureに対するImaging接続の構成
Captureに対するImaging接続を構成する手順:
Captureワークスペース・コンソールの「コミット」ページに移動します。
「新規コミット・プロファイルの作成」を選択します。
「一般設定」ページで、次の手順を実行します。
「コミット・プロファイル名」を入力します。
「コミット・ドライバ」として「WebCenter Content Imaging」を選択します。
「ドキュメント出力書式」メニューからオプションを選択します。
該当する場合、「ドキュメント・プロファイル」を選択します。
「次へ」を選択します。
「コミット・ドライバ設定」ページで次を入力します。
ImagingサーバーのユーザーIDとパスワードを入力します。
「Imaging WebService URL」を次の書式で入力します。
http://WebLogic Server:Imagingポート番号/imaging/ws
「接続」を選択し、Imagingサーバーに接続します。
「ステータス」フィールドで接続のステータスを確認します。
ポリシー・ストアを構成するには、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』のOPSSセキュリティ・ストアの構成に関する項を参照してください。
Captureのサーバー移行を構成するには、第11.2.9.6項「Imaging管理対象サーバーのサーバー移行の構成」の手順に従ってください。
Oracle RACデータベース接続などの一部のリソースでは、フェイルオーバーが短時間で済みます。失敗したインスタンスをオンラインに戻して、バッチ・コミットが再試行されるようにするには、「再配信の制限」の値を増やす必要があります。「再配信の制限」のデフォルト値は-1です。「再配信の制限」の値は、MaxBatchProcessingAttemptsの値(デフォルトは5)よりも大きくする必要があります。Enterprise Manager Fusion Middleware ControlのMBeanブラウザを使用して、MaxBatchProcessingAttemptsの値を構成します。
「再配信の制限」の値を増やす手順:
管理コンソールにログインします。
「ドメイン構造」ウィンドウで、「サービス」ノードを開いて「JMSモジュール」をクリックします。
「チェンジ・センター」で「ロックして編集」をクリックします。
capture-jms-moduleをクリックします。
capture-commitprocessorを選択して、「配信の失敗」タブをクリックします。
新しい値を「再配信の制限」フィールドに入力します。値は、MaxBatchProcessingAttemptsの値(デフォルトは5)よりも大きくする必要があります。
