Oracle® Fusion Middleware Oracle WebCenter Contentエンタープライズ・デプロイメント・ガイド 11g リリース1 (11.1.1) B66703-06 |
|
![]() 前 |
![]() 次 |
この章では、トポロジの設定後に実行できる操作について説明します。実行できる操作には、トポロジの監視、スケーリング、バックアップなどがあります。
この章には次の項が含まれます:
第19.3項「Oracle WebCenter Contentエンタープライズ・デプロイメント・トポロジ内でのコンポジットおよびアーティファクトのデプロイ」
第19.9項「Oracle WebCenter Contentエンタープライズ・デプロイメントにおけるバックアップとリカバリの実行」
第19.12項「Oracle WebCenter ContentとImagingサービスで使用するOracle Web Service Managerのセキュリティ・ポリシーの構成」
第19.13項「Oracle WebCenter Contentエンタープライズ・デプロイメント・トポロジのトラブルシューティング」
Oracle WebCenter Contentエンタープライズ・デプロイメントを構成したら、この章の情報を使用してトポロジを管理できます。表19-1に、トポロジを管理するために実行できるタスクを示します。
表19-1 Oracle WebCenter Contentトポロジを管理するためのタスク
タスク | 説明 | 詳細 |
---|---|---|
Imagingクラスタにおいて高いパフォーマンス、スケーラビリティおよび高可用性を実現するためのImagingの構成 |
入力ファイルを最適化する戦略を定義します。 |
第19.2項「Imagingの入力ファイルを最適化する戦略の定義」 |
Imagingで使用するOracle SOA Suiteサブシステムの管理 |
SOAコンポジットをサーバーのアドレスにデプロイし、Oracle SOA Suiteインフラストラクチャ内の領域を管理し、UMSドライバを構成します。 |
第19.3項「Oracle WebCenter Contentエンタープライズ・デプロイメント・トポロジ内でのコンポジットおよびアーティファクトのデプロイ」 第19.4項「SOAインフラストラクチャ・データベースでの領域の管理」 第19.5項「Oracle WebCenter Content: ImagingのUMSドライバの構成」 |
スケール・アップまたはスケール・アウトによるトポロジの拡張 |
ノードに新しい管理対象サーバーを追加するか、または新しいノードを追加します。 |
第19.6項「Oracle WebCenter Contentトポロジのスケール・アップ」 第19.7項「Oracle WebCenter Contentトポロジのスケール・アウト」 |
構成の変更前後におけるトポロジのバックアップ |
ディレクトリおよびファイルをバックアップし、構成の変更によって発生する障害から保護します。 |
第19.9項「Oracle WebCenter Contentエンタープライズ・デプロイメントにおけるバックアップとリカバリの実行」 |
接続タイムアウトの防止 |
データベース接続がタイムアウトしないようにファイアウォールを構成します。 |
|
Oracle WebCenter ContentとOracle WebCenter Content: ImagingのWebサービスで使用するOracle Web Service Manager (Oracle WSM)のセキュリティ・ポリシーの構成 |
HTTP基本認証のかわりに適切なOracle WSMポリシーを適用します。 |
第19.12項「Oracle WebCenter ContentとImagingサービスで使用するOracle Web Service Managerのセキュリティ・ポリシーの構成」 |
問題のトラブルシューティング |
トポロジの構成後に発生する可能性のある既知の問題の解決方法を実施します。 |
第19.13項「Oracle WebCenter Contentエンタープライズ・デプロイメント・トポロジのトラブルシューティング」 |
Oracle WebCenter Contentの管理の詳細は、次のドキュメントを参照してください。
Oracle Fusion Middleware Oracle WebCenter Captureの管理
Oracle Fusion Middleware Oracle WebCenter Contentの管理
Oracle Fusion Middleware Oracle WebCenter Content: Imagingの管理
Oracle Fusion Middleware Oracle WebCenter Contentの管理
入力ファイルは、入力エージェントがスケジュール設定および処理できる作業の最小単位です。Imagingクラスタにおいて最高のパフォーマンス、スケーラビリティ、および可用性を実現するために、いくつかの考慮事項があります。
Imagingクラスタ内のすべてのマシンは、共通の入力ディレクトリを共有します。
このディレクトリからの入力ファイルは、JMSキューを介してそれぞれのマシンに配信されます。
このディレクトリをポーリングして新しいファイルを調べる間隔は構成可能です。
各マシンには、入力ファイルを処理する解析エージェントが複数あります。解析エージェントの数は、Imagingデプロイメント内で作成されたワーク・マネージャを使用して構成されます。
次のような場合に最適なパフォーマンスを実現できます。
それぞれの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ドキュメントの処理が完了するようになります。また、一方のサーバーで障害が発生した場合、処理が正常に終了するまでもう一方のサーバーで解析エージェントに残っている処理を続行できます。
Imagingによって使用されているOracle SOA SuiteサブシステムにSOAコンポジットをデプロイする場合は、ロード・バランサのアドレス(wcc.mycompany.com
)ではなく、特定のサーバーのアドレスにデプロイします。ロード・バランサ・アドレスにデプロイするには、デプロイヤ・ノードから外部のロード・バランサ・アドレスへの直接接続が必要になることがあり、その接続のために、システムのファイアウォールで追加ポートを開く必要が生じる場合があります。
すべてのコンポジットでデータベースが頻繁に使用されるわけではありませんが、サービス・エンジンは大量のデータをCUBE_INSTANCE
スキーマとMEDIATOR_INSTANCE
スキーマで生成します。データベース領域が不足すると、SOAコンポジットが機能しなくなることがあります。Oracle Enterprise Manager Fusion Middleware Control(ダッシュボードなど)で、oracle.fabric.common.FabricInvocationException
のような一般的なエラーがないかどうか監視してください。Oracle SOA Suiteサーバーのログについても、次のようなエラーがないかどうか検索します。
Error Code: 1691 ... ORA-01691: unable to extend lob segment SOAINFRA.SYS_LOB0000108469C00017$$ by 128 in tablespace SOAINFRA
これらのメッセージは、通常、データ・ファイルの追加や既存のファイルへの領域の追加を必要とする、データベースの領域の問題を示します。SOAデータベース管理者は、領域の追加で使用される拡張ポリシーとパラメータを決定する必要があります。また、古いコンポジット・インスタンスを消去してSOAインフラストラクチャ・データベースのサイズを縮小することもできます。Oracle Enterprise Manager Fusion Middleware Controlのこのような操作への使用は、ほとんどの場合、トランザクション・タイムアウトが発生するのでお薦めできません。
提供されるSQLパッケージに含まれている可能性のある操作の詳細は、Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイドのSOAコンポジット・アプリケーションの管理とデプロイに関する項を参照してください。正しく消去するには、提供されているスクリプトを常に使用します。composite_dn
表からのみ行を削除すると、Oracle Fusion Middleware SOAインフラストラクチャが使用するその他の表の参照が解決されなくなる場合があります。
UMSドライバの構成情報は、Oracle SOA Suiteクラスタに自動的には伝播されません。Oracle WebCenter Content: Imagingによって起動されるOracle SOA SuiteシステムがUMSを使用する場合、UMSドライバを構成する必要があります。
注意: この手順が必要になるのは、Oracle WebCenter Content: Imagingが使用するOracle SOA SuiteシステムがUnified Messaging System (UMS)を使用している場合のみです。 |
ImagingのUMSドライバを構成する手順は次のとおりです。
UMSドライバの構成情報を、そのドライバを使用するエンタープライズ・デプロイメント・トポロジ内のすべてのサーバーに適用します。
サーバーの移行機能を使用すると、サーバーは別のノードのドメイン・ディレクトリに移動します。UMSドライバ構成は、フェイルオーバー・ノード内であらかじめ作成しておく必要があります。UMSドライバ構成ファイルの場所は次のとおりです。
ORACLE_BASE/admin/domain_name/mserver/domain_name/servers/server_name/
tmp/_WL_user/ums_driver_name/*/configuration/driverconfig.xml
コマンド内の*
は、デプロイ中にOracle WebLogic Serverによってランダムに生成される3682yq
などのディレクトリ名を表しています。
フェイルオーバーに備えてファイルを作成するには、強制的にサーバー移行を実行してファイルをソース・ノードからコピーしてください。例:
WLS_IMG1のドライバをWCCHOST1内に構成します。
WCCHOST2へのWLS_IMG1のフェイルオーバーを強制的に実行します。フェイルオーバー・ノード内のUMSドライバ構成のディレクトリ構造が、次のとおりであることを確認してください。
cd ORACLE_BASE/admin/domain_name/mserver/domain_name/servers/server_name/
tmp/_WL_user/ums_driver_name/*/configuration
コマンド内の*
は、デプロイ中にWLSによってランダムに生成される3682yq
などのディレクトリ名を表しています。
次のコマンドをWCCHOST1で実行し、WCCHOST1からWCCHOST2にドライバ構成ファイルをリモート・コピーします
scp ORACLE_BASE/admin/domain_name/mserver/domain_name/servers/server_name/
tmp/_WL_user/ums_driver_name/*/configuration/
driverconfig.xml oracle@WCCHOST2:ORACLE_BASE/admin/domain_name/mserver/domain_name/servers/server_name/tmp/_WL_user/ums_driver_name/*/configuration/
コマンド内の*
は、デプロイ中にOracle WebLogic Serverによってランダムに生成される3682yq
などのディレクトリ名を表しています。
これまでに行った変更を有効にする(変更後の構成情報をドライバに読み取らせる)ためにドライバを再起動する必要があります。
ドライバを再起動する手順は次のとおりです。
WebLogicサーバーの管理コンソールにログインします。
ナビゲーション・ツリーで「環境」ノードを開きます。
「デプロイメント」をクリックします。
ドライバを選択します。
「停止」→「作業完了時」をクリックし、操作を確定します。
ドライバの状態が「準備完了」
に変化するまで待ちます(必要に応じて、管理コンソール・ページを更新します)。
ドライバをもう一度選択し、「起動」→「すべてのリクエストを処理」をクリックして、操作を確定します。
ドライバのプロパティが保持されていることを、Fusion Middleware Controlで確認します。
トポロジのスケールアップとは、1つ以上の管理対象サーバーをすでに実行しているノードに新しい管理対象サーバーを追加することです。必要なコンポーネントを使用して構成されている管理対象サーバーを実行するノードがすでに存在しています。このノードには、共有記憶域内にWebLogic ServerホームとMiddlewareホームが存在します。新しい管理対象サーバーを作成する場合は、このような既存のインストール(WebLogic Serverホーム、Middlewareホーム、ドメイン・ディレクトリなど)を使用します。WebLogic Serverのバイナリを新しい場所にインストールしたり、pack
とunpack
を実行したりする必要はありません。
注意: コンテンツ・サーバーを含む管理対象サーバーの場合、共有ドメイン・ディレクトリは動作しません。 |
スケール・アップの手順は、トポロジのコンポーネントによって異なります。
1つのドメイン、1つのノードに対して、Oracle Fusion MiddlewareがサポートするWebCenter Content管理対象サーバーは1つのみです。WebCenter Content管理対象サーバーを追加するには、第19.7.1項「WebCenter Contentのスケール・アウト手順」に従い、新しいノードにWebCenter Content管理対象サーバーを追加します。
Imagingサーバーをスケール・アップする前に、WCCHOST1 (WCCHOST1VHN2など)で仮想IPアドレスを有効にし、トポロジで使用されるネットワーク・システムでもホスト名を(DNSサーバーまたはホスト解決のいずれかで)正しく解決する必要があります。仮想IPアドレスの有効化方法の詳細は、第11.6項「管理対象サーバーのノード・マネージャの構成」を参照してください。
エンタープライズ・デプロイメント・トポロジ内でImagingサーバーをスケール・アップする手順は次のとおりです。
WebLogic Server管理コンソールを使用し、WLS_IMG1のクローンを作成して新しい管理対象サーバーにします。クローニング元となるソース管理対象サーバーは、新しい管理対象サーバーを実行するノード上にすでに存在している必要があります。
管理対象サーバーをクローニングする手順は次のとおりです。
WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」ノードを開いて、「サーバー」を開きます。
「サーバーのサマリー」ページで、「ロックして編集」をクリックし、クローンを作成する管理対象サーバー(WLS_IMG1)を選択します。
「クローンの作成」をクリックします。
新しい管理対象サーバーの名前を「WLS_IMG
n
」にします。n
は、新しい管理対象サーバーの識別番号です。
サーバーのリスニング・アドレスに対して、この新しい管理対象サーバーに使用するホスト名またはホストIPアドレスを割り当てます。このサーバーに対してサーバー移行の使用を計画している場合は(推奨)、このアドレスにサーバーの仮想ホスト名を割り当てる必要があります。この仮想ホスト名は、既存の管理対象サーバーとは別のものを使用してください。
サーバーのリスニング・ポートに対して、Imagingクラスタ(IMG_Cluster)のリスニング・ポート番号を入力します。このガイドにおける参照用トポロジはポート番号16000を使用します。
「OK」をクリックし、「変更のアクティブ化」をクリックします。この時点で、「サーバーのサマリー」に、新しく作成されたサーバーWLS_IMGnが表示されます。
以降の手順は、新しいサーバーをWCCHOST1に追加する場合の想定に基づいています。このホストではすでにWLS_IMG1が実行されています。
Oracle WebCenter Content: Imaging用にJMS永続ストアとJMSサーバーを構成します。
2つのノードから参照できるディレクトリとして、JMS永続ストアの場所を構成します。デフォルトでは、Imagingで使用されるJMSサーバーに永続ストアは構成されず、WebLogic Serverのストア(ORACLE_BASE
/admin/
domain_name
/mserver/
domain_name
/servers/
server_name
/data/store/default
)を使用しています。
次のように、共有ベースのディレクトリを使用するように、各Oracle JMSサーバーの永続ストアを変更する必要があります。
WebLogicサーバーの管理コンソールにログインします。
「ドメイン構造」ウィンドウで、「サービス」ノードを開いて「永続ストア」ノードをクリックします。
「永続ストアのサマリー」ページで「ロックして編集」をクリックします。
「新規」→「ファイル・ストアの作成」をクリックします。
「新しいファイル・ストアの作成」ページで次の情報を入力します。
- 名前: IMGJMSServer
N
Store
(例: IMGJMSServer3Store
。これにより、作成対象のサービスを特定できます)。
- ターゲット: WLS_IMG
n
(例: WLS_IMG3
)。
- ディレクトリ: WCCHOST1とWCCHOST2の両方からアクセスできる共有記憶域にあるディレクトリを指定します (ORACLE_BASE
/admin/
domain_name
/
img_cluster_name
/jms
)。
「OK」をクリックして、変更内容を有効にします。
「ドメイン構造」ウィンドウで、「サービス」ノード→「メッセージ」ノードを開いて、「JMSサーバー」をクリックします。
「JMSサーバーのサマリー」ページで「新規」をクリックし、次の情報を入力します。
- 名前: IpmJmsServer
n
(例: IpmJmsServer3
)。
- 永続ストア: 前述のとおり作成した永続ストアIMGJMSServerN
Store(例: IMGJMSServer3Store)を選択します。
「次へ」をクリックし、WLS_IMG
n
(例: WLS_IMG3
)をターゲットとして指定します。
「終了」をクリックして変更内容を有効にします。
トランザクション・リカバリのためのWLS_IMGnのデフォルトの永続ストアを構成します。
WebLogicサーバーの管理コンソールにログインします。
「ドメイン構造」ウィンドウで、「環境」ノードを開いて「サーバー」ノードをクリックします。
「サーバーのサマリー」ページで、表の「名前」列にある(ハイパーリンクで表示されている)「WLS_IMGn
」をクリックします。WLS_IMGnサーバーの設定ページが開き、「構成」タブがアクティブに表示されます。
「サービス」タブをクリックします。
「ロックして編集」をクリックします。
表示されたページの「デフォルト・ストア」セクションで、デフォルトの永続ストアのデータ・ファイルを格納するフォルダのパスを入力します。このパスのディレクトリ構造は次のとおりです。
ORACLE_BASE/admin/domain_name/img_cluster_name/tlogs
「保存」をクリックして、変更をアクティブ化します。
新しい管理対象サーバーのホスト名検証をまだ無効にしていない場合は、第9.4.5項「ホスト名検証の無効化」の手順に従って無効にします。
WLS_IMGn管理対象サーバーの起動および検証を可能にするには、事前にホスト名検証を無効にする必要があります。管理サーバーとWCCHOSTnのノード・マネージャとの通信用のサーバー証明書構成が完了したら、ホスト名検証を再度有効にできます。新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効にされている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されるため、これらの手順は不要です。
新しく作成した管理対象サーバー(WLS_IMG)を起動します。
WebLogicサーバーの管理コンソールにログインします。
「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」をクリックします。
「サーバーのサマリー」ページで、「制御」タブを開き、クラスタ内にある既存のWLS_IMGnすべての管理対象サーバーを停止します。
新規作成した管理対象サーバーであるWLS_IMGnが稼働していることを確認します。
WLS_IMGn管理対象サーバー(WCCHOSTnVHN2)のホスト名をSocketHostNameSecurityFilter
パラメータ・リストに追加します。
テキスト・エディタで、ORACLE_BASE
/admin/
domain_name
/
wcc_cluster_name
/cs/config/config.cfg
のファイルを開きます。
リスニング・アドレスをOracle WebCenter Contentへの接続を許可するアドレスのリストに追加するために、WLS_IMGn管理対象サーバーを追加します(SocketHostNameSecurityFilter=localhost|localhost.mycompany.com|WCCHOST1|WCCHOST2|WCCHOST
nVHN
n)。
変更されたconfig.cfg
ファイルを保存しら、WebLogic Server管理コンソールを使用してOracle WebCenter Contentのサーバーを再起動し、変更を有効にします。
サーバー移行が新しい管理対象サーバー用に構成されていることを確認します。
注意: これはスケール・アップ操作であるため、ノード・マネージャと、サーバー移行に対して構成された環境が、あらかじめノードに用意されている必要があります。よって、次の手順は確認用にのみ使用されます。新しいImaging管理対象サーバー用の浮動IPアドレスも、すでに存在している必要があります。 |
サーバー移行が構成されていることを確認する手順は次のとおりです。
WebLogicサーバーの管理コンソールにログインします。
「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」をクリックします。
「サーバーのサマリー」ページで、表の「名前」列にある移行を構成する新しい管理対象サーバー名(ハイパーリンクで表示されている)をクリックします。
選択したサーバーの「設定」ページで、「移行」サブタブを開きます。
「移行の構成」セクションで、移行に参加するサーバーを 「使用可能」ウィンドウから選択して右向き矢印をクリックします。ノード上に存在するサーバーと同じ移行ターゲットを選択してください。
たとえば、すでにWLS_IMG1が実行されているWCCHOST1上の新しい管理対象サーバーには、WCCHOST2を選択します。すでにWLS_IMG2が実行されているWCCHOST2上の新しい管理対象サーバーには、WCCHOST1を選択します。
注意: 移行時に複数の管理対象サーバーを同時に実行するには、十分な空きリソースを確保しておく必要があります。 |
「サーバーの自動移行を有効化」オプションが選択されていることを確認します。
これにより、ノード・マネージャが、障害の発生したサーバーをターゲット・ノード上で自動的に起動できるようになります。
「保存」をクリックします。
ノード・マネージャ、管理サーバーおよびサーバー移行が構成されているサーバーを再起動します。
まず、管理コンソールを使用して管理対象サーバーを停止します。
次に、ノード・マネージャと管理サーバーを再起動します(第9.4.5項「ホスト名検証の無効化」の手順11を参照)。
最後に、管理コンソールを使用して管理対象サーバーを再度起動します。
この新しいサーバー用のサーバー移行をテストします。移行をテストするには、新しいサーバーを追加したノードで次の手順を実行します。
WLS_IMGn管理対象サーバーを強制的に停止します。そのためには、管理対象サーバーのPIDに対してkill -9
pid
を実行します。ノードのPIDは次のコマンドで特定できます。
ps -ef | grep WLS_IMGn
ノード・マネージャ・コンソールに、WLS_IMGnの浮動IPアドレスが無効になったことを示すメッセージが表示されることを確認します。
ノード・マネージャがWLS_IMGnの2回目の再起動を試行するまで待機します。ノード・マネージャは30秒間待機してからこの再起動を試行します。
ノード・マネージャがサーバーを再起動したら、サーバーを再び停止します。サーバーが再びローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されるようになります。
注意: サーバーの移行後、そのサーバーを元のノードまたはマシンにフェイルオーバーするには、WebLogic Server管理コンソールから管理対象サーバーを停止し、再起動します。管理対象サーバーは、適切なノード・マネージャによって以前に割り当てられていたマシン上で起動されます。 |
Oracle WebCenter Captureサーバーをスケール・アップする前に、WCCHOST1 (WCCHOST1VHN3など)で仮想IPアドレスを有効にし、トポロジで使用されるネットワーク・システムでもホスト名を(DNSサーバーまたはホスト解決のいずれかで)正しく解決する必要があります。仮想IPアドレスの有効化方法の詳細は、第11.6項「管理対象サーバーのノード・マネージャの構成」を参照してください。
エンタープライズ・デプロイメント・トポロジでCaptureサーバーをスケール・アップする手順は次のとおりです。
WebLogic Server管理コンソールを使用して、WLS_CPT1をクローニングして新しい管理対象サーバーを作成します。クローニング元となるソース管理対象サーバーは、新しい管理対象サーバーを実行するノード上にすでに存在している必要があります。
管理対象サーバーをクローニングする手順は次のとおりです。
WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」ノードを開いて、「サーバー」を開きます。
「サーバーのサマリー」ページで、「ロックして編集」をクリックし、クローンを作成する管理対象サーバー(WLS_CPT1)を選択します。
「クローンの作成」をクリックします。
新しい管理対象サーバーの名前をWLS_CPT
nにします。nは、新しい管理対象サーバーの識別番号です。
サーバーのリスニング・アドレスに対して、この新しい管理対象サーバーに使用するホスト名またはホストIPアドレスを割り当てます。このサーバーに対してサーバー移行の使用を計画している場合は(推奨)、このアドレスにサーバーの仮想ホスト名を割り当てる必要があります。この仮想ホスト名は、既存の管理対象サーバーとは別のものを使用してください。
サーバーのリスニング・ポートに対して、Captureクラスタ(CPT_Cluster)のリスニング・ポート番号を入力します。このガイドにおける参照用トポロジはポート番号16400を使用します。
「OK」をクリックし、「変更のアクティブ化」をクリックします。この時点で、「サーバーのサマリー」に、新しく作成されたサーバーWLS_CPTnが表示されます。
以降の手順は、新しいサーバーをWCCHOST1に追加することを想定しています。このホストではすでにWLS_CPT1が実行されています。
Capture用にJMS永続ストアとJMSサーバーを構成します。
2つのノードから参照できるディレクトリとして、JMS永続ストアの場所を構成します。デフォルトでは、Captureで使用されるJMSサーバーに永続ストアは構成されず、WebLogic Serverのストア(ORACLE_BASE
/admin/
domain_name
/mserver/
domain_name
/servers/
server_name
/data/store/default
)を使用しています。
次のように、共有ベースのディレクトリを使用するように、各Oracle JMSサーバーの永続ストアを変更する必要があります。
WebLogicサーバーの管理コンソールにログインします。
「ドメイン構造」ウィンドウで、「サービス」ノードを開いて「永続ストア」ノードをクリックします。
「永続ストアのサマリー」ページで「ロックして編集」をクリックします。
「新規」→「ファイル・ストアの作成」をクリックします。
「新しいファイル・ストアの作成」ページで次の情報を入力します。
- 名前: CPTJMSServer
n
Store
(例: CPTJMSServer3Store
。これにより、作成対象のサービスを特定できます)。
- ターゲット: WLS_CPT
n(例: WLS_CPT3
)。
- ディレクトリ: WCCHOST1とWCCHOST2の両方からアクセスできる共有記憶域にあるディレクトリを指定します (ORACLE_BASE
/admin/
domain_name
/
cpt_cluster_name
/jms
)。
「OK」をクリックして、変更内容を有効にします。
「ドメイン構造」ウィンドウで、「サービス」ノード→「メッセージ」ノードを開いて、「JMSサーバー」をクリックします。
「JMSサーバーのサマリー」ページで「新規」をクリックし、次の情報を入力します。
- 名前: CaptureJmsServer
n
(例: CaptureJmsServer3
)。
- 永続ストア: 前述のとおり作成した永続ストアCPTJMSServern
Store(例: CPTJMSServer3Store)を選択します。
「次へ」をクリックし、WLS_CPT
n
(例: WLS_CPT3
)をターゲットとして指定します。
「終了」をクリックして変更内容を有効にします。
トランザクション・リカバリのためのCPTnのデフォルトの永続ストアを構成します。
WebLogicサーバーの管理コンソールにログインします。
「ドメイン構造」ウィンドウで、「環境」ノードを開いて「サーバー」ノードをクリックします。
「サーバーのサマリー」ページで、表の「名前」列にある(ハイパーリンクで表示されている)「CPT_IMGn
」をクリックします。CPT_IMGnサーバーの設定ページが開き、「構成」タブがアクティブに表示されます。
「サービス」タブをクリックします。
「ロックして編集」をクリックします。
表示されたページの「デフォルト・ストア」セクションで、デフォルトの永続ストアのデータ・ファイルを格納するフォルダのパスを入力します。このパスのディレクトリ構造は次のとおりです。
ORACLE_BASE/admin/domain_name/cpt_cluster_name/tlogs
「保存」をクリックして、変更をアクティブ化します。
新しい管理対象サーバーのホスト名検証をまだ無効にしていない場合は、第9.4.5項「ホスト名検証の無効化」の手順に従って無効にします。
CPT_IMGn管理対象サーバーの起動および検証を可能にするには、事前にホスト名検証を無効にする必要があります。管理サーバーとWCCHOSTnのノード・マネージャとの通信用のサーバー証明書構成が完了したら、ホスト名検証を再度有効にできます。新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効にされている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されるため、これらの手順は不要です。
新しく作成した管理対象サーバー(WLS_CPT)を起動します。
WebLogicサーバーの管理コンソールにログインします。
「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」をクリックします。
「サーバーのサマリー」ページで、「制御」タブを開き、クラスタ内にある既存のWLS_CPTnすべての管理対象サーバーを停止します。
新規作成した管理対象サーバーであるWLS_CPTnが稼動していることを確認します。
WLS_CPTn管理対象サーバー(WCCHOSTnVHN3)のホスト名をSocketHostNameSecurityFilter
パラメータ・リストに追加します。
テキスト・エディタで、ORACLE_BASE
/admin/
domain_name
/
wcc_cluster_name
/cs/config/config.cfg
のファイルを開きます。
リスニング・アドレスをOracle WebCenter Contentへの接続を許可するアドレスのリストに追加するために、WLS_CPTn管理対象サーバーを追加します(SocketHostNameSecurityFilter=localhost|localhost.mycompany.com|WCCHOST1|WCCHOST2|WCCHOST
nVHN
n)。
変更されたconfig.cfg
ファイルを保存しら、WebLogic Server管理コンソールを使用してOracle WebCenter Contentのサーバーを再起動し、変更を有効にします。
サーバー移行が新しい管理対象サーバー用に構成されていることを確認します。
注意: これはスケール・アップ操作であるため、ノード・マネージャと、サーバー移行に対して構成された環境が、あらかじめノードに用意されている必要があります。よって、次の手順は確認用にのみ使用されます。新しいImaging管理対象サーバー用の浮動IPアドレスも、すでに存在している必要があります。 |
サーバー移行が構成されていることを確認する手順は次のとおりです。
WebLogicサーバーの管理コンソールにログインします。
「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」をクリックします。
「サーバーのサマリー」ページで、表の「名前」列にある移行を構成する新しい管理対象サーバー名(ハイパーリンクで表示されている)をクリックします。
選択したサーバーの「設定」ページで、「移行」サブタブを開きます。
「移行の構成」セクションで、移行に参加するサーバーを 「使用可能」ウィンドウから選択して右向き矢印をクリックします。ノード上に存在するサーバーと同じ移行ターゲットを選択してください。
たとえば、すでにWLS_CPT1が実行されているWCCHOST1上の新しい管理対象サーバーには、WCCHOST2を選択します。すでにWLS_CPT2が実行されているWCCHOST2上の新しい管理対象サーバーには、WCCHOST1を選択します。
注意: 移行時に複数の管理対象サーバーを同時に実行するには、十分な空きリソースを確保しておく必要があります。 |
「サーバーの自動移行を有効化」オプションが選択されていることを確認します。
これにより、ノード・マネージャが、障害の発生したサーバーをターゲット・ノード上で自動的に起動できるようになります。
「保存」をクリックします。
ノード・マネージャ、管理サーバーおよびサーバー移行が構成されているサーバーを再起動します。
まず、管理コンソールを使用して管理対象サーバーを停止します。
次に、ノード・マネージャと管理サーバーを再起動します(第9.4.5項「ホスト名検証の無効化」の手順11を参照)。
最後に、管理コンソールを使用して管理対象サーバーを再度起動します。
この新しいサーバー用のサーバー移行をテストします。移行をテストするには、新しいサーバーを追加したノードで次の手順を実行します。
WLS_CPTn管理対象サーバーを強制的に停止します。そのためには、管理対象サーバーのPIDに対してkill -9
pid
を実行します。ノードのPIDは次のコマンドで特定できます。
ps -ef | grep WLS_IMGn
ノード・マネージャ・コンソールに、WLS_CPTnの浮動IPアドレスが無効になったことを示すメッセージが表示されることを確認します。
ノード・マネージャがWLS_CPTnの2回目の再起動を試行するまで待機します。ノード・マネージャは30秒間待機してからこの再起動を試行します。
ノード・マネージャがサーバーを再起動したら、サーバーを再び停止します。サーバーが再びローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されるようになります。
注意: サーバーの移行後、そのサーバーを元のノードまたはマシンにフェイルオーバーするには、WebLogic Server管理コンソールから管理対象サーバーを停止し、再起動します。管理対象サーバーは、適切なノード・マネージャによって以前に割り当てられていたマシン上で起動されます。 |
Imagingサーバーをスケール・アップする前に、WCCHOST1 (WCCHOST1VHN1など)で仮想IPアドレスを有効にし、トポロジで使用されるネットワーク・システムでもホスト名を(DNSサーバーまたはホスト解決のいずれかで)正しく解決する必要があります。仮想IPアドレスの有効化方法の詳細は、第11.6項「管理対象サーバーのノード・マネージャの構成」を参照してください。
注意: Oracle WebCenter Content: Imagingが使用するOracle SOA Suiteサブシステムのスケール・アップについては、Oracle SOA Suiteエンタープライズ・デプロイメント・トポロジのドキュメントを参照してください。 |
エンタープライズ・デプロイメント・トポロジ内でOracle SOA Suiteサーバーをスケール・アップする手順は次のとおりです。
WebLogic Server管理コンソールを使用して、WLS_SOA1をクローニングして新しい管理対象サーバーを作成します。クローニング元となるソース管理対象サーバーは、新しい管理対象サーバーを実行するノード上にすでに存在している必要があります。
管理対象サーバーをクローニングする手順は次のとおりです。
WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」ノードを開いて、「サーバー」を開きます。
「サーバーのサマリー」ページで、クローンを作成する管理対象サーバー(WLS_SOA1)を選択します。
「クローンの作成」をクリックします。
新しい管理対象サーバーの名前をWLS_SOAnにします。nは、新しい管理対象サーバーの識別番号です。
注意: 以降の手順は、新しいサーバーをWCCHOST1に追加することを想定しています。このホストではすでにWLS_SOA1が実行されています。 |
リスニング・アドレスとして、この新しい管理対象サーバー用に使用するホスト名またはIPアドレスを割り当てます。このサーバーに対してサーバー移行の使用を計画している場合は(推奨)、別のノードへの移動を可能にするために、このアドレスに仮想IPアドレス(浮動IPアドレスともいう)を割り当てる必要があります。仮想IPアドレスは、すでに実行されている管理対象サーバーで使用されているものとは別のものである必要があります。
新しい管理対象サーバーにOracle SOA SuiteおよびUMSのJMSサーバーを作成します。
WebLogic Server管理コンソールを使用して、新しいSOAJMSServerの新しい永続ストアを作成し、SOAJMSFileStore_N
のような名前を付けます。このストアのパスを指定します。第4.3項「各種ディレクトリの推奨場所について」でお薦めしているように、これは共有記憶域上のディレクトリにします。
ORACLE_BASE/admin/domain_name/soa_cluster_name/jms/
Oracle SOA Suiteの新しいJMSサーバーを作成します(例: SOAJMSServer_N
)。SOAJMSFileStore_N
は、このJMSサーバーで使用します。SOAJMSServer_Nサーバーのターゲットとして、前述の手順で作成した管理対象サーバー(WLS_SOAn)を指定します。
新しいUMSJMSServerの新しい永続ストアを作成します(たとえば、UMSJMSFileStore_N
)。このストアのパスを指定します。第4.3項「各種ディレクトリの推奨場所について」でお薦めしているように、これは共有記憶域上のディレクトリにします。
ORACLE_BASE/admin/domain_name/soa_cluster_name/jms/
注意: 新しいUMS JMSサーバーのストアとして |
UMS用の新しいJMSサーバーを作成します(例:UMSJMSServer_N)。UMSJMSFileStore_N
は、このJMSサーバーで使用します。UMSJMSServer_Nサーバーのターゲットとして、前述の手順で作成した管理対象サーバー(WLS_SOAn)を指定します。
SOA JMSモジュールのサブデプロイメント・ターゲットを更新し、先ほど作成したSOA JMSサーバーを追加します。そのためには、WebLogic Server管理コンソールの左側の「ドメイン構造」ツリーで、「サービス」ノードを開き、「メッセージング」ノードを開きます。「JMSモジュール」をクリックします。「JMSモジュール」ページが表示されます。「SOAJMSModule」(表の「名前」列にハイパーリンクとして表示)をクリックします。SOAJMSModuleの「設定」ページが表示されます。「サブデプロイメント」タブを開きます。SOAJMSのサブデプロイメント・モジュールが表示されます。
注意: このサブデプロイメント・モジュール名は、 |
「SOAJMSServerXXXXXX」サブデプロイメントをクリックします。Oracle SOA Suiteの新しいJMSサーバーであるSOAJMSServer_N
をこのサブデプロイメントに追加します。「保存」をクリックします。
UMSJMSSystemResourceのサブデプロイメント・ターゲットを更新し、先ほど作成したUMS JMSサーバーを追加します。そのためには、WebLogic Server管理コンソールの左側の「ドメイン構造」ツリーで、「サービス」ノードを開き、「メッセージング」ノードを開きます。「JMSモジュール」をクリックします。「JMSモジュール」ページが表示されます。「UMSJMSSystemResource」(表の「名前」列にハイパーリンクとして表示)をクリックします。UMSJMSSystemResourceの「設定」ページが表示されます。「サブデプロイメント」タブを開きます。UMSJMSのサブデプロイメント・モジュールが表示されます。
注意: このサブデプロイメント・モジュール名は、 |
「UMSJMSServerXXXXXX」サブデプロイメントをクリックします。UMSの新しいJMSサーバーであるUMSJMSServer_
N
をこのサブデプロイメントに追加します。「保存」をクリックします。
新しいサーバーにコンポジットをデプロイするようにOracle Coherenceを構成します。手順は、第13.5項「コンポジットをデプロイするためのOracle Coherenceの構成」を参照してください。
注意: 変更の必要があるのは、サーバーの |
新しいサーバーのTx永続ストアを構成します。これは、共有記憶域に関する推奨事項で示されるとおり、他のノードから見える場所にする必要があります。(第4.3項「各種ディレクトリの推奨場所について」を参照)。
管理コンソールから、「サービス」タブにあるサーバー名(WLS_SOAn)を選択します。「デフォルト・ストア」の「ディレクトリ」に、デフォルトの永続ストアがデータ・ファイルを格納するフォルダのパスを入力します。
ORACLE_BASE/admin/domain_name/soa_cluster_name/tlogs
新しい管理対象サーバーのホスト名検証をまだ無効にしていない場合は、第9.4.5項「ホスト名検証の無効化」の手順に従って無効にします。
WLS_SOAn管理対象サーバーの起動および検証を可能にするには、事前にホスト名検証を無効にする必要があります。管理サーバーとWCCHOSTnのノード・マネージャとの通信用のサーバー証明書構成が完了したら、ホスト名検証を再度有効にできます。新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効にされている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されるため、これらの手順は不要です。
WebLogic Server管理コンソールから新しい管理対象サーバーを起動して、テストします。
新規作成した管理対象サーバーであるWLS_SOAnが稼働していることを確認します。
LBR上のアプリケーション(http://wccinternal.mycompany.com/soa-infra
)にアクセスします。アプリケーションが機能している必要があります。
注意: トポロジ内のOracle HTTP Serverは、新たに追加したサーバーにリクエストをラウンド・ロビンする必要があります(リクエストによっては、クラスタ内のサーバー数に応じて新しいサーバーにヒットする必要がある場合もまれにあります)。Oracle HTTP Serverの |
新しい管理対象サーバーのサーバー移行を構成します。
注意: これはスケール・アップ操作であるため、ノード・マネージャと、サーバー移行に対して構成された環境が、あらかじめノードに用意されている必要があります。新しいOracle SOA Suite管理対象サーバー用の浮動IPアドレスも、すでに存在している必要があります。 |
サーバー移行を構成する手順は次のとおりです。
WebLogicサーバーの管理コンソールにログインします。
「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」をクリックします。
「サーバーのサマリー」ページで、表の「名前」列にある移行を構成する新しい管理対象サーバー名(ハイパーリンクで表示されている)をクリックします。
選択したサーバーの「設定」ページで、「移行」サブタブを開きます。
「移行の構成」セクションで、移行に参加するサーバーを 「使用可能」ウィンドウから選択して右向き矢印をクリックします。ノード上に存在するサーバーと同じ移行ターゲットを選択してください。
たとえば、すでにWLS_SOA1が実行されているWCCHOST1上の新しい管理対象サーバーには、WCCHOST2を選択します。すでにWLS_SOA2が実行されているWCCHOST2上の新しい管理対象サーバーには、WCCHOST1を選択します。
注意: 移行時に複数の管理対象サーバーを同時に実行するには、十分な空きリソースを確保しておく必要があります。 |
「サーバーの自動移行を有効化」オプションが選択されていることを確認します。
これにより、ノード・マネージャが、障害の発生したサーバーをターゲット・ノード上で自動的に起動できるようになります。
「保存」をクリックします。
ノード・マネージャ、管理サーバーおよびサーバー移行が構成されているサーバーを再起動します。
まず、管理コンソールを使用して管理対象サーバーを停止します。
次に、ノード・マネージャと管理サーバーを再起動します(第9.4.5項「ホスト名検証の無効化」の手順11を参照)。
最後に、管理コンソールを使用して管理対象サーバーを再度起動します。
この新しいサーバー用のサーバー移行をテストします。移行をテストするには、新しいサーバーを追加したノードで次の手順を実行します。
WLS_SOAn管理対象サーバーを強制的に停止します。そのためには、管理対象サーバーのPIDに対してkill -9
pid
を実行します。ノードのPIDは次のコマンドで特定できます。
ps -ef | grep WLS_SOAn
ノード・マネージャ・コンソールに、WLS_SOA1の浮動IPアドレスが無効になったことを示すメッセージが表示されることを確認します。
ノード・マネージャがWLS_SOAnの2回目の再起動を試行するまで待機します。ノード・マネージャは30秒間待機してからこの再起動を試行します。
ノード・マネージャがサーバーを再起動したら、サーバーを再び停止します。サーバーが再びローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されるようになります。
注意: サーバーの移行後、そのサーバーを元のノードまたはマシンにフェイルオーバーするには、WebLogic Server管理コンソールから管理対象サーバーを停止し、再起動します。管理対象サーバーは、適切なノード・マネージャによって以前に割り当てられていたマシン上で起動されます。 |
トポロジのスケール・アウトでは、新しいノードに構成された新しい管理対象サーバーを追加します。
前提条件
この項の手順を実行する前に、次の要件が満たされていることを確認してください。
Oracle Fusion Middlewareで構成された管理対象サーバーを実行しているノードがトポロジ内に存在しています。
新しいノードは、WebLogic ServerとFusion Middlewareの既存のホーム・ディレクトリにアクセスできます。(新しい管理対象サーバーを作成するには、共有記憶域内の既存のインストールを使用します。WebLogic ServerやFusion Middlewareのバイナリを新しい場所にインストールする必要はありませんが、新しいノードでpack
とunpack
を実行してドメイン構成をブートストラップする必要はあります。)
ORACLE_HOME
またはWL_HOME
が、異なるノードの複数のサーバーによって共有されている場合、これらのノードのOracleインベントリとMiddlewareホーム・リストを常に最新の状態にして、インストールとパッチ・アプリケーションの整合性を確保することをお薦めします。ノードでoraInventory
ディレクトリを更新して、これに共有記憶域のインストールを関連付けるには、ORACLE_HOME
/oui/bin/attachHome.sh
を使用します。
WL_HOME
を追加または削除してMiddlewareホーム・リストを更新する場合は、User_Home
/bea/beahomelist
ファイルを編集します。次の手順を参照してください。
新しいサーバーは新しい個別のドメイン・ディレクトリを使用できます。また、他の管理対象サーバー用ドメイン・ディレクトリが共有記憶域にある場合、それらのサーバーのドメイン・ディレクトリを再利用できます。
注意: コンテンツ・サーバーを含む管理対象サーバーの場合、共有ドメイン・ディレクトリは動作しません。intradoc.cfgなどのドメイン内の特定のファイルは各ノードに固有だからです。ノード固有のファイルの問題を防ぐには、各Oracle WebCenter ContentおよびOracle WebCenter Content: Inbound Refinery管理対象サーバーにローカル(ノードごと)のドメイン・ディレクトリを使用します。 |
スケール・アウト手順
スケール・アウトの手順は、トポロジのコンポーネントによって異なります。
WebCenter Contentのスケール・アウト手順では、構成済のWLS_WCCn管理対象サーバーを新しいノードに追加します。
エンタープライズ・デプロイメント・トポロジ内でWebCenter Contentのサーバーをスケール・アウトする手順は次のとおりです。
新しいノードで、Oracle WebCenter Contentのインストールとドメイン・ディレクトリが格納されている既存のMiddlewareホームをマウントし、ドメイン内の他のノードと同様に、新しいノードがこのディレクトリにアクセスできることを確認します。
注意: この手順では、管理対象サーバーが1つも実行されていないノードnに、新しいWebCenter Contentのサーバーを追加することを想定しています。 |
共有記憶域内のORACLE_HOME
をローカルのOracleインベントリに追加するには、WCCHOSTnで次のコマンドを実行します(まだ実行していない場合)。
cd ORACLE_COMMON_HOME/oui/bin/ ./attachHome.sh -jreLoc ORACLE_BASE/product/fmw/jrockit_160_version
注意: このガイドで説明する例ではOracle JRockitを使用します。この手順には、動作保証された任意のバージョンのJavaを使用することができ、特に記載がないかぎり完全にサポートされています。 |
Middlewareホーム・リストを更新するには、MW_HOME
/bea/beahomelist
ファイルを作成し(別のWebLogicインストールがノード内に存在する場合はそれを編集)、それにORACLE_BASE
/product/fmw
追加します。
WebLogicサーバーの管理コンソールにログインします。
新しいノード用の新しいマシンを作成し、このマシンをドメインに追加します。
注意: ドメインおよびアプリケーションのディレクトリがすでに存在するホストでWLS_WCCnサーバーをスケール・アウトする場合は、 |
このマシンのノード・マネージャのアドレスを更新して、スケール・アウトに使用されているノードのIPアドレスをマップします。
WebLogic Server管理コンソールを使用して、WLS_WCC1をクローニングして新しい管理対象サーバーを作成します。これにWLS_WCCnという名前を付けます(nには番号を指定します)。
注意: この手順では、管理対象サーバーが1つも実行されていないノードnに、新しいサーバーを追加することを想定しています。 |
新しい管理対象サーバーのサーバー・リスニング・アドレスとして使用するWCCHOSTnのホスト名またはIPアドレスを割り当てます。
WLS_WCCn管理対象サーバーを新しく作成されたマシンに割り当てます。
使用可能なサーバーのリストからWLS_WCCnを選択し、「終了」→「変更のアクティブ化」の順にクリックします。
WCCHOST1でpack
コマンドを実行してテンプレート・パックを作成します。
注意: 管理対象サーバーのドメイン・ディレクトリはWCCHOSTnでまだ作成されていないため、この手順と次の2つの手順を実行する必要があります。 |
cd ORACLE_COMMON_HOME/common/bin ./pack.sh -managed=true -domain=ORACLE_BASE/admin/domain_name/aserver/domain_name -template=edgdomaintemplateScaleWCC.jar -template_name=edgdomain_templateScaleWCC
次のコマンドをWCCHOST1で実行し、作成したテンプレート・ファイルをWCCHOSTnにコピーします。
scp edgdomaintemplateScaleWCC.jar oracle@WCCHOSTn:/ORACLE_COMMON_HOME/common/bin
次のように、unpack
コマンドをWCCHOSTnで実行して、このテンプレートを管理対象サーバーのドメイン・ディレクトリに解凍します。
cd ORACLE_COMMON_HOME/common/bin ./unpack.sh -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name -template=edgdomaintemplateScaleWCC.jar -app_dir=ORACLE_BASE/admin/domain_name/mserver/applications
WCCHOSTnで次のコマンドを実行し、ノード・マネージャを起動します。
CD WL_HOME/server/bin
./startNodeManager.sh
新しい管理対象サーバーのホスト名検証をまだ無効にしていない場合は、第9.4.5項「ホスト名検証の無効化」の手順に従って無効にします。
WLS_WCCn管理対象サーバーの起動および検証を可能にするには、事前にホスト名検証を無効にする必要があります。管理サーバーとWCCHOSTnのノード・マネージャとの通信用のサーバー証明書構成が完了したら、ホスト名検証を再度有効にできます。新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効にされている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されるため、これらの手順は不要です。
WebLogic Server管理コンソールで、新しい管理対象サーバーであるWLS_WCCnを起動し、サーバーの状態が「実行中」と表示されることを確認します。
新しい管理対象サーバーであるWLS_WCCnを構成します。
http://WCCHOST
n:16200/cs
でWebLogic Serverの管理ユーザー名とパスワードを使用してWLS_WCCnにログインします。WebCenter Contentの「構成」ページが表示されます。
注意:
|
「サーバーの構成」ページで次の値を変更します。「クラスタ・ノード識別子」が、管理対象サーバーの名前(WLS_WCC1など)と一致するように設定されていることを確認してください。
- コンテンツ・サーバーのインスタンス・フォルダ: これをORACLE_BASE
/admin/
domain_name
/
wcc_cluster_name
/cs
に設定します。
- ネイティブ・ファイル・リポジトリの場所: これをORACLE_BASE
/admin/domain_name/
wcc_cluster_name
/cs/vault
に設定します。
- Webレイアウト・フォルダ: これをORACLE_BASE
/admin/
domain_name
/
wcc_cluster_name
/cs/weblayout
に設定します。
- ユーザー・プロファイル: これをORACLE_BASE
/admin/
domain_name
/
wcc_cluster_name
/cs/data/users/profiles
に設定します。
完了したら「送信」をクリックし、WebLogic Server管理コンソールを使用して新しい管理対象サーバーを再起動します。
Oracle WebCenter Contentで許可されているホストのリスト(ORACLE_BASE
/admin/domain_name/
wcc_cluster_name
/cs/config/config.cfg
ファイル)に、WLS_WCCnのリスニング・アドレスを追加します。管理コンソールを使用して、Oracle WebCenter Content管理対象サーバーを再起動します。
サーバーおよびリスニング・アドレスは次のContent Serverプールに追加されます。
WCCHOST1:4444
WCCHOST2:4444
WCCHOST3:4444
詳細は、第14.5.13項「コンテンツ・サーバーへの接続の作成」を参照してください。
LBR上のアプリケーション(https://wcc.mycompany.com/cs
)にアクセスしてWLS_WCCn管理対象サーバーをテストします。アプリケーションが機能している必要があります。
注意: トポロジ内のHTTPサーバーは、新たに追加したサーバーにリクエストをラウンド・ロビンする必要があります(リクエストによっては、クラスタ内のサーバー数に応じて新しいサーバーにヒットする必要がある場合もまれにあります)。Oracle HTTP Serverの |
Imagingのスケール・アウト手順では、構成済のWLS_IMGn管理対象サーバーを新しいノードに追加します。
エンタープライズ・デプロイメント・トポロジ内でImagingサーバーをスケール・アウトする手順は次のとおりです。
新しいノードで、Oracle WebCenter Contentのインストールと(必要に応じ、他のノードで管理対象サーバー用ドメイン・ディレクトリが共有記憶域にある場合)ドメイン・ディレクトリが格納されている既存のMiddlewareホームをマウントし、ドメイン内の他のノードと同様、新しいノードからこのディレクトリにアクセスできることを確認します。
共有記憶域内のORACLE_HOME
をローカルのOracleインベントリに追加するには、WCCHOSTnで次のコマンドを実行します(まだ実行していない場合)。
cd ORACLE_COMMON_HOME/oui/bin/ ./attachHome.sh -jreLoc ORACLE_BASE/product/fmw/jrockit_160_version
Middlewareホーム・リストを更新するには、MW_HOME
/bea/beahomelist
ファイルを作成し(別のWebLogicインストールがノード内に存在する場合はそれを編集)、それにORACLE_BASE
/product/fmw
追加します。
注意: このガイドで説明する例ではOracle JRockitを使用します。この手順には、動作保証された任意のバージョンのJavaを使用することができ、特に記載がないかぎり完全にサポートされています。 |
WebLogicサーバーの管理コンソールにログインします。
新しいノード用の新しいマシンを作成し、このマシンをドメインに追加します。
注意: WLS_WCCnサーバーと同じマシンでWLS_IMGnサーバーをスケール・アウトする場合、新しいマシンを作成する必要はありません。第19.7.1項「WebCenter Contentのスケール・アウト手順」の手順4で作成したマシンを使用します。 |
このマシンのノード・マネージャのアドレスを更新して、スケール・アウトに使用されているノードのIPアドレスをマップします。
WebLogic Server管理コンソールを使用して、WLS_IMG1をクローニングして新しい管理対象サーバーを作成します。これにWLS_IMGnという名前を付けます(nには番号を指定します)。
注意: この手順では、管理対象サーバーが1つも実行されていないノードnに、新しいサーバーを追加することを想定しています。 |
新しい管理対象サーバー用に使用するホスト名またはIPアドレスを、その管理対象サーバーのリスニング・アドレスとして割り当てます。このサーバーに対してサーバー移行を実行する予定の場合は(これをお薦めします)、これはサーバーの仮想IPアドレス(別称: 浮動IPアドレス)である必要があります。この仮想IPアドレスは、既存の管理対象サーバーとは別のものを使用してください。
注意: ノードnでは仮想IPアドレスを有効にし、トポロジで使用されるネットワーク・システムでもホスト名を(DNSサーバーまたはホスト解決のいずれかで)正しく解決する必要があります。仮想IPアドレスを有効化する方法の詳細は、第6.6項「仮想IPアドレスの有効化」を参照してください。 |
「はい、このサーバーを既存のクラスタのメンバーにします。」を選択します。
新しく作成したサーバーを、手順4で追加したマシンに割り当てます。これを実行しない場合、クローン元のサーバーのマシン名が残ります。
新しい管理対象サーバーでOracle WebCenter Content: ImagingのJMSサーバーを作成します。
WebLogic Server管理コンソールを使用して、新しいIpmJmsServerN用の新しい永続ストアを最初に作成し(作成方法は後述)、IMGJMSServer
N
Store
などの名前を付けます。JMS永続ストアのディレクトリとして、第4.3項「各種ディレクトリの推奨場所について」でお薦めしているストアのパスを指定します。
ORACLE_BASE/admin/domain_name/cluster_name/jms
新しいJMSサーバーを作成します(例: IpmJmsServer
N
)。
前の手順で作成したIMGJMSServerNStoreをJMSサーバーに使用します。IpmJmsServerNサーバーのターゲットとして、先ほど作成した管理対象サーバー(WLS_IMGn)を指定します。
トランザクション・リカバリ用にデフォルトの永続ストアを構成します。
WebLogic Server管理コンソールで、新しく作成したWLS_IMGnサーバーを選択します。
「サービス」を開きます。
ディレクトリに追加します。つまり、デフォルトの永続ストアのデータ・ファイルを格納するフォルダへのパスを入力します。
このパスのディレクトリ構造は次のとおりです。
ORACLE_BASE/admin/domain_name/img_cluster_name/tlogs
WCCHOST1でpack
コマンドを実行してテンプレート・パックを作成します。
cd ORACLE_COMMON_HOME/common/bin ./pack.sh -managed=true -domain=ORACLE_BASE/admin/domain_name/aserver/domain_name -template=edgdomaintemplateScaleIMG.jar -template_name=edgdomain_templateScaleIMG
注意: 他の管理対象サーバーのドメイン・ディレクトリが共有ディレクトリに存在する場合、この手順および次の2つの手順は不要です。そのかわり、新しいノードは既存のドメイン・ディレクトリをマウントし、これを新しく追加された管理対象サーバー用に使用します。 |
次のコマンドをWCCHOST1で実行し、作成したテンプレート・ファイルをWCCHOSTnにコピーします。
scp edgdomaintemplateScaleIMG.jar oracle@WCCHOSTn:/ORACLE_COMMON_HOME/common/bin
注意: 新しいホストである、WCCHOSTnがWCCHOST1と同じMiddlewareホームを使用する場合、この手順は不要です。 |
次のように、unpack
コマンドをWCCHOSTnで実行して、このテンプレートを管理対象サーバーのドメイン・ディレクトリに解凍します。
cd ORACLE_COMMON_HOME/common/bin ./unpack.sh -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name -template= edgdomaintemplateScaleIMG.jar -app_dir=ORACLE_BASE/admin/domain_name/mserver/applications
注意: ドメインおよびアプリケーションのディレクトリがすでに存在するホストでWLS_IMGnサーバーをスケール・アウトする場合は、 |
新しい管理対象サーバーのホスト名検証をまだ無効にしていない場合は、第9.4.5項「ホスト名検証の無効化」の手順に従って無効にします。
WLS_WCCn管理対象サーバーの起動および検証を可能にするには、事前にホスト名検証を無効にする必要があります。管理サーバーとWCCHOSTnのノード・マネージャとの通信用のサーバー証明書構成が完了したら、ホスト名検証を再度有効にできます。新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効にされている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されるため、これらの手順は不要です。
次により、「サーバーの自動移行を有効化」
オプションを無効にします。
WebLogic Server管理コンソールの左側の「ドメイン構造」ツリーで、「環境」ノードを開き、「サーバー」を選択します。
WLS_IMGn
管理対象サーバーを選択し、「移行」タブをクリックします。
「サーバーの自動移行を有効化」の選択を解除します。
「保存」および「変更のアクティブ化」をクリックします。
ノード・マネージャがまだ起動されていない場合は、新しいノードで起動します。WCCHOSTnで次のコマンドを実行し、ノード・マネージャを起動します。
CD WL_HOME/server/bin
./startNodeManager.sh
Fusion Middleware Controlで、新しい管理対象サーバーであるWLS_IMGnを起動し、稼働していることを確認します。
Oracle WebCenter Content Serverで許可されているホストのリストに、新しいImagingサーバーのリスニング・アドレスを追加します。第14.5.12項「Oracle WebCenter Contentで許可されたホストのリストに対するImagingサーバーのリスニング・アドレスの追加」の手順に従って、新しいサーバーを、Oracle WebCenter ContentのSocketHostNameSecurityFilter
構成に追加します。
注意: Imaging管理対象サーバーのホスト名が、 |
WebLogic Server管理コンソールを使用してすべてのOracle WebCenter Content管理対象サーバーを再起動します。
LBR上のアプリケーション(https://wcc.mycompany.com/imaging
)にアクセスしてWLS_IMGn管理対象サーバーをテストします。アプリケーションが機能している必要があります。
注意: トポロジ内のHTTPサーバーは、新たに追加したサーバーにリクエストをラウンド・ロビンする必要があります(リクエストによっては、クラスタ内のサーバー数に応じて新しいサーバーにヒットする必要がある場合もまれにあります)。Oracle HTTP Serverの |
新しく追加したサーバー用のサーバー移行を構成します。
新しいサーバーのクローン元となったソース・サーバー(ここではWLS_IMGn)はすでにサーバー移行が構成されていると想定しています。この場合、サーバー移行の設定はクローンされたサーバーに伝播されるため、次の手順は不要です。
すでにノード・マネージャにホスト名検証証明書を設定している場合は、前提条件として、新しく作成されたサーバーに対してこの手順を実行する必要があります。詳細は、第16.3項「ノード・マネージャのホスト名検証証明書の有効化」を参照してください。
注意: この新しいノードでは既存の共有記憶域インストールが使用されるため、このノードにはノード・マネージャが存在しています。また、サーバー移行用の環境(ネットマスク、インタフェース、wlsifconfigスクリプトのスーパーユーザー権限など)が構成済です。新しいノードで定義される権限を検証して、サーバー移行が機能することを確認します。権限の要件の詳細は、第17章「エンタープライズ・デプロイメント用のサーバーの移行の構成」を参照してください。 |
サーバー移行を構成する手順は次のとおりです。
WebLogicサーバーの管理コンソールにログインします。
「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」をクリックします。
「サーバーのサマリー」ページで、表の「名前」列にある移行を構成するサーバー名(ハイパーリンクで表示されている)をクリックします。
選択したサーバーの「設定」ページで、「移行」サブタブを開きます。
「移行の構成」セクションの「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右向き矢印をクリックします。
注意: マシンのうち、負荷が最も低いものを新しいサーバーの移行ターゲットとして指定します。このノードで追加の管理対象サーバーを維持するのに十分なリソースを確保できるように、必要なキャパシティ・プランニングをあらかじめ行ってください。 |
「サーバーの自動移行を有効化」オプションを選択します。これにより、ノード・マネージャが、障害の発生したサーバーをターゲット・ノード上で自動的に起動できるようになります。
「保存」をクリックします。
ノード・マネージャ、管理サーバーおよびサーバー移行が構成されているサーバーを再起動します。
まず、管理コンソールを使用して管理対象サーバーを停止します。
次に、ノード・マネージャと管理サーバーを再起動します(第9.4.5項「ホスト名検証の無効化」の手順11を参照)。
最後に、管理コンソールを使用して管理対象サーバーを再度起動します。
この新しいサーバー用のサーバー移行をテストします。移行をテストするには、新しいサーバーを追加したノードで次の手順を実行します。
WLS_IMGn管理対象サーバーを強制的に停止します。そのためには、管理対象サーバーのPIDに対してkill -9
pid
を実行します。ノードのPIDは次のコマンドで特定できます。
ps -ef | grep WLS_IMGn
ノード・マネージャ・コンソールに、WLS_IMGnの浮動IPアドレスが無効になったことを示すメッセージが表示されることを確認します。
ノード・マネージャがWLS_IMGnの2回目の再起動を試行するまで待機します。ノード・マネージャは30秒間待機してからこの再起動を試行します。
ノード・マネージャがサーバーを再起動したら、サーバーを再び停止します。サーバーが再びローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されるようになります。
注意: サーバーの移行後、そのサーバーを元のノードまたはマシンにフェイルオーバーするには、WebLogic Server管理コンソールから管理対象サーバーを停止し、再起動します。管理対象サーバーは、適切なノード・マネージャによって以前に割り当てられていたマシン上で起動されます。 |
Imagingのスケール・アウト手順では、構成済のWLS_CPTn管理対象サーバーを新しいノードに追加します。
エンタープライズ・デプロイメント・トポロジ内でCaptureサーバーをスケール・アウトする手順は次のとおりです。
新しいノードで、Oracle WebCenter Contentのインストールと(必要に応じ、他のノードで管理対象サーバー用ドメイン・ディレクトリが共有記憶域にある場合)ドメイン・ディレクトリが格納されている既存のMiddlewareホームをマウントし、ドメイン内の他のノードと同様、新しいノードからこのディレクトリにアクセスできることを確認します。
共有記憶域内のORACLE_HOMEをローカルのOracleインベントリに追加するには、WCCHOSTnで次のコマンドを実行します(まだ実行していない場合)。
cd ORACLE_COMMON_HOME/oui/bin/ ./attachHome.sh -jreLoc ORACLE_BASE/product/fmw/jrockit_160_version
Middlewareホーム・リストを更新するには、MW_HOME
/bea/beahomelist
ファイルを作成し(別のWebLogicインストールがノード内に存在する場合はそれを編集)、それにORACLE_BASE
/product/fmw
追加します。
注意: このガイドで説明する例ではOracle JRockitを使用します。この手順には、動作保証された任意のバージョンのJavaを使用することができ、特に記載がないかぎり完全にサポートされています。 |
WebLogicサーバーの管理コンソールにログインします。
新しいノード用の新しいマシンを作成し、このマシンをドメインに追加します(まだ実行していない場合)。
このマシンのノード・マネージャのアドレスを更新して、スケール・アウトに使用されているノードのIPアドレスをマップします。
WebLogic Server管理コンソールを使用して、WLS_CPT1をクローニングして新しい管理対象サーバーを作成します。これにWLS_CPTnという名前を付けます(nには番号を指定します)。
注意: この手順では、管理対象サーバーが1つも実行されていないノードnに、新しいサーバーを追加することを想定しています。 |
新しい管理対象サーバー用に使用するホスト名またはIPアドレスを、その管理対象サーバーのリスニング・アドレスとして割り当てます。このサーバーに対してサーバー移行を実行する予定の場合は(これをお薦めします)、これはサーバーの仮想IPアドレス(別称: 浮動IPアドレス)である必要があります。この仮想IPアドレスは、既存の管理対象サーバーとは別のものを使用してください。
注意: ノードnでは仮想IPアドレスを有効にし、トポロジで使用されるネットワーク・システムでもホスト名を(DNSサーバーまたはホスト解決のいずれかで)正しく解決する必要があります。仮想IPアドレスを有効化する方法の詳細は、第6.6項「仮想IPアドレスの有効化」を参照してください。 |
新しく作成したサーバーを、手順4で追加したマシンに割り当てます。これを実行しない場合、クローン元のサーバーのマシン名が残ります。
新しい管理対象サーバーにCapture用のJMSサーバーを作成します。
WebLogic Server管理コンソールを使用して、新しいCaptureJmsServerN用の新しい永続ストアを最初に作成し(作成方法は後述)、CPTJMSServer
N
Store
などの名前を付けます。JMS永続ストアのディレクトリとして、第4.3項「各種ディレクトリの推奨場所について」でお薦めしているストアのパスを指定します。
ORACLE_BASE/admin/domain_name/cluster_name/jms
新しいJMSサーバーを作成します(例: CaptureJmsServer
N
)。1つ前の手順で作成したCPTJMSServerNStore永続ストアをこのJMSサーバーに使用します。CaptureJmsServerNのターゲットとして、前述の手順で作成した管理対象サーバー(WLS_CPTn)を指定します。
トランザクション・リカバリ用にデフォルトの永続ストアを構成します。
WebLogic Server管理コンソールで、新しく作成したWLS_IMGnサーバーを選択します。
「サービス」を開きます。
ディレクトリに追加します。つまり、デフォルトの永続ストアのデータ・ファイルを格納するフォルダへのパスを入力します。
このパスのディレクトリ構造は次のとおりです。
ORACLE_BASE/admin/domain_name/img_cluster_name/tlogs
WCCHOST1でpack
コマンドを実行してテンプレート・パックを作成します。
cd ORACLE_COMMON_HOME/common/bin ./pack.sh -managed=true -domain=ORACLE_BASE/admin/domain_name/aserver/domain_name -template=edgdomaintemplateScaleCPT.jar -template_name=edgdomain_templateScaleCPT
注意: 他の管理対象サーバーのドメイン・ディレクトリが共有ディレクトリに存在する場合、この手順および次の2つの手順は不要です。そのかわり、新しいノードは既存のドメイン・ディレクトリをマウントし、これを新しく追加された管理対象サーバー用に使用します。 |
次のコマンドをWCCHOST1で実行し、作成したテンプレート・ファイルをWCCHOSTnにコピーします。
scp edgdomaintemplateScaleCPT.jar oracle@WCCHOSTn:/ORACLE_COMMON_HOME/common/bin
注意: 新しいホストである、WCCHOSTnがWCCHOST1と同じMW_HOMEホームを使用する場合、この手順は不要です。 |
次のように、unpack
コマンドをWCCHOSTnで実行して、このテンプレートを管理対象サーバーのドメイン・ディレクトリに解凍します。
cd ORACLE_COMMON_HOME/common/bin ./unpack.sh -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name -template= edgdomaintemplateScaleCPT.jar -app_dir=ORACLE_BASE/admin/domain_name/mserver/applications
注意: ドメインおよびアプリケーションのディレクトリがすでに存在するホストでWLS_CPTnサーバーに |
新しい管理対象サーバーのホスト名検証をまだ無効にしていない場合は、第9.4.5項「ホスト名検証の無効化」の手順に従って無効にします。
WLS_WCCn管理対象サーバーの起動および検証を可能にするには、事前にホスト名検証を無効にする必要があります。管理サーバーとWCCHOSTnのノード・マネージャとの通信用のサーバー証明書構成が完了したら、ホスト名検証を再度有効にできます。新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効にされている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されるため、これらの手順は不要です。
次により、「サーバーの自動移行を有効化」
オプションを無効にします。
WebLogic Server管理コンソールの左側の「ドメイン構造」ツリーで、「環境」ノードを開き、「サーバー」を選択します。
WLS_CPTn
管理対象サーバーを選択し、「移行」タブをクリックします。
「サーバーの自動移行を有効化」の選択を解除します。
「保存」および「変更のアクティブ化」をクリックします。
ノード・マネージャがまだ起動されていない場合は、新しいノードで起動します。WCCHOSTnで次のコマンドを実行し、ノード・マネージャを起動します。
CD WL_HOME/server/bin
./startNodeManager.sh
Fusion Middleware Controlで、新しい管理対象サーバーであるWLS_CPTnを起動し、稼動していることを確認します。
Oracle WebCenter Content Serverで許可されているホストのリストに、新しいCaptureサーバーのリスニング・アドレスを追加します。第14.5.12項「Oracle WebCenter Contentで許可されたホストのリストに対するImagingサーバーのリスニング・アドレスの追加」の手順に従って、新しいサーバーを、Oracle WebCenter ContentのSocketHostNameSecurityFilter
構成に追加します。
注意: Capture管理対象サーバーのホスト名が、 |
WebLogic Server管理コンソールを使用してすべてのOracle WebCenter Content管理対象サーバーを再起動します。
LBR上のアプリケーション(Captureコンソールの場合はhttps://wcc.mycompany.com/dc-console
、Captureクライアントの場合はhttps://wcc.mycompany.com/dc-client
)にアクセスして、WLS_CPTn管理対象サーバーをテストします。アプリケーションが機能している必要があります。
注意: トポロジ内のHTTPサーバーは、新たに追加したサーバーにリクエストをラウンド・ロビンする必要があります(リクエストによっては、クラスタ内のサーバー数に応じて新しいサーバーにヒットする必要がある場合もまれにあります)。Oracle HTTP Serverの |
新しく追加したサーバー用のサーバー移行を構成します。
新しいサーバーのクローン元となったソース・サーバー(ここではWLS_CPTn)はすでにサーバー移行が構成されていると想定しています。この場合、サーバー移行の設定はクローンされたサーバーに伝播されるため、次の手順は不要です。
すでにノード・マネージャにホスト名検証証明書を設定している場合は、前提条件として、新しく作成されたサーバーに対してこの手順を実行する必要があります。詳細は、第16.3項「ノード・マネージャのホスト名検証証明書の有効化」を参照してください。
注意: この新しいノードでは既存の共有記憶域インストールが使用されるため、このノードにはノード・マネージャが存在しています。また、サーバー移行用の環境(ネットマスク、インタフェース、wlsifconfigスクリプトのスーパーユーザー権限など)が構成済です。新しいノードで定義される権限を検証して、サーバー移行が機能することを確認します。権限の要件の詳細は、第17章「エンタープライズ・デプロイメント用のサーバーの移行の構成」を参照してください。 |
サーバー移行を構成する手順は次のとおりです。
WebLogicサーバーの管理コンソールにログインします。
「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」をクリックします。
「サーバーのサマリー」ページで、表の「名前」列にある移行を構成するサーバー名(ハイパーリンクで表示されている)をクリックします。
選択したサーバーの「設定」ページで、「移行」サブタブを開きます。
「移行の構成」セクションの「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右向き矢印をクリックします。
注意: マシンのうち、負荷が最も低いものを新しいサーバーの移行ターゲットとして指定します。このノードで追加の管理対象サーバーを維持するのに十分なリソースを確保できるように、必要なキャパシティ・プランニングをあらかじめ行ってください。 |
「サーバーの自動移行を有効化」オプションを選択します。これにより、ノード・マネージャが、障害の発生したサーバーをターゲット・ノード上で自動的に起動できるようになります。
「保存」をクリックします。
ノード・マネージャ、管理サーバーおよびサーバー移行が構成されているサーバーを再起動します。
まず、管理コンソールを使用して管理対象サーバーを停止します。
次に、ノード・マネージャと管理サーバーを再起動します(第9.4.5項「ホスト名検証の無効化」の手順11を参照)。
最後に、管理コンソールを使用して管理対象サーバーを再度起動します。
この新しいサーバー用のサーバー移行をテストします。移行をテストするには、新しいサーバーを追加したノードで次の手順を実行します。
WLS_CPTn管理対象サーバーを強制的に停止します。そのためには、管理対象サーバーのPIDに対してkill -9
pid
を実行します。ノードのPIDは次のコマンドで特定できます。
ps -ef | grep WLS_CPTn
ノード・マネージャ・コンソールに、WLS_CPTnの浮動IPアドレスが無効になったことを示すメッセージが表示されることを確認します。
ノード・マネージャがWLS_CPTnの2回目の再起動を試行するまで待機します。ノード・マネージャは30秒間待機してからこの再起動を試行します。
ノード・マネージャがサーバーを再起動したら、サーバーを再び停止します。サーバーが再びローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されるようになります。
注意: サーバーの移行後、そのサーバーを元のノードまたはマシンにフェイルオーバーするには、WebLogic Server管理コンソールから管理対象サーバーを停止し、再起動します。管理対象サーバーは、適切なノード・マネージャによって以前に割り当てられていたマシン上で起動されます。 |
Imagingのスケール・アウト手順では、構成済のWLS_SOAn管理対象サーバーを新しいノードに追加します。
注意: Captureが使用するOracle SOA Suiteサブシステムのスケール・アウトについては、Oracle SOA Suiteエンタープライズ・デプロイメント・トポロジのドキュメントを参照してください。 |
エンタープライズ・デプロイメント・トポロジ内でOracle SOA Suiteサーバーをスケール・アウトする手順は次のとおりです。
新しいノードで、Oracle SOA Suiteのインストールとドメイン・ディレクトリが格納されている既存のMiddlewareホームをマウントし、ドメイン内の他のノードと同様に、新しいノードがこのディレクトリにアクセスできることを確認します。
共有記憶域内のORACLE_HOME
をローカルのOracleインベントリに追加するには、WCCHOSTnで次のコマンドを実行します(まだ実行していない場合)。
cd ORACLE_COMMON_HOME/oui/bin/ ./attachHome.sh -jreLoc ORACLE_BASE/product/fmw/jrockit_160_version
Middlewareホーム・リストを更新するには、MW_HOME
/bea/beahomelist
ファイルを作成し(別のWebLogicインストールがノード内に存在する場合はそれを編集)、それにORACLE_BASE
/product/fmw
追加します。
注意: このガイドで説明する例ではOracle JRockitを使用します。この手順には、動作保証された任意のバージョンのJavaを使用することができ、特に記載がないかぎり完全にサポートされています。 |
WebLogicサーバーの管理コンソールにログインします。
新しいノード用の新しいマシンを作成し、このマシンをドメインに追加します。
注意: ドメインおよびアプリケーションのディレクトリがすでに存在するホストでWLS_SOAnサーバーをスケール・アウトする場合は、 |
このマシンのノード・マネージャのアドレスを更新して、スケール・アウトに使用されているノードのIPアドレスをマップします。
WebLogic Server管理コンソールを使用し、WLS_SOA1をクローニングして新しい管理対象サーバーを作成します。これにWLS_SOAnという名前を付けます。nは番号です。
注意: この手順では、管理対象サーバーが1つも実行されていないノードnに、新しいサーバーを追加することを想定しています。 |
新しい管理対象サーバー用に使用するホスト名またはIPアドレスを、その管理対象サーバーのリスニング・アドレスとして割り当てます。
このサーバーに対してサーバー移行を実行する予定の場合は(これをお薦めします)、これはサーバーの仮想IPアドレス(別称: 浮動IPアドレス)である必要があります。この仮想IPアドレスは、既存の管理対象サーバーとは別のものを使用してください。
WCCHOST1でpack
コマンドを実行してテンプレート・パックを作成します。
cd ORACLE_COMMON_HOME/common/bin ./pack.sh -managed=true -domain=ORACLE_BASE/admin/domain_name/aserver/domain_name -template=edgdomaintemplateScaleSOA.jar -template_name=edgdomain_templateScaleSOA
注意: 他の管理対象サーバーのドメイン・ディレクトリが共有ディレクトリに存在する場合、この手順は不要です。そのかわり、新しいノードは既存のドメイン・ディレクトリをマウントし、これを新しく追加された管理対象サーバー用に使用します。 |
次のコマンドをWCCHOST1で実行し、作成したテンプレート・ファイルをWCCHOST2にコピーします。
scp edgdomaintemplateScaleSOA.jar oracle@WCCHOST2:/ORACLE_COMMON_HOME/common/bin
次のように、unpack
コマンドをWCCHOST2で実行して、このテンプレートを管理対象サーバーのドメイン・ディレクトリに解凍します。
cd ORACLE_COMMON_HOME/common/bin ./unpack.sh -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name -template= edgdomaintemplateScaleSOA.jar -app_dir=ORACLE_BASE/admin/domain_name/mserver/applications
注意: ドメインおよびアプリケーションのディレクトリがすでに存在するホストでWLS_CPTnサーバーをスケール・アウトする場合は、 |
新しい管理対象サーバーにOracle SOA SuiteおよびUMSのJMSサーバーを作成します。
WebLogic Server管理コンソールを使用して、新しいSOAJMSServerの新しい永続ストアを作成し、SOAJMSFileStore_N
のような名前を付けます。このストアのパスを指定します。第4.3項「各種ディレクトリの推奨場所について」でお薦めしているように、これは共有記憶域上のディレクトリにします。
ORACLE_BASE/admin/domain_name/cluster_name/jms
Oracle SOA Suiteの新しいJMSサーバーを作成します(たとえば、SOAJMSServer_N)。SOAJMSFileStore_Nは、このJMSサーバーで使用します。SOAJMSServer_Nサーバーのターゲットとして、前述の手順で作成した管理対象サーバー(WLS_SOAn)を指定します。
新しいUMSJMSServerの新しい永続ストアを作成します(たとえば、UMSJMSFileStore_N
)。このストアのパスを指定します。第4.3項「各種ディレクトリの推奨場所について」でお薦めしているように、これは共有記憶域上のディレクトリにします。
ORACLE_BASE/admin/domain_name/cluster_name/jms
注意: 新しいUMS JMSサーバーのストアとして |
UMS用の新しいJMSサーバーを作成し、UMSJMSServer_N
などの名前を付けます。UMSJMSFileStore_N
は、このJMSサーバーで使用します。UMSJMSServer_Nサーバーのターゲットとして、前述の手順で作成した管理対象サーバー(WLS_SOAn)を指定します。
SOA JMSモジュールのサブデプロイメント・ターゲットを更新し、先ほど作成したSOA JMSサーバーを追加します。そのためには、WebLogic Server管理コンソールの左側の「ドメイン構造」ツリーで、「サービス」ノードを開き、「メッセージング」ノードを開きます。「JMSモジュール」をクリックします。「JMSモジュール」ページが表示されます。「SOAJMSModule」(表の「名前」列にハイパーリンクとして表示)をクリックします。SOAJMSModuleの「設定」ページが表示されます。「サブデプロイメント」タブを開きます。SOAJMSのサブデプロイメント・モジュールが表示されます。
注意: このサブデプロイメント・モジュール名は、 |
「SOAJMSServerXXXXXX」サブデプロイメントをクリックします。Oracle SOA Suiteの新しいJMSサーバーであるSOAJMSServer_Nをこのサブデプロイメントに追加します。「保存」をクリックします。
UMSJMSSystemResourceのサブデプロイメント・ターゲットを更新し、先ほど作成したUMS JMSサーバーを追加します。そのためには、WebLogic Server管理コンソールの左側の「ドメイン構造」ツリーで、「サービス」ノードを開き、「メッセージング」ノードを開きます。「JMSモジュール」をクリックします。「JMSモジュール」ページが表示されます。「UMSJMSSystemResource」(表の「名前」列にハイパーリンクとして表示)をクリックします。UMSJMSSystemResourceの「設定」ページが表示されます。「サブデプロイメント」タブを開きます。UMSJMSのサブデプロイメント・モジュールが表示されます。
注意: このサブデプロイメント・モジュール名は、 |
「UMSJMSServerXXXXXX」サブデプロイメントをクリックします。このサブデプロイメントに、UMSJMSServer_Nと呼ばれる、UMSの新しいJMSサーバーを追加します。「保存」をクリックします。
新しいサーバーのTx永続ストアを構成します。これは、共有記憶域に関する推奨事項で示されるとおり、他のノードから見える場所にする必要があります。(第4.3項「各種ディレクトリの推奨場所について」を参照)。
管理コンソールから、「サービス」タブにあるサーバー名(WLS_SOAn)を選択します。「デフォルト・ストア」の「ディレクトリ」に、デフォルトの永続ストアがデータ・ファイルを格納するフォルダのパスを入力します。
ORACLE_BASE/admin/domain_name/soa_cluster_name/tlogs
新しい管理対象サーバーのホスト名検証をまだ無効にしていない場合は、第9.4.5項「ホスト名検証の無効化」の手順に従って無効にします。
WLS_SOAn管理対象サーバーの起動および検証を可能にするには、事前にホスト名検証を無効にする必要があります。管理サーバーとWCCHOSTnのノード・マネージャとの通信用のサーバー証明書構成が完了したら、ホスト名検証を再度有効にできます。新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効にされている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されるため、これらの手順は不要です。
新しいノードでノード・マネージャを起動します。ノード・マネージャを起動するには、既存のノードの共有記憶域内にあるインストールを使用し、次のようにWCCHOSTnで新しいノードのホスト名をパラメータとして渡します。
WL_HOME/server/bin/startNodeManager.sh New_Node_IP
注意: 第7章にある「Oracle WebLogic Serverのインストールとミドルウェア・ホームの作成」で示されたパスを使用した場合は、 |
WebLogic Server管理コンソールで、新しい管理対象サーバーであるWLS_SOAnを起動し、稼働していることを確認します。
LBR上のアプリケーション(http://wccinternal.mycompany.com/soa-infra
)にアクセスしてWLS_SOAn管理対象サーバーをテストします。アプリケーションが機能している必要があります。
注意: トポロジ内のHTTPサーバーは、新たに追加したサーバーにリクエストをラウンド・ロビンする必要があります(リクエストによっては、クラスタ内のサーバー数に応じて新しいサーバーにヒットする必要がある場合もまれにあります)。Oracle HTTP Serverの |
新しく追加したサーバー用のサーバー移行を構成します。
注意: この新しいノードでは既存の共有記憶域インストールが使用されるため、このノードにはノード・マネージャが存在しています。また、サーバー移行用の環境(ネットマスク、インタフェース、wlsifconfigスクリプトのスーパーユーザー権限など)が構成済です。新しいOracle SOA Suite管理対象サーバーの浮動IPアドレスも、新しいノードにすでに存在します。 |
サーバー移行を構成する手順は次のとおりです。
WebLogicサーバーの管理コンソールにログインします。
「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」をクリックします。
「サーバーのサマリー」ページで、表の「名前」列にある移行を構成するサーバー名(ハイパーリンクで表示されている)をクリックします。
選択したサーバーの「設定」ページで、「移行」サブタブを開きます。
「移行の構成」セクションの「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右向き矢印をクリックします。
注意: マシンのうち、負荷が最も低いものを新しいサーバーの移行ターゲットとして指定します。このノードで追加の管理対象サーバーを維持するのに十分なリソースを確保できるように、必要なキャパシティ・プランニングをあらかじめ行ってください。 |
「サーバーの自動移行を有効化」オプションを選択します。これにより、ノード・マネージャが、障害の発生したサーバーをターゲット・ノード上で自動的に起動できるようになります。
「保存」をクリックします。
ノード・マネージャ、管理サーバーおよびサーバー移行が構成されているサーバーを再起動します。
まず、管理コンソールを使用して管理対象サーバーを停止します。
次に、ノード・マネージャと管理サーバーを再起動します(第9.4.5項「ホスト名検証の無効化」の手順11を参照)。
最後に、管理コンソールを使用して管理対象サーバーを再度起動します。
この新しいサーバー用のサーバー移行をテストします。移行をテストするには、新しいサーバーを追加したノードで次の手順を実行します。
WLS_SOAn管理対象サーバーを強制的に停止します。そのためには、管理対象サーバーのPIDに対してkill -9
pid
を実行します。ノードのPIDは次のコマンドで特定できます。
ps -ef | grep WLS_SOAn
ノード・マネージャ・コンソールに、WLS_SOAnの浮動IPアドレスが無効になったことを示すメッセージが表示されることを確認します。
ノード・マネージャがWLS_SOAnの2回目の再起動を試行するまで待機します。ノード・マネージャは30秒間待機してからこの再起動を試行します。
ノード・マネージャがサーバーを再起動したら、サーバーを再び停止します。サーバーが再びローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されるようになります。
注意: サーバーの移行後、そのサーバーを元のノードまたはマシンにフェイルオーバーするには、WebLogic Server管理コンソールから管理対象サーバーを停止し、再起動します。管理対象サーバーは、適切なノード・マネージャによって以前に割り当てられていたマシン上で起動されます。 |
ノードで障害が発生した場合は、管理サーバーを別のノードにフェイルオーバーできます。この項では、管理サーバーをWCCHOST1からWCCHOST2にフェイルオーバーする方法を説明します。
次の前提条件があることに留意してください。
管理サーバーを、任意のアドレスではなくADMINVHN上でリスニングするように構成します。第9.3項「WCCHOST1での構成ウィザードを使用したドメインの作成」の手順13を参照してください。
管理サーバーはWCCHOST1からWCCHOST2にフェイルオーバーされ、この2つのノードに次のIPアドレスがある。
WCCHOST1: 100.200.140.165
WCCHOST2: 100.200.140.205
ADMINVHN: 100.200.140.206
。これは管理サーバーを実行している場所の仮想IPアドレスであり、eth
X
:Y
に割り当てられています。
WCCHOST1での管理サーバーの実行場所であるドメイン・ディレクトリは共有記憶域にあり、WCCHOST2からもマウントされています。
第7章「エンタープライズ・デプロイメント用のソフトウェアのインストール」の説明のとおり、Oracle WebLogic ServerおよびOracle Fusion MiddlewareコンポーネントはWCCHOST2にインストールされています(つまり、WCCHOST1に存在するORACLE_HOME
およびMW_HOME
のパスをWCCHOST2でも使用できます)。
管理サーバーを別ノード(WCCHOST2)にフェイルオーバーする手順は次のとおりです。
管理サーバーが実行されている場合は停止します。
IPアドレスを第2ノードに移行します。
WCCHOST1上で次のコマンドをroot
権限で実行します(ここでは、X:YがADMINVHNで現在使用されているインタフェースになります)。
/sbin/ifconfig ethX:Y down
次のコマンドをWCCHOST2上で実行します。
/sbin/ifconfig interface:index IP_address netmask netmask
例:
/sbin/ifconfig eth0:1 100.200.140.206 netmask 255.255.255.0
注意: 使用するネットマスクとインタフェースは、WCCHOST2で使用可能なネットワーク構成と一致している必要があります。また、第4.3項「各種ディレクトリの推奨場所について」で説明するとおりの位置に、管理サーバー・アプリケーションのディレクトリがマウントされていることを確認してください。 |
次の例のとおり、arping
を使用してWCCHOST2のルーティング表を更新します。
/sbin/arping -q -U -c 3 -I eth0 100.200.140.206
WCCHOST2でノード・マネージャを起動するには、第9.4.2項「WCCHOST1でのノード・マネージャの起動」の説明に従います。
WCCHOST2上で管理サーバーを起動するには、第9.4.3項「WCCHOST1での管理サーバーの起動」の説明に従います。
次の方法でWCCHOST2上の管理サーバーにアクセスできることをテストします。
http://ADMINVHN:7001/console
でWebLogic Server管理コンソールにアクセスできることを確認します。
http://ADMINVHN:7001/em
でOracle Enterprise Manager Fusion Middleware Controlにアクセスできることを確認し、そのコンポーネントのステータスを確認します。
第9.5.5項「ロード・バランサを使用したアクセスの検証」と同様の手順を実行します。この目的は、WCCHOST2で稼動中の管理サーバーにアクセスできることを確認することにあります。
この手順により、管理サーバーをフェイルバックできることを確認します。すなわち、WCCHOST2では管理サーバーを停止し、WCCHOST1で再び管理サーバーを実行します。
ADMINVHNを元のWCCHOST1ノードに移行する手順は次のとおりです。
管理サーバーが起動されていないことを確認します。
次のコマンドをWCCHOST2上で実行します。
/sbin/ifconfig ethZ:N down
次のコマンドをWCCHOST1上で実行します。
/sbin/ifconfig ethX:Y 100.200.140.206 netmask 255.255.255.0
注意: 使用するネットマスクとインタフェースは、WCCHOST1で使用可能なネットワーク構成と一致している必要があります。 |
arping
を使用し、ルーティング表を更新します。次のコマンドをWCCHOST1から実行します。
/sbin/arping -q -U -c 3 -I ethZ 100.200.140.206
WCCHOST1上で管理サーバーを再度起動するには、第9.4.3項「WCCHOST1での管理サーバーの起動」の説明に従います。
http://ADMINVHN:7001/console
でWebLogic Server管理コンソールにアクセスできるかどうかテストします。
http://ADMINVHN:7001/em
でOracle Enterprise Manager Fusion Middleware Controlにアクセスできることを確認し、そのコンポーネントのステータスを確認します。
表19-2は、Oracle WebCenter Content 11gのエンタープライズ・デプロイメントのバックアップ対象である静的アーティファクトを示しています。
表19-2 Oracle WebCenter Content 11gのエンタープライズ・デプロイメントのバックアップ対象である静的アーティファクト
タイプ | ホスト | 場所 | 層 |
---|---|---|---|
Oracleホーム(DB) |
CUSTDBHOST1およびCUSTDBHOST2 |
ユーザー定義 |
データ層 |
Middlewareホーム(OHS) |
WEBHOST1およびWEBHOST2 |
|
Web層 |
Middlewareホーム(Oracle WebCenter ContentとOracle SOA SuiteのOracleホームも含まれます) |
WCCHOST1およびWCCHOST2* |
Oracle WebCenter ContentおよびOracle SOA SuiteのOracleホームも |
アプリケーション層 |
インストール関連ファイル |
|
N/A |
表19-3は、Oracle WebCenter Content 11gのエンタープライズ・デプロイメントのバックアップ対象であるランタイム・アーティファクトを示しています。
表19-3 Oracle WebCenter Content 11gのエンタープライズ・デプロイメントのバックアップ対象であるランタイム・アーティファクト
タイプ | ホスト | 場所 | 層 |
---|---|---|---|
アプリケーション・アーティファクト(EARおよびWARファイル) |
WCCHOST1およびWCCHOST2 |
アプリケーション・アーティファクトの場所を調べるには、管理コンソールですべてのデプロイメントを表示します。 |
アプリケーション層 |
Oracle WebCenter Contentランタイム・アーティファクト |
WCCHOST1またはWCCHOST2 |
|
アプリケーション層 |
Captureランタイム・アーティファクト |
WCCHOST1またはWCCHOST2 |
|
アプリケーション層 |
Oracle WebCenter Captureランタイム・アーティファクト |
WCCHOST1またはWCCHOST2 |
|
アプリケーション層 |
Oracle SOA Suiteランタイム・アーティファクト |
WCCHOST1またはWCCHOST2 |
|
アプリケーション層 |
Oracle WebCenter Content用にカスタマイズされた管理対象サーバーの構成 |
WCCHOST1またはWCCHOST2 |
および
|
アプリケーション層 |
Oracle SOA Suite用にカスタマイズされた管理対象サーバーの構成 |
WCCHOST1またはWCCHOST2 |
UMSを使用する場合: ( および
|
アプリケーション層 |
Oracle HTTP Serverインスタンス・ホーム |
WEBHOST1およびWEBHOST2 |
|
Web層 |
Oracle RACデータベース |
CUSTDBHOST1およびCUSTDBHOST2 |
ユーザー定義 |
データ層 |
Oracle Fusion Middlewareコンポーネントのバックアップとリカバリの詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。
本番エンタープライズ・デプロイメントでは、かなりの部分にファイアウォールが使用されています。データベース接続はファイアウォールを介して行われるため、データベース接続がタイムアウトしないようにファイアウォールを構成することをお薦めします。Oracle Real Application Clusters (RAC)の場合、データベース接続はOracle RACの仮想IPアドレスとデータベース・リスナー・ポートに対して行われます。このような接続がタイムアウトしないように、ファイアウォールが構成されている必要があります。そのように構成できない場合は、データベース・サーバー上のORACLE_HOME
/network/admin/sqlnet.ora
ファイルの*SQLNET.EXPIRE_TIME=n*
パラメータを設定してください。n
は分単位の数値です。この値を、ネットワーク・デバイス(つまりファイアウォール)の既知のタイムアウト値よりも小さくしてください。Oracle RACの場合、このパラメータをすべてのOracleホーム・ディレクトリで設定してください。
Imaging管理対象サーバーを構成した後でLDAPプロバイダを変更した場合は、Imagingセキュリティ表のグローバル・ユーザーID (GUID)は無効になります。Imagingは、外部LDAPプロバイダからGUIDをキャッシュしてローカルのセキュリティ表に格納し、そのIDを認証に使用します。WLSTコマンドまたはOracle Enterprise Manager Fusion Middleware Controlを使用して、Imagingセキュリティ表のGUID値をリフレッシュできます。
両方のLDAPプロバイダに存在するユーザーおよびグループに対してのみ、GUIDがリフレッシュされます。以前のLDAPからユーザーおよびグループに割り当てられたImaging権限は、新しいLDAPに一致するユーザーおよびグループにリフレッシュされます。ユーザーやグループが新しいLDAPプロバイダのユーザーやグループに一致しない場合、refreshIPMSecurity
はそのユーザーやグループを無視します。
注意: リフレッシュ中、対応する識別情報が見つからないユーザーまたはグループは無視されます。セキュリティに変更を加えると、無効なユーザーまたはグループがImagingデータベースから削除されます。 |
コマンド・ラインからGUID値をリフレッシュする場合は、Oracle WebLogic Scripting Tool (WLST)を使用できます。
WLSTを使用してImagingセキュリティ表のGUID値をリフレッシュするには、次の手順を実行します。
第9.4.3項「WCCHOST1での管理サーバーの起動」の説明に従って、Oracle WebLogic Serverドメインの管理サーバーを起動します。
Oracle WebLogic Server管理サーバーにログインします。
Oracle WebCenter Contentのホーム・ディレクトリMW_HOME
/
WCC_ORACLE_HOME
に移動します。
WLSTを呼び出します。
cd common/bin ./wlst.sh
WLSTコマンド・プロンプトで、次のコマンドを入力します。
wls:/offline> connect() Please enter your username :weblogic Please enter your password : XXXXXXXXXXXXX Please enter your server URL [t3://localhost:7001] :t3://host_name:16000 Connecting to t3://host_name:16000 with userid weblogic ... Successfully connected to Managed Server 'IPM_server1' that belongs to domain 'domainName'. Warning: An insecure protocol was used to connect to the server. To ensure on-the-wire security, the SSL port or Admin port should be used instead. wls:/domainName/serverConfig> listIPMConfig() <This is just to check that the connection is to the right Imaging server> wls:/domainName/serverConfig> refreshIPMSecurity() <This is the command that will refresh the GUIDs in the Security tables.> wls:/domainName/serverConfig> exit()
Imagingにログインして、ユーザーおよびグループのセキュリティを確認します。
MBeanを介してGUID値をリフレッシュする場合は、Fusion Middleware ControlのシステムMBeanブラウザを使用できます。
Fusion Middleware Controlを使用してImagingセキュリティ表のGUID値をリフレッシュするには、次の手順を実行します。
Fusion Middleware Controlにログインします。
左側のナビゲーション・ツリーでWebLogicドメイン、Oracle WebCenter Contentドメイン・フォルダ、IPM_Clusterの順に展開し、IPM_server1などImagingサーバーの名前を展開します。
右側で、「WebLogic Server」ドロップダウン・メニューをクリックし、「システムMBeanブラウザ」を選択します。
「システムMBeanブラウザ」ナビゲーション・ツリーで、「アプリケーション定義のMBean」、oracle.imaging、「サーバー: IPM_server1」、「cmd」の順に展開し、「cmd」をクリックします。
右側のrefreshIPMSecurityをクリックします。
「呼出し」ボタンを押します。
Imagingにログインして、ユーザーおよびグループのセキュリティを確認します。
初回インストール時、Oracle WebCenter ContentおよびImagingのWebサービスは、Oracle Web Service Manager (OWSM) のセキュリティ・ポリシーを適用せずに構成されています。セキュリティ・ポリシーが適用されていない場合、サービスは、HTTPの基本認証メカニズムを使用します。このメカニズムでは、ユーザーの資格証明(ユーザーIDおよびパスワード)は、WebサービスのHTTPメッセージ・ヘッダー内で送信されます。HTTP基本認証ではなく適切なOracle WSMポリシーを適用することをお薦めします。Oracle WebCenter ContentおよびImagingのWebサービスで使用するOracle WSMのセキュリティ・ポリシーを構成するには、Oracle Fusion Middleware Oracle WebCenter Content: Imagingの開発および『Oracle Fusion Middleware Oracle WebCenter Contentのインストールと構成』の手順に従います。
この項の項目は次のとおりです。
第19.13.1項「soa-infraアプリケーションにロード・バランサ経由でアクセスしたときに「ページが見つかりません」というエラーが発生する」
第19.13.2項「デプロイメント・フレームワークの問題が原因でsoa-infraアプリケーションの起動に失敗する(Coherence)」
第19.13.4項「データベース内の最大プロセス数に達したために、WebCenter Contentサーバー、Oracle SOA SuiteサーバーまたはImagingサーバーの起動に失敗する」
第19.13.7項「サーバー移行後にSOAサーバー、ImagingサーバーまたはCaptureサーバーがフェイルオーバーしない」
第19.13.8項「サーバー移行後にSOAサーバー、ImagingサーバーまたはCaptureサーバーにブラウザからアクセスできない」
第19.13.11項「Oracle Access Managerに対する変更をアクティブ化した後でユーザーが管理コンソールのホーム・ページにリダイレクトされる」
第19.13.16項「Oracle WebCenter Content管理対象サーバーのマスター・パスワードを再生成する」
第19.13.17項「WebLogic Server管理コンソールからログアウトしても、ユーザー・セッションが終了しない」
第19.13.20項「リモートでデプロイされたアプリケーションで使用するアップロード・ディレクトリおよびステージ・ディレクトリの変更」
問題: ロード・バランサのアドレスを使用してsoa-infraアプリケーションにアクセスしようとしたときに、404メッセージ(ページが見つかりません
)がWebブラウザに表示されます。このエラーは断続的に発生し、WebLogic Server管理コンソールではOracle SOA Suiteサーバーが「実行中」
と表示されます。
解決方法: Oracle SOA Suite管理対象サーバーが実行中であっても、そのサーバー内のアプリケーションの状態がActive
ではなく、Admin
やPrepared
である場合があります。Oracle SOA Suiteサーバーが実行中でも、soa-infraアプリケーションが使用不可になることもあります。管理コンソールの「デプロイメント」ページで、soa-infraアプリケーションの状態を調べてください。これが「アクティブ」
状態である必要があります。Oracle SOA Suiteサーバーの出力ログにsoa-infraアプリケーション関連のエラーがないことを確認し、管理コンソールの「デプロイメント」ページでsoa-infraアプリケーションを起動してください。
問題: デプロイメントのCoherence構成に対する変更を適用した後、soa-infraアプリケーションの起動に失敗します。Oracle SOA Suiteサーバーの出力ログには、次のように報告されます。
Cluster communication initialization failed. If you are using multicast, Please make sure multicast is enabled on your network and that there is no interference on the address in use. Please see the documentation for more details.
解決方法:
SOAコンポジットのクラスタ・デプロイメントに対してユニキャストではなくマルチキャストを使用する場合、前述のようなメッセージが表示されることがあります。その原因は、soa-infraアプリケーションの起動時(つまり、Oracle SOA Suiteが実行される管理対象サーバーの起動時)にマルチキャスト競合が発生したためです。このメッセージは、Oracle Coherenceがランタイム例外をスローしたときに生成されるもので、例外自体の詳細情報も含まれています。このようなメッセージが表示された場合、ネットワークのマルチキャスト構成を確認してください。マルチキャスト・アドレスに対してpingを実行できることを確認します。さらに、ネットワーク内の別の名前のクラスタが同じマルチキャスト・アドレスを使用しているかどうかを調べてください。このようなクラスタがあると、競合が発生してsoa-infraを起動できなくなることがあります。ネットワークでマルチキャストが有効化されていない場合、ユニキャストを使用するようにデプロイメント・フレームワークを変更してください。その方法については、『Oracle Coherence開発者ガイド』を参照してください。
ユニキャスト用の既知アドレス・リストをサーバー起動パラメータ内に入力するときは、ノードのローカル・ホストおよびクラスタ化されたサーバー用のアドレスが正しいことを確認してください。アドレスのいずれかが正しく解決されていない場合は、サーバーの出力ログに次のようなエラー・メッセージが報告されます。
oracle.integration.platform.blocks.deploy.CompositeDeploymentCoordinatorMessages errorUnableToStartCoherence
問題: ノード・マネージャのプロパティをstartScriptEnabled=true
に設定する前にOracle SOA Suiteサーバーを管理コンソールから起動しようとすると、失敗します。このプロパティを設定した後も、サーバーは起動しません。Oracle SOA Suiteサーバーの出力ログには、次のように報告されます。
SEVERE: <.> Unable to Encrypt data Unable to Encrypt data. Check installation/post-installation steps for errors. Check for errors during SOA server startup. ORABPEL-35010 . Unable to Encrypt data. Unable to Encrypt data. Check installation/post-installation steps for errors. Check for errors during SOA server startup. . at oracle.bpel.services.common.util.EncryptionService.encrypt(EncryptionService.java:56) ...
解決方法: クラスタ内の最初のOracle SOA Suiteサーバーの起動が失敗したためにポリシー移行が未完になります。正常に移行するには、次のようにsystem-jazn-data.xml
ファイル内の<jazn-policy>
要素を編集してbpm-services.jar
に権限を付与します。
<grant> <grantee> <codesource> <url>file:${oracle.home}/soa/modules/oracle.soa.workflow_11.1.1/bpm-services.jar</url> </codesource> </grantee> <permissions> <permission> <class>java.security.AllPermission</class> </permission> </permissions> </grant>
問題: WebCenter Contentサーバー、Oracle SOA SuiteサーバーまたはImagingサーバーの起動に失敗します。新しい管理対象サーバー・タイプ用にドメインが拡張されている(たとえば、Imaging用にWebCenter Contentを拡張)か、システムがスケール・アップ(同じタイプの新しいサーバーを追加)されています。WebCenter Contentサーバー、Oracle SOA SuiteサーバーまたはImagingサーバーの出力ログには、次の例外が報告されます。
<Warning> <JDBC> <BEA-001129> <Received exception while creating connection for pool "SOADataSource-rac0": Listener refused the connection with the following error: ORA-12516, TNS:listener could not find available handler with matching protocol stack >
解決方法: データベース内のプロセス数を確認し、それにあわせて調整します。SYSユーザーとして、SHOW PARAMETERコマンドを発行します。
SHOW PARAMETER processes
次のSQLコマンドを使用して初期化パラメータを設定します。
ALTER SYSTEM SET processes=300 SCOPE=SPFILE
データベースを再起動します。
注意: パラメータ値の変更に使用する方法は、パラメータが静的であるか動的であるかと、データベースがパラメータ・ファイルとサーバー・パラメータ・ファイルのどちらを使用するかによって異なります。パラメータ・ファイル、サーバー・パラメータ・ファイルおよびパラメータ値の変更方法の詳細は、Oracle Database管理者ガイドを参照してください。 |
問題: 管理サーバー・ノードに障害が発生して別のノードへの手動フェイルオーバーが実行された後で、管理サーバーの起動に失敗します。管理サーバーの出力ログには、次のように報告されます。
<Feb 19, 2009 3:43:05 AM PST> <Warning> <EmbeddedLDAP> <BEA-171520> <Could not obtain an exclusive lock for directory: ORACLE_BASE/admin/edg_domain/aserver/edg_domain/servers/AdminServer/data/ldap/ldapfiles. Waiting for 10 seconds and then retrying in case existing WebLogic Server is still shutting down.>
解決方法: ノードの障害発生後にノードを復旧させるときに、ドメイン・ディレクトリに共有記憶域が使用されている場合、ロック・クリーンアップの失敗が原因で、管理サーバーのログにこのエラーが記録されることがあります。このエラーを解決するには、ファイルORACLE_BASE
/admin/
domain_name
/aserver/
domain_name
/servers/AdminServer/data/ldap/ldapfiles/EmbeddedLDAP.lok
を削除します。
問題: サーバーの起動構成を変更した後で、管理コンソールで変更をアクティブ化しようとすると失敗します。「変更のアクティブ化」をクリックすると、管理コンソールに次のように表示されます。
An error occurred during activation of changes, please see the log for details. [Management:141190]The commit phase of the configuration update failed with an exception: In production mode, it's not allowed to set a clear text value to the property: PasswordEncrypted of ServerStartMBean
解決方法: これは、管理コンソールでサーバーの起動パラメータが変更された場合に発生する可能性があります。この場合、管理コンソールで、構成を変更した特定のサーバーのサーバー起動構成でユーザー名とパスワードの情報を指定します。
問題: ローカルのノード・マネージャによる再起動試行回数が最大数に達した後で、フェイルオーバー・ノードのノード・マネージャがサーバーの再起動を試行しますが、サーバーが起動しません。ノード・マネージャの出力情報には、サーバーがフェイルオーバーしたことが報告されます。ノード・マネージャがOracle SOA Suiteサーバー、Oracle WebCenter Content: ImagingサーバーまたはOracle WebCenter Captureサーバーの移行を試行した後でも、このサーバーが使用する仮想IPアドレスがフェイルオーバー・ノード内で有効になりません(フェイルオーバー・ノードでifconfig
を実行しても、どのインタフェースの仮想IPアドレスも報告されません)。コマンドsudo ifconfig $INTERFACE $ADDRESS $NETMASK
を実行しても、そのIPアドレスはフェイルオーバー・ノード内で有効になりません。
解決方法: sudo
実行時にパスワード入力を要求するような権限と構成を設定しないでください。パスワード入力を要求しなくてもsudo
が動作するようにsudo
が構成されていることを、システム管理者に確認してください。
問題: サーバー移行は正常に実行されます(Oracle SOA SuiteサーバーまたはOracle WebCenter Content: Imagingサーバーがフェイルオーバー・ノード内で再起動される)が、Virtual_Hostname
:8001/soa-infra
のURLにWebブラウザからアクセスできません。元のホストではすでにサーバーが強制終了されており、フェイルオーバー・ノードのノード・マネージャでは、仮想IPアドレスが移行済でサーバーが起動していることが報告されます。Oracle SOA Suiteサーバー、ImagingサーバーまたはCaptureサーバーが使用する仮想IPアドレスに対して、クライアントのノード(ブラウザが使用されているノード)からpingを実行しても応答がありません。
解決方法: arping
コマンドがノード・マネージャによって実行されてARPキャッシュが更新されましたが、この更新が適切にブロードキャストされていません。この場合、そのノードが外部ノードからは到達不能になります。nodemanager.propertiesファイルを更新してMACBroadcastを追加するか、次のように手動でarpingを実行してください。
/sbin/arping -b -q -c 3 -A -I INTERFACE ADDRESS > $NullDevice 2>&1
ここで、INTERFACEは、仮想IPアドレスが有効化されているネットワーク・インタフェース、ADDRESSは仮想IPアドレスです。
問題: OAM構成ツールを使用して、複数のURLをまとめてOracle Access Managerのポリシーに追加しました。しかし、そのURLの1つに誤記がありました。正しいURLを指定してOAM構成ツールをもう一度実行すると、処理は正常に完了しますが、ポリシー・マネージャには誤ったURLが依然として表示されます。
解決方法: 同じapp_domain
名を指定してOAM構成ツールを実行すると、既存ポリシーへの新しいURLの追加のみが行われます。特定のURLを削除するには、Oracle Access Managerのポリシー・マネージャ・コンソールを使用してください。Oracle Access Managerのアクセス管理サイトにログインして、「ポリシー・ドメイン」→「SOA_EDG」(作成済のポリシー・ドメイン)→「リソース」タブをクリックし、誤ったURLを削除します。
問題: WebLogic Server管理コンソールにアクセスするためにOHSおよびLBRを構成した後で、なんらかの変更のアクティブ化を行うと、管理コンソールのログイン画面にリダイレクトされます。
解決方法: これは、ユーザーがポート、チャネルおよびセキュリティの設定を変更するときに、コンソールがその変更を反映しようとすると発生します。変更内容によっては、コンソールが管理サーバーのリスニング・アドレスにリダイレクトされることがあります。このリダイレクトにかかわらず、アクティブ化は完了します。ユーザーは再度ログインする必要はなく、URLをwcc.mycompany.com/console/console.portal
に変更すれば、管理コンソールのホーム・ページに直接アクセスできます。
注意: この項で説明されている変更の追跡を無効にしてある場合は、この問題は発生しません。 |
問題: Oracle Access Managerを構成した後でなんらかの変更をアクティブ化すると、管理コンソールのホーム・ページにリダイレクトされるようになります(アクティブ化の実行場所であるコンテキスト・メニューには戻りません)。
解決方法: これは、Oracle Access Manager SSOが構成され、管理コンソールが構成の変更を反映するように設定されている場合に発生することが予想されます(リダイレクトはなんらかの変更をアクティブ化する際に管理コンソールによって実行されます)。このリダイレクトにかかわらず、アクティブ化は完了します。連続して変更を行ってもリダイレクトされないようにするには、管理コンソールにアクセスして、「プリファレンス」→「共有プリファレンス」を選択し、「構成変更の追跡」チェック・ボックスの選択を解除します。
問題: Javaオブジェクト・キャッシュ(OWSM管理対象サーバーなど)を使用している管理対象サーバーの起動に失敗します。次のエラーがログに表示されます。
J2EE JOC-058 distributed cache initialization failure J2EE JOC-043 base exception: J2EE JOC-803 unexpected EOF during read.
解決方法: JOCが取得しようとしているポートを別のプロセスが使用しています。そのプロセスを停止するか、このクラスタのJOCを再構成して、推奨されるポート範囲内で別のポートを使用するようにします。
問題: Oracle WebCenter Content: Imagingが、起動中に資格証明のアクセス権限を作成し、system-jazn-data.xml
ファイルのローカル・ドメイン・ディレクトリ・コピーを更新します。LDAPポリシー・ストアが構成されていない状態で環境をテストしている間に、Imagingサーバーの存在しているドメイン・ディレクトリに、system.jazn-data.xml
ファイルへの手動の更新を管理サーバーがプッシュする可能性があります。これによって、ファイルのコピーが上書きされたり、Imagingコンソールの再起動またはアクセス時に、様々な例外およびエラーが発生したりする可能性があります。
解決方法: 資格証明のアクセス権限を再作成し、管理サーバーにある、system-jazn-data.xml
ファイルのドメイン・ディレクトリ・コピーを更新するために、Oracle WebLogic Scripting ToolでgrantIPMCredAccess
コマンドを使用します。このためには、Oracle WebCenter Contentに関連付けられたORACLE_HOME
からwlst.sh
を起動して管理サーバーに接続し、WCCHOST1でgrantIPMCredAccess()
コマンドを実行します。
cd ORACLE_HOME/common/bin
./wlst.sh
wls:/offline> connect()
wls:/domain_name/serverConfig> grantIPMCredAccess()
注意: 接続時には、管理サーバー用の資格証明とアドレスを指定してください。 |
問題: ホスト名ベースのセキュリティ・フィルタがOracle WebCenter Content (config.cfg
ファイル)で使用されている場合、Oracle WebCenter Content: ImagingからOracle WebCenter Contentに情報量の多いドキュメントをアップロードする際に、大きな遅延とパフォーマンスへの影響がシステム内に発生する可能性があります。この問題の原因は、Imagingサーバーからの接続を許可するためにOracle WebCenter Contentで必要とされるDNSの逆引き参照です。
解決方法: 災害からの保護および異なるホストへのリストアのためにシステム構成を準備する場合、ホスト名ベースのセキュリティ・フィルタを使用することをお薦めします(ホスト名ベースのセキュリティ・フィルタ使用時は、使用される構成がIPにとらわれないものになるため)。ただし、アップロードのパフォーマンスを向上させる必要がある場合は、ホスト名ベースのフィルタのかわりにIPベースのセキュリティ・フィルタを使用できます。
Oracle WebCenter Contentでホスト名ベースのセキュリティ・フィルタをIPベースのフィルタに変更する手順は次のとおりです。
テキスト・エディタで、ORACLE_BASE
/admin/
domain_name
/
wcc_cluster_name
/cs/config/config.cfg
のファイルを開きます。
次の行を削除またはコメント・アウトします。
SocketHostNameSecurityFilter=localhost|localhost.mycompany.com|wcchost1vhn1|wcchost2vhn1 AlwaysReverseLookupForHost=Yes
WLS_CPT1およびWLS_CPT2管理対象サーバー(それぞれWCCHOST1VHN3およびWCCHOST2VHN3)のIPアドレス(リスニング・アドレス)をSocketHostAddressSecurityFilter
パラメータ・リストに追加します。
SocketHostAddressSecurityFilter=127.0.0.1|0:0:0:0:0:0:0:1|X.X.X.X|Y.Y.Y.Y
この例では、X.X.X.XおよびY.Y.Y.Yは、それぞれWLS_CPT1とWLS_CPT2のリスニング・アドレスです。(同様に、アドレス127.0.0.1がこのリストに含まれている必要があります。)
変更されたconfig.cfg
ファイルを保存しら、WebLogic Server管理コンソールを使用してOracle WebCenter Contentのサーバーを再起動し、変更を有効にします。
問題: 管理対象サーバーでメモリー不足が発生します。
解決方法: Java VMに割り当てられているメモリー・ヒープのサイズを少なくとも1GBに増やします。
Java VMに割り当てられているメモリー・ヒープのサイズを増やす手順は次のとおりです。
WebLogicサーバーの管理コンソールにログインします。
「環境」をクリックし、「サーバー」をクリックします。
管理対象サーバー名をクリックします。
「構成」タブを開きます。
2列目にある「サーバーの起動」タブを開きます。
「引数」ボックスでメモリー・パラメータを追加します。例:
-Xms256m -Xmx1024m -XX:CompileThreshold=8000 -XX:PermSize=128m -XX:MaxPermSize=1024m
注意: メモリー・パラメータ要件は、各種のJVM (Sun JDK、Oracle JRockitなど)ごとに異なる可能性があります。詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentのインストールと構成』の管理対象サーバーのJava VMヒープ・サイズの増加に関する項を参照してください。 |
構成の変更を保存します。
WebLogic Server管理コンソールを使用して、実行中のすべての管理対象サーバーを再起動します。
Oracle WebCenter Content管理対象サーバーのドメイン・ホームのcwallet.sso
ファイルが、クラスタ間で不整合を生じたり、ORACLE_BASE
/admin/
domain_name
/aserver/
domain_name
/config/fmwconfig/
ディレクトリにおける無効なコピーによってこのファイルが削除または誤って上書きされた場合は、ファイルを再生成できます。
Oracle WebCenter Content管理対象サーバーのマスター・パスワードを再生成する手順は次のとおりです。
すべてのOracle WebCenter Content管理対象サーバー(WLS_WCCx)を停止します。
ORACLE_BASE
/admin/
domain_name
/mserver/
domain_name
/config/fmwconfig/
のcwallet.sso
ファイルを削除します。
ORACLE_BASE
/admin/
domain_name
/aserver/
wcc_cluster_name
/cs/config/private
のpassword.hda
ファイルを削除します。
WCCHOST1でWLS_WCC1サーバーを起動します。
ORACLE_BASE
/admin/
domain_name
/aserver/
wcc_cluster_name
/cs/config/private/
にあるpassword.hda
ファイルの作成と同様に、ORACLE_BASE
/admin/
domain_name
/mserver/
domain_name
/config/fmwconfig/
にあるcwallet.sso
ファイルの作成または更新も検証します。
Oracle WebCenter Contentのシステム・プロパティのコマンドライン・ツールを使用して、データベースのパスワードを更新します。
スタンドアロンのOracle WebCenter Contentアプリケーション(Batchloader、システム・プロパティなど)が正しく機能しているか検証します。
cwallet.sso
ファイルをORACLE_BASE
/admin/
domain_name
/mserver/
domain_name
/config/fmwconfig/
から、ORACLE_BASE
/admin/
domain_name
/aserver/
domain_name
/config/fmwconfig/
の管理サーバーのドメイン・ディレクトリにコピーします。
2つ目のOracle WebCenter Content管理対象サーバーを起動し、更新されたcwallet.sso
ファイルを、管理サーバーがWCCHOST2におけるORACLE_BASE
/admin/
domain_name
/mserver/
domain_name
/config/fmwconfig/
にプッシュし、そのファイルがWCCHOST1上のOracle WebCenter Contentのサーバーによって作成または更新されたのと同じファイルであることを検証します。
スタンドアロンのOracle WebCenter Contentアプリケーション(Batchloader、システム・プロパティなど)が正しく機能しているか検証します。
スタンドアロンのOracle WebCenter Contentアプリケーションが両方のノードで同時に正しく機能することを検証します。
Oracle Access Managerのシングル・サインオン(SSO)を使用してWebLogic Serverの管理コンソールにログインする場合、ログアウトボタンをクリックしても、ユーザー・セッションが終了しません。これは、SSOのログアウトのガイドラインに従って、Oracle Access Managerログイン・ページにリダイレクトされるのではなく、ホームページがリロードされるからです。本当にログアウトするには、WebブラウザのCookieを手動で消去する必要があります。
問題: 次のトランザクション・タイムアウト・エラーがログに表示されます。
Internal Exception: java.sql.SQLException: Unexpected exception while enlisting XAConnection java.sql.SQLException: XA error: XAResource.XAER_NOTA start() failed on resource 'SOADataSource_soaedg_domain': XAER_NOTA : The XID is not valid
解決方法: トランザクション・タイムアウトの設定を確認し、JTAトランザクション・タイムアウトがDataSource XAトランザクション・タイムアウトよりも短くなっており、distributed_lock_timeout
よりも短くなっていることを(データベースで)確認します。
すぐに使用できる構成の場合、SOAデータ・ソースはXAタイムアウトに値を設定していません。Set XA Transaction Timeout
構成パラメータはWebLogic Server管理コンソールでは確認されません。この場合、データ・ソースは30
に設定されたドメインレベルのJTAタイムアウトを使用します。また、データベースのdistributed_lock_timeout
のデフォルト値は60
です。この結果、トランザクションにかかる時間がこれらの値よりも短いと想定されるシステムでは、SOA構成は正しく動作します。特定の操作に想定されるトランザクション時間に合せて、これらの値を調整します。
Oracle WebCenter Contentは、ファイルに対して固有のロック・メカニズムを使用するため、ファイル属性のキャッシュおよびクラスタ・ノードにより実行されるロックなしでファイルにアクセスする必要があります。ノードの1つがある状態のファイルにアクセスし、そのファイルがキャッシュされている場合、そのノードは別のノードがすでに実行しているプロセスの実行を試みる場合があります。または、特定のファイルがノード・クライアントの1つにロックされている場合、別のノードによるアクセスが妨げられる場合があります。ファイル共有でファイル属性のキャッシュを無効化すると、パフォーマンスに影響する可能性があります。よって、必要とされる特定のフォルダでのみキャッシュおよびロックを無効化することが重要です。たとえば、ネットワーク・ファイル・システム(NFS)を介して共有を作成している場合は、マウント・オプションでnoac
およびnolock
を使用します。
アプリケーションをリモートでデプロイした場合は、ドメインを作成しmserver
ディレクトリに解凍した後、upload
ディレクトリおよびstage
ディレクトリを絶対パスに更新する必要がある場合があります。絶対パスの名前により、リモートのデプロイメントの問題とステージ・モードを使用するデプロイメントの混乱を防ぐことができます。
これらのディレクトリに対するデフォルトのパス名は次のとおりです。
./servers/AdminServer/upload ./servers/server_name/stage